经过近半年的跟踪后，今年元旦，销售部门与某银行签订了一个银行前置机的软件系统的项目，合同规定，5月1日之前系统必需完成，并且进行试运行。在合同鉴定后，销售部门将此合同移交给了软件开发部，进行项目的实施。

王伟被指定为这个项目的项目经理，王伟做过5年的金融系统的应用软件研发工作，有较丰富的经验，可以作系统分析员，系统设计，但作为项目经理还是第一次。另外项目组还有另外4名成员， 1个系统分析员（含项目经理），2个有1年工作经验的程序员，1个技术专家（不太熟悉业务）。项目组的成员均全程参加项目。

在被指定负责这个项目后，王伟制定了项目的进度计划，简单描述如下为：

1) 1月10日～2月1日需求分析

2) 2月1日～2月25日系统设计，包括概要设计和详细设计

3) 2月26日～4月1日编码

4) 4月2日～4月30日系统测试

5) 5月1日试运行

但在2月17日王伟检查工作时发现详细设计刚刚开始，2月25日肯定完不成系统设计，您建议王伟应该如何做？他在项目的管理中有问题吗？

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

题目：处理的办法

分析：淡定，再淡定，然后分析延期的原因，冷静的解决

题目：软件项目延期

分析：压缩编码时间，和测试时间合并。

抓紧时间完成可靠的详细设计。

题目：软件项目延期，怎么办？的分析

分析：1,压缩后面进度时间

2，向客户正确更多的项目时间

3，流水线式编程，把软件分模块，各模块独立开始详细设计、编码、测试，然后在集成测试。加快时间。

题目：软件项目延期，怎么办

分析：重新制定项目计划，并随时根据项目进度调整计划

题目：软件进度规划

分析：计划没有变化快，随机应变才是正道。

若软件延期，可先安排硬件贴片及组装，最后下载软件。

题目：新手试着分析一下

分析：建议

1.分析目前情况，提出项目进度计划变更申请

2.根据wbs，以工作包为单位分别执行

3.申请更多资源（技术人员，投入时间等）

问题

1.监控失职

2.计划不是渐进明细，与实际情况不符时，应及时采取纠偏措施

分析：延期前：

1、5月1日这个日期是如何定下的？定期Deadline之前是否考虑了公司的研发资源/力量？

2、项目开始前是否做过风险分析？进度是否是该项目的风险？

3、项目是否有例会？例会的频度是否与项目的周期相匹配？例会的议程是否包含对目前项目面临的问题/风险的跟踪？

4、项目组的组成：项目经理同时又是系统分析员。项目经理应该懂业务，最好不要当系统分析员，不然会陷入技术细节纠缠不清。

5、项目计划是怎么做出来的？是否经过工作量的详细估计？是谁估计的？应该由具体执行人员估计，再加上技术专家的意见。

6、是否识别出了关键路径？是否对关键任务进行了重点监控？

7、项目的人力资源是如何获取的？是否与该项目的难度、进度相匹配？资源的数量是如何确定的？是根据工作量确定的吗？

题目：常见现象

分析：虽然王伟第一次做项目经理，但仅从本文描述来看，并不能完全断定王伟的管理有问题：

1、阶段性的时间延迟是常有的事，资深的项目经理也不能完全控制每个阶段一定遵循预定时间

2、对于需求不明确、业务背景复杂的项目，适当延长需求分析的时间，有利于保证后期设计的准确性和减少需求变更的幅度和次数

3、需求分析是与客户共同开展的，你所做的工作、所花费的时间，客户是有目共睹的，是能够容忍的

4、延误的时间只有从后面几个阶段中挤出来，例如编码和测试同步进行等

5、万不得已，由于客户原因导致项目延期，适当延长工期，是必不可少的，总比开发成果与客户预期相悖要好

分析：问题：

1。计划没有依据。完全根据客户的要求来划分计划。比如用户要求在5个月内完成。那么需求30％就是1。5个月。没有根据实际情况来定计划。计划应该是在所有任务进行细化的情况下做出来的。

2。检查工作周期太长，发现问题已无法挽救，造成比较大的损失。

解决办法：

1。首先通知客户、领导项目的情况。做好延期准备。

2。慎重考虑是否增加人手，一般情况下不要。

3。适当加班（过多则导致工作效率下降）

题目：这样如何

分析：1。争取延长时间

2。争取3。1完成详细设计。

3。压缩编码时间。并加强单元模块测试。

题目：同情王春龙——遭遇一样

分析：简述：

1 计划欠周详，需求分析与系统设计合并；测试不需要这么长。

2 人员分配，系统分析员负责整体，专家负责可行性，程序员辅助。自己协调检查沟通，为成员服务。

3 制定补救计划，合理分配时间。（时间应该够）

4 与市场部沟通，实情相告，但不必通知客户，因为时间还早。

延期后：

1、重新进行工作量估计，在保证5月1日的前提下，调整内部阶段点。既然详细设计已经延期，就干脆再把该阶段放宽一点，写得详细一点，减少编码阶段的困难与周期。

2、要有周例会，进行风险管理。对有延期风险的模块至少应半周一汇报，甚至做非正式的日报。关键要汇报问题和风险。

3、要注意“问题升级”，PM协调不了的问题不要拖，及时向上司汇报。

4、谨慎地增加资源：并不是加人就管用，不然就不会有《人月神话》这本书了。在目前阶段（详细设计），还是可以考虑加人的。关键是加什么样的人，一定要是“熟练工”。

5、传统方法：对关键任务进行分解，是否可以并行执行？

6、加强时间管理，有效利用时间。

7、用企业文化/政策协助项目管理：是否可以要求加班或搞封闭式开发？

8、如实在保证不了进度，就要和客户协商了。注意：千万不要用牺牲质量来满足进度，要有一个平衡点。要看到公司的长期利益。

分析：5个人的一个小团队，到了2月17号才发现详细设计刚刚开始，王伟平时在干什么？作为项目经理我认为他严重失职。

从案例上看这份进度计划太粗，5个人的团队，5个月的工期，计划应该可以做得很详细，一旦详细需求分析结束，关于需求的、技术的很多风险应该就能标识出来，同时根据团队人员的技术情况，应该可以基本判断出项目实施的可能性，会存在哪些问题，而不用等到事到临头才发现。