案例分析：范围确认

A 公司刚刚和 M 签订了一份新的合同，合同的主要内容是处理公司以前为 M 开发的信息系统的升级工作。升级后的系统可以满足 M 公司新的业务流程和范围。

由于是一个现有系统的升级，项目经理老张特意请来了原系统的需求调研人员李工担任该项目的需求调研负责人。在李工的帮助下，很快地完成了需求开发的工作并进入设计与编码。

由于 M 公司的业务非常繁忙，其业务代表没有足够的时间投入到项目中，确认需求的工作一拖再拖。老张认为，双方已经建立了密切的合作关系，李工也参加了原系统的需求开发，对业务的系统比较熟悉，因此定义的需求是清晰的。故老张并没有催促业务代表在需求说明书中签字。

进入编码阶段后，李工因故移民加拿大，需要离开项目组。老张考虑到系统需求已经定义，项目已经进入编码期，李工的离职虽然会对项目造成一定的影响，但影响较小，因此很快办理好了李工的离职手续。

案例分析：可行性研究问题

在项目计划和选择的过程中，需要完成的首要工作是对项目进行估算。项目估算的范围涉及方方面面，例如项目或产品开发的范围、投入和回报、项目风险、作用和意义等。在传统信息系统工程方法中，是以可行性研究的方式来组织对项目的主要估算内容的。在企业实际的业务过程中，可行性研究通常作为一个重要的环节，被包含在整个项目立项，或项目选择和确认的过程中。

可行性研究的范围可能覆盖很广泛的技术、经济、执行、环境等各种需要评估的因素，但它并不是最后的精细计划(例如：项目的时间进度及人员安排)。通常在进行可行性研究的阶段，甚至项目的目标或产品的最终方向也是高度易变化的。但可行性研究的意义在于，虽然可行性研究不能指出项目最终的精细计划和方向，但可行性研究可以在项目定义阶段用较小的代价识别出错误构思的系统，从而规避未来更多的资源投入的损失(时间、资金、人力、机会)，或者因遭遇到无法逾越的技术障碍或环境障碍导致的不可避免的失败。

案例分享：项目计划编制

某市电子政务信息系统工程，总投资额约 500 万元，主要包括网络平台建设和业务办公应用系统开发，通过公开招标，确定工程的承建单位是 A 公司，按照《合同法》的要求与 A 公司签订了工程建设合同，并在合同中规定 A 公司可以将机房工程这样的非主体、非关键性子工程分包给具备相关资质的专业公司 B，B 公司将子工程转手给了 C 公司。

在随后的应用系统建设过程中，监理工程师发现 A 公司提交的需求规格说明书质量较差，要求 A 公司进行整改。此外，机房工程装修不符合要求，要求 A 公司进行整改。

项目经理小丁在接到监理工程师的通知后，对于第二个问题拒绝了监理工程师的要求，理由是机房工程由 B 公司承建，且 B 公司经过了建设方的认可，要求追究 B 公司的责任，而不是自己公司的责任。对于第一个问题，小丁把任务分派给程序员老张进行修改，此时，系统设计工作已经在进行中，程序员老张独自修改了已进入基线的程序，小丁默许了他的操作。老张在修改了需求规格说明书以后采用邮件通知了系统设计人员。

案例分析：创建工作分解结构

某信息系统项目较为复杂，有许多需要进行的工作，老刘是这个项目的经理，为了更好地制订项目计划，更有效地对项目实施过程进行管理与控制，老刘需要对项目开发过程可能涉及的工作进行分解。老刘的助手对开发过程进行了分解，认为可以划分为 5 大块：确定需要、设计、研发、测试和安装，如下表所示。

老刘认为，制订 WBS 是项目范围管理中的重要过程，一个详细的工作分解结构对项目的管理工作很有好处，但助手的工作分解结构并不完整。

案例分析：一筹莫展的项目经理

老王是一家 IT 公司软件开发部的项目经理，6 个月前他被公司派往新动力贸易集团有限公司（以下简称新动力）现场组织开发财务管理信息系统，并担任项目经理。老王已经领导开发过好几家公司的财务系统，并已形成较为成熟的财务管理软件产品，所以他认为此次去后应当只要适当地做一些二次开发，并根据用户需求作少量的新功能开发即可大功告成。

老王满怀信心地带着他的项目团队进驻新动力了，老王和项目团队在技术上已经历过多次考验，他们在 3 个月的时间就将系统开发完毕，项目很快进入了验收阶段。可是新动力分管财务的陈总认为，一个这么复杂的财务系统在短短的 3 个月的时间里就完成了，这在新动力的 IT 项目中还是首次，似乎不太可能。他拒绝在验收书上签字，并要求财务部的刘经理和业务人员认真审核集团公司及和各个子公司的财务管理上的业务需求，并严格测试相关系统的功能。

财务部的刘经理和相关人员经过认真审核和测试，发现系统开发基本准确，但实施起来比较困难，因为业务流程变更较大。这样一来，又过去了 1 个月，新动力的陈总认为系统还没有考虑集团公司领导对财务的需求，并针对实施较困难的现状，要求项目组从集团公司总部开始，一家一家子公司地逐步推动系统的使用。

案例分析：人员流失对项目的影响

老杨为某分公司项目经理，在接到分公司副总的任命后，负责公司内部营账系统项目的管理工作。

为了更好地选拔项目成员，老杨制订了对项目成员的人员要求计划，从公司现有人员中选拔项目成员。老杨的选择标准依次为学历、资格证书、工作年限、技术方向。按照老杨的要求，一些公司的技术骨干由于学历原因，虽然入选了项目组，但没有被放在骨干的位置上。项目组成员到位后，老杨为量化项目团队成员工作，制订了一系列绩效考核制度，并按照百分制原则按月发放绩效工资。如员工当月绩效分为 90 分，则按照该员工在项目中的岗位，可获得该岗位 90%的绩效工资。

随着项目的开展，一些弊端开始浮上水面。分公司资深老员工吴某为原开发部门技术骨干，但由于学历为中专，在进入项目组后未被放在核心岗位，在架构设计阶段，吴某对老杨所采用的系统架构提出不同意见，而老杨在坚信自己的经验之际，拒绝了吴某的意见。在项目设计和编码阶段，吴某由于技术熟练和编程能力较强，连续 3 个月在绩效分中获得了 200 分，并一直保持全项目团队绩效第一名。按照老杨原告所定的绩效工资制度，吴某应得到某岗位200%的绩效工资，然而在发放项目绩效工资时，老杨认为如果一次发放项目奖金可能会为项目后期带来人员流失风险，于是对所有团队成员扣发展了 30%的绩效工资，承诺项目验收完成后一次性发放扣发的绩效工资。吴某在连续 3 个月只领到 70%的绩效工资后，愤而辞职离开了公司，随后一些绩效分超过 100 分的员工也不断辞职离开了公司，最后项目不了了之，老杨被调往其他分公司任职。