大家好,欢迎来到IT知识分享网。
项目范围管理包括确保项目做且只做所需的全部工作,以成功完成项目的各个过程。
管理项目范围主要在于定义和控制哪些工作应该包括在项目内,哪些不应该包括在项目内。
1、项目范围管理概述
规划范围管理
|
为记录如何定义、确认和控制项目范围及产品范围,而创建范围管理计划的过程
|
规划过程组
|
收集需求
|
为实现项目目标而确定、记录并管理相关方的需要和需求的过程
|
|
定义范围
|
制定项目和产品详细描述的过程
|
|
创建 WBS
|
将项目可交付成果和项目工作分解为较小的、更易于管理的组件的过程
|
|
确认范围
|
正式验收已完成的项目可交付成果的过程
|
监控过程组
|
控制范围
|
监督项目和产品的范围状态,管理范围基准变更的过程
|
项目范围管理概述:
1.1、范围
产品范围,某项产品、服务或成果所具有的特征和功能。
项目范围,为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。项目范围有时也包括产品范围。
1.1.1、预测型、适应型、敏捷型的区别
在预测型生命周期中,在项目开始时就对项目可交付成果进行定义,对任何范围变化都要进行渐进管理。
在适应型或敏捷型生命周期中,通过多次迭代来开发可交付成果,并在每次迭代开始时定义和批准详细的范围。
适应型生命周期,旨在应对大量变更,需要相关方持续参与项目,应将适应型项目的整体范围分解为一系列拟实现的需求和拟执行的工作;预测型项目中,这些过程在项目开始时开展,并在必要时通过实施整体变更控制过程进行更新。
在适应型或敏捷型生命周期中,发起人和客户代表应该持续参与项目,随同可交付成果的创建提供反馈意见,并确保产品未完项反映他们的当前需求。在每次迭代中,都会重复开展两个过程:确认范围和控制范围;在预测型项目中,确认范围在每个可交付成果生成时或者在阶段审查点开展,而控制范围则是一个持续性的过程
在预测型项目中,经过批准的项目范围说明书、工作分解结构(WBS)和相应的 WBS 词典构成项目范围基准。只有通过正式变更控制程序,才能进行基准变更;适应型生命周期的项目,则使用未完项(包括产品需求和用户故事)反映当前需求。
敏捷方法有目的地构建和审查原型,并通过多次发布版本来明确需求。这样一来,范围会在在整个项目期间被定义和再定义。在敏捷方法中,把需求列入未完项。
对于需求不断变化、风险大或不确定性高的项目,在项目开始时通常无法明确项目的范围,而需要在项目期间逐渐明确。
敏捷方法特意在项目早期缩短定义和协商范围的时间,并为持续探索和明确范围而延长创建相应过程的时间。
1.1.2、范围完成的界定
项目范围的完成情况是根据项目管理计划来衡量的,而产品范围的完成情况是根据产品需求来衡量的。
需求:根据特定协议或其他强制性规范,产品、服务或成果必须具备的条件或能力。
需求管理过程结束于需求关闭,即把产品、服务或成果移交给接收方,以便长期测量、监控、实现和维持效益。
确认范围是正式验收已完成的项目可交付成果的过程。
2、 规划范围管理
规划范围管理是为记录如何定义、确认和控制项目范围及产品范围,而创建范围管理计划的过程。
本过程的主要作用是,在整个项目期间对如何管理范围提供指南和方向。
本过程仅开展一次或仅在项目的预定义点开展。
2.1、输出
2.1.1、范围管理计划
范围管理计划是项目管理计划的组成部分,描述将如何定义、制定、监督、控制和确认项目范围。
范围管理计划要对将用于下列工作的管理过程做出规定:
·制定项目范围说明书;
·根据详细项目范围说明书创建 WBS;
·确定如何审批和维护范围基准;
·正式验收已完成的项目可交付成果。
根据项目需要,范围管理计划可以是正式或非正式的。
2.1.2、需求管理计划
需求管理计划是项目管理计划的组成部分,描述将如何分析、记录和管理项目和产品需求。
需求管理计划的主要内容包括(但不限于):
·如何规划、跟踪和报告各种需求活动;
·配置管理活动,例如,如何启动变更,如何分析其影响,如何进行追溯、跟踪和报告,以及变更审批权限;
·需求优先级排序过程;
·测量指标及使用这些指标的理由;
·反映哪些需求属性将被列入跟踪矩阵的跟踪结构
3、 收集需求
收集需求是为实现目标而确定、记录并管理相关方的需要和需求的过程。
本过程的主要作用是,为定义产品范围和项目范围奠定基础,且仅开展一次或仅在项目的预定义点开展。
3.1、工具与技术
系统交互图是产品范围的可视化描绘。
3.1.1、数据收集
访谈:通过与相关方直接交谈,来获取信息的正式或非正式的方法。
焦点小组:焦点小组是召集预定的相关方和主题专家,了解他们对所讨论的产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论。
问卷调查:指设计一系列书面问题,向众多受访者快速收集信息。适用于受众多样化,需要快速完成调查,受访者地理位置分散,并且适合开展统计分析。
标杆对照:将实际或计划的产品、过程和实践,与其他可比组织的实践进行比较,以便识别最佳实践,形成改进意见,并为绩效考核提供依据。
3.1.2、数据表现
亲和图:用来对大量创意进行分组的技术,以便进一步审查和分析。
思维导图:把从头脑风暴中获得的创意整合成一张图,用以反映创意之间的共性与差异,激发新创意
3.1.3、人际关系与团队技能
名义小组技术。 名义小组技术是用于促进头脑风暴的一种技术,通过投票排列最有用的创意,以便进一步开展头脑风暴或优先排序。
观察和交谈。 观察和交谈是指直接察看个人在各自的环境中如何执行工作(或任务)和实施流程。当产品使用者难以或不愿清晰说明他们的需求时,需要观察来了解工作细节。
引导。引导与主题研讨会结合使用,把主要相关方召集在一起定义产品需求。可用于快速定义跨职能需求并协调相关方的需求差异。
3.1.4、系统交互图
系统交互图是范围模型的一个例子,它是对产品范围的可视化描绘,显示业务系统(过程、设备、计算机系统等)及其与人和其他系统(行动者)之间的交互方式
3.1.5、原型法
原型法是指在实际制造预期产品之前,先造出该产品的模型,并据此征求对需求的早期反馈。
原型是有形的实物,它使得相关方可以体验最终产品的模型。
原型法支持渐进明细的理念,需要经历从模型创建、用户体验、反馈收集到原型修改的反复循环过程。
在经过足够的反馈循环之后,就可以通过原型获得足够的需求信息,从而进入设计或制造阶段。
3.2、输出
3.2.1、需求文件
需求文件描述各种单一需求将如何满足与项目相关的业务需求。
需求的类别:
业务需求
|
整个组织的高层级需要
|
|
相关方需求
|
相关方或相关群体的需要
|
|
解决方案需求
|
为满足业务需求和相关方需求,产品、服务或成果必须具备的特性、功能和特征。可细分为功能需求、非功能需求。
|
|
功能需求
|
产品应具备的功能
|
|
非功能需求
|
对功能需求的补充,是产品正常运行所需的环境条件或质量要求。如 性能、安全性等
|
|
过度和就绪需求
|
过渡阶段的临时需要
|
|
项目需求
|
项目需要满足的行动、过程或其他条件
|
|
质量需求
|
用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准
|
3.2.2、需求跟踪矩阵
需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。
使用需求跟踪矩阵:有助于确保每个需求都具有商业价值;有助于确保需求文件中被批准的每项需求在项目结束的时候都能交付;为管理产品范围变更提供了框架。
4、 定义范围
定义范围是制定项目和产品详细描述的过程。
本过程的主要作用是,描述产品、服务或成果的边界和验收标准。
定义范围过程就要从需求文件(收集需求过程的输出)中选取最终的项目需求,然后制定出关于项目及其产品、服务或成果的详细描述。
4.1、工具与技术
4.1.1、产品分析
产品分析可用于定义产品和服务,包括针对产品或服务提问并回答,以描述要交付的产品的用途、特征及其他方面。
先获取高层级的需求,然后将其细化到最终产品设计所需的详细程度。
产品分析技术(但不限于):
产品分解;
需求分析;
系统分析;
系统工程;
价值分析;
价值工程。
4.2、输出
4.2.1、项目范围说明书
1、项目范围说明书定义
项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。
2、项目范围说明书作用
项目范围说明书记录了整个范围,包括项目和产品范围;详细描述了项目的可交付成果;还代表项目相关方之间就项目范围所达成的共识。
3、项目范围说明书包含内容
详细的项目范围说明书包括以下内容:
·产品范围描述,产品、服务或成果的特征。
·可交付成果
·验收标准,可交付成果通过验收前必须满足的一系列条件。
·项目的除外责任,识别排除在项目之外的内容。
4、项目章程与项目范围说明书
项目章程包含高层级的信息,而项目范围说明书则是对范围组成部分的详细描述。项目章程与项目范围说明书如下:
5、 创建 WBS
创建工作分解结构(WBS)是把项目可交付成果和项目工作分解成较小、更易于管理的组件的过程。
WBS 是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解。
工作 是指作为活动结果的工作产品或可交付成果,而不是活动本身。
本过程的主要作用是,为所要交付的内容提供架构,它仅开展一次或仅在项目的预定义点开展。
WBS是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解。
WBS 最低层的组成部分称为工作包,其中包括计划的工作。
工作包对相关活动进行归类,以便对工作安排进度、进行估算、开展监督与控制。
5.1、根据与技术
5.1.2、分解
分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术;工作包是 WBS 最低层的工作,可对其成本和持续时间进行估算和管理。
要把整个项目工作分解为工作包,通常需要开展以下活动:
·识别和分析可交付成果及相关工作;
·确定 WBS 的结构和编排方法;
·自上而下逐层细化分解;
·为 WBS 组成部分制定和分配标识编码;
·核实可交付成果分解的程度是否恰当。
对 WBS 较高层组件进行分解,就是要把每个可交付成果或组件分解为最基本的组成部分,即可核实的产品、服务或成果。
过细的分解会造成管理努力的无效耗费、资源使用效率低下、工作实施效率降低,同时造成 WBS 各层级的数据汇总困难。
要在未来远期才完成的可交付成果或组件,当前可能无法分解。项目管理团队因而通常需要等待对该可交付成果或组成部分达成一致意见,才能够制定出 WBS 中的相应细节。这种技术有时称做滚动式规划。
WBS 包含了全部的产品和项目工作,包括项目管理工作。通过把 WBS 底层的所有工作逐层向上汇总,来确保既没有遗漏的工作,也没有多余的工作。这有时被称为 100% 规则。
5.2、输出
5.2.1、范围基准
范围基准是经过批准的范围说明书、 WBS 和相应的 WBS 词典,只有通过正式的变更控制程序才能进行变更。
范围基准是项目管理计划的组成部分,包括:项目范围说明书、WBS、工作包、规划包、WBS词典。
WBS 的最低层级是带有独特标识号的工作包。每个工作包都是控制账户的一部分,而控制账户则是一个管理控制点。在该控制点上,把范围、预算和进度加以整合,并与挣值相比较,以测量绩效。控制账户拥有两个或更多工作包,但每个工作包只与一个控制账户关联。
6、 确认范围
确认范围是正式验收已完成的项目可交付成果的过程。
本过程的主要作用是,使验收过程具有客观性;同时通过确认每个可交付成果,来提高最终产品、服务或成果获得验收的可能性。
本过程应根据需要在整个项目期间定期开展。
确认范围过程与控制质量过程的不同之处在于,前者关注可交付成果的验收,而后者关注可交付成果的正确性及是否满足质量要求。
控制质量过程通常先于确认范围过程。
6.1、工具与技术
6.1.1、检查
检查是指开展测量、审查与确认等活动,来判断工作和可交付成果是否符合需求和产品验收标准。检查,也被称为审查、产品审查和巡检。
6.2、输出
6.2.1、验收的可交付成果
符合验收标准的可交付成果应该由客户或发起人正式签字批准。
应该从客户或发起人那里获得正式文件,证明相关方对项目可交付成果的正式验收。
7、 控制范围
控制范围是监督项目和产品的范围状态,管理范围基准变更的过程。
本过程的主要作用是,在整个项目期间保持对范围基准的维护,且需要在整个项目期间开展。
控制项目范围确保所有变更请求、推荐的纠正措施或预防措施都通过实施整体变更控制过程进行处理。
未经控制的产品或项目范围的扩大(未对时间、成本和资源做相应调整)被称为范围蔓延。
免责声明:本站所有文章内容,图片,视频等均是来源于用户投稿和互联网及文摘转载整编而成,不代表本站观点,不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益,请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权,请联系删除,如若转载,请注明出处:https://yundeesoft.com/34683.html