该帖子同步发自：(牛草草的博客  访问该博客)

　　项目已经完成过半，项目的期限马上就要到了，但是PM在日常绩效审核(绩效审核是反应项目组效率的非常客观直接的一种方式)中发现整个项目组制订的计划的执行越来越拖拉，原来一个星期内做好的事情，现在两个星期了还没有完成，这样下去，随时有项目失败的危险

　　1.项目很可能要延期。项目组在试运行即将结束的阶段，用户对两个比较大的模块提出改进意见，这就意味着项目组要多花至少半个月时间来重新做，面临正式运行的期限，项目延期几乎是必然的。

　　2.个别人怠工。因为项目要延期，个别人在项目组里面担心自己的利益受损，在项目的比较关键的时刻怠工，以此作为筹码想让项目组满足他自己的一些私人利益，为了达到目的，曾经还与其它的相关成员进行了协商，这样很多项目组的成员也与他一道来对抗。根据上述内容进行了深刻的分析：分析一：项目组的每一个人都担心项目失败，这样肯定会很大程度上影响个人利益，而并不是对项目组的其他人有看法。项目发生变动以后，项目主管并没有及时的把部门和用户的真实用意与所有项目组成员及时沟通，导致大家纷纷猜测，并且很可能被一些别有用心的人利用了这种情绪。分析二：这里面也的确有个别别有用心的人为因素，这个问题一定的及早处理，否则它会搅得整个项目组不得安宁。

　　经过分析，找到问题根源，首先得解决沟通的问题。这包括与用户、部门领导、项目组成员之间的沟通。

　　1)PM与最终用户沟通：把用户的更改要求和我们的理解与用户进行了更加细致的沟通确认，让用户认识到我们非常在意他们的意愿，但是按照原来的方案更改的话，项目正式运行时间至少要延期半个月，其实这个风险对用户方的影响也很大，最终项目组与用户达成了折中的方案：项目组在正式运行的时候，只是更改那些工作量不是非常大的但是不解决无法让用户方领导满意的问题，而对于其它的问题，都放在正式运行之后一直到验收这段时间来完成。其实，当时用户并没有想得非常多，只是想尽量尽早的把所有的工作提前做完，也并没有认真考虑到很多工作需要耗费大量的时间和精力而导致整个项目拖延而影响到他们自己，而这些工作大部分并不是那么要紧。经过第一次沟通以后，项目组成员对于项目的问题和期限有了更加清晰的认识，已经能够感觉到其实用户并非是故意难为项目组，项目即使延期，对项目整体的影响并不大。

　　2)PM与部门领导沟通：把项目需求变更可能导致延期的问题和原因进行了汇报，随即在项目例会中，部门领导对项目组的整体成绩给予了肯定，对项目组的优秀人员给予了口头表彰，对个别的非常懈怠的员工也提出了一定的批评。终于，项目组内部的种种猜疑都基本上结束了，用户方和部门内部对于项目的问题都有了比较清楚的认识，项目组的成员也都明白：项目虽然有困难，但是还是会成功结束的，每一个人的利益其实并不受什么影响。

　　3)PM与项目组内部沟通：沟通的问题解决以后，还是有个别涣散军心的人继续做一些对项目不利的事情。但是这个人在项目组中又比较重要，如果轻易的在项目组中去除，很多比较关键的工作就没有人负责了。为了避免这个人笼络更多的人，最后掌握更多的要害来要挟项目组而造成更坏的结果，当时在项目组中专门制定了“代码同行评审”的制度，每天抽出一点时间对于项目中比较共性的设计、代码进行相互评审，这也是一个相互学习的过程，对于表现比较好的个人记入绩效，予以表彰。这不但让每个人都有更多机会了解学习他人，也给每个人提供了更加好的展示自己的舞台，大大激发了大家学习进取的积极性。这样不但更好的保证设计与编码的一致性以及好的设计、代码的复用性，而且大大降低了个别人的变动对整个项目组的影响。然后项目组决定把涣散军心的人的地位抬高到系统设计师的地位，而把具体的工作不断的拆分给那些比较好学的其它人员手中。果然，当项目后期这个人离开的时候，项目组中的其它两个人已经可以接手他的工作了。