项目组在试运行即将结束的阶段，用户对两个比较大的模块提出改进意见，这就意味着项目组要多花至少半个月时间来重新做，面临正式运行的期限，项目延期几乎是必然的。项目已经完成过半，项目的期限马上就要到了，但是PM在日常绩效审核(绩效审核是反应项目组效率的非常客观直接的一种方式)中发现整个项目组制订的计划的执行越来越拖拉，原来一个星期内做好的事情，现在两个星期了还没有完成，这样下去，随时有项目失败的危险。
因为项目要延期，个别人在项目组里面担心自己的利益受损，在项目的比较关键的时刻怠工，以此作为筹码想让项目组满足他自己的一些私人利益，为了达到目的，曾经还与其它的相关成员进行了协商，这样很多项目组的成员也与他一道来对抗。根据上述内容进行了深刻的分析：分析一：项目组的每一个人都担心项目失败，这样肯定会很大程度上影响个人利益，而并不是对项目组的其他人有看法。项目发生变动以后，项目主管并没有及时的把部门和用户的真实用意与所有项目组成员及时沟通，导致大家纷纷猜测，并且很可能被一些别有用心的人利用了这种情绪。分析二：这里面也的确有个别别有用心的人为因素，这个问题一定的及早处理，否则它会搅得整个项目组不得安宁。
经过分析，找到问题根源，首先得解决沟通的问题。这包括与用户、部门领导、项目组成员之间的沟通。
1)PM(PM培训)与最终用户沟通：把用户的更改要求和我们的理解与用户进行了更加细致的沟通确认，让用户认识到我们非常在意他们的意愿，但是按照原来的方案更改的话，项目正式运行时间至少要延期半个月，其实这个风险对用户方的影响也很大，最终项目组与用户达成了折中的方案：项目组在正式运行的时候，只是更改那些工作量不是非常大的但是不解决无法让用户方领导满意的问题，而对于其它的问题，都放在正式运行之后一直到验收这段时间来完成。其实，当时用户并没有想得非常多，只是想尽量尽早的把所有的工作提前做完，也并没有认真考虑到很多工作需要耗费大量的时间和精力而导致整个项目拖延而影响到他们自己，而这些工作大部分并不是那么要紧。经过第一次沟通以后，项目组成员对于项目的问题和期限有了更加清晰的认识，已经能够感觉到其实用户并非是故意难为项目组，项目即使延期，对项目整体的影响并不大。
2)PM与部门领导沟通：把项目需求变更可能导致延期的问题和原因进行了汇报，随即在项目例会中，部门领导对项目组的整体成绩给予了肯定，对项目组的优秀人员给予了口头表彰，对个别的非常懈怠的员工也提出了一定的批评。终于，项目组内部的种种猜疑都基本上结束了，用户方和部门内部对于项目的问题都有了比较清楚的认识，项目组的成员也都明白：项目虽然有困难，但是还是会成功结束的，每一个人的利益其实并不受什么影响。