某软件项目工程延期的处理案例
某公司是一家专门从事系统集成和应用软件开发的公司，公司目前有员工50多人，公司有销售部、软件开发部、系统网络部等业务部门，其中销售部主要负责进行公司服务和产品的销售工作，他们会将公司现有的产品推销给客户，同时也会根据客户的具体需要，承接应用软件的研发项目，然后将此项目移交给软件开发部，进行软件的研发工作。软件开发部共有开发人员有18人，主要是进行软件产品的研发，及客户应用软件的开发。
经过近半年的跟踪后，今年元旦，销售部门与某银行签订了一个银行前置机的软件系统的项目，合同规定，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日肯定完不成系统设计，您建议王伟应该如何做？他在项目的管理中有问题吗？
分析列表：
题目：项目在2.1完成需求分析 作者：forgiveme (moto ltd. wuweihua@sina.com.cn)
项目在2.1完成需求分析，在设置检查点的时候，在此是否应该考虑有个点；在项目计划中应该对项目的关键路径进行设置，并依据此路径设置必要检查点。
问题既然已经发生，5.1已成为必定的时间，那么，首先必须对原因进行分析，在之基础之上再进行重新构建，我会考虑对项目范围作些调整，也会作些相应的加班
题目：否有例会 作者：forgiveme (moto ltd. wuweihua@sina.com.cn)
延期前：
1、5月1日这个日期是如何定下的？定期Deadline之前是否考虑了公司的研发资源/力量？
2、项目开始前是否做过风险分析？进度是否是该项目的风险？
3、项目是否有例会？例会的频度是否与项目的周期相匹配？例会的议程是否包含对目前项目面临的问题/风险的跟踪？
4、项目组的组成：项目经理同时又是系统分析员。项目经理应该懂业务，最好不要当系统分析员，不然会陷入技术细节纠缠不清。
5、项目计划是怎么做出来的？是否经过工作量的详细估计？是谁估计的？应该由具体执行人员估计，再加上技术专家的意见。
6、是否识别出了关键路径？是否对关键任务进行了重点监控？
7、项目的人力资源是如何获取的？是否与该项目的难度、进度相匹配？资源的数量是如何确定的？是根据工作量确定的吗？
题目：计划调整是必须的 作者：寇震 (中铁十八局集团 18kz@vip.sina.com)
软件开发计划包含了需求分析，这是造成开发计划不准确的最大风险来源，我们的开发计划必须是根据需求分析后，进行工作分解得到的，而我们通常都不能这么做。我认为需求分析后，再次进行计划调整变更，确定项目的最终时间表，并和领导、客户沟通是最可靠的。
题目：常见现象 作者：李子军 (北京诺德信科技开发有限公司 zijun.li@nordsan.com)
虽然王伟第一次做项目经理，但仅从本文描述来看，并不能完全断定王伟的管理有问题：
1、阶段性的时间延迟是常有的事，资深的项目经理也不能完全控制每个阶段一定遵循预定时间
2、对于需求不明确、业务背景复杂的项目，适当延长需求分析的时间，有利于保证后期设计的准确性和减少需求变更的幅度和次数
3、需求分析是与客户共同开展的，你所做的工作、所花费的时间，客户是有目共睹的，是能够容忍的
4、延误的时间只有从后面几个阶段中挤出来，例如编码和测试同步进行等
5、万不得已，由于客户原因导致项目延期，适当延长工期，是必不可少的，总比开发成果与客户预期相悖要好
为政府实施电子政务项目的案例
公司A是市政府背景很强的股份制企业，机制比较灵活（shanghai），目前该公司的正在进行的一个项目是政府机关的一个Mis系统，现在整个开发全部完成，系统已经试运行2个月左右，目前运行情况比较顺利，但是，目前有几个比较大的问题如下：
1. 客户同公司关系特别密切（毕竟客户是机关），不能完全按照合同进展。
2.政府的工作节奏比较慢，在项目实施进程中，严重单方面拖延实施进度，造成项目延期。（他们很小的项目决定需要开会讨论）
3.不可预测的项目变更风险（机关领导一句话，项目经理就要处理变更需求；可称其为领导人风险）。
4.客户没有项目周期（软件项目）等认识，对合同规定的验收不予回应。这个需要该公司老总才能协调。（项目经理没有这方面的权利）
项目经理在项目组中本来负责软件开发设计，开发后期被部门经理任命为项目主管，对于客户主关需求变更，项目管理目前沟通的比较好。但对于一些政策性的变更，则非常的难处理（需要必须改动），没办法，只有进行变更处理。该公司应该怎么才能结束该项目呢。
分析列表：
题目：维护方式 作者：丁丁 (m ccdingr@hotmail.com)
客户是政府机关，单位机制。不太适应常规的市场经济运营方式。那就软件公司适应客户吧。
1、列举重要的指标点，让客户确认。
2、在合适的时间点，把项目由开发阶段过渡到稳定维护阶段。而且可以收取所谓的验收费用（运作～～）
3、抽出原班人马，稳定一个阶段后，指定个人，就在现在做维护和简单开发（不限期），也是保持良好的客户关系，和公司名誉。
题目：分析干系人 作者：张清俭 (大连 zqjcep@vip.sina.com)
这是中国现阶段制度决定的。在接政府的项目时，干系人分析显得异常重要，一定要有风险分析和应对计划，管理储备的比例也要增加，同时项目经理的沟通时间提高到95%。
题目：服务客户，培养人才 作者：贺炜 (西北工业大学 ishewei@163.com)
以前我们也曾接手这样的两个政府信息化项目，最终通过为对方培养人才脱手的。最后项目完成后一个月，还偶尔要求我们过去，后来就完全由我们培养的政府自己的技术人员接手了。
题目：电子政务实施中的服务意识 作者：冷酷到底 (EXOA exoa2002@163.com)
电子政务建设必须经历“从无到有，从有到好”的过程，所以我们在事实电子政务的时候也必须向用户灌输一个这样的理念，明白电子政务的建设需要过程需要时间，如果达成一个这样的共识的话项目的实施相对来说风险会小的很多，所以晓川先生分析的非常的精辟，但是电子政务建设出现了“用而不验”或“验而不用”那就是项目组的悲哀，所以实施电子政务项目必须要树立一个服务意识，项目靠服务产生利润，而不是单纯的靠产品产生利润！政府向企业买产品，也要买服务。项目应该将设计和实施划分开来，明确设计和实施的区别和界定，这样项目作的轻松，政府用的放心，用户当然也是开心了（特别是领导，电子政务是很大的业绩），总结一句电子政务项目实施要企业要作好定位，服务才是最能产生利润的。
题目：关系与商务不能等同 作者：陈荣森 (深圳市佳创 meid998@21cn.com)
与客户关系亲密固然是好事，但不能等同于在做项目时都事事迁就于客户，朋友是朋友，商务是商务，不能等同，否则会陷入很被动的局面。建议：
如果客户领导提出变更的想法，你不好意思明说，但你必须每次都向他列举这样的变更会给系统带来很大的变更和变更的困难，以便给提出变更的客户压力，随着压力的积累，客户再次提变更时会有压力而变得谨慎。
题目：如何实施电子政务项目 作者：石灵 (SIM shilingchen@sina.com.cn)
我同意晓川先生的说法。在我国的行政机构中存在的两个突出问题就是领导意志和作风拖沓。相信在短期内这一现象难以消除。因此，阶段目标的制定就变得非常重要。管理水平的提高，往往不在于某项重大制度的变革，而是基于许多细微的、渐进的变化。因此，在进行阶段目标的设定时，要首先提供让政府各级部门感到方便的功能，使他们逐渐具有兴趣，从而形成一种良性循环，其过程如同微软公司的软件发布一样。
我们做的是一个财务管理软件，在项目初期我们的项目经理做的售前工作，跟客户了解了大体的需求，并且制定了项目方案，而项目方案是一个很笼统的框架性的东西，而我被指派与客户详细的调研需求，整个项目的与客户面对面接触调研需求共3次，第一次我已完全理解客户的需求和意图，而第二次并没有什么实质性的收获，因为客户给我的时间就很少，我们只简单讨论了与客户现存系统的接口问题，第三次谈需求，客户提出了一些需求而针对他的子系统的结构是很难实现的，当时我极力反对，但反对无效，因为我们的客户分两部分：转包客户、最终客户。
这还是个二包项目。而这种很难实现的需求是最终客户提出而转包客户不反对反倒支持。这样三次需求调研的结果就是得到一个业务逻辑异常复杂的业务模型。有了详细的业务模型之后，我很快初步估算出代码最少5万行，并且向项目总监通报了情况，但是项目总监认为项目不可能这么简单，也没去与客户沟通。
我只好按着这个需求继续往下进行（当我与客户做二次需求调研时，我就已经变为项目经理的角色，当然此时我就是项目经理了，而原来的项目经理就是现在的项目总监了），当然了，在有了详细业务模型后，我们先设计了软件原型，用了两个星期，这阶段解决了几乎所有的界面组件（有很强的通用性）。然后再与客户讨论原型，不过客户那边的反映很迟缓，光让他确认这个原型就浪费了二十天时间，不过这段时间我也没闲着，开始着想考虑他那个难缠的需求是不是有什么解决方法，结果分析来分析去，最终得出结论，根本不存在什么合适的解决方案，而这块需求倒底做不做一直困惑我很长时间，其实与客户沟通很不方便，因为我们开发的地点与客户不在一个城市里，对于这样的问题我跟客户在msn上沟通过多次，客户都不明白我要说的问题的本质是什么，他还是坚持要实现这个需求，结果为此我又努力偿试寻找解决方案。
客户催要一个初步的软件版本，因为但是因业务逻辑的核心问题，我们无法进行业务模块的编码，已经完成的是与业务关系不大的部分。而此时我又进一步估算，代码量应该有8万行了，因为更细致的架构接口已经有了，也就是说一个完整的框架都有了，估算出的代码行数就比较准了。
8万行代码远远超出了原来的预算，就是去掉与客户不断的争论业务需求的时间都用来写代码，8万行代码也不是这个费用够用的，目前我处在骑虎难下的境地，公司要求我能拿出有利于我们有说服力的证据来，但事实上，客户除了那个比较难缠的需求外，没有更多多余的需求，而我也只对需求做了一些润色，我觉得这是很有必要的，去掉反倒不妥，并没有增加多余的需求。但就是这样的需求完成他确实需要写8万行代码，如果去掉业务员的功能，我想能精减个一万行代码。那还有7万呢啊。
公司要求我在尽可能短的时间内先完成一些基本的功能，但我不知道应该如何划分基本功能，在我看来，这些功能都很必要嘛，可以说大部分功能都是紧扣客户需求的，只有少部分可以暂时省掉。与其说在最短的时候内完成一个基本功能版与客户谈，还不如说在最短的时候内完成软件第一个完整版本（只缺少很少的一点儿功能），短时间肯定没戏。完成了再跟客户谈价钱吗？其实这个项目我们是赔大发了，继续做，公司也是支持不下去的。
这个问题难道就无解了吗？
案例太长了，大概了解了一下意思：
我的建议如下：
1.软件开发前期准备做的不到位，项目的准备成本是永远低于实际操作成本（当然在项目完成时间内）；
2.将用户需求明细在合同中；
3.项目开发的所有功能均按照合同的确定后方案执行，期间用户需求一但有变动，需让用户直接与项目管理人沟通，并明确需求的变动不在我方。
个人建议，请参考！
题目：重新梳理需求，评估项目和预算，适量要求追加预算 作者：游永明 (广东省计算中心 yym@gdcc.com.cn)
通过对案例的分析，我们了解到
1、对于项目的需求比较清晰，但是核心业务了解不够，同时还存在不合理需求
2、项目进度控制存在问题，和客户沟通因为2次转包存在一定的弊端，对客户的引导不够
3、对系统基本功能把握不够，其实也是对客户业务不够深入了解
4、工作量估计出现很大出入，导致预算超支
我的建议：前面有朋友提出加强和客户沟通，确定基本功能等，我再补充一下。针对客户急需初步版本，我认为可以选取两个业务流程来重点实现，作为demo版本演示给客户以增加客户信心。另外比较重要的是重新梳理需求，删除自己认为合理但是得不到客户认同的，列出客户重点需求。根据梳理后得需求重新估计工作量，确定项目预算。最后就是针对梳理后的需求，进行合理的调整与客户沟通增加投资的问题。适当采用需求增加导致费用增加的方法，因为案例并没有提到客户对需求的完全确认，这是一个突破口。
让客户对你们有信心，同时你们要显示出自己的实力，最后就是双方的妥协适量增加投资预算，达到项目的最终完成。
题目：确定客户要的基本模块,并只保障之 作者：黄飞生 (保留 SZFISION@YAHOO.COM.CN)
1 确定客户要的基本模块,并只保障之.
2 下狠心的把自己很满意的部分也按实际的客户基本需求情况进行删除.
除非充分与客户沟通,得到新的资源.没其他办法!
题目：项目执行所需要的人员成本超出了预算，而且项目已经严重泄后 作者：kitty (南京 jiwei1030@163.com)
既然是用户型的项目，那就应该好好的利用客户。其实客户有时自己都不明白自己要做的是什么，要实现的是哪些功能。所以在前期需求阶段要花费很多的时间与客户讨论，究竟做哪，怎么做，然后达成一致的意见。这种意见不是口头的，而是要经过双方具体代表性的人物签字确认的。。否则后面的变更会变得不可追溯。。
题目：软件的基本功能！ 作者：赵宏伟 (东信北邮 zhaohongwei@ebupt.com)
其实针对一个软件的基本功能完全可以和用户谈判或者讨论来决定的！ 在规定好的时间内完成相应的内容！ 这样子也是一个项目执行过程中的调整！ 你自认为的“在我看来，这些功能都很必要嘛，“ 这都是你自己认为的 并不表示客户真正需求的！
所以在最短的时候内完成一个基本功能版 完全可以在自己的控制之下完成呢！
题目：确认需求 作者：唐旭东 (电子有限公司 zhengwest@163.com)
其实对于需求调研工作,我觉得这个是在培养客户,而不是在让客户任意发挥,因为客户不会对自己随口说出的话负责,只是觉得有这个需要,想这么做,在这个时候:
1.我觉得关键是要引导客户,把客户引导到自己的思路上,这样才有助于项目的进展,因为客户在自己心中不会有系统的模型;
2.其次,是要控制需求,抓主要矛盾,把主要的功能先实现,保证在主要的业务上系统能够实现,不会出问题;
3.再次,我觉得原因在于没有完全了解客户的业务,也就是说以前没有这方面的业务经验,对于需要调研那些方面,那些范围,没有在调研前做一个详细的分析和整理;
题目：精简需求 作者：陈晨 (河北保定智能电脑有限公司 seesunny@126.com)
1、最主要的还是要有机会与最终用户沟通。了解所作项目用户最关心的是那部分。这部分作完成后等于完成了80%的工作。
2、确定哪些部分不用臆想出来的，把这部分仅仅做个界面，和简单的功能模拟就可以了。
3、如果希望项目成功，建议，不要仅仅看需求文档。要看用户的工作是否真的非常紧迫的需要某些功能。如果是没有什么含糊的努力做，如果不是就可以简单带过，功能有了就可以了。
当前最需要做的是把自己需要的工作，理顺出来，看看那些才是最重要的中心环节，这些弄明白了，个人认为可以按步就班的开发了
题目：一点拙见 作者：于先生 (南方数码 eolia_yu@126.com)
1、看来应该是前期调研补充分的结果，那么现在在时间和资金紧张的情况下，可不可以只考虑客户最急需的部分，而不是自己认为有用的部分，此后在试运行期间完善呢？
2、可以根据项目进展情况，做一份项目实施估算报告，体现出导致紧张的各方面，这样更有说服力，并且一定要和总监与客户三方对话，因为这种情况下客户只认总监。
3、给出新的项目需求、实施计划及困难所在，必要时重新谈价格。
最近遇到了一个版本控制的难题，导致多次上线后系统大面积瘫痪。正在进行的项目是一个二期开发项目，一期、二期在一个同一个环境，目前项目内的工作内容有：对于一期中Bug的修改、更新和对于二期内容的开发。其中：一期内容和二期内容有很强的关联性；一期内容的Debug结果要求用户方面测试，测试后及时更新上线；二期开发内容要求分阶段上线。所以结果导致：有时一期Debug结果上线后，影响二期开发、已上线内容；有时二期开发内容上线后，影响一期内容，或一期Debug上线内容。
最常见的头疼问题比如：功能A是一期Debug结果、两个月前开发完成，近日用户测试完成，A功能完成后，Debug开发进程继续。功能B是二期功能，一个月前开发完成，二期开发进程继续。在A功能开发完，但未上线的时候，对于A功能相关的类进行了更新。
昨天，用户要求对于A、B功能进行上线，但不能有其他内容上线。结果：A功能上线后，由于修改了某二期内容（已上线）的公用函数，导致原二期系统瘫痪；B功能上线后，加入了B功能之后开发的代码内容，但是由于DB更新没有进行，导致系统报错。
抽象化一下就是：N久以前，项目组开发了若干个功能（比如20个，其中有复杂的公用类和接口），之后继续进行开发（此时有严格的版本管理），之后，用户要求对于其中的1，2，6，8，19号功能上线，结果上线系统瘫痪，但开发，测试环境的测试过程，是最新的结果，包括所有功能，没有任何报错。
分析列表：
题目：应该加强产品管理 作者：游永明 (广东省计算中心 yym@gdcc.com.cn)
（刚才按错了，重发）
案例的项目问题在于将开发管理和产品管理分离开来，或者说没有严格进行产品管理导致。
一般来讲开发人员手头会同时拥有两个版本的开发权限, 一个称为trunk分支,又叫做功能变化分支, 一个称为bugfix分支, 简单理解, trunk会有功能的增加, bugfix没有功能的增加。
案例提到的一期和二期就是bugfix分支和trunk分支的关系，虽然案例中提到严格的版本管理，我分析应该仅仅是指开发库的管理，没有涉及产品库。其实我们知道版本库应该包括两个：开发库和产品库。
案例应该加强的是产品库管理。一期的bugfix正常发布，但是二期的发布应该是对一期bugfix发布的一个merge才正确。公共库还是统一维护，并且整个作为一条产品线来维护才对。
题目：应该加强产品管理 作者：游永明 (广东省计算中心 yym@gdcc.com.cn)
楼主的项目问题在于将开发管理和产品管理分离开来，或者说没有严格进行产品管理导致。
题目：版本控制的难题 作者：arkingchen (tn arkingchen@hotmail.com)
对公用函数库进行版本区分
一期和二期使用不同版本的公用函数
项目管理需要沟通－wadcom公司案例
-------------------------------------------------------------------------------
Wadcom是一家跨国电信设备公司，在中国设有分支机构。公司在中国的组织结构如图1所示。
2000年7月，Wadcom公司与中国的运营商A公司签订了全国29个城市的IP电话设备供货合同，合同总值超过1.5亿元人民币，计划一年完成。
为此，Wadcom公司成立了专门的项目团队，由销售工程经理Harrison担任项目经理。项目团队的其他成员如表一所示。项目的干系人还包括A公司在国内29个城市负责确保现场安装环境的工程师，以及A公司聘请的负责系统测试的工程师。
7月20日，Wadcom公司中国区总裁Peter召开了第一次项目大会，开发团队中的Grant和Art以及生产项目经理Nick 和订单管理经理Jerry通过电话参加会议。会上宣布了项目团队的组建事宜。
随后的一周，Harrison和助手Jane一起完成了项目说明书和项目计划的起草，并提请相关人员确认。之后，项目正式启动。
项目初期进展得很顺利。很快，Harrison和Jane就制定出了项目时间计划、资源管理计划和风险管理计划等。
此时，位于美国总部的开发团队项目经理Art提出，希望销售工程师能够提供更多的用户需求细节以便提高开发效率和准确性。为此，Harrison制定了为期一个半月的每周开发例会，要求Art和售前工程师Bing以及相关人员参加。
紧接着，订单管理经理Jerry告诉Harrison，由于事先没有沟通，出于“零库存”的考虑，公司没有过多备件，需要延长交货时间。Harrison与生产项目经理Nick讨论后得知，交货时间可能比预期要晚两个月。显然，这是无法接受的。因此，Harrison将此问题提交给Peter。Peter要求Harrison制定了为期两个月的每周两次的订单状态报告和协调会议，并要求相关的高层经理参加，尽量缩短交货时间。
在即将交货的前两周，在一次和A公司的研讨会上，Harrison突然得知A公司项目中有些辅助的备件现场没有，这将影响施工进度。无奈之下，Harrison 要求系统安装和支持队伍在两周内到现场做实地勘察，并将所需的材料和备件统一上报。由于工期紧迫，这些辅助备件不得不在国内单独采购。因而，Harrison需要组织采购工作会议，并设置采购的工作程序。
此外，由于A公司各省局的相对独立性，项目的培训和准备工作比预期更为复杂。虽然合同中规定了较详细的内容，但Harrison还是不得不参与本应属于A公司的一些具体工作。
最后，所有货物运到安装现场比预期晚了近一个月。在此期间，项目相关的培训工作也结束了，项目进入现场安装阶段。
Harrison本以为项目前期那些繁杂的会议可以减少了，然而很快他就发现新的问题接踵而来。由于恰逢国内春节时期，A公司各省局全部封网，项目不能按计划进行。Harrison需要重新计划各地的实施日期，这给原本紧张的工期又增加了压力。另外，由于工期的延误，负责施工的技术人员已开始忙其它工程，Harrison还得重新与负责技术支持的经理磋商安排。
经过近3个月的安装和调试，系统开始试运行。按照合同规定，尾款要等到验收合格才能支付，双方都组织了各自的测试队伍。3个月后，系统通过测试，项目在2001年9月底结束。
在一些大型项目中，通常涉及的项目人员众多，并且会有多个职能部门参与。如何将这些职能人员组成一个有效的项目团队，是项目成功的关键因素之一。
管理需要沟通
管理学指出，通常，管理者要用70%的时间用于与人沟通。而对于项目经理来说，需要花费90%或更多的时间来进行沟通。
就像上文的案例中，Harrison不但要与公司内部的销售、开发、生产、安装、培训等多个部门打交道，还需要与公司外部的客户打交道。因而，沟通就不是一件容易的事情。
在上面的案例中，由于项目经理在沟通管理方面做得不够，“麻烦”接踵而至。先是库存不足需要延长交货时间，然后又出现安装现场缺乏辅助备件等问题。原本项目经理制定好了项目计划，安排好了项目进度，却总是被一些“突发事件”搞得措手不及，最终还影响了项目进度。
沟通管理的六要素
那么，如何在项目中进行行之有效的沟通管理呢？一般说来，要从以下六个方面来考虑。
首先，项目经理应该将沟通本身加以计划，也就是要有具体的沟通计划。虽然在各类项目管理教材中有许多关于沟通管理的论述，但是真正的IT项目环境中，大多没有具体的沟通管理计划，一般都只是简单罗列了项目的干系人。沟通计划的制定至少要包括以下几个方面：
1、项目干系人的列表。最好以团队为基础建立干系人列表。
2、确定以团队为基础的项目干系人的信息需求和沟通需求，即何人何时需要何种信息。一般来讲，由于大的项目沟通渠道实在太多，以团队为基础能够大大减少这种渠道。
3、信息分发的渠道和方式。对于重要的项目一定要有定期的项目绩效报告和问题状态报告。
4、项目定期会议，最好是每周例会。这样，项目干系人知道有了问题在何时能够得到讨论和解决，并可避免突发组织会议找不到人的局面。
5、特殊问题的沟通对策。
其次，项目经理要尽量利用好干系人的首次会议，将项目的内容做较为详细的交待，并提请所有干系人对项目可能出现的问题提出建议。
在本案例中，需求不清和备件不足的问题如果很快被识别，就不会出现临时组织会议的复杂局面。因此，除了项目成立大会外，项目经理最好再召开一到两次全体项目干系人大会（或以团队为基础的会议）。也就是说，在解释了项目的背景并分发相关的信息以后，留给项目干系人一到两周时间仔细考虑可能面对的问题，并及早识别加以解决。这与风险识别并不完全一样。有时候，识别的可能是风险，有的时候可能根本就是一种实际情况，如案例中公司备件不足的问题。
第三，项目经理要严格控制会议的次数和内容，全面管理自己的时间分配。在上文的案例中，Harrison组织了很多的例会，与不同的项目团队交流。此时，项目经理要明确自己的职责，要努力将会议的时间限制在一定范围。并且，会议最好要形成具体可行的活动内容，并指派具体的实施人员。
第四，项目经理要理解沟通的不同层次，同时要利用这些层次为自己的项目服务。即使项目经理本身就是一个高级管理人员，他通常也无法解决所有的问题。因此，项目经理需要定期与高层管理人员进行交流，需要高层解决的问题一定要及时上报。
第五，沟通的目的一定要非常明确，项目经理要对沟通的内容进行管理，要注意防止跑题。跑题的情况通常在项目的后期中容易出现，随着项目人员的熟悉，很多与项目无关的话题都有可能占用项目会议的时间，并且通常还不易察觉。因此无论是项目会议还是相关文件，都要明确所要讨论的内容。
第六，沟通不仅局限在公司内部，同时也要同外部，尤其是客户进行交流。特别是对项目重要的里程碑，需要征得客户的支持。这包括客户的准备活动（最好有一份准备文档）、施工的时间、客户的工作日历等等。
事实上，沟通管理是一门复杂的管理科学，需要项目经理在实践中加以总结。项目管理中的沟通与日常管理中沟通的不同之处在于，项目经理要在最短的时间内，达到满足项目需求的沟通效果。
某一家软件公司，近来接到一个B/S结构的PHP网络应用程序项目。此项目由五个开发人员组成，项目经理亦充当开发人员的角色。
开发的初级阶段，使用的是Windows为基础的IIS 网络服务器，而有的开发人员却使用了Linux 为基的Apeche网络服务器。
当项目开发到了中级阶段时，项目经理决定进行一次“里程碑”的第一次整合测试，结果很显然的，不同服务器的代码不能正确的整合在一起，而项目经理命令继续开发下去。
当项目开发到了终级阶段时，出现文件路径问题，和诸多冲突，有的开发人员不得不进行很大程度的修改。同时发现，很多开发者开发的代码，在项目进展过程中也未能及时得到整合。
项目管理的处于失控状态，请问这个项目的问题要主在哪里，应该如何处理？
分析
题目：教训 作者：高华 (中国石油 ghchianren@bgp.com.cn)
我认为这个项目没有按照项目管理要求去做．
项目初期没有规划，团队人员思想不一致，没有方案的详细设计或是接口没设计好，就开始行动了．显然的无组织，无纪律，无目标．第一步就导致了项目的失败．
在项目经理发现问题后没有和团队成一起分析问题，找出补救措施．是错上加错．
如果要补救已经是不可能的了．和队员达成共识意见后从头在来吧．
题目：补课！ 作者：张翼 (SHPM Dill_Jacob@hotmail.com)
在项目中采用异构整合，不见得不可行，关键要先做好架构设计，至少是接口设计。
不少软件公司在做项目时，都急着写代码，结果是生产出许多无效代码。既然楼主来到了联盟，就应该运用你的项目管理知识，设法扭转这种局面。
项目经理兼做开发，不应该陷入具体的技术问题的研发，不妨担负起技术经理是职责，把这个项目的设计做好。
问题主要出现在哪里？这个问题实在让我无语！
现在解决问题最有效的办法就是补课，把5名开发人员招集在一起，讨论清楚每个人开发的模块之间的接口，接口不清楚，写出再好的代码都是无效的，不要惋惜各个模块中创意的设计，无法整合在一起，再好的创意都是徒然的。
在这个项目中，做好组织、协调工作，才是项目经理的职责。
题目：防患于未然！ 作者：安安 (北京 lilac_bk@126.com)
这个项目的主要问题很明显，在开发的初级阶段，就铺下了问题的隐患。而在中级阶段时，尽管问题已经很明显，而且会制约项目的进行，项目经理依然命令继续开发而没有采取任何的补救措施，导致最后项目处于失控状态。
对这个项目而言没，其实在最初已经可以预见最后的结果。
题目：项目管理技术管理 作者：严长洪 (484789 ychych123456@126.com)
问题：计划，控制，监督，里程碑的检察和反省自已，工作的安排和整理，工作的可靠性。
题目：很糟糕的事情 作者：daijiangbao (自由职业 daijiangbao@hotmail.com)
作项目经理就不能去做开发，尤其不能深入到开发过程中，技术不能代替管理
没有必要谈失控，连个计划都没有，控制的基线都没有，谈什么失控，没有意义的
题目：管理学基础知识掌握不牢 作者：桂良民 (江西新余学院 guiliangming1012@yahoo.com.cn)
文字
从以上不难看出，该公司出现了管理问题。上述提到的代码问题应归结为该公司没有统一指挥。没有统一的指挥就会导致组织混乱。
违反了法约耳14原则中的统一指挥的原则。我对项目管理的具体知识不是很精通，只能用管理学的内容分析，如有错误请与本人联系
对像项目管理这样高深的理论来讲，无用说，对管理学掌握要更牢
这方面的知识可以参考 武汉大学出版社文字管理学 谭力文 有关法约耳14像管理原则。上海复旦大学出版社 周三多 管理学原理与方法 中有关原理与方法部分和计划部分。
题目：管理学基础知识掌握不牢 作者：桂良民 (江西新余学院 guiliangming1012@yahoo.com.cn)
文字
从以上不难看出，该公司出现了管理问题。上述提到的代码问题应归结为该公司没有统一指挥。没有统一的指挥就会导致组织混乱。
违反了法约耳14原则中的统一指挥的原则。我对项目管理的具体知识不是很精通，只能用管理学的内容分析，如有错误请与本人联系
对像项目管理这样高深的理论来讲，无用说，对管理学掌握要更牢
这方面的知识可以参考 武汉大学出版社文字管理学 谭力文 有关法约耳14像管理原则。上海复旦大学出版社 周三多 管理学原理与方法 中有关原理与方法部分和计划部分。
题目：项目整体管理问题 作者：制造太阳海 (开发部 makesunsea@vip.sina.com.cn)
对于软件开发项目,项目管理的流程应该结合软件生命周期进行,并每一步进行严格的控制,项目启动阶段应该选择项目经理,并由项目经理指导作好项目的可行性分析,需求获取等工作,在计划阶段,应该对需求进行分析,设计,并相应的培训相应的开发人员,统一项目使用的平台,开发工具,以及应该遵守的编码规范,然后再是执行和控制软件的开发和测试及项目的培训和上线.整个项目管理的过程应该紧紧结合软件生命周期进行,并且要求整个团队都依一种软件工程的思想,使用相同的平台,相同的工具和相同生命周期进行项目的开发.
题目：质疑？ 作者：SP (成都信息工程学院 sp-58911985@163.com)
公司为什么让没有一点经验的人当这个项目的项目经理~高层应有一点责任吧~？
题目：Fire the PM 作者：douglas chan (secret douglas_chan@163.com)
只能说那个PM对技术没经验，同时没有对现场问题进行分析、
合理应对的能力。fire him
题目：这能叫项目管理吗？ 作者：穆海成 (北京亚杰科技发展有限公司 mu_haicheng@263.net)
不管项目经理是以什么身份参与项目的，也不管成员之间的沟通是否到位（当然在这个项目中肯定连最基本的沟通都没做好）。我觉得此项目中的PM根本就没把这个开发任务当成一个项目来做，而仅仅是一次技术练兵。以下是我的一些看法，有说的不对的请大家指正，谢谢。
1、项目管理最基础的就是计划，这个项目从一开始就没有一个很详细的计划作为指导，从一开始就为以后出现的混乱情况埋下了祸根。
2、项目进入执行阶段，总会在适当的时候对项目运作情况进行考核，也就是文中提到的“里程碑”式的整合测试，这个考核是以实际项目运行情况和项目开始时的计划进行对照的，如果有问题，就一定要马上进行处理，让问题自己消失根本不可能。这一点在这个项目中也没看到。造成最后的失控局面也就不足为奇了。
题目：pm的领导不力和团队整体的不协调 作者：许剑明 (Briontech xjmshanghai@gmail.com)
首先，PM对自己角色定位不对，很多PM都是从技术人员上去的，往往把自己当作一个programmer，动不动就当救火队员。在一个团队工作中，协调者•沟通者•观测者的角色甚为重要，PM应当侧重这些方面，转换自己的观念。
第二，SCM环节缺失，Team的团队开发环境在项目构思前就应该要有统一标准和专人维护。
第三，开发计划失利，在团队开发中，PM应该对先期的规划和安排有所澄清，让每个成员了解项目思路，统一认识。这样才不会等到中级阶段才发现脱节问题。
第四，PM应变能力不强，当发现中期有问题时，适当的要有所调整，很多项目由于是Time—driven，很多PM顾头不顾尾，决策欠妥，往往是雪上加霜。
其他的也不写了，我想项目做成这样，整个团队都是有责任的，不光是PM的领导不力，成员中的协作和上下级沟通肯定有脱节。
题目：项目经理的工作 作者：sangsang (新闻传媒 zhs@btc.sh.cn)
我认为主要还是项目经理的管理能力存在问题,在项目实施初期,项目经理应该很明确的做几点说明:
1.软件开发的工具,或者说应该是软件开发的平台是什么,应该统一.
2.项目里程碑,让每一位team member 知道项目的实施计划.
另外该经理的失误在于当第一次里程碑整合时已经发生风险时,他没有做及时的规避,没有采用沟通的方式,及时控制TM的行动方向.
题目：管理问题 作者：韦少才 (桂林空军学院7053 we26@163.com)
我觉得，经理的技术能力值得怀疑。在不同服务器上的计算机程序运行时本来就不大相同。在中期测试时已经出现端倪了，却还要进行开发，也不要求修改程序代码，让程序在不同的服务器上无法兼容。这本来就是一般的常识嘛！
虽然这么说，但是下面的开发人员，却也跟着做。在项目的整体结果就可想而知了。
题目：软件开发项目的失控 作者：nbwzy (kd nbwzy@163.com)
项目管理出了问题：
１、该项目经理可以说根本就没有什么项目管理的经验或者是完全按照自己的经验在做事情。而且中期检查时发现了问题，却不知道其严重性，试问该项目经理该承担什么样的责任？
２、这不是一个好的开发团队。应该说为什么连队友是在什么环境下开发都不知道，那还叫团队吗？
３、项目没有一个尺度把握，更没有一个周期控制。
４、公司的管理制度存在很大问题：没有相关的制度对项目进行监控
５、各部门协调有问题：一个项目９０%以上来自销售部，等到项目出了这么大问题销售还不知道项目情况，那就有问题了！
总结：该开发团队如不在项目管理上加大学习力度，那该团队只能接手一些小型项目（各做各的），稍微大点的项目就会出问题，而且该公司也很快就会被淘汰。
题目：软件开发项目的失控 作者：林 (成都西南交大 linsizhu2006@173.com)
开始时没把网络服务器交代好，前期缺乏沟通
题目：对项目管理没有概念的必然结果 作者：安乃红 (AMDOCS-LONGSHINE yulongan007@gmail.com)
案例中的项目经理对项目管理没有概念导致现在的局面。现在要重新对项目管理进行认识和补救。在总结这一段时间的经验教训后，制定相应的项目管理计划和制度。分析合并两种代码的代价，选择代价和运行成本性价比较好的方案。但是学习项目管理和软件开发的相关知识是基础。
题目：项目规划 作者：coolgh (dfasdf gongchp@163.com)
项目开始的时候，项目经理没有做好规划，不能把控全局。
题目：技术问题 作者：何晖 (大众科技 hehuii@sina.com)
我认为还是项目经理的技术能力不足，另外也不应该充当开发人员
某通信公司的交换扩容项目案例分析
2006-7-5
--------------------------------------------------------------------------------
项目背景：根据200X年以前的工作情况，基站网点的分布和容量，社会对移动电话的需求，省公司制定了200X年的总体业务增长计划，分配到我公司的建设任务工程。
可行性分析：根据省公司要求，对公司现阶段的工程建设进行了调研，认为工程在适量的投资下是可以进行的，包括新建、扩容，总体能够达到省公司要求。
实施过程：
1.公司传达上级公司的要求，工程管理中心按要求进行项目建设规划。
2.将规划上报领导进行审批，上报省公司进行审批3.省公司对建设规划的工程量进行了扩大，认为部分建设内容对以后的扩容要留有更大的空间，对投资资金计划进行了压缩。
4.根据审批后的建设规划工程管理中心对项目进行分解，制定项目计划，包括资金的投放计划和额度、建设进度计划、质量验收标准、建设范围、风险规方案等等，进行任务分配；工程建设部负责设备采购、工程建设；工程管理中心负责项目进度监管和验收；财务部门进行资金配合；人力资源部进行人力调配；网络部、后勤部等部门进行协助；5.在分配任务时，工程建设部认为公司投资额度不足，工作量大，按现有人手和设备难以完成认为，要求增加人手和工具设备的投入。工作只能跟着感觉走，没钱再说。
6.人事部认为工程建设部门的人手不够可以配合，但是公司员工编制有限，只能在社会聘请，费用由工程建设部门从工程费用中支付。工程建设部理解公司人事制度，勉强同意，但要工程管理中心协调省公司。
7. 8月份，财务报告，工程建设资金告紧，工程管理中心提交资金追加申请。
8. 9月份省公司同意追加资金，工程继续。
9. 10月份大量工程进入验收阶段，工程中心疲于奔命，发现不少工程有质量问题，限定工程建设部门改进。
10. 12月份工程基本都按进度完工，进行验收，工程质量还是有不少问题，但是为了按时完成省公司的工程计划，否则奖金没有，小问题放过，不大不小的问题口头责令整改，大问题瞒上不瞒下，责令承建商继续整改。
11. 每月上交进度报告，召开业务协调会议，有需要时召开临时会议。
根据案例分析以下问题：
1. 对当前问题描述
2.对组织结构建议
3.对沟通管理的建议
4.对成本管理的建议
5.对进度管理的建议
6.其他建议
分析： 电信运营商的基础网络设施之项目管理 作者：howard_hong (普华 howard_hong2001@yahoo.com)
1.对当前问题描述
A:中国式项目管理的情形是：项目目标终就会实现，只是在过程中大家辛苦成都有所不同；深究其原因所在，计划的龙头指挥作用没有得到很好的贯彻，大多数电信运营商在过程中对于最终的目标能否实现没有提前预见能力，因为他们对于项目的控制依赖于统计，类似CHECKLIST，失去基线，也就失去问题可预见性；跟着感觉走、经验主义，累是必然的。
2.对组织结构建议
A:电信运营商网络基础设施项目的管理组织架构属于职能型，谁都不直接对项目结果负责，经常出现问题了，找不着可以挨板子的人。工程管理部和工程管理中心职责不清。
3.对沟通管理的建议
A: 工程管理部和工程管理中心应该充分借用监理的力量，让自己处于内部协调、外部支持、监督执行，阶段评审的角色。运营商自己管得越多，也不见得是好事，有些事情自己并不擅长。
4.对成本管理的建议
A:电信运营商由于项目个数众多，并不是每个项目都进行招标，选择承包商基本都是从年度资格入围的承包商中进行选择，大家都有饭吃，所以给个项目没有合同标的；其次，承包商、供应商的费用基本是按实际工程量进行结算的方式。所以成本管理是一个空架子，项目群的预算总额并没有分解到具体的一个个项目上，实际成本超支是必然的，除非你人为放大了预算总额。
5.对进度管理的建议
A:建议多设置项目群阶段评审、阶段验收的里程碑；在项目群的收尾阶段集中评审，只能使市移动公司对验收刷浆糊；
6.其他建议
国外电信运营商基础网络设施项目群普遍采用TURN KEY的项目运作方式，将风险转嫁给实施商，运营商自己在项目中只承担监督、协调和支持，费用不会超，人员也少，管理也轻松，何乐而不为？ 管理体制问题：什么事情总想自己管，累是必然的，可能还不讨好。
分析2：
题目：一个非常成功的项目 作者：王勇 (远达网络 fwang@uninetsystems.com)
通信公司案例，尤其是甲方提交的案例，真的是难得一见！绝对的精华贴！
总体而言，我认为这是一个成功的项目管理案例。
首先，项目参与各方满意，目标完成了。
1.省公司的工程计划按时完成了。
2.工程项目部门的奖金保证了，工程质量问题在有效的范围内得到了控制。
3.承建商拿到了项目，完成了项目，尽管会有遗留问题要处理。
其次，工程沟通顺利。
1.审批阶段各部门协调不错，遇到问题了，没有纠缠，而是找到可行的解决，或者留待后期处理。例如工程部门处理投资不够问题， 人事部门处理人手不够问题。遇到了问题，不是消极等待，而是提出积极有效的建议。绿灯行，黄灯跑3，遇到红灯绕着行。
2.财务处理有效。在8月份工程费用不够的问题出现了，2个月内就解决。
3.定期的业务协调会议，临时会议。
4.团队合作。尽管楼主没有特意的谈到团队合作的问题。但是从文中可以发现，该通信公司团队合作比较顺畅，而且各个职能部门配合较好，没有推诿和拖拉的现象。
最后，质量控制
1.工程中心发现问题，工程建设部们整改问题。
综上所述，楼主的案例是一个比较成功的案例。楼主所在的公司也是管理比较成功的公司。当然，工程项目中会遇到各种各样的问题，不可能完全避免。 如果楼主所在的公司管理水平还要提高的话，估计就要从战略层面考虑了，如何节约成本，提高效率。例如建设ERP系统，建设PM 信息系统。
BTW:说了这么多好话，最后说一些反话。 俗话说，有钱好办事。现在通信运营商大都是有钱的主。而且工程建设，工程项目内容比较单一，工作知识和经验转移比较容易，不成功就怪了。