第五章 项目范围管理

做且只做,防止范围蔓延,反对镀金!

5.1 规划范围管理 (规划过程组)

5.2 收集需求(规划过程组)

5.3 定义范围

5.4 创建WBS

5.5 确认范围(验收)

5.6 控制范围

范围管理包括:

•产品范围(椅背,椅座...)

项目将得到产品所具有的特性与功能

•项目范围(锯木头,刷漆...)

为得到产品,必须完成的项目工作

❗️项目范围包含产品范围（即项目范围服务于产品范围）

5.1 规划范围管理 (规划过程组)

对如何管理范围提供指南和方向

指导如何进行5.2～5.6

•定义

创建范围管理计划,书面描述将如何定义、确认、控制项目范围

•作用

在整个项目中如何管理范围提供指南和方向

•输入

1.项目章程⭐️

包含高层级需求、高层级项目描述、边界和主要可交付成果

2.项目管理计划

•质量管理计划

•项目生命周期描述

•开发方法

3.事业环境因素

4.组织过程资产

•工具与技术

1.专家判断

请教专家类似项目、专业领域的信息

2.数据分析

备选方案分析：比较两种方案的优劣

3.会议

通过会议讨论并制定范围管理计划

•输出

1.范围管理计划⭐️

如何管理范围

•内容包括

如何制定项目范围说明书、实施整体变更控制

如何创建WBS

如何审批和维护范围基准

如何验收已完成的可交付成果

•格式

正式或非正式、非常详细或高度概括

2.需求管理计划⭐️

如何管理需求

•定义

是项目管理计划的组成部分；描述将如何记录、分析和管理需求

•规划

(1)需求管理：如何规划、跟踪和报告需求

(2)配置管理(如何启动变更、如何分析其影响..)

(3)排序需求优先级

(4)测量指标及使用这些指标的理由

(5)定义需求跟踪矩阵

•格式

正式或非正式、非常详细或高度概括

5.2 收集需求(规划过程组)

•定义

为实现项目目标而确定、记录并管理相关方的需要和需求的过程

•作用

为定义和管理项目范围奠定基础

- 需求决定范围

- 需求应当是量化的、并可被测量的

- 多关注说不清的需求、少关注合同

- 为实现项目目标(确定,记录,管理)相关方需求

- 相关方深入参与需求的探索和分析能直接促进新项目成功

•输入

1.项目章程⭐️

包含高层级需求

2.项目管理计划

范围/需求/相关方 管理计划

3.项目文件

•假设日志

•经验教训登记册

•相关方登记册

4.商业文件(商业论证)⭐️

包含了项目的背景和启动原因

Ex：市场需求、组织需要、客户要求...

5.协议⭐️

包含项目和产品的明确需求

6.事业环境因素

7.组织过程资产

•工具与技术

1.专家判断

2.数据收集

•头脑风暴：短时间内收集大量创意

•访谈：一对一、直接

•焦点小组：主持人、深入定向了解(收集同一领域的相关方需求)

•问卷调查：受众多样化、需快速完成、地理位置分散、并且适合开展统计分析

•标杆对照：最佳实践

3.数据分析

•文件分析：分析文件(协议、商业计划、问题日志...)

4.决策

•投票

一致同意：100%

大多数同意：超过50%

相对多数同意

•独裁

•多标准决策：对众多创意进行评估和排序

5.数据表现

•亲和图：对大量创意进行分组(分类)

•思维导图：层级关系、分散思维

6.人际关系与团队技能

•名义小组：通过投票排列最有用的创意(主持人记录每个人的想法)

•观察与交谈：挖掘隐藏需求

Ex：工作跟随、参与观察

•引导：跨职能、协调相关方的需求差异

(1)联合应用设计或开发(JAD)

业务专家和技术专家一起讨论需求，改进软件开发过程

(2)质量功能展开(QFD)

•收集客户声音

•对客户需要进行分类和排序

•为实现客户需要设定目标

Ex：质量屋

(3)用户故事

需求-需求相关方-期望获得的效果-需要实现的目标

故事的要素：谁、(目标)需要的是什么、(动机)为什么

7.系统交互图

对产品范围的可视化描绘、显示业务系统与其他系统之间的交互方式

Ex：淘宝用户-淘宝-商家-支付宝

8.原型法

制作有型的实物或模型,不再抽象讨论

渐进明细（通过新原型对旧原型的迭代，不断明确客户需求）

Ex：故事版

•输出

1.需求文件⭐️

❗️罗列

单一需求如何满足项目与项目相关的业务需求

•需求的类别：

- 业务需求

- 相关方需求

- 解决方案需求：可交付成果必须具备的特性、功能和特征

         ·功能需求：产品应具备的功能

         ·非功能需求：性能、保密性、安全性...

- 过度和就绪需求：数据转换、培训需求

- 项目需求：项目里程碑、合同工期...

- 质量需求：应用在化工园区的产品,必须通过防爆认证

2.需求跟踪矩阵⭐️

❗️跟踪

(产品需求)什么样的需求、(需求源)谁提出的、为什么收录该需求、优先级如何、(可交付成果)通过可交付成果的哪些特性来响应需求、需求当前状态如何等

了解项目的所有需求、以及相应的变更执行情况

5.3 定义范围（规划过程组）

制定项目和产品的详细描述

•作用

描述产品、服务或成果的边界和验收标准

•输入

1.项目章程

2.项目管理计划

3.项目文件

•假设日志

•需求文件

•风险登记册

4. 事业环境因素

5.组织过程资产

过往项目的经验教训

•工具与技术

1.专家判断

2.数据分析

•备选方案分析

3.决策

4.人际关系与技能

•引导

5.产品分析

把高层级的产品或服务描述转变为有意义的可交付成果

产品分析技术包括：

•产品分解

•需求分析

•系统分析

•系统工程

•价值分析

•价值工程

•输出

1.项目范围说明书⭐️

内容包括：

•产品范围描述

•项目可交付成果：新来的pm想了解可交付成果，可查看…

•验收标准

•项目除外责任

2.项目文件更新

•假设日志

•需求文件

•需求跟踪矩阵

•相关方登记册

5.4 创建WBS（规划过程组）

将可交付成果分解为较小的、更易于管理的组件的过程

•作用

对所要交付的内容提供架构

工作分解结构中的工作是指：

为活动结果的工作产品或可交付成果，而不是活动本身

•输入

1.项目管理计划

•范围管理计划：定义了如何创建WBS

2.项目文件

•项目范围说明书：描述了需要实施的工作及不包含在项目中的工作

•需求文件：详细的描述了各种单一的需求如何满足项目的业务需求

3.事业环境因素

项目所在行业的WBS标准…

4.组织过程资产

•政策、程序和模版

•以往项目的项目档案

•以往项目的经验教训

•工具与技术

1.专家判断

2.分解

整个项目工作分解为工作包：

•识别和分析可交付成果和编排方法

•确定WBS的结构和编排方法

•自上而下逐层细化分解，提高估算的准确性

•为WBS组成部分制定和分配标识编码

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

WBS的结构：P159

•以项目生命周期的各个阶段作为分解的第二层

•以主要可交付成果作为分解的第二层

•纳入由项目团队以外的组织开发的各种较低层次组件（如外包工作）

过细的分解：

会造成管理努力的无效耗费、资源使用效率低下、工作实施效率降低、同时造成WBS各层级的数据汇总困难

滚动式规划：未来远期才能完成的可交付成果或组件、当前可能无法分解…

100%规则：确保WBS中的要素是必要且充分的

WBS包含了全部的产品和项目工作，包括项目管理工作（组织并定义了项目的总范围）

•输出

1.范围基准⭐️⭐️⭐️

•项目范围说明书

•WBS

•工作包：WBS的最低层级是带有独特标识号的工作包，

❗️每个工作包都是控制账户的一部分，而控制账户则是一个管理控制点

❗️控制账户：把范围、预算、进度加以整合，并与挣值相比较，以测量绩效（进行挣值管理）

•规划包：工作内容已知，但详细的进度活动未知

•WBS词典：用于详细描述WBS的每个组件，包括其工作内容，进度信息，成本信息…

2.项目文件更新

•假设日志

•需求文件

5.5 确认范围(监控过程组）

❗️验收

•定义

正式验收已完成的项目可交付成果的过程

•作用

使验收过程具有客观性；

验收每个可交付成果，提高最终产品、服务或成果获得验收的可能性；

通过获得客户对每个可交付成果的及时验收，保证项目不偏离轨道

•输入

1.项目管理计划

•范围管理计划：定义了如何验收

•需求管理计划：定义了如何验证需求是否满足

•范围基准：将可交付成果和基准做比较

2.项目文件

•经验教训登记册

•质量报告：内容包括由团队管理或需上报的全部质量保证事项、改进建议、以及在控制质量过程中发现的情况的概述。在验收产品之前，需要查看所有这些内容

•需求文件：将需求与实际结果做比较，…

•需求跟踪矩阵

3.核实的可交付成果

是8.3控制质量的输出

4.工作绩效数据

包含符合需求的程度，不一致的数量等信息

•工具与技术

1.检查

开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和(项目范围说明书中)产品验收标准

其他名称

审查review

产品审查product review

审计audit

巡检walkthrough

2.决策

投票：项目团队和其他相关方进行验收时通过投票来形成结论

•输出

1. 验收可交付成果

符合验收标准的可交付成果，应该由客户或发起人正式签字批准，同意验收

将作为4.7结束项目或阶段过程的输入

2.工作绩效信息

包括：

•项目进展信息，

•验收了多少

•未通过的验收有多少

•验收通过率是多少

•哪些可交付成果未通过验收及原因

•如何处理未符合验收的可交付成果

记录这些内容后传递给相关方

3.变更请求

记录未通过验收可交付成果及原因；

提出变更请求进行缺陷补救；

由实施整体变更控制流程进行审查与处理；

4.项目文件更新

•经验教训登记册：记录所遇到的挑战、本应如何避免该挑战挑战，以及良好的可交付成果验收方法；

•需求文件：记录实际的验收结果，更新需求文件。需要注意实际结果比原定需求更好的情况，或者原定需求已经被放弃的情况；

•需求跟踪矩阵：根据验收结果更新，包括所采用的验收方法及其使用结果；

❗️确认范围和控制质量的区别：

确认范围是验收，是让用户确认，这个可交付成果是不是他想要的；

控制质量是合规，确认可交付成果是否符合规格，质量是否过关；

控制质量在前，确认范围在后；

5.6 控制范围（监控过程组）

持续对范围进行监督,管理范围变更，在整个项目期间开展

•定义

监督项目或产品的范围状态、管理范围基准变更的过程

•作用

在整个项目期间保持对范围基准的维护

•范围蔓延：未经控制的产品或项目范围的扩大

•输入

1.项目管理计划

怎么控制：

和什么去比较：

组件包括：

•范围管理计划

•需求管理计划

•变更管理计划

•配置管理计划

•范围基准

•绩效测量基准

2.项目文件

•经验教训登记册

•需求文件

•需求跟踪矩阵：用于确认范围和控制范围过程，来跟踪需求的实现情况

3.工作绩效数据

已审核/未审核的可交付成果数量

收到的/批准的范围变更请求数量

4.组织过程资产

•工具与技术

1.数据分析

偏差分析：将实际值和基准值做比较，检查偏差是否在合理范围之内

趋势分析：预测未来，判断情况会改善还是恶化

将实际绩效与计划绩效进行分析，并做出决策

•纠偏措施

•预防措施

•调整计划

•输出

1.工作绩效信息

将工作绩效数据通过数据分析（偏差分析、趋势分析）得出的结果

例如多做了多少工作，少做了多少工作

2.变更请求

变更范围基准、进度基准或项目管理计划中的其他组件

3.项目管理计划更新

•范围管理计划

•范围基准：在针对范围、范围说明书、WBS或WBS词典的变更获得批准后，需要对范围基准做出相应的变更

•进度基准

•成本基准

•绩效测量基准

4.项目文件更新

•经验教训登记册

•需求文件

•需求跟踪矩阵