第5章 项目范围管理

确保项目做且只做所需的全部工作

定义和控制哪些工作应该包括在项目内，哪些不应该包括在项目内

范围的定义：

• 产品范围——某项产品、服务或成果所具有的特性和功能
• 项目范围——为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。项
  目范围有时也包括产品范围。

项目范围基准：

• 经过批准的项目范围说明书
• 工作分解结构（WBS）
• 相应的 WBS 词典

总结

本章的控制维度是范围，通过对范围的确定和控制，来让项目只做对的事情。

重点

• WBS
• 项目范围说明书

5.1 规划范围管理

规划范围管理是创建范围管理计划，书面描述将如何定义、确认和控制项目范围的过程。

5.1.1 规划范围管理：输入

5.1.1.1 项目管理计划

见 4.2.3.1 节。

5.1.1.2 项目章程

见 4.1.3.1 节。

项目章程提供了高层级的项目描述和产品特征。产品特征出自项目工作说明书。

5.1.1.3 事业环境因素

见 2.1.5 节。

• 组织文化
• 基础设施
• 人事管理制度
• 市场条件

5.1.1.4 组织过程资产

见 2.1.4 节。

• 政策和程序
• 历史信息和经验教训知识库

5.1.2 规划范围管理：工具与技术

5.1.2.1 专家判断

5.1.2.2 会议

5.1.3 规划范围管理：输出

5.1.3.1 范围管理计划

范围管理计划是项目或项目集管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围。

• 制定详细项目范围说明书
• 根据详细项目范围说明书创建 WBS
• 维护和批准 WBS
• 正式验收已完成的项目可交付成果
• 处理对详细项目范围说明书的变更

5.1.3.2 需求管理计划

需求管理计划是项目管理计划的组成部分，描述将如何分析、记录和管理需求。阶段与阶段间的关系（见 2.4.2.1 节）对如何管理需求有很大影响。

• 如何规划、跟踪和报告各种需求活动
• 配置管理活动
• 需求优先级排序过程
• 产品测量指标及使用这些指标的理由
• 用来反映哪些需求属性将被列入跟踪矩阵的跟踪结构

5.2 收集需求

收集需求是为实现项目目标而确定、记录并管理干系人的需要和需求的过程。

需求是指根据特定协议或其他强制性规范，项目必须满足的条件或能力，或者产品、服务或成果必须具备的条件或能力。

已量化且书面记录的需要和期望

需求将成为工作分解结构（WBS）的基础。
需求也是成本、进度和质量规划的基础，有时也是采购工作的基础。

5.2.1 收集需求：输入

5.2.1.1 范围管理计划

见 5.1.3.1 节。

5.2.1.2 需求管理计划

见 5.1.3.2 节。

5.2.1.3 干系人管理计划

见 13.2.3.1 节。

5.2.1.4 项目章程

见 4.1.3.1 节。

5.2.1.5 干系人登记册

5.2.2 收集需求：工具与技术

5.2.2.1 访谈

是通过与干系人直接交谈来获取信息的正式或非正式的方法

提出预设和即兴的问题

5.2.2.2 焦点小组

焦点小组是召集预定的干系人和主题专家，了解他们对所讨论的产品、服务或成果的期望和态度。

5.2.2.3 引导式研讨会

引导式研讨会把主要干系人召集在一起，通过集中讨论来定义产品需求。

研讨会是快速定义跨职能需求和协调干系人差异的重要技术。

从而有利于干系人达成一致意见

研讨会能够比单项会议更早发现问题，更快解决问题.

5.2.2.4 群体创新技术

• 头脑风暴法。多种创意的技术
• 名义小组技术。通过投票排列最有用的创意，以便进一步开展头脑风暴或优先排序。
• 概念/思维导图。头脑风暴中获得的创意整合成一张图的技术，共性与差异，激发新创意
• 亲和图。对大量创意进行分组的技术，以便进一步审查和分析。
• 多标准决策分析。而对众多方案进行评估和排序

5.2.2.5 群体决策技术

• 一致同意
• 大多数原则
• 相对多数原则
• 独裁

5.2.2.6 问卷调查

5.2.2.7 观察

观察，也称为“工作跟踪”，通常由观察者从外部来观看业务专家如何执行工作。

5.2.2.8 原型法

原型法支持渐进明细的理念，需要经历从模型创建、用户体验、反馈收集到原型修改的反复循环过程。

故事板是一种原型技术，通过一系列的图像或图示来展示顺序或导航路径。

5.2.2.9 标杆对照

便识别最佳实践，形成改进意见

5.2.2.10 系统交互图

系统交互图是范围模型的一个例子

5.2.2.11 文件分析

5.2.3 收集需求：输出

5.2.3.1 需求文件

只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，且主要干系人愿意认可的需求，才能作为基准。

主要包括

• 业务需求
  
  • 可跟踪的业务目标和项目目标
  • 执行组织的业务规则
  • 组织的指导原则
• 干系人需求
  
  • 对组织其他领域的影响
  • 对执行组织内部或外部团体的影响
  • 干系人对沟通和报告的需求
• 解决方案需求
  
  • 功能和非功能需求
  • 技术和标准合规性需求
  • 支持和培训的需求
  • 质量需求
  • 报告需求
• 项目需求
  
  • 服务水平、绩效、安全和合规性
  • 验收标准
• 过渡需求
• 与需求相关的假设条件、依赖关系和制约因素

5.2.3.2 需求跟踪矩阵

把产品需求从其来源连接到能满足需求的可交付成果的一种表格。

确保每个需求都具有商业价值。

在整个项目生命周期中跟踪需求的一种方法

主要包括

• 业务需要、机会、目的和目标
• 项目目标
• 项目范围/ WBS 可交付成果
• 产品设计
• 产品开发
• 测试策略和测试场景
• 高层级需求到详细需求

5.3 定义范围

定义范围是制定项目和产品详细描述的过程。
本过程的主要作用是，明确所收集的需求哪些将包含在项目范围内，哪些将排除在项目范围外，从而明确项目、服务或成果的边界。

定义范围过程就要从需求文件（收集需求过程的输出）中选取最终的项目需求。

5.3.1 定义范围：输入

5.3.1.1 范围管理计划

见 5.1.3.1 节。

5.3.1.2 项目章程

见 4.1.3.1 节。

5.3.1.3 需求文件

见 5.2.3.1 节。

5.3.1.4 组织过程资产

见 2.1.4 节。

• 用于制定项目范围说明书的政策、程序和模板
• 以往项目的项目档案
• 以往阶段或项目的经验教训

5.3.2 定义范围：工具与技术

5.3.2.1 专家判断

5.3.2.2 产品分析

以产品为可交付成果的项目

产品分析技术包括产品分解、系统分析、需求分析、系统工程、价值工程和价值分析等。

5.3.2.3 备选方案生成

制定尽可能多的潜在可选方案的技术

5.3.2.4 引导式研讨会

见 5.2.2.3 节。

5.3.3 定义范围：输出

5.3.3.1 项目范围说明书

项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。

项目范围说明书也代表项目干系人之间就项目范围所达成的共识。

主要包括

• 产品范围描述
• 验收标准
• 可交付成果
• 项目的除外责任
• 制约因素
• 假设条件

项目章程包括高层级的信息，而项目范围书说明则是对项目范围的详细描述。项目范围需要在项目过程中渐进明细。

5.3.3.2 项目文件更新

• 干系人登记册
• 需求文件
• 需求跟踪矩阵

5.4 创建 WBS

创建工作分解结构（WBS）是把项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程。

所要交付的内容提供一个结构化的视图。

WBS 组织并定义了项目的总范围

WBS 最低层的组件被称为工作包

5.4.1 创建 WBS：输入

5.4.1.1 范围管理计划

见 5.1.3.1 节。

5.4.1.2 项目范围说明书

见 5.3.3.1 节。

5.4.1.3 需求文件

见 5.2.3.1 节。

5.4.1.4 事业环境因素

见 2.1.5 节。

项目所在行业的 WBS 标准，可以作为创建 WBS 的外部参考资料。

5.4.1.5 组织过程资产

见 2.1.4 节。

• 用于创建 WBS 的政策、程序和模板
• 以往项目的项目档案
• 以往项目的经验教训

5.4.2 创建 WBS：工具与技术

5.4.2.1 分解

分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术。

工作包是 WBS 最低层的工作，可对其成本和持续时间进行估算和管理。

分解的程度取决于所需的控制程度，以实现对项目的高效管理。

需要开展以下工作

• 识别和分析可交付成果及相关工作
• 确定 WBS 的结构和编排方法
• 自上而下逐层细化分解
• 为 WBS 组件制定和分配标识编码
• 核实可交付成果分解的程度是否恰当。

WBS 的结构可以采用多种形式

• 以项目生命周期的各阶段作为分解的第二层，把产品和项目可交付成果放在第三层
• 以主要可交付成果作为分解的第二层
• 整合可能由项目团队以外的组织来实施的各种子组件（如外包工作）。随后，作为外包工作的一部分，卖方须制定相应的合同 WBS。

工作分解得越细致，对工作的规划、管理和控制就越有力。但是，过细的分解会造成管理努力的无效耗费、资源使用效率低下、工作实施效率降低，同时造成 WBS 各层级的数据汇总困难。

100%规则

可参考《工作分解结构实践标准》（第 2 版）

5.4.2.2 专家判断

5.4.3 创建 WBS：输出

5.4.3.1 范围基准

范围基准是经过批准的范围说明书、工作分解结构（WBS）和相应的 WBS 词典.

范围基准是项目管理计划的组成部分:

• 项目范围说明书
• WBS。“账户编码。控制账户是一个管理控制点。在该控制点上，把范围、预算、实际成本和进度加以整合，并与挣值相比较
• WBS 词典
  
  • 账户编码标识
  • 工作描述
  • 假设条件和制约因素
  • 负责的组织
  • 进度里程碑
  • 相关的进度活动
  • 所需资源
  • 成本估算
  • 质量要求
  • 验收标准
  • 技术参考文献
  • 协议信息

5.4.3.2 项目文件更新

• 需求文件

5.5 确认范围

确认范围是正式验收已完成的项目可交付成果的过程。

确认范围过程与控制质量过程的不同之处在于，前者关注可交付成果的验收，而后者关注可交付成果的正确性及是否满足质量要求。控制质量过程通常先于确认范围过程，但二者也可同时进行。

5.5.1 确认范围：输入

5.5.1.1 项目管理计划

见 4.2.3.1 节。

• 范围管理计划
• 范围基准
  
  • 批准的范围说明书
  • WBS
  • 对应的WBS词典

只有通过正式的变更控制程序才可对基准进行变更。

5.5.1.2 需求文件

见 5.2.3.1 节。

5.5.1.3 需求跟踪矩阵

见 5.2.3.2 节。

5.5.1.4 核实的可交付成果

见 8.3.3.3 节。

5.5.1.5 工作绩效数据

见 4.3.3.2 节。

5.5.2 确认范围：工具与技术

5.5.2.1 检查

检查是指开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准。

5.5.2.2 群体决策技术

见 5.2.2.5 节。

5.5.3 确认范围：输出

5.5.3.1 验收的可交付成果

符合验收标准的可交付成果应该由客户或发起人正式签字批准。
应该从客户或发起人那里获得正式文件，证明干系人对项目可交付成果的正式验收。

5.5.3.2 变更请求

变更请求应该由实施整体变更控制过程（见 4.5 节）进行审查与处理。

5.5.3.3 工作绩效信息

10.3.3.1

5.5.3.4 项目文件更新

5.6 控制范围

控制范围是监督项目和产品的范围状态，管理范围基准变更的过程。

未经控制的产品或项目范围的扩大（未对时间、成本和资源做相应调整）被称为范围蔓延。变更不可避免，因此在每个项目上，都必须强制实施某种形式的变更控制。

5.6.1 控制范围：输入

5.6.1.1 项目管理计划

见 4.2.3.1 节。

• 范围基准
• 范围管理计划
• 变更管理计划
• 配置管理计划
• 需求管理计划

5.6.1.2 需求文件

见 5.2.3.1 节。

便于发现任何对于批准的项目或产品范围的偏离。

5.6.1.3 需求跟踪矩阵

见 5.2.3.2 节。

5.6.1.4 工作绩效数据

见 4.3.3.2 节。

5.6.1.5 组织过程资产

见 2.1.4 节。

• 现有的、正式和非正式的，与范围控制相关的政策、程序和指南
• 可用的监督和报告的方法与模板

5.6.2 控制范围：工具与技术

5.6.2.1 偏差分析

偏差分析是一种确定实际绩效与基准的差异程度及原因的技术

5.6.3 控制范围：输出

5.6.3.1 工作绩效信息

5.6.3.2 变更请求

5.6.3.3 项目管理计划更新

• 范围基准更新。
• 其他基准更新。

5.6.3.4 项目文件更新

• 需求文件
• 需求跟踪矩阵

5.6.3.5 组织过程资产更新

• 造成偏差的原因
• 所选的纠正措施及选择理由
• 从项目范围控制中得到的其他经验教训