项目团队具有典型的生命周期特征。一个项目团队的形成是需要时间的，从组建到解散，是一个不断成长和变化的过程，通常要经历五个阶段：形成、震荡、正规、出成效和终结。实际上，项目经理可以使用各种工作技巧来缩短项目团队的前三个阶段，由此将整个项目生命周期简化为三个阶段：

　　1、在开始阶段，团队带着一种期待和所得到的承诺来到一起，历经士气高涨的团队角色定位期、对项目目标和方法的分歧期，而后进入正规期。他们接受了工作环境以及角色和职责分配，开始就各种问题达成一致。正规对团队的最终绩效很重要，但它可能也有负面作用，如果团队太正规，他们会过于关注自己的团队，并将自己同组织的其他团队孤立开来。以至于产生不利于组织整体的东西。

　　2、一旦绩效达到稳定状态，团队就可以在项目期间内有效合作。这一阶段中的团队成员互相理解，高效沟通，密切配合，团队绩效与凝聚力达到最佳状态。然而此时可能出现的状况是，成员开始变得自满，然后他们的效能就下降。所以，项目经理需要改变团队的结构或组成，维持绩效的稳定状态。

　　3、随着团队接近任务结束，有两种情况可能发生。或者效能随着成员一致努力而上升，或者随着团队成员为项目结束和他们已经建立的关系的结束而失落，一致效率下降。如果未来不确定，则后一种情况会发生。项目经理有责任鼓励并保持团队高效的工作。

　　二、项目团队激励因素分析

　　根据马斯洛的需求层次理论，当人们的低层次需求得到满足时，这些需求便失去了作用。由于项目团队中的成员多为知识型员工，因此他们更加注重高层次需求的满足。据此我们提取出了对团队成员更为重要的五项激励因素：

　　1、目的。人们必须相信他们的工作是重要的，而且有助于组织的发展。

　　2、授权。由于事业的道路变得很不清晰并难以预测，以及与高层管理者的疏远，人们希望管理自己的事业发展。

　　3、利益分享。鼓励员工自己解决问题，主动满足客户需求，而且允许员工分享收益。

　　4、个人发展。团队成员重视学习经验的机会，每个新项目都是学习新技能的机会，因此增加了受尊重感和自我成就感。

　　5、认可。专业上的认可是另一个成就的度量。对其专业技能的认可和赞扬，增加他们的受尊重感和成就感。尤其是在缺少高层经理与项目成员直接接触的组织中，高层经理对专业人员的认可将起到更大的激励作用。
      三、激励因素在项目团队生命周期中的运用

　　这五个激励因素的效力在项目团队生命周期的三个阶段内应有所差异。

　　1、在第一个阶段，团队的成员既兴奋又焦虑，而且还有一种主人翁感，试图确定自己在新团队中的位置，由于定位不清，团队凝聚力由于争斗而迅速下降，此时，项目团队迫切需要解决的问题是确定项目要干什么，团队的整体目标是什么，每个个人的任务和目标是什么。因此，目标激励在这一阶段显得极为重要。明确的目标使个人有机会通过解决问题来展示个人的专业技能，定位自己在组织中的位置，同时了解组织中的其他成员，使组织顺利进入正规阶段。

　　2、在项目团队的出成效阶段，团队成员关注的焦点从项目目的转移到完成的工作上。充分的授权、学习机会的增多和利益分配的可能性都是在这一阶段确定的，这两类激励措施是对成员良好绩效的肯定，是增强员工归属感，使员工获得尊重的重要手段。授权同样可以通过给人们分配责任，而使人们有机会展示自己的专业技能。通过这些激励手段，团队成员互相理解、高效沟通，团队的绩效和凝聚力均达到最佳状态。

　　3、在团队终结阶段，五个激励要素都成为焦点，需要再次重申在交付使用中的目的;成员交付成果并得到应有的奖励;如果项目盈利，人们可以总结这一阶段经验，加入下一个阶段;得到专业上的认可。个人可以得到相应的咨询来帮助其事业发展，应该帮助个人确定他们的发展需求和编制如何实现需求的计划，通过允许选择下一个项目对他们在当前项目上的良好绩效加以肯定，帮助他们设计在其事业发展中的组织内外网络。

三、激励因素在项目团队生命周期中的运用

　　这五个激励因素的效力在项目团队生命周期的三个阶段内应有所差异。

　　1、在第一个阶段，团队的成员既兴奋又焦虑，而且还有一种主人翁感，试图确定自己在新团队中的位置，由于定位不清，团队凝聚力由于争斗而迅速下降，此时，项目团队迫切需要解决的问题是确定项目要干什么，团队的整体目标是什么，每个个人的任务和目标是什么。因此，目标激励在这一阶段显得极为重要。明确的目标使个人有机会通过解决问题来展示个人的专业技能，定位自己在组织中的位置，同时了解组织中的其他成员，使组织顺利进入正规阶段。

　　2、在项目团队的出成效阶段，团队成员关注的焦点从项目目的转移到完成的工作上。充分的授权、学习机会的增多和利益分配的可能性都是在这一阶段确定的，这两类激励措施是对成员良好绩效的肯定，是增强员工归属感，使员工获得尊重的重要手段。授权同样可以通过给人们分配责任，而使人们有机会展示自己的专业技能。通过这些激励手段，团队成员互相理解、高效沟通，团队的绩效和凝聚力均达到最佳状态。

　　3、在团队终结阶段，五个激励要素都成为焦点，需要再次重申在交付使用中的目的;成员交付成果并得到应有的奖励;如果项目盈利，人们可以总结这一阶段经验，加入下一个阶段;得到专业上的认可。个人可以得到相应的咨询来帮助其事业发展，应该帮助个人确定他们的发展需求和编制如何实现需求的计划，通过允许选择下一个项目对他们在当前项目上的良好绩效加以肯定，帮助他们设计在其事业发展中的组织内外网络。

1.        瀑布模型

瀑布模型是一个经典的软件生命周期模型，一般将软件开发分为：可行性分析（计划）、需求分析、软件设计（概要设计、详细设计）、编码（含单元测试）、测试、运行维护等几个阶段，瀑布模型中的每项开发活动具有以下特点：

l        从上一项开发活动接受该项活动的工作成果作为输入；

l        利用这一输入，实施该项活动应完成的工作内容；

l        给出该项活动的工作成果，作为输出传给下一项开发活动；

l        该项活动的实施工作成果进行评审，若其工作成果得到确认，则继续进行下一开发活动，否则返回前一项，甚至更前项。尽量减少多个阶段间的反复，以较小的费用来开发软软件。

2.        螺旋模型

螺旋模型是一个演化软件过程模型，将原型实现的迭代特征与线性顺序（瀑布）模型中的控制结合起来。使软件的增量版本的快速开发成为可能。在这个模型中，软件开发式一系列的增量发布。在早期的迭代中，发布的增量可能是一个之上的模型或原型，在以后的迭代中，被开发系统的更完善版本逐步产生。

螺旋模型的开发过程具有周期性重复的螺旋线状。四个象限分别标志每个周期的四个阶段：制定计划、风险分析、实施工程和客户评估。螺旋模型强调了风险分析，特别是用于庞大而复杂的、高风险系统。

3.        迭代模型

大多数传统的项目生命周期中，阶段是以其中的主要活动命名的：需求分析、设计、编码、测试。传统的软件开发工作大部分强调一个序列化过程，其中一个活动需要在另一个开始之前完成。但是在迭代式的过程中，每个阶段都包括不同比例的所有活动。

迭代式开发模型从组织管理的角度将整个软件开发生命周期分析四个阶段：初始、细化、构造、移交，可进一步描述为周期（Cycle）、阶段（Phase）、迭代（Iteration）。核心工作流从技术角度描述迭代模型的静态组成部分，包括：业务建模、需求获取、分析与设计、实现、测试、部署，几乎每个部分在所有的时间段内均有工作量，只是大小不同而已。

初始阶段：系统地阐述项目的范围，选择可行的系统构架，计划和准备业务案例。

细化阶段：细化构想，细化过程和基础设施，细化构架并选择构件。

构造阶段：资源管理和控制，过程最优化，完成构件的开发并依据评价标准进行测试，根据构想的验收标准评估产品的发布。

移交阶段：同步并使开发的构造增量集成到一致的实施基线中，根据完整的构想和需求集的验收标准评估与实施有关的工程活动的实施基线。

   某公司是一家专门从事系统集成和应用软件开发的公司，公司目前有员工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:说了这么多好话，最后说一些反话。 俗话说，有钱好办事。现在通信运营商大都是有钱的主。而且工程建设，工程项目内容比较单一，工作知识和经验转移比较容易，不成功就怪了。 
 

【说明】

 A公司是一家中小型集成公司, 在2006年3月正在准备对某证券公司数据大集中项目进行投标，A公司副总张总授权销售部的林某为本次投标的负责人，来组织和管理整个投标过程。

    林某接到任务后，召集了由公司商务部、销售部、客服部和质管部等相关部门参加的启动说明会，并把各自的分工和进度计划进行了部署。

    随后，在投标前3天进行投标文件评审时，发现技术方案中所配置的设备在以前的项目使用中是存在问题的，必须更换，随后修改了技术方案。最后，A公司中标并和客户签订了合同。根据公司的项目管理流程，林某把项目移交了实施部门，由他们具体负责项目的执行和验收。

    实施部门接手项目后，鲍某任命为项目实施经理，负责实施和验收工作。鲍某并发现由于前期自己没有介入，许多前期事情不是很清楚，而导致后续跟进进度缓慢，影响项目的进度，同时，鲍某还发现设计方案中尚存在一些问题：方案遗漏一项基本需求，有多项无效需求，并五书面需求调研报告，在项目的工期和系统功能售后服务方面，存在过度承诺现象。于是项目组重新调研用户需求，编制设计方案，增加了实施难度和成本，可是后来又发现采购部仍然上按照最初的方案采购设备，导致设备中的模块配置功能不符合要求的情况。

    而在A公司，类似现象已经多次发生。

【问题1】

针对说明中描述的现象，分析A公司在项目管理方面存在的问题。

【问题2】

针对A公司在该项目管理方面存在的问题，提出补救措施。

【问题3】

针对A公司的项目管理现状，结合你的实际经验，就A公司项目管理工作的持续改进提出意见和建议。

【案例分析】

这个案例反应了A公司在项目组织结构、整体管理和流程及沟通管理等多方面的问题。

【问题1回答】

1、项目内部启动会，没有邀请技术部门或实施部门。

2、项目组织结构是职能型，导致企业是以各职能部门为中线，缺乏项目的整体协调和规划。

3、缺乏项目评审机制或有效项目评审制度的执行。

4、缺乏执行有效的项目变更管理，多次出现修改的文档反复修改现象。

5、缺乏项目各阶段项目干系人和参与角色的职责划分

6、公司级的项目管理体系不够健全，或执行的不好。

首要任务是阅读案例发现问题，然后根据发现的问题分析清楚问题的所在，参考正常的项目管理体系，有哪些欠缺和问题，问题清楚了，接下来就是解决问题了。

【问题2回答】

1、改进项目的组织结构形式，明确项目团队和职能部门之间的协作关系和工作程序.

2、做好项目当前的经验教训收集和归纳工作。

3、明确项目工作的交付物，建立和实施项目的质量评审机制、

4、建立项目的变更管理机制，识别变更中的利益相关的影响分析并加强沟通

5、加强对项目团队成员和相关人员的项目管理培训

本案例实际上反映了一个问题，一个企业项目管理出现的问题通常会出现在以下方面，这似乎成了老生常谈：

a)    公司组织结构尚处于职能型组织阶段，尚不能很好的支持项目管理的开展

b)    因为组织结构未到位，自然，整体项目管理流程也不可能建设好，这一点上CE公司有一批项目管理专家，在制度建设上是考虑的比较到位的。

c)    项目范围管理和质量评审出现问题

d)    项目变更管理是项目管理问题的重灾区

e)    项目团队建设和沟通问题。

f)    项目质量管理和配置管理不到位。

【问题3 回答】

1、建立企业级的项目管理体系和工作规范

2、加强对项目工作记录的管理，属于项目沟通管理的范畴

3、加强项目质量管理和相应的评审制度。

4、加强项目管理经验教训的收集、归纳、积累和分享工作

5、引入合适的项目管理工具平台。提升项目管理工作效率。

【2008案例试题二】

【说明】

D公司是一家系统集成商，章某为D公司高级项目经理，现正负责某市开发区的办公网络项目的管理工作，该项目划分为综合布线，网络工程和软件开发三个子项目，需要3个项目经理负责，很快章某找到了负责综合布线和网络工程的项目经理，而软件开发的项目经理一直未有合适人选。由于D公司近年发展迅猛，项目经理人手不够，章某建议从工作两年以上的业务骨干中选拔项目经理，结果李某被选中。在项目项目初期，依照公司的管理规定，李某带领几名项目成员刻苦工作，项目进展顺利。

    随着项目进一步开展，项目成员逐步增加，李某在项目团队管理方面遇到很多困难。她领导的团队经常返工而效率低下，团队成员对发生的错误互相推诿，开会人员从来没有到齐过，甚至李某因忙于自己负责的模块开会都迟到。大家向李某汇报项目的实际进度和成本往往言过其实，直到李某对自己负责的模块进行接口调试才发现这些问题。

【问题1】

请分析项目中出现这些问题的可能原因。

【问题2】

你认为高级经理章某应该如何指导和帮助李某

【问题3】

请说明李某作为项目经理要承担哪些角色?要成为一名合格的项目经理要具备哪些知识和技能？

【案例分析】

从案例描述中可用看出本案例主要聚焦在人力资源管理，主要考察如何选拔和培养项目经理，建设项目的管理团队，并对下属进行传帮带，从而使管理团队成为自己管理能力的放大器，最终提升高级管理者自己的管理水平和领导水平

【问题1回答】

1、李某缺乏项目经理的经验和能力

2、章某对李某的帮传带做的不够或不到位

3、公司缺乏培训项目经理的机制

4、李某在沟通管理和管理流程上、会议管理，测试管理和评审管理等管理活动上均出现问题

5、缺乏有效的项目绩效管理机制

6、项目工作的沟通没有建立有效的机制和方式方法

【问题2回答】

1、项目管理专项培训

2、提供工作模板帮助转型

3、让小李明确工作职责，帮助其实现角色转变

4、参加小李周列会，以便及时发现问题

5、从整体项目层面对各子系统进行计划和协调，对子项目提出具体要求

6、针对子项目出现的问题，及时提出纠正和预防措施

【问题3回答】

1、作为一名项目经理要同时承担项目管理者和项目领导者的角色，这些角色工作包括：计划。组织。协调。控制。监督。领导。

2、合格的项目经理应具备观看能看和一般专业技能，包括广播的知识，项目管理知识，行业知识，IT知识和客户知识；丰富的经历经验；良好的协调能力；

    良好的职业道德；良好的沟通与表达能力；良好的领导能力。

【案例试题三】

J公司2008年3月中标某市公安局的人口管理系统开发项目，因该市要在2008年11月举办大型国际会议，因此公安局要求人口管理系统一定要在2008年7月1日之前投入使用，强某是负责该项目的项目经理，虽然他进公司才不到3年，但已经成功管理过两个类似项目，人称“救火队长”，强某对自己也有信心，但这次和以往不同的是，强某还同时管理另外两个项目，而这个人口管理系统项目工期要求紧，他能调用的人手少。

    该人口管理系统项目属于升级项目，原系统为J公司开发，C/S结构，只能管理本地常住人口，新的人口管理系统要求是B/S结构，能够管理常住人口和流动人口，而公安局首先要求把流动人口管理起来，该项目从技术角度可分为网络改造和软件开发，而软件又分为界面、业务流程和数据库三个子系统。他们团队有6人，其中有人做过类似项目，而公司刚刚结束的一个网络项目与本次承担的网络改造项目在技术架构方面几近相同，只是规模不同。公安局新系统能够支持移动接入技术，强某凭直觉知道，依现有的人员在2008年7月1日前完成项目是不可能的。

【问题1】

请说明强某可以用什么方法和技术来估算项目的工期

【问题2】

请说明强某可以采取哪些方法来压缩工期，以使项目能够在08年7月1日前交付。

【问题3】

请说明强某可以采用哪些方法来跟踪项目的进度，以确保项目能够按期交付。

【问题1回答】

1、明确定义项目的工作分解结构

2、对于升级项目类比估算法。

3、对于新增的移动接入模块可采用专家评定法即专家德尔菲方法估算

4、对于细化的工作分解结构可用采用“参数估算”和“三点估算”方法。

【问题2回答】

1、与客户沟通并梳理关键需求，协商需求分阶段提交的方法

2、制定合理的技术方案，对于不熟悉的部分可用外包

3、赶工——对成本和进度进行权衡，确定如何以最小的成本增加取得最大的历时压缩。赶工并不一定能提出可行的替代方案，并且常导致成本增加。

4、明确目标责任和奖罚制度，提供工作效率。

5、清晰定义功能接口，并发工作效果。

【问题3回答】

1、基于WBS和工时估算活动网络图，制定项目工作进度计划

2、建立对于项目工作的监督和测量机制

3、确定项目里程碑，并建立严格评审制度

4、使用有效的项目管理工具

5、对项目发现的问题进行有效变更管理，及时采取纠正和预防措施

6、关键路径方法，图形评审技术（GERT）和计划评审技术(PERT)帮助制定进度计划

【说明】

某系统集成商B最近在争取某钢铁公司A的办公网络外迁外地的项目。李某为B公司销售经理，鲍某为实施经理。由于以往销售经理过度承诺给后继实施工作带来麻烦，鲍某此此主动请缨为售前顾问，该项目工作包括A公司办公楼综合布线，网络系统升级，机房建设，视频会议系统，生产闭路监视系统。A公司招标工作2006年8月4日开始，要求2006年12月29日完成。

时间已到了2006年8月9日，A公司希望B公司在8月15日前提交项目建议书，A对项目进度非常关注，是他们选择集成商的重要指标之一。鲍某组织制定了初步项目计划，通过对项目进度的分析预测，认为按正常流程很难达到客户的进度要求，但销售经理李某则急于赢得合同，希望在项目建议书明确给出进度保证，首先赢得合同才说。鲍某和李某产生了分歧，但本着支持销售的原则，鲍某采取了多种措施，组织制定了一个切实可行的进度计划，虽然报价高于竞争对手，但评标委员会认为该方案有保证可行，于是B公司中标，并由其实施部负责项目实施。

【问题1】

在制定项目进度计划时，鲍某可能会采取哪些措施使制定的进度计划满足客户的要求？

【问题2】

B公司目前组织类型是什么？如何改进项目的组织方式？如何改进其项目管理的流程？如何降低管理外地项目的成本？

【问题3】

在项目实施过程中，李某应当承担哪些工作？

【案例分析】

主要考察时间管理、项目组织架构、售前和售后沟通等理论应用

【问题1回答】

1、沟通，强调该项目对B公司的意义，提供项目优先级。可用使用会议形式，争取相关部门的建议，支持与承诺。

2、从现有资源和情况出发，优化网络图，压缩关键路径长度。

3、子任务并行，内部流程优化。

4、尽可能调配非关键路径上的路径用于关键路径上的任务。

5、优化外部、采购等环节并全程监控。

【问题2回答】

1、B公司当前组织类型为职能式。

2、建议B公司改成矩阵式。

3、最后的方法是下阶段人员提前介入到前一阶段，如实施阶段的项目经理正式参与售前工作，也可选择做好各流程交接工作，如实施和售后服务的技术交接。

4、委托，外包给当地有资质的集成商，或在当地找人，如果材料或负责在当地获得可降低成本，尽量压缩人员出差成本。使用虚拟远程沟通手段。

【问题2回答】

1、与客户高层继续沟通，了解客户对项目实施情况的反应，维护客户关系，发掘新的项目机会。

2、参加周列会，了解周报，了解项目进展和问题。

3、参与可能发生变更的前期评审工作。

4、负责或协助收款。

【案例试题二】

阅读项目资源冲突管理的描述：

某电子政务项目涉及保密信息。项目建设的资源尤其人力资源必须从甲方单位内部获得，因为如果把项目部分任务交给分包商。一方面要征得甲方的同意，一方面要求分包商具有相应的保密资质，而保密资质的审核需要很长时间，这将严重危及到项目交付日期。当项目团队工程师完成90%编程和测试任务时，项目承接单位一名副总承揽了新项目，他把程序员、测试员从该项目上调走，去执行她的新项目。

【问题1】

请简要说明上述情况的可能原因

【问题2】

简要叙述如果该项目经理希望继续推进该项目，应如何进行？

【问题3】

请简要叙述如何处理多个项目之间的资源冲突

【案例分析】

重点需要冲突管理方面的经验和方法

【问题1回答】

1、可能是单位没有对项目进行统一管理。谁的权大谁的项目就获得优先权支持。

2、副总承揽了新的更重要的项目

3、项目经理忽视单位内部竞争性项目出现带来的风险

4、可能是本项目绩效不好，已经失去了项目相关方面的支持。

5、失去了项目干系人内定该项目暂停或下马。

【问题2回答】

1、如果经过评估后项目存在可行性，就应书面报告该项目现状和前景预测，向主管领导汇报、说服和沟通，陈述该项目的重要性和预期利润，如果项目下马将造成的损失，以及应得到及时的和满足要求的资源支持

[这一幕似乎经常发生，我公司的一个老PM带的项目被临时取消，遗憾的上该项目经理可能没有项目被临时下马的经验显得没有后续的应变措施]

2、因为本项目要保密，可以签订保密协议，或者社会招聘人员。

3、如果只剩下10%工作，可说服原来团队加班赶工以完成项目

【问题3回答】

1、建议单位统一管理所有的项目和资源，制定资源在项目之间分配的原则，比如成立项目管理办公室PMO。

2、定期检查项目执行情况，根据项目进展和企业整体绩效重新排定项目的优先顺序，从资源上优先支持重要的和进展良好的项目。

3、外包。

4、必要时，增加资源。

5、建立项目管理体系，成立项目管理办公室，统一管理单位所有项目。

[实际上大部分公司就是使用专门项目管理部门如项目管理办工室或项目经理管理部来统一调配资源，每个项目均按项目周报模板填写进度和资源分配情况，以最大化利用企业资源，解决资源冲突] （铁歌整理）

【问题1 回答】
 1、缺乏项目整体管理
 2、缺乏整体变更控制规程
 3、缺乏项目干系人的沟通
 4、缺乏整体版本管理
 5、缺乏单元接口测试和集成测试

 【问题2 回答】
 1、制定配置管理计划。确定方针，分配资源，分配责任，培训计划，确定干系    人，制环识别配置项准则，制定配置项管理表

 2、配置项识别。识别配置项，分配唯一标识，确定配置项重要特征，确定拥有者责任，记录配置项进入时间，进行配置项登记管理。
 3、建立配置管理系统。建立分级管理机制，存储和检索配置项，共享和转换配置项，进行归档、记录、保护和权限设置。

 4、基线化。获得授权，建立或发布基线，形成文件，使基线可用。
 5、建立配置库。开发库（动态库），受控库，产品库（静态库）。
 6、变更控制。配置库实现变更控制，变更请求，变更控制过程，包括变更请求记录、分析、批准、实施、验证、存档。
 7、配置状态统计。
 8、配置审计 。

 【问题3 回答】
 从保护已有工作成果 厘清问题原因 推倒项目继续良好进展的角度

 1 针对目前系统建立基线。
 2 梳理变更脉络，确定统一的最终需求和设计。
 3 梳理配置项及历史版本。
 4 对照最终需求和设计逐项分析现有配置项及历史版本的符合情况。
 5 根据分析结果由相关干系人确定整体变更计划并实施。
 6 单元测试和集成测试。
 7 整体版本管理 。

 点评：

     首先，从问题表象处发现问题

     第二，分析问题，分析问题产生的原因，

     最后，在系统掌握项目管理知识体系PMPOK的基础上，对症下药，开出药房，能否药到病除就看项目管理师解决问题的功力了，实际上方法论上和咨询顾问解决企业问题遵循共同的规律，项目经理应该是企业项目管理方面的咨询顾问和教练。

【2006案例试题二】

【说明】

    小李是国内某知名IT企业的项目经理，负责某省一个企业管理信息系统建设项目的管理。在该项目合同中，简单地列出了几条项目承建方应完成的工作，据此，小李自订的项目范围书。甲方的有关工作由其信息中心组织和领导，信息中心主任兼该项目的甲方经理。可在实施中有时是甲方财务部有时是销售部直接向小李提出变更需求，甚至相互矛盾，面对这些变更要求，小李试图用范围说明书说服甲方，甲方就会引用合同，而合同因为太粗，导致双方理解不一致，小李对这些变更不是简单拒绝或接受而为难，如果不改变这种状况，项目看来要遥遥无期。

 【问题1】
 分析出现这种情况的原因
 【问题2】
  如果你是小李，你怎样在合同谈判、计划和执行分别进行项目范围管理？     【问题3】
  请说明合同的作用，详细范围说明书的作用，以及两者之间的关系。

【问题1 回答】
 1、合同签订不够好，不够细，导致理解有歧义；

 2、甲方没有对各部门的需求有统一的管理和组织规程；

 3、缺乏变更的控制过程；

 4、缺乏对乙方项目干系人的分析，缺乏足够的信息来源，范围定义不全面、不准确。

 5、双方未能就项目范围达成一致认可或承诺。

 6、缺乏项目生命周期的范围控制。

 7、缺乏客户与用户参与。

【问题2 回答】

 本问题实际上是考察我们的项目范围管理的方法和工具技术的运用。

 在项目生命周期的范围管理控制中，小李需要对不同的阶段给出相应的解决方  案。

1、  合同谈判阶段

1）  取得明确的工作说明书或更细化的合同条款

2）  在合同中明确双方的权利和义务，尤其关于变更问题

3）  采取措施使合同签约双方对合同的理解保持一致。

说明：

本质上合同谈判阶段所产生的工作说明书和合同均作为范围计划编制的输入文档。

2、  计划阶段

1）  编制项目范围说明书

2）  创建项目工作分解结构WBS

3）  制定项目的范围管理计划

3、  执行阶段

1）  在项目执行过程中加强对已分解任务的跟踪和控制记录

2）  建立和项目干系人统一的沟通渠道

3）  建立整体变更控制规程并执行

4）  加强对项目阶段性成果的评审和确认

4、  项目全生命周期范围变更管理

1）  在项目管理体系中包括一套严格、实用、高效的变更程序

2）  规定对用户的范围变更请求，应正式提出变更申请，并经过双方项目经理审核后，作影响分析，视不同的情况，做相应的处理

5、  项目全生命周期变更管理

【问题3 回答】

【合同法】：“合同是平等主体的自然人、法人、其他组织之间设立、变更、终止民事权利义务关系的协议”，是买卖双方共同遵守的协议，买方有义务支付  合同规定付款，卖方有义务提供合同指定的产品和服务。

    项目范围说明书详细说明了项目可交付物和产生这些可交付物所必须做的  项目工作。它在所有项目干系人之间建立了一个对项目范围的共识，描述了项  目的主要目标，使团队能够进行更详细的规划，指导团队在项目实施期间的工  作，并为评估是否为客户需求进行变更是否在项目范围之内提供基线。详细的  范围说明书包括如下内容：

1）  项目和范围的目标

2）  产品范围描述

3）  项目边界

4）  项目可交付物

5）  产品可接受标准

6）  项目的约束条件

7）  项目的假定

 合同是制定项目范围说明书的依据。

点评：

     案例分析是最接近于项目管理实践的，首先要要善于发现问题，发现问题的根源就已经解决了问题的一半，通过案例表像发现现象产生的原因分析，然后，在联想到项目管理知识体系PMPOK的相关工具方法和技术，对症下药，从而解决问题，这是案例分析的基本思路，同样是项目管理实践的基本思路。（铁歌整理）