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