(1)、对于技术出身的项目经理，大多数追求尽善尽美效果，这样往往带来的结果是项目延期、客户怨言多、产品迟迟不能上线、开发团队身心疲惫，最后的结果是不言而喻的，项目over。

　　(2)、对于管理出身的项目经理，多数重视项目过程，无法控制项目在开展过程中存在的具体风险(比如技术的成熟度、人员分配、技术分工等等)，待项目不能如期上线时很难控制整体局面，最终造成项目over。

　　(3)、对于略懂技术又略懂管理的项目经理而言，上述两种情况都有可能发生。

　　综述我个人建议无论大型项目还是小型项目在管理过程中我们应该掌握如下方法，更好的应用到具体的项目实际进展中，达到项目的顺利上线，后期的圆满运行。

　　三个避免

　　一、避免自己管理的事情太多而显得杂乱无章、毫无层次：

　　大项目要好，小项目也罢都意味着需求变更，参与的人员变化，如何保证项目的进度，避免事情太多，需求点太多而导致最后项目失控，就是项目组加班加点做了大量的工作，最后却发现什么都没有做好，客户不认可，领导很焦虑，下属很失望，你很郁闷的局面。　　在项目进行过程中不可避免地会遇到很多提出的需求和修改意见，如何快速把握这些需求提出正确可行的解决方案是项目经理首先要考虑的事情。

　　别忘了项目合同上都是有时间限制的，如何在时间段之内完成项目而且完成得好就是关键。一味地否认抵制客户的需求当然不行，全盘照收只会让项目越变越大，项目组的人每日每夜地加班。

　　建议：

　　必须记录成文字性的文档，然后根据实际情况提出哪些现在做，哪些暂时不做，哪些到二期或三期工作时再考虑，并请他们确认。

　　这套方法很适用，希望对各位项目经理弟兄们在项目运营过程有实际的帮助。

　　二、我们要避免客户太多个性化、完美化的需求

　　这是pmp最头痛的事情，如果客户是大公司，那么文山会海肯定是没完没了，每个会议都要求得非常正规，而且客户看起来确实是很正规，相关的制度文档相关的人员以及部门级的经理都甚至高层的领导也会请到会议室来和你谈需求，每个经理都会有自己的部门的特点和需求，如何尊重他们的意见并保持自己的思路是非常重要的。笔者早期参加这样的会议时也一样很听客户的话，程序实现的过程中则是非常痛苦，经历过多次后，笔者建议各位项目经理要保证突出你们的专业知识和经验，不要被客户的职位所迷惑了，因为他们的经验很丰富，但在专业特别是软件方面你是专家，而且他们提出的是现实中各个部门的特点，并没有要求软件一定要实现。

　　建议：　　所以现场一定要记住，不要答应得太快，笔者后面就养成了一句口头禅，我们回去研究讨论后再确定。

　　三、避免人浮于事的现象

　　大公司都会有的现象，如何让你的项目组成员在项目进行过程中最大限度地减少这样的消耗是项目经理要关注的事。大公司踢皮球的现象大家都有所耳闻，所以做为项目经理的你能做就是如何做好事前的工作，避免出了问题后指责，到时你会发现没有人和这有关，都是你的错。所以少些抱怨，事前尽可能多做准备。笔者最常用的方法就是在需求说明书(实际工作中提出，非早期完整的需求说明书)中注明这是某某人提出的，以及我们的意见是什么，你别指望他会签字，一个需求点如果要等他确认签字你就等个两个星期吧。

　　四个注意

　　一、注意内部团结一致，互帮互助和高度的热情保证得项目快速往前推进。

　　项目小组的团结一致，这是基石，不论是在需求讨论分析，还是开发过程和项目内部测试，大家都团结一结，不断提出自己的看法一起交流，在最短时间内将问题细化和明确下来，大大缩短了开发周期。保持项目小组成员高度的热情使得项目讯速得到突破，达到了预期的要求，这是项目经理真正最重要的工作。在项目运作过程中，别忘记项目小组不是孤军奋战，背后还有整个公司的资源别忘了使用。

　　二、注意项目进度的严格控制

　　这是老生长谈的问题，核心还是《人月神话》，在现有的人手配置和资源上如何控制项目的进度，这是所有项目经理也是公司领导最关注的事情。因为大项目的进度要控制出了偏差，后期很多预想不到的事情会让你焦头烂额的。所以必要的会议还是要开，总结和安排工作是每周都必须要进行的工作，笔者当初是将工作总结工作安排和需求讨论严格分开的，即使是参加的人员一样。因为需求讨论需求分析有时是无底洞，有些实现起来是有难度的，这时在会议上一定要注意控制方向鼓励大家踊跃发言的同时要保证主题方向。因为需求的扩散和实现的难度将直接影响到项目的进度，很多项目最后失控追根结底相当一部分原因是需求没有把握住。笔者一同事负责的一个百万级的项目，超过签定合同时间的半年了还没有完成，公司后期调动了所有可调用的技术人员进入项目组，搞得人人疲惫，当初最大的原因就是客户的需求不断扩散导致程序开发无休止地进行。

　　三、注意搞好各方面的关系

　　项目经理首先要搞好的是你和你的领导的关系，特别是老板的关系，你要体会你的老板的心情，他是希望做成功大项目然后开始扩张，他的心里比你更关注项目的进展，要是出问题他心里比你更焦虑，所以记得要让你的老板参与到项目中来，别因为他不懂技术不懂项目管理就把他晾在一边。笔者的做法是每周都会将工作写成简单的总结发给上级领导，然后抄送给BOSS，有什么计划要执行或调整时预先做好书面材料发送给领导们，这时要忌讳的就是越级上报，所以这样的计划我一般是只发送我的直属上级，在MAIL中写到等计划正式拟定后请他转呈老总，大的事情一般是他都会在比你更期望的时间代你向老总汇报了，因为只有和老总搞好关系，他才会信任你，而且还会源源不断地支持你，不然一些公司接到一个大项目要失败了，公司搞不好就负债了，所以你要明白BOSS可能是将公司前途放在你身上。接下来就是要搞好下属的关系，他们是实现完成工作的核心和中流抵柱，平时要舍得花些银子请他们吃吃饭组织一些体育活动，程序员都是典型的亚健康状态，看看程序员那象怀胎三个月的肚子就知道了。再接着就是要搞好客户的关系了，除了言语上尊重他们外，必要的银子还是要花的，而且要花得有特色，因为他们聚餐也不少啊。所以大家明白我为何要将搞好和老总的关系放在第一位了吧，不然这些白花花的银子，老总不签字，项目再失败了，你赔了血本都不够啊!

　　四、注意项目验收的各个环节

　　这是大家都关心特别是老总最关心的问题了，有时你别看他表面上非常平静，一点都没有开心的样子，我的老总那天在去洗手间的路上就哼起了小曲，这是好几年都没有的事情。但是要达成这样的任务并不是象小项目那样双方有意向后谈一天就可以签字，大公司都有自己一套套的验收标准，如果按照他们那样的标准，你卖硬件都难，更不用说软件了，而且谁在这上面签了字以后出了问题谁就要负责，而且软件永远都没有100%没有问题的，你看微软还不是不断升级和发补丁包。如何采用让双方都能接受的方式签定验收合同就要求你平时就要做好准备，笔者一般是每个月都会有一个功能模块实现的清单请他们确认，要他们签字是不可能，笔者的做法是请他们指出哪些没有完成的或有意见的，这样日积月累下来，对方认可了你的工作，后面他个人这一关是可以通过了，后面一定是他的上级以及副总层层把关，记住这时谈的一定要是实现完成了哪些功能，对新需求的千万不能答应就改，可以放到后期，并在验收合同中注明哪些是新需求还没有完成的，层层把关让折磨你的性情考验你的耐性，两周之内要能签下字就算是顺利了。还有一点有过大项目经验的仁兄有没有注意到，项目验收签字的都是客户的最高层和最低层两三个人的名字一起签在上面，中间管理层做了许多幕后工作，所以在验收的过程中不要忘记向客户的每个上级多表扬一下项目中参与的他下属人员的业绩，当他们都是功臣时在最后一关卡住的机会会少很多。因为最后一关没有通过，所有的一切努力都是白搭!

　　最后，希望此篇文章对广大同行能有实际的帮助。