《项目管理及案例分析分析题》由会员分享，可在线阅读，更多相关《项目管理及案例分析分析题（21页珍藏版）》请在金锄头文库上搜索。
1、案例分析一：项目管理过程 项目背景 某市电子政务信息系统工程，总投资 500 万，主要包括网络平台建设和业务办公应用系统开发，通过公开招标， 确定工程的承建单位是 A 公司，按照合同法的要求与 A 公司签订了工程建设合同，并在合同中规定 A 公司可 以将机房工程这样的非主题、非关键性子工程分包给具备相关资质的专业公司 B，B 公司将子工程转手给了 C 公司。在随后的应用系统建设过程中，监理工程师发现 A 公司提交的需求规格说明书质量较差，要求 A 公司进行整改。 此外，机房工程装修不符合要求，要求 A 公司进行整改。 项目经理小丁在接到监理工程师的通知后，对于第二个问题拒绝了监理工程师的要求，
2、理由是机房工程由 B 公司 承建，且 B 公司经过了用户方的认可，要求追究 B 公司的责任，而不是追究自己公司的责任。对于第一个问题， 小丁把任务分派给程序员老张进行修改，此时，系统的设计工作已经开始，程序员老张独自修改了已进入基线的 程序，小丁默许了他的操作。老张在修改了需求规格说明书后采用邮件通知了系统设计人员。 合同生效后，小丁开始进行项目计划的编制，开始启动项目。由于工程紧张，甲方要求提前完工，总经理比较关 心该项目，询问项目的一些进展情况，在项目汇报会上，小丁向总经理递交了进度计划，公司总经理在阅读进度 计划后，对项目经理小丁指出任务之间的关联关系不够清晰，要求小丁重新更改一下计划,
3、新的项目计划出来了， 在计划实施过程中，由于甲方的特殊要求，需要项目提前 2 周完工，小丁又更改了项目进度计划，项目最终按时 完工。 案例问题 问题 1 小丁在合同生效后进行的项目计划编制工作应该如何进行？ 小丁在接到任务后开始项目计划的编制工作，应包括： 项目总计划：范围计划、工作范围定义、活动定义、资源需求、资源计划、活动排序、费用估算、进度和费用计 划 项目辅助计划：质量计划、沟通计划、人力资源计划、风险计划、采购计划等 问题 2 小丁在处理监理工程师提出的问题上处理是否正确？你作为项目经理，应该如何处理？ 依据中华人民共和国招投标法第 48 条：中标人应当根据合同约定履行义务，完成中标
4、项目。中标人不得向他 人转让中标项目，也不得将中标项目肢解后分别向他人转让。中标人按照合同约定或经招标人同意，可以将中标项目的部分非主体、非关键性工作分包给他人完成。接受分 包的人应具备相应的资格条件，并不得再次分包。 本案例中，A 公司将子项工程分包给 B，B 又将其分包给 C，显然违背了招标法第 48 条规定“中标人应当就分 包项目向招标人负责，接受分包的人就分包项目承担连带责任” ，A 公司显然要承担责任，B 公司也负连带责任 问题 3 在项目执行过程中，由于程序员老张独自修改了以进入基线的程序，小丁默许了他的操作，小丁的处理方式是否 正确？你作为项目经理，应该如何处理？ 项目经理小丁不
5、应默许老张的行为，且修改后的东西没有经过评审。项目缺乏变更控制体系，同时，项目团队其他成员不清楚变更程序的步骤和要求。 建立配置管理体系 建立变更请求流程 组建变更控制委员会 CCB 问题 4 该案例中，项目管理的哪些方面需要改进？从项目管理 9 大知识体系出发阐述改进方面；本项目管理交弱的方面是重点改进方向： 项目经理法律法规的理解（招投标管理） 项目进度管理 项目变更控制配置管理和计划的变更将导致成本、质量的变化 案例分析二：项目变更控制 项目背景 某软件中心（A 方）承担了某大型上市公司（B 方）ERP 系统开发与实施项目。项目计划确定后，在实施过程中， 几次发生计划变更，原因如下： （
6、1）证监会要求上市公司执行新的会计制度，需要修改 ERP 系统财务子系统； （2）B 方首付资金未能按时支付，导致 A 方开发计划推迟； （3）A 方盲目确定进度目标，实际难以完成； （4）B 方因机构重组改变了业务流程，需要修改项目范围； （5）A 方的前期设计有疏漏，需要修改设计方案； （6）B 方提出增加合同审计功能，需要修改项目范围； （7）由于 B 方需求表达不清，A 方理解有误，双方沟通不够，导致项目实施时发现需求偏差，需要纠偏； （8）B 方自行负责的机房工程延误，影响了实施进度； （9）A 方开发人员跳槽，影响了开发进度； （10）B 方行业主管部门发布了新的行业 ERP 实施
7、规范，需要修改项目实施方案。 案例问题 问题 1 项目变更的内部因素和外部因素分别指什么？ 由项目执行偏差导致项目计划变更的各种诱发因素称为项目变更的内部因素。由项目目标变化导致项目计划变更的各种诱发因素称为项目变更的外部因素。 问题 2 上述 5 条变更，哪些属于内部因素？哪些属于外部因素？ （2） （3） （5） （7） （8） （9）属于项目变更的内部因素；（1） （4） （6） （10）属于项目变更的外部因素 问题 3 由于内部因素导致变更，从而可能增加建设经费？是否一定要由承建方承担？ （3） （5） （9）属于 A 方责任，由此增加的项目费用由 A 方承担；（7）属于双发责任，A、
8、B 双方协商分摊；其余各条，无论 B 方是否负有责任，均应承担由此增加的项目费用。 问题 4 对于由于内部因素和外部因素引发的变更请求，变更评估的重点有何不同？对于由内部因素引起的变更请求，变更评估的重点是确定最优变更方案；对于由外部因素引起的变更请求，应重点评估变更的必要性。案例一：范围定义案例一：范围定义 项目背景 黎明信息技术有限公司原本是一家专著于企业信息化的公司，在电子政务如火如荼的时候，开始进军电子政务行 业。在电子政务的市场中，承接的第一个项目是开发一套工商审批系统。 由于电子政务保密要求（国家要求） ，该系统涉及到两个互不联通的子网：政务内网和政务外网。政务内网中储存 着全部信
9、息，其中包含部分机密信息；政务外网可以对公众开放，开放的信息必须得到授权。 系统要求在这两个子网中的合法用户都可以访问到被授权的信息，访问的信息必须一致可靠，政务内网的信息可 以发布到政务外网，政务外网的信息在经过审批后可以进入政务内网系统。 丁伟是该项目的项目经理，在捕获到这个需求后认为电子政务项目建设和企业 MIS 项目有很大不同，有其特殊性， 若照搬企业信息化项目原有的经验和方法必定失败。 丁伟在该项目中采用了严格的瀑布模型，并专门招聘了熟悉网络互联互通的技术人员参与设计了解决方案，在经 过严格评审后开始实施项目。 在项目交付时，虽然系统完全满足了项目保密性要求，但用户对系统用户界面提出
10、了较大异议，认为不符合政务 信息系统的要求和风格，操作也不够便捷，要求彻底更换。由于最初设计的缺陷，系统表现层和逻辑层紧密耦合，导致 70%的代码重写，而第二版的用户界面仍然没有达到 用户的要求，最终又重写了部分代码才勉强通过用户验收。由于整个项目反复变更，项目组成员产生了强烈的挫 折感，士气低落，项目工期也必原先的计划超出一倍，项目成本超出预算的 100%，项目用户满意度较低。 该项目最终的结果与公司的期望偏差很大，黎明公司决定暂时放弃进军电子政务市场，并要求相应的事业部进行 业务转型，大幅度裁员，骨干技术人员流失严重！ 问题 1 如何评估丁伟的项目管理行为？ 1.注意到了系统运行环境的特殊
11、性，在良好设计和实现的情况下满足了用户要求 2.忽略了系统用户的潜在要求，在用户界面和操作风格上范围定义不清，造成项目交付时产生重大变更 3.第一次问题发生后仍没有对范围进行有效管理，造成项目第二次变更 4.没有对用户界面是否能够满足要求的风险进行有效的管理，而采用抗风险较弱的瀑布模型组织开发 5.没有对设计的质量进行有效控制，造成表现层和业务逻辑层紧密耦合，直接导致增加了变更代价 问题 2 从项目范围管理的角度找出项目实施过程中的管理问题？ 1.没有挖掘到系统的全部隐形需求，缺乏精确的范围定义 2.当发生第一次变更时，丁伟仍没有进行有效的范围管理，直接造成项目的第二次变更 3.重复的系统变更
12、说明丁伟对项目范围控制不足，导致项目范围接二连三的变更、反复 问题 3 从范围管理的角度出发，如何避免类似问题的发生？ 有效的范围管理包括了从范围定义到范围控制等众多方面的工作，每一项工作都是重要的 1.结合行业特点进行需求分析充分挖掘系统隐形需求 2.通过原型法来验证需求的定义，避免范围定义不清的问题 3.在发生需求变更时应进行有效的需求控制，在满足用户需求前提下缩小需求范围，避免需求再次变更 案例点评 这是一个失败的项目，丁伟在项目管理过程中既有闪光的地方，也要失败的地方； 项目范围管理的失误是造成失败的关键原因: 模糊的范围定义 错误的工作分解 缺失的范围确认 无力的范围控制 也暴露出风
13、险管理、系统设计方面的问题 案例分析 丁伟对项目范围有一定把握（闪光点） 发现了不同行业间具有不同的特点 捕获到了政务内、外网的需求，并进行了定义，严格控制了这一需求的设计和实现 如果忽视这一行业标准，项目将招致更大的失败 丁伟对于像用户界面的风格和操作便捷性的需求没有充分考虑，导致一而再，再而三的变更 没有意识到系统“隐形需求”的重要性 行业特点决定范围约束（用户界面、操作便捷性） 丁伟对项目范围和需求的定义理解并不完整 电子政务行业特点，使对项目范围定义更加困难 最终用户不参加需求和开发工作 需求的间接性 丁伟在范围确认和范围控制方面存在失误 第一次变更就应该充分认识界面、操作的重要性 应
14、该立即采取措施清晰的定义界面风格、操作风格 丁伟没有进行充分的风险管理 隐形行规和行业特点意味着项目范围定义的风险 采用瀑布模型增加了风险发生后带来的损失这个案例中，缺乏良好的设计也是明显的缺陷 用户界面中耦合了大量的业务逻辑，增加了变更代价 总结语总结语 项目的闪光点在于对项目运行环境进行了清晰的定义，并最终满足了用户的要求 不充分的范围定义和范围确认导致了项目的失败 采用抗风险较弱的瀑布模型和低质量的设计增加了项目范围变更得代价 案例二：范围管理工作要点案例二：范围管理工作要点 项目背景 A 集团是黎明信息技术有限公司的多年客户，黎明公司已经为其开发了多个信息系统，最近 A 集团又和公司签
15、订 了新的开发合同，以扩充整个企业信息系统的业务范围； 张凡被任命为该项目的项目经理。项目经理张凡组织相关人员对该项目的工作进行了分解，并参考了黎明公司和 A 集团曾经合作的项目，评估得到项目总工作量为 60 人月，计划工期为 6 个月。 项目刚刚开始不久，张凡的高层经理孙总找到张凡，孙总表示由于公司运作的需要，要求张凡在 4 个月内完成项 目，考虑到压缩工期的现实，可以为该项目增派两名开发人员。 张凡认为，整个项目的工作量是经过仔细分解后评估得到的，评估过程也参考了历史上与 A 集团合作的项目度量 数据，该工作量是客观现实的。目前项目已经开始，增派新的开发人员还需要一定时间的熟悉，因此即使增
16、派两 人也很难在四个月内完成项目，如果强行要求项目组成员通过加班加点方式追逐 4 个月完成项目的目标，肯定会 降低项目的质量，造成用户的不满。 对此，张凡提出的解决方案是：将整个项目分成两部分实现，第一部分使用三个半月的时间，第二部分使用三个 月的时间，分别制定出两部分的验收标准，这样不增派开发人员也能完成项目。 高层经理孙总认为该方案可以满足公司运作的要求，用户也同意按照这种方案进行实施。 六个半月以后，项目在没有增加人员投入的情况下顺利完成，虽然整个项目比最初的计划延长了半个月，但既达 到了公司的要求，客户对交付的系统也比较满意，项目成员也没有感受到很大的压力。 问题 1 点评张凡是如何应对项目范围变更的，采取了哪些措施？ 1.首先对最初的项目范围进行了清晰的定义，并根据定义对项目任务进行了分解，制定了 WBS 2.对项目进行了估算，且估算结果真实可信，对项目工作量有量化的把握 3.在出现新的项目目标后，对项目范围进行了控制，缩小了第一阶段实现的项目范围 4.对重新定义的项目范围进行了确认，与高层经理和客户达成了一致 5.对项目进行了沟通管理，协调了多个项目关系人之
