软考信息系统实施项目经理经验总结

怎么样做好项目计划

首先是找几个关键组员， 比如客户业务专家、系统分析员等等，做一下项目模块划分工作。项目分成几块去做， 每一块完成什么，模块之间的信息如何交换等。

这里要强调一点：完成一个目标有很多种方式，你要选一种你最熟悉的，而不是看上去最完美的，这个思路会让你的项目减少很多风险。

采用一个计划会让你的工作更加明确，比如用微软的Project 软件，你填写完表格以后，就可以知道这个项目有多少件事情要做，每件事情需要什么资源，他们之间的前后关系如何，消耗的时间有多长，完成后有什么标志等。

所有的结果最后用一个叫做甘特图的形式表现出来。你做完这个表以后会惊奇地发现，甘特图上项目的结束时间会远远落后于你的计划结束时间。

项目实施阶段

进入这个阶段反而是项目经理比较空闲的时候，不像前期的时候项目经理要像记者一样到处和不同的人接触，搞清楚他们在说什么，努力猜测他们在想什么和他们的真正目的，那才是最累人的事情。

项目经理这段时间的主要工作是保持和客户领导以及自己领导的沟通。和客户领导沟通时特别要注意，除非你需要对方给你支持，那么你需要讲得具体一点，否则，告诉他一切正常就可以了，而且态度要积极一些，千万不要说一些领导不懂的细节。

和组员开会， 除了一些项目进度跟踪会议以外， 还有很多讨论会， 需要大家用头脑风暴方法给出解决问题。

与会人员很多都是技术人员，他们的特点是注重细节、缺乏大局观、有点消极悲观、自尊心强(如果总结得不对，欢迎大家拍砖) ，所以，你作为会议的主持人，只要负责提出问题和记录下他们的观点，千万不要做评判者的角色。

一个问题，有很多方面，从不同的角度看，现象是完全不同的，想想盲人摸象的故事吧。这些技术人员，他们往往精通一个方面，就自己的角度发表见解，除非一些很特别的情况，你都应该认为， 他们提出的方案， 从他们的角度来看是最合理的。

你的长处是掌握事情的优先级，评估各个方面的轻重缓急，从而根据他们的意见得出一个合适的(而不是正确的)方案。

所以， 在会议上， 你要充分尊重每一个人和他的意见， 夸奖那些意见提得比较好的人，千万不要把会议带入无休止的争论。

会后，你自己写文档，做决定。会议上大家的面子都被照顾了，自己实施起来的阻力就小， 如果还有意见的，你就私下找他聊， 如果还不能说服他， 你就要让他明白，因为你负责这个项目、你担当风险，所以，这个优先级应该你来判断。

组织中的高层，并不见得水平会比一般的成员高，但是，他要承担组织的风险，加之信息的不对称性，所以，对事情的优先级的判断肯定比下属强。

终可交付成果一定要是可以被检查的，比如， 【界面要求：美观大方、简洁明快】。

时刻考虑如何检查结果、如何向客户交付是项目经理一直要注意的事情。

需求变更

变更通常分为两种：

一种是部分更改了原先的目标，即需求变更。

另一种是没改变目标，但是客户不满意目前的实现方式，大到流程的实现，小到界面的布局， 都是属于这类。

碰到这种情况是难以避免的， 主要是事先沟通的不够充分和客户随着项目的进展， 慢慢想清楚了问题， 改变了以前的思路。

这时候，如果需要改并且你的战略是容许这种情况的，那么注意下面几点：

1、确保以前的文档，就是记载着以前的结论的东西，客户是否签过字，如果没有，赶紧把你的工作停下来，赶快再和客户自己确认一下你的方案，然后让他签字，避免以后说话没有凭据。

2、和客户坐下来，

项目验收

所谓验收，就是我按照测试文档的测试用例跑一遍， 结果和预期结果一致就应该算通过了， 而且还容许有一些小错误留在验收后改正，他可以对测试用例提意见。

所以，验收前双方要确认测试计划和测试用例。如果他认为系统不符合要求，那么他应该举证，证明这个系统和最初设计相背离的。所以，参考法律概念，千万不要举证倒置。

另外，认为系统完美了才能验收的想法也是错误的，软件开发合同里一定要注明验收以后维护期的费用问题，否则，客户担心一旦验收就得不到你们的支持，自然不配合验收，那么，你这个项目经理就很难交功课了。