PMP 学习笔记:第五章《项目范围管理》 2019-11-26 / 29 次 / 快抢沙发 /

项目管理中的“范进成”中的范。

PMP 学习笔记:第五章《项目范围管理》
说明:范围管理是属于“范进成”里面的。
范围管理:
做且只做所需的全部工作。这句话非常重要。All & Only。

产品和项目范围的区别:
产品范围:某项产品、服务或成果所具有的特性和功能。
项目范围:为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。


表 1:产品范围和项目范围区别

 区分   产品范围   项目范围 
 相互关系   决定项目范围   服务于产品范围 
 影响关系   自身变化不一定会引起项目范围的变化   自身变化不一定会引起产品范围的变化 
 包含关系   不包含项目范围   广义上有时也包括产品范围 
 衡量依据   产品需求文件   项目管理计划 


产品范围由产品需求文件衡量,项目范围由项目管理计划衡量。


表 1:预测型生命周期和适应型生命周期之范围管理对比

 区分   预测型生命周期   适应型/敏捷型生命周期 
 总体模式   项目开始时就对项目可交付成果进行定义
对任何范围变化都要进行渐进管理 
 通过多次迭代来开发可交付成果
并在每次迭代开始时定义和批准详细的范围 
 基本特征   需求稳定,技术成熟   应对大量变更,相关方持续参与 
 何时从哪里
收集需求
定义范围
创建 WBS 
 在项目开始时,从所有需求中开展这些过程
必要时通过实施整体变更控制过程进行更新 
 在每个迭代开始时
在产品未完项中
选择最优先项开展这些过程 
 何时确认范围
控制范围 
 确认范围:每个可交付成果生成时或在阶段审查点
控制范围:持续性进行。 
 美的迭代中 
 最终范围基准   项目范围说明书 + WBS + WBS 词典   未完项(包括产品需求和用户故事) 
项目范围管理的发展趋势和新兴实践
需求一直是项目管理中的重点。组织开始认识到如何使用商业分析,通过定义、管理和控制需求活动来提高竞争优势。
商业分析活动可在项目启动和项目经理任命之前就开始。要注重与商业分析专业人士的合作。
需求管理过程始于需要评估,结束于需求关闭。
项目经理与商业分析师之间是伙伴式合作关系。
商业分析师负责需求管理相关的活动。
项目经理负责确保这些活动在项目管理计划有所安排,并且在预算内按时完成,同时能够创造价值。

在敏捷和适应型环境中需要考虑的因素:
特意在项目早期缩短定义和协商范围的时间,并未持续探索和明确范围而延长创建相应过程的时间。
有目的的构建和审核原型,并通过多次发布版本来明确需求。吧需求列入未完项。

整合管理过程之一:“规划范围管理”(规划过程组)
规划范围管理:未记录如何定义、确认和控制项目范围及产品范围,而创建范围管理计划的过程。
本过程的作用:在整个项目中对如何管理范围提供指南和方向。

规范范围管理-输出:范围管理计划
范围管理计划:描述将如何定义、指定、监督、控制和确认项目范围。
1.范围管理计划无范围(范围在范围基准中)
2.范围管理计划可以是正式或非正式的,非常详细或高度概括的。
规划范围管理-输出:需求管理计划
需求管理计划(商业分析计划):描述将如何分析、记录和管理项目和产品需求。
1.需求管理计划无需求(需求在需求文件中)
2.内容包括配置管理活动、需求优先级排序过程、测量指标等。

整合管理过程之二:“收集需求”(规划过程组)
收集需求:为实现目标而确定、记录并管理相关方的需要和需求的过程。
本过程作用:为定义产品范围和项目范围奠定基础。

什么是需求?
根据特定协议或其他强制性范围,产品、服务或成果必须具备的条件或能力。
需求包括发起人、客户和其他相关方的已量化且书面记录的需要和期望。

收集需求-输入:项目文件
相关方登记册:用于了解哪些相关方能够提供需求方面的信息,及记录相关方对项目的需求和期望。
收集需求-输入:商业文件
会影响手机需求过程的商业文件是商业论证,它描述了为满足业务需求而应该达到的必要、期望及可选标准。
收集需求-输入:协议
协议包含项目和产品需求。
收集需求-工具与技术
数据收集
1.头脑风暴:大量创意、各种想法、畅所欲言
2.访谈:直接交谈、预设和即兴问题、一对一、多对多、获取机密信息
3.焦点小组:同职能、同一领域、有相似背景、主题专家(SME)、主持人应道互动式讨论
4.问卷调查:受众多样化、需快速完成、地理位置分散、适合开展统计分析
5.标杆对照:标杆可以是内部或外部、同样和或不同行业、识别最佳实践、形成改进意见
数据分析
1.文件分析:分析现有文件。
决策
1.投票:一致同意:每个人都同意,德尔菲(专家、匿名、多轮、趋同、消除偏见)。大多数同意:超过 50%,一般把决策小组的人数定为奇数。相对多数同意:相对多数,通常候选项超过两个时使用。
2.独裁型决策制定:一个人做决策。
3.多标准决策分析:决策矩阵、多种标准、评估和排序。
数据表现
1.亲和图:分组、审查和分析
2.思维导图:整合、反映共性与差异、激发新创意、脑图。
人际关系与团队技能
1.名义小组:促进头脑风暴、投票、优先排序、五分制、数论。
2.观察(工作跟随)和交谈:“工作跟随”、难以或不愿清晰说明、挖掘隐藏的需求
3.引导:与主题研讨会结合使用、跨职能、不同部门、协调相关方差异
4.联合应用设计或开发(JAD)软件开发行业、业务主题专家和开发团队集中
5.质量功能展开(QFD)制造行业、收集客户需要(客户声音)开始、分类和排序。
6.用户故事:需求研讨会、角色、目标、动机。
系统交互图
1.拓扑图、可视化
原型法
1.支持渐进明细的理念。例如:故事板,能减轻返工的风险。
2.步骤(反复循环):1.模型创建 2.用户体验 3.反馈收集 4.原型修改(可能需要走变更流程)
收集需求-输出:需求文件
需求文件:描述各种单一需求将如何满足与项目相关的业务需求。
只有明确的(可测量和可测试的)、可跟踪的、完整的、相互协调的,且主要相关方愿意认可的需求,才能作为基准。

需求的分类:
1.业务需求:
整个组织的高层级需求。
2.相关方需求:
相关方或相关方群体的需求。
3.解决方案需求:
为满足业务需求和相关方需求、产品、服务或成果必须具备的特性、功能和特征。分功能需求和非功能需求。
4.过渡和就绪需求:
从“当前状态”过渡到“将来状态”所需的临时能力。例如:数据转换和培训需求。
5.项目需求:
项目需要满足的行动、过程或其他条件,例如里程碑日期、合同责任、制约因素。
6.质量要求:
用于确认可交付成果的成功完成或其他项目需求的实现的任何条件或标准,例如:测试、认证、确认。

收集需求-输出:需求跟踪矩阵
需求跟踪矩阵:把产品需求从其来源连接到能满足需求的可交付成果的一种表格。
1.把每个需求与业务目标或项目目标联系起来,有助于确保每个需求都具有商业价值。
2.提供了在整个项目生命周期中跟踪需求的一种方法(正想跟踪和逆向跟踪)。
3.有助于确保需求文件中被批准的每项需求再项目结束的时候都能被交付。
4.收集需求产生的需求问阿金和需求跟踪矩阵并不代表项目的真实范围。
5.需要进一步说明哪些包含在项目范围内,哪些排除在项目范围外。(定义范围)

项目范围管理过程之三:“定义范围”(规划过程组)
定义范围:制定项目和产品详细描述的过程。
本过程的作用:描述产品、服务或成果的边界和验收标准。
注意点:
1.应根据项目启动过程中记载的主要可交付成果、假设条件和制约因素来编制项目范围说明书。
2.还需啊哟分析现有风险、假设条件和制约因素的完整性,并做必要的增补或更新。
3.需要多次反复开展定义范围过程。

定义范围-输入:项目章程
项目章程中包含对项目的高层级描述、产品特征和审批要求。
定义范围-输入:项目文件
需求文件:识别了应纳入范围的需求。
定义范围-工具与技术:数据分析
可用于本过程的数据分析技术包括:备选方案分析。
定义范围-工具与技术:决策
可用于本过程的决策技术包括:多标准决策分析。
定义范围-工具与技术:人际关系和团队技能
在研讨会和座谈会中使用引导技能来协调具有不同期望或不同专业知识的关键相关方,使他们就项目可交付成果以及项目和产品边界达成跨职能的共识。
定义范围-工具与技术:产品分析
产品分析:把高层级的产品描述转变为有形的可交付成果。产品分析技术包括产品分解、系统分析、需求分析、系统工程、价值工程、价值分析等。
定义范围-输出:项目范围说明书
项目范围说明书:是对项目范围、主要可交付成果、假设条件和制约因素的描述。记录了整个范围,包括项目和产品范围。
项目范围说明书详细描述了项目的可交付成果,还代表项目相关方之间就项目范围所达成的共识。
为了便于管理相关方的期望,项目范围说明书可明确的指出哪些工作不属于本项目范围。
项目范围说明书包含:
1.产品范围描述
逐步细化再项目章程和需求文件中所描述的产品、服务或成果的特征。
2.可交付成果
必须产出的任何独特并可核实的产品、成果或服务能力。也包括辅助成果,如项目管理报告和文件。
3.验收标准
可交付成果通过验收前必须满足的一系列条件。
4.除外责任
明确说明哪些内容不属于项目范围,有助于管理相关方的期望及减少范围蔓延。

项目范围管理过程之四:“创建 WBS”(规划过程组)
创建 WBS:把项目可交付成果和项目工作分解成较小的、更容易管理的组件的过程。
本过程作用:对所要交付的内容提供架构。
WBS 组织并定义了项目的总范围(项目范围说明书只定义范围,没有组织范围)
WBS 最底层的组成部分称为工作包,其中包含计划的工作。
在“工作分解结构”这个词语中,“工作”是指作为活动结果的工作产品或可交付成果,而不是活动本身。

创建 WBS -工具与技术:分解
分解:把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术。
工作包:WBS 最底层的组件,可对其成本和持续时间进行估算和管理。
创建 WBS,就是要将整个项目工作分解为工作包。

分解的五个步骤:
1.识别和分析可交付成果及相关工作
2.确定 WBS 的结构和编排方法
3.自上而下逐层细化分解
4.为 WBS 组件制定和分配标识编码
5.核实可交付成果分解的程度是否恰当

WBS 可以采用如下形式:
把项目生命周期的各阶段作为分解的第二层,产品和项目可交付成果放到第三层。
把主要可交付成果作为分解的第二层。
纳入由项目团队以外的组织开发的各种较低层次组件(如外包工作)

创建 WBS 的四个注意:
如果采用敏捷方法,可以将长篇故事分解成用户故事。
不同的可交付成果可以分解到不同的层次。
并不是分解得越细越好。过细的分解会造成管理努力的无消耗费、资源使用效率低下、工作实施效率降低,同时造成 WBS 各层级的数据汇总困难。
远期才能完成的可交付成果或组件,当前可能无法分解(规划包),需要滚动式规划。

创建 WBS 的四个主要原则:
无遗漏无多余:100% 原则。
工作包 80 小时:80 小时原则。
4-6 层原则:不宜过多分解。
责任明确原则:有明确责任人。

创建 WBS 的输出:范围基准
1.范围说明书:
产品范围描述、验收标准、可交付成果、项目的除外责任
2.WBS:
工作包、规划报、控制账户
3.WBS 词典:
账户编码标志号;工作描述、负责的组织;进度里程碑清单;相关的进度活动;所需的资源;成本估算;质量要求;验收标准;技术参考文献;协议信息;
哪儿找可交付成果和验收标准:首选范围说明书,次选 WBS 词典,再选范围基准。

控制账户与工具包:
控制账户:是一个管理控制点(可以与组织的财务程序链接),在该控制点上,把范围、预算、实际成本和进度加以整合,并与挣值相比较,以测量绩效。
绩效测量基准(PMB):由范围基准、进度基准、成本基准共同构成。
每个控制账户可能包括一个或多个工作包(或规划包),但是一个工作包只属于一个控制账户。
例如:一个部门对应 N 个工作包,将这些工作包归入一个控制账户,以考核绩效。
工作包 1 (账户编码 1) -> 控制账户 1 -> OBS 中的组织 1 (市场部)
工作包 2/3 (账户编码 2/3) -> 控制账户 2 -> OBS 中的组织 2 (财务部)

项目范围管理过程之五:“确认范围”(监控过程组)
确认范围:“客户”或“发起人”正式验收已完成的项目可交付成果的过程。
本过程的作用:通过验收每个可交付成果,提高最终产品、服务或成果验收的可能性。

确认范围-输入:核实的可交付成果
核实的可交付成果:已经完成,并被控制质量过程检查为正确的可交付成果。
确认范围-工具与技术:检查
检查(审查、产品审查、巡检)— 开展测量、审查与确认等活动,来判断工作和可交付成果是否符合需求和产品验收标准。
确认范围-输出:验收的可交付成果
符合验收标准的可交付成果应该由客户或发起人正式签字批准。
应该从客户或发起人那里获得正式文件,证明相关方对项目可交付成果的正式验收。
确认范围-输出:变更请求
如果未通过验收,处理步骤:1.记录原因 2.提交变更请求 3.进行缺陷补救。

项目范围管理过程之六:“控制范围”(监控过程组)
控制范围:监控项目和产品的范围状态,管理范围基准变更的过程。
本过程的作用:
在整个项目期间保持对范围基准的维护。
确保所有变更请求、纠正措施、预防措施都通过实施整体变更控制过程进行处理。

控制范围-工具与技术:数据分析
偏差分析:用于将基准与实际结果进行比较,以确定偏差是否处于临界值区间或是否有必要采取纠正或预防措施。
趋势分析:旨在审查项目绩效随时间的变化情况,以判断绩效是否正在改善或者正在恶化。
确定偏离范围基准的原因和程度,并决定是否采取纠正或预防措施,是项目范围控制的重要工作。

范围蔓延、镀金、范围潜变
范围蔓延:
未对时间、成本和资源做相应调整,未经控制的产品或项目范围的扩大。
来自团队内部原因造成的范围蔓延称为“镀金”
来自团队外部原因造成的范围蔓延称为“范围潜变”
镀金:
项目人员为了“讨好”客户而坐的不解决实际问题、没有应用价值的项目活动。
范围潜变:范围潜变是指客户不断地提出小的、不易察觉的范围改变,如果不加以控制,累计起来的导致项目严重偏离既定的范围基准,导致项目失控和失败。

如果已经出现了范围蔓延,一样需要走变更流程。

打赏
本博客所有文章如无特别注明均为原创。复制或转载请以超链接形式注明转自ifeegoo,原文地址《PMP 学习笔记:第五章《项目范围管理》
上一篇: « 下一篇:

> 添加新评论

Copyright © ifeegoo Time is limited, less is more! / 粤ICP备15109713号-1 / Theme by Hang & Ben / WordPress / 知识共享许可协议