软考高项论文范围管理常见子题目

项目范围管理的含义是关注项目内容的定义和控制,明确并确保哪些内容包含在项目中以作为项目开发的各项工作落实的依据。项目范围管理的作用是确保项目包含且只包含达到项目成功所必须完成的工作,同时通过有效的项目范围管理,就项目的建设范围在干系人中达成共识,确保项目范围的变更合理和受控。

业界数据显示,大部分的失败项目不是失败在技术上,而是失败在项目范围没有管理好。作为一个有多年信息系统项目建设经验的项目经理,我一直非常清楚,项目范围是一个信息系统项目建设成功的关键。项目范围管理得好,范围就是万善之源;如果没有管理好,范围就是万恶之源。因此我们说项目范围对项目的意义是成败的起点和根源,一点也不为过。

项目范围管理就是要确定哪些工作是项目该做的,哪些工作是不该做的。如果项目范围不明确,我和我的团队成员把时间浪费到不属于我们职责的工作上,就可能引起项目的进度延误、成本提高、质量无法保证等一系列连锁反应,甚至造成交付的产品与客户需求不一致。

作为项目经理,我深知做好计划的重要性,好的计划是成功实施项目的基础,为后续工作提供指南和方针范围管理明确该项目哪些工作需要完成,哪些不需要做,在了解项目初步范围基础上,我组织会议,召集项目组成员依据项目管理计划、项目章程、采用公司组织过程资产的计划模板,结合以往项目的成功经验,制定了范围管理计划、需求管理计划。考虑到项目组成员相关经验的局限性,为了保证计划的准确性,我们又采用专家判断方法作为对计划论证的补充,我们邀请运维方面关于技术和经济方面的专家5人,根据专家的丰富经验,对我们计划的完善提出了很多建设性意见,包括如何进行范围定义、制定、确认、监督和控制以及如何进行WBS的分解及如何对项目的需求进行定义确定、记载、核实和控制

范围管理计划和需求管理计划见《论文中涉及的图表汇总》

见《论文中涉及的图表汇总》

项目范围说明书主要内容:①产品范围描述②验收标准③可交付成果④项目的除外责任⑤制约因素⑥假设条件

定义范围的主要目的是制定详细的范围说明书,明确所收集的需求中,哪些属于项目范围内,哪些属于项目范围外。从而明确产品和服务的边界。在收集完需求后,我组织各干系人,依据范围管理计划、需求文件中的内容,通过产品分析技术,反复沟通和讨论,制定了范围说明书,并得到项目各干系人的批准和认可。项目范围说明书主要描述和规定了产品范围、可交付成果、项目验收标准、项目边界、项目约束条件等。其主要作用是确定了项目可交付成果和要完成的工作,可作为沟通管理、范围变更的主要依据。

范围说明书见《论文中涉及的图表汇总》

在创建WBS的时候,已经识别出WBS中最底层的可交付成果物:工作包。为了更好的规划项目,工作包通常应该进一步细分为更小的组成部分,即活动。活动与工作包的关系可以是一对一的关系,也可以是一对多的关系。也就是说有可能多个活动完成一个工作包。定义活动的主要作用就是将工作包分解为活动的过程,作为项目进程估算,进度规划执行,监督和控制的基础。

原则、作用意义:

我们进行WBS分解时制定了如下原则:在各层次上都保证项目的完整性;一个工作单元只从属于一个上层工作单元;相同层次的工作包应有相同性质;工作单元应便于进行进度和成本的控制;工作包一般不大于80小时;采用滚动规划,不求一次把所有工作包都分解出来。对于WBS中工作单元的细节信息,我们在WBS字典中加以描述。WBS分解是一项很重要的工作,在这一过程中我们发现《项目范围说明书》中存在较多不明确的方面,通过WBS分解而得到明确。WBS分解工作完成后,项目范围基准就确定了

步骤:WBS分解的五个步骤

1)识别和分析可交付成果及相关工作

2)确定WBS结构和编排方法

3)自上而下逐层细化分解

4)为WBS组件制订和分配标识编码

5)核实可交付成果分解的程度是否恰当

方法:WBS分解的方法

据此我们的WBS分成四层,第一层是按照子系统划分的,包括十四个子系统和项目管理;第二层是按定义需求、设计、编码、测试、验收等生命周期来划分的;第三层是对第二层的进一步细化,比如定义需求又分成需求调研、需求分析、需求定义和需求验证等;第四层是对第三层的进一步细分,比如需求调研又分成客户现场访谈、会议、建立原型等。

2种结构:WBS的2种结构(分级树形、表格型)

在项目范围管理过程中,我个人认为最难做好的是WBS分解,因为分解WBS虽然容易,但要分解到合适却不容易。为了做到这一点,我们让从事设计和编码的人员参与WBS的分解,实践证明这样做既符合后续设计和编码的人员实际的能力水平(因为自己最了解自己),又能得到他们最大可能的认同和配合(因为自己做的事情自己最认可);由于该项目我们采用的是滚动式规划,即已经明确的需求先分解,需求暂时不明确的,先做为规划包,等待需求明确后再分解。每次WBS分解后,我们都会和创建WBS的同事一起审核被分解到的所有工作包是否符合这三个标准:可估算,可分工,可控制。对于不能同时满足这三个条件的工作包,我们一定会再次分解和修订,直至满足这三条标准为止。

WBS分解图见《论文中涉及的图表汇总》

项目范围说明书以及后续的各项可交付成果及时得到发起人或客户的签字验收,能大大提升项目的成功率。确认范围和质量控制的区别体现在三个方面。分别是执行顺序,实施时点,强调的侧重点

确认范围一般在质量控制之后施行,或者两者同时进行。确认范围一般在阶段末进行,而质量控制并不一定需要在阶段末施行。质量控制属于内部检查,由执行组织的相应质量部门进行;确认范围一般由外部干系人或发起人来实施。

质量控制强调的是可交付成果的正确性,确认范围强调的是可交付成果获得客户或发起人的确认与验收

确认范围和项目收尾的区别与联系主要体现在以下两个方面:两者都在阶段末进行。确认范围强调可交付成果物的验收,项目收尾强调的是产品的验收。是除了成果物验收之外,项目收尾还需要做流程性的工作。

范围控制是监控项目范围状态,确保所有请求的变更和采取的纠正行动,都要通过整体变更控制过程处理。一般来说,范围变更源自于用户的前期需求未正确识别或用户中后期新增需求,少数情况下也会出现项目团队内部的范围蔓延,也就是镀金。因此在项目中,我定期组织召开项目状态审查会,审查项目的范围,通过对照范围基础,找出范围偏差,并做分析,严格杜绝一切的范围蔓延以及镀金。例如:在一次状态审查会上,我发现项目的功能模块中,库存管理模块多了盘库功能,我查了一下系统变更日志,未找到有类似的变更记录,于是我参照责任分配矩阵,分别找到这个模块开发的负责人询问原因,A成员则是因为在开发库存管理模块时,发现整个库存管理没有库存盘点的功能,他认为做库存管理,肯定需要用到盘点功能,而且这是个亮点,所以他私自增加了这一功能。针对这两种情况,我首先向这名成员强调了范围基准、以及变更流程的重要性;其次,针对这项多出来的功能,我要求相关人员提交正式的变更申请,走正常的变更控制流程。从事项目管理工作的我深知,项目范围不是一经定义,就一成不变的,项目干系人出于项目利益以及各种情况考虑,总会有一些需求变更,管理这些变更,就需要在项目规划时,就制定好变更控制流程以及成立一个专门的需求变更控制委员会(CCB),因此,我和我的团队在项目早期就制定了一套标准的变更流程:1.提交变更申请;2.评估变更;3.报CCB审批;4.实施变更并调整基准;5.将变更信息通知相关干系人;6.对变更的结果进行追踪与审核。有了这些流程以及CCB的控制,项目的需求变更得以良性发展,变更带来更多是项目利益以及效率的提升。

如何做好项目范围控制,防止项目范围蔓延:

第一,定义科学合理的范围变更控制流程

第二,甲乙双方明确范围或需求变更的接口人

第三,所有变更一律要求书面化

第四,严格按范围变更控制流程执行范围变更,绝不允许有特例

以上四点做到位,则能很好的防止项目范围蔓延。

如何防止范围蔓延

如果做好以下的五点,可以很好的防止范围蔓延

(1)在收集需求时彻底理解客户的需求;

(2)对所有的需求,变更请求都书面记录,不接受口头的变更申请;

(3)事先编制项目范围管理计划,并规划定义范围控制流程;

(4)规范确认范围过程,必须接受干系人综合评审;

(5)强调完工时间和预算的重要性;

我认为引起项目范围变更的因素主要有三个方面。第一,前期范围调研不充分,范围描述的不准确;第二,用户出现新的需求;第三,政策改变导致范围变更。

变更流程:

发起变更;②填写需求变更申请表;③分析变更对项目的影响;④将评估结果发给需求变更发起人审批;⑤将需求变更申请表及其结果发给CCB审批;⑥执行变更;⑦记录变更和实施情况;⑧归档需求变更的实施结果

范围变更控制的主要工作有哪些?

(1)影响导致范围变更的因素,并尽量使这些因素朝有利的方面发展;

(2)判断当前范围是否发生变更;

(3)范围变更实际发生时,确保所有被请求的变更按照项目整体变更控制过程处理范围控制的重要性;

范围控制是监督项目和产品的范围状态,管理范围基准变更的过程。信息系统项目发生变更请求在所难免,但如果不对项目范围基准进行有效的控制,不采用范围控制过程来管理实际的变更的话,就会出现未经批准的变更,甚至是项目范围的扩大。发生项目范围蔓延的风险。

我认为需求开发就是需求从调研开始到被双方认可的这一过程,因此需求开发一般包括需求获取,需求分析,需求定义和需求验证这四个主要活动;而需求管理就是针对需求开发这一过程,进行有效的跟踪和维护,确保需求被正确的开发出来,从而为后续工作顺利进行提供保障,因此需求管理是为需求开发提供服务的一个管理手段;范围管理则是针对项目所要完成的全部工作进行规划,识别,分解,确认和控制,从而达到做好了该做的工作这一目标。

(1)范围与进度管理的关系:

分解完WBS工作包后,紧接着需要定义活动。

当进度落后成本超支时,可以在甲方同意的基础上,适当的减少范围来挽回进度;有了项目范围基准以后,才能安排进度计划;

如果出现了范围蔓延,那么必将对进度造成负面影响。

范围基准包括项目范围说明书WBS和WBS词典,可用于定义活动,持续时间估算和进度管理

WBS中有一个控制账户的概念,它是定义WBS中用于进度成本绩效测量的结点;

(2)进度管理与范围管理的关系:

范围基准是规划进度管理的输入之一,可用于定义活动,持续时间估算和进度管理。

在定义活动时需明确考虑范围基准中的WBS可交付成果,制约因素和假设条件

估算活动持续时间时,需要考虑项目范围说明书中所列的假设条件和制约因素。

控制进度的输出有工作绩效信息,里面针对WBS组件,工作包和控制账户,计算出进度偏差与进度绩效指数,并记录下来传达给干系人。

(3)范围与质量的关系:

质量控制一般在确认范围前进行,也可以同时进行。在质量控制过程中将可交付成果进行确认,在范围确认过程中再将确认的可交付成果进行核实;

(4)范围与干系人的关系:

在收集需求的过程中,使用到了干系人管理计划和干系人登记册作为输入;

确认范围包括与客户或发起人一起检查可交付成果,确保可交付成果圆满完成,并获得客户或发起人的正式验收。

我们在与客户干系人进行可交付成果验收的时候要让客户意识到确认范围虽然是正式的,但这并不意味着该项目的范围就是铁板一块,不能再修改了。

(5)范围管理与沟通管理的关系:

在收集需求中的工具与技术使用了访谈,焦点小组,引导式研讨会,群体决策技术,问卷调查等都需要用到沟通

项目范围说明书的作用就是沟通基础,它表明项目干系人之间就项目范围所达成的共识。确认范围并不是容易的事情,它的不容易主要体现在与用户的沟通上;

(6)范围管理与变更管理的关系:

项目范围说明书也是变更的基础,他为评价变更请求或额外工作是否超出项目边界提供基准;

范围控制过程的主要作用是在整个项目期间保持对范围的维护,管理范围基准的变更的过程

范围基准的变更一定要执行变更控制程序;

(7)范围管理与风险管理的关系:

范围蔓延的风险、收集需求不足的风险项目范围发生变化,则项目10大领域都会受到影响,因为范围变化会导致成本进度质量以及合同等变化;

获取更多软考资料

关注公众号

添加微信好友

© 版权声明
THE END
喜欢就支持一下吧
点赞6赞赏 分享
评论 抢沙发
头像
欢迎您留下宝贵的见解!
提交
头像

昵称

取消
昵称表情

    暂无评论内容