项目综合案例分析

案例二：范围管理工作要点
案例问题
问题1
• 点评张凡是如何应对项目范围变更的，采取了哪些措 施？
问题2
• 结合案例指出项目范围管理的工作要点？
案例二：范围管理工作要点
案例点评 这是一个成功的项目管理案例，项目经理张凡有 效的运用范围管理手段，在不同项目干系人中达 成一致，使项目的结果同时满足了公司高层经理、 客户、项目组成员的要求。 作为一个项目经理，必须熟练掌握和应用项目管 理九大知识领域的技能，对于信息系统开发项目 而言，范围管理是其中最重要的技能之一。
案例二：范围管理工作要点
岐兵 qib@epsoft.com.cn
案例二：范围管理工作要点
项目背景 A集团是黎明信息技术有限公司的多年客户， 黎明公司已经为其开发了多个信息系统，最近 A集团又和公司签订了新的开发合同，以扩充 整个企业信息系统的业务范围； 张凡被任命为该项目的项目经理。
1. 注意到了系统运行环境的特殊性，在良好设计和实 现的情况下满足了用户要求 2. 忽略了系统用户的潜在要求，在用户界面和操作风 格上范围定义不清，造成项目交付时产生重大变更 3. 第一次问题发生后仍没有对范围进行有效管理，造 成项目第二次变更 4. 没有对用户界面是否能够满足要求的风险进行有效 的管理，而采用抗风险较弱的瀑布模型组织开发 5. 没有对设计的质量进行有效控制，造成表现层和业 务逻辑层紧密耦合，直接导致增加了变更代价
案例一：范围定义
案例问题
问题1
• 如何评估丁伟的项目管理行为？
问题2
• 从项目范围管理的角度找出项目实施过程中的管理问 题？
问题3
• 从范围管理的角度出发，如何避免类似问题的发生？
பைடு நூலகம்
案例一：范围定义
案例点评 这是一个失败的项目，丁伟在项目管理过程中既 有闪光的地方，也要失败的地方； 项目范围管理的失误是造成失败的关键原因；
案例三：范围确认
案例场景 进入编码阶段后，李伟因故移民加拿大，需要离开项目 组，王强考虑到系统需求已经定义，项目也进入编码阶 段，李伟的离职虽然会对项目造成一定影响，但影响较 小，因此很快为其办好离职手续。 在系统交付的时候，M公司的业务代表认为甲方已经提 出的需求很多没有实现，实现的需求也有很多不能满足 M公司现有的业务要求，必须全部实现这些需求后才能 验收。此时，李伟已经离开项目组，没有人能够清晰地 解释乙方已经完成的需求说明书。 最终系统需求发生重大变更，项目延期超过50%，M的 业务代表也因为系统的延期表示了强烈的不满。
案例二：范围管理工作要点
案例分析 软件项目的范围变更应重新进行项目计划的调整
• 将项目分解成两部分，实际上项目范围已经被扩大了 • 范围变化导致任务、任务之间的逻辑关系的重新调整 • 需要考虑分割项目的验收标准，这是与用户达成一致的前提

范围控制并非总是针对客户的要求而进行的
• 控制项目范围＝控制需求，这个公式是错误的 • 设计策略是项目经理可以把握的（够用策略、牺牲质量特性策 略、过度设计） • 即使需求已经确定，有效的范围管理仍能给项目带来巨大收益 • 范围管理的空间很大，带来的收益是降低成本、缩短工期
丁伟对于像用户界面的风格和操作便捷性的需求
没有充分考虑，导致一而再，再而三的变更
• 没有意识到系统“隐形需求”的重要性 • 行业特点决定范围约束（用户界面、操作便捷性）
丁伟对项目范围和需求的定义理解并不完整
案例一：范围定义
案例分析 电子政务行业特点，使对项目范围定义更加困难
• 最终用户不参加需求和开发工作 • 需求的间接性
• • • • 模糊的范围定义 错误的工作分解 缺失的范围确认 无力的范围控制
也暴露出风险管理、系统设计方面的问题
案例一：范围定义
案例分析 丁伟对项目范围有一定把握（闪光点）
• 发现了不同行业间具有不同的特点 • 捕获到了政务内、外网的需求，并进行了定义，严格 控制了这一需求的设计和实现 • 如果忽视这一行业标准，项目将招致更大的失败
案例二：范围管理工作要点
案例分析 软件项目的范围主要是由系统需求构成的，而系 统需求既是难以把握的，也是容易调整和控制的
• 在满足项目目标前提下，可以定义出不同的系统需求 • 根据经验，软件项目管理总是从范围管理开始，先定 义系统的边界，然后再在明确的范围内进行时间、成 本、质量和风险的管理 • 范围、时间、成本、质量之间的逻辑关系是项目管理 的客观规律 • 当范围因素已经确定的条件下，不妨根据时间、资源 （成本）的重新计划来调整合理的项目范围
案例一：范围定义
问题解答 问题2：从项目范围管理的角度找出项目实施 过程中的管理问题？
1. 没有挖掘到系统的全部隐形需求，缺乏精确的范围 定义 2. 当发生第一次变更时，丁伟仍没有进行有效的范围 管理，直接造成项目的第二次变更 3. 重复的系统变更说明丁伟对项目范围控制不足，导 致项目范围接二连三的变更、反复
案例二：范围管理工作要点

案例场景



项目经理张凡组织相关人员对该项目的工作进行了分 解，并参考了黎明公司和A集团曾经合作的项目，评估 得到项目总工作量为60人月，计划工期为6个月。 项目刚刚开始不久，张凡的高层经理孙总找到张凡， 孙总表示由于公司运作的需要，要求张凡在4个月内完 成项目，考虑到压缩工期的现实，可以为该项目增派 两名开发人员。 张凡认为，整个项目的工作量是经过仔细分解后评估 得到的，评估过程也参考了历史上与A集团合作的项目 度量数据，该工作量是客观现实的。目前项目已经开 始，增派新的开发人员还需要一定时间的熟悉，因此 即使增派两人也很难在四个月内完成项目，如果强行
案例场景 由于该项目是一个现有系统的升级项目，王强特意请来 了原系统的需求调研人员李伟担任该项目的需求调研负 责人。 在李伟的帮助下，很快完成了需求分析的工作，并进入 设计和编码，由于M公司的业务非常繁忙，M公司的业 务代表没有足够时间投入到项目中，确认需求的工作一 拖在拖。 王强认为双方已经建立了密切合作的关系，李伟也已经 参加了原系统的需求开发工作，对M公司的业务比较熟 悉，因此定义的需求是清晰的，故王强并没有催促业务 代表在需求说明书中签字。
案例一：范围定义
案例场景 由于最初设计的缺陷，系统表现层和逻辑层紧密耦合， 导致70%的代码重写，而第二版的用户界面仍然没有达 到用户的要求，最终又重写了部分代码才勉强通过用户 验收。由于整个项目反复变更，项目组成员产生了强烈 的挫折感，士气低落，项目工期也必原先的计划超出一 倍，项目成本超出预算的100%，项目用户满意度较低。 该项目最终的结果与公司的期望偏差很大，黎明公司决 定暂时放弃进军电子政务市场，并要求相应的事业部进 行业务转型，大幅度裁员，骨干技术人员流失严重！
丁伟在范围确认和范围控制方面存在失误
• 第一次变更就应该充分认识界面、操作的重要性 • 应该立即采取措施清晰的定义界面风格、操作风格
丁伟没有进行充分的风险管理
• 隐形行规和行业特点意味着项目范围定义的风险 • 采用瀑布模型增加了风险发生后带来的损失
案例一：范围定义
案例分析 这个案例中，缺乏良好的设计也是明显的缺陷
案例二：范围管理工作要点
案例分析 案例中，张凡还运用了其他范围管理手段
• 项目刚开始，对项目范围进行了定义 • 划分了项目WBS，并对项目进行了估算、计划 • 在孙总提出缩短工期的要求后，首先进行了范围控制， 缩小了第一步需要完成的项目范围，接着又对两阶段 需要完成的项目范围进行了重新定义 • 制定了两阶段验收标准 • 对重新定义的范围进行了确认，与客户、高层经理达 成一致
案例一：范围定义
案例场景 丁伟是该项目的项目经理，在捕获到这个需求后认为电 子政务项目建设和企业MIS项目有很大不同，有其特殊 性，若照搬企业信息化项目原有的经验和方法必定失败。 丁伟在该项目中采用了严格的瀑布模型，并专门招聘了 熟悉网络互联互通的技术人员参与设计了解决方案，在 经过严格评审后开始实施项目。 在项目交付时，虽然系统完全满足了项目保密性要求， 但用户对系统用户界面提出了较大异议，认为不符合政 务信息系统的要求和风格，操作也不够便捷，要求彻底 更换。
案例三：范围确认
岐兵 qib@epsoft.com.cn
案例三：范围确认
项目背景 黎明信息技术有限公司和M企业签订了一份合同， 合同的主要内容是处理黎明公司以前为M公司开 发的信息系统的升级工作。升级后的信息系统可 以满足M公司新的业务流程和范围； 王强被任命为该项目的项目经理。
案例三：范围确认
案例二：范围管理工作要点

问题解答

问题2：结合案例指出项目范围管理的工作要点？
1. 2. 3. 4. 5. • 制定范围管理计划 进行项目范围定义 项目工作分解WBS 进行项目范围确认 对项目范围进行控制 本案例中，张凡首先进行了范围定义和工作分解，得到清晰的 项目范围；在出现新的项目目标后，张凡进行了范围控制，重 新定义了两个阶段的项目范围；最后，将重新定义的范围与项 目干系人进行了确认
• 用户界面中耦合了大量的业务逻辑，增加了变更代价
总结语
• 项目的闪光点在于对项目运行环境进行了清晰的定义， 并最终满足了用户的要求 • 不充分的范围定义和范围确认导致了项目的失败 • 采用抗风险较弱的瀑布模型和低质量的设计增加了项 目范围变更得代价
案例一：范围定义
问题解答 问题1：如何评估丁伟的项目管理行为？
案例二：范围管理工作要点
案例分析
总结语
• 张凡在范围管理方面进行全面的控制，此外也运用了 其他项目管理手段，包括对项目估算计划（时间管 理），协调多个项目干系人之间的矛盾（沟通管理）
案例二：范围管理工作要点

问题解答

问题1：点评张凡是如何应对项目范围变更的，采取了 哪些措施？
1. 首先对最初的项目范围进行了清晰的定义，并根据定义对项目 任务进行了分解，制定了WBS 2. 对项目进行了估算，且估算结果真实可信，对项目工作量有量 化的把握 3. 在出现新的项目目标后，对项目范围进行了控制，缩小了第一 阶段实现的项目范围 4. 对重新定义的项目范围进行了确认，与高层经理和客户达成了 一致 5. 对项目进行了沟通管理，协调了多个项目关系人之间的矛盾
项目管理综合案例分析
－项目范围管理
岐兵 qib@epsoft.com.cn
案例一：范围定义
岐兵 qib@epsoft.com.cn
案例一：范围定义
项目背景 黎明信息技术有限公司原本是一家专著于企业信息化的 公司，在电子政务如火如荼的时候，开始进军电子政务 行业。在电子政务的市场中，承接的第一个项目是开发 一套工商审批系统。 由于电子政务保密要求（国家要求），该系统涉及到两 个互不联通的子网：政务内网和政务外网。政务内网中 储存着全部信息，其中包含部分机密信息；政务外网可 以对公众开放，开放的信息必须得到授权。 系统要求在这两个子网中的合法用户都可以访问到被授 权的信息，访问的信息必须一致可靠，政务内网的信息 可以发布到政务外网，政务外网的信息在经过审批后可 以进入政务内网系统。
案例一：范围定义
问题解答 问题3：从范围管理的角度出发，如何避免类 似问题的发生？
• 有效的范围管理包括了从范围定义到范围控制等众 多方面的工作，每一项工作都是重要的 1. 结合行业特点进行需求分析充分挖掘系统隐形需求 2. 通过原型法来验证需求的定义，避免范围定义不清 的问题 3. 在发生需求变更时应进行有效的需求控制，在满足 用户需求前提下缩小需求范围，避免需求再次变更
案例二：范围管理工作要点

案例场景




要求项目组成员通过加班加点方式追逐4个月完成项目 的目标，肯定会降低项目的质量，造成用户的不满。 对此，张凡提出的解决方案是：将整个项目分成两部 分实现，第一部分使用三个半月的时间，第二部分使 用三个月的时间，分别制定出两部分的验收标准，这 样不增派开发人员也能完成项目。 高层经理孙总认为该方案可以满足公司运作的要求， 用户也同意按照这种方案进行实施。 六个半月以后，项目在没有增加人员投入的情况下顺 利完成，虽然整个项目比最初的计划延长了半个月， 但既达到了公司的要求，客户对交付的系统也比较满 意，项目成员也没有感受到很大的压力。