第9章-项目范围管理

引言

• 项目范围管理包括确保项目做且只做所需的全部工作，以成功完成项目。

• 项目范围管理主要在于定义和控制哪些工作应该包括在项目内，哪些不应该包含在项目内。

9.1 管理基础

9.1.1产品范围和项目范围

产品范围：

• 指某项产品、服务或成果所具有的特征和功能。产品范围的完成情况是根据产品需求来衡量的。“需求”是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力。

项目范围：

• 包括产品范围，是为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。项目范围的完成清况是根据项目管理计划来衡量的。

9.1.2管理新实践

• 项目范围管理的新趋势和新兴实践更加注重与商业分析师一起合作，以便：确定问题并识别商业需要；识别并推荐能够满足需要的可行解决方案；收集、记录并管理干系人需求满足商业和项目目标；推动项目集或项目产品、服务或最终成果成功应用。

• 商业分析师的职责还应包括需求管理相关的活动，项目经理则负责确保这些活动列入项目管理计划，并且在预算内按时完成，同时能够创造价值。

• 项目经理与商业分析师之间应该是伙伴式合作关系。如果项目经理和商业分析师能够理解彼此在促进项目目标实现过程中的角色和职责，项目成功的可能性会更大。

9.2 项目范围管理过程

9.2.1 过程概述

项目范围管理（做且只做）

规划范围管理

• 输入：项目章程、项目管理计划、事业环境因素、组织过程资产

• 输出：范围管理计划、需求管理计划

• 技术：专家判断、数据分析、会议

收集需求

• 输入：立项管理文件、项目章程、项目管理计划、项目文件、协议、事业环境因素、组织过程资产

• 输出：需求文件、需求跟踪矩阵

• 技术：专家判断、数据收集、数据分析、决策、数据表现、人际关系与团队技能、系统交互图、原型法

定义范围

• 输入：项目章程、项目管理计划、项目文件、事业环境因素、组织过程资产

• 输出：范围说明书、项目文件更新

• 技术：专家判断、数据分析、决策、人际关系与团队技能、产品分析

创建WBS

• 输入：项目管理计划、项目文件、事业环境因素、组织过程资产

• 输出：范围基准、项目文件更新

• 技术：分解、专家判断

确认范围

• 输入：项目管理计划、项目文件、工作绩效数据、核实的可交付成果

• 输出：验收的可交付成果、变更请求、工作绩效信息、项目文件更新

• 技术：检查、决策

控制范围

• 输入：项目管理计划、项目文件、工作绩效数据、组织过程资产

• 输出：工作绩效信息、变更请求、项目管理计划更新、项目文件更新

• 技术：数据分析

9.2.2 裁剪考虑因素

裁剪时应考虑的因素包括：知识和需求管理、确认和控制、开发方法、需求的稳定性、治理

9.2.3 敏捷与适应方法

在许多情况下，不断涌现的需求往往导致真实的业务需求与最初所述的业务需求之间存在差异。因此，敏捷方法有目的地构建和审查原型，并通过多次发布版本来明确需求，范围会在整个项目期间被定义和再定义。

采用敏捷或适应型生命周期，旨在应对大量变更，需要干系人持续参与项目。每次迭代中，都会重复开展：收集需求、定义范围、创建WBS、确认范围、控制范围。

9.3 规划范围管理

规划范围管理-定义、作用

规划范围管理是为了记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程。

主要作用是在整个项目期间对如何管理范围提供指南和方向。

本过程仅开展一次或仅在项目的预定义点开展。

规划范围管理-ITTO

• 输入：项目章程、项目管理计划、事业环境因素、组织过程资产

• 输出：范围管理计划、需求管理计划

• 技术：专家判断、数据分析、会议

数据流向图

范围管理计划

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

范围管理计划用于指导如下过程和相关工作：

• 1、制定项目范围说明书；

• 2、根据详细项目范围说明书创建WBS；

• 3、确定如何审批和维护范围基准；

• 4、正式验收已完成的项目可交付成果。

根据项目需要，范围管理计划可以是正式或非正式的，非常详细或高度概括的。

需求管理计划

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

需求管理计划的主要内容包括：

• 1、如何规划、跟踪和报告各种需求活动；

• 2、配置管理活动，例如，如何启动变更，如何分析其影响，如何进行追溯、跟踪和报告，以及变更审批权限；

• 3、需求优先级排序过程；

• 4、测量指标及使用这些指标的理由；

• 5、反映哪些需求属性将被列入跟踪矩阵等。

9.4 收集需求

收集需求-定义、作用

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

主要作用是为定义产品范围和项目范围奠定基础。

本过程仅开展一次或仅在项目的预定义点开展。

收集需求-ITTO

• 输入：立项管理文件、项目章程、项目管理计划、项目文件、协议、事业环境因素、组织过程资产

• 输出：需求文件、需求跟踪矩阵

• 技术：专家判断、数据收集、数据分析、决策、数据表现、人际关系与团队技能、系统交互图、原型法

数据流向图

收集需求过程中的，工具与技术说明

需求文件（需求分类）

需求跟踪矩阵

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

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

• 为管理产品范围变更提供了框架

数据收集

头脑风暴

• 用来产生和收集对项目需求与产品需求的多种创意

• 庭外判决、自由鸣放、追求数量

访谈

• 向被访者提出预设和即兴的问题，并记录他们的回答

• “一对一”谈话（也可“多对多"）

• 对象：有经验的项目参与者、发起人和其他高管，以及主题专家

焦点小组 FOCUS GROUP

• 召集预定的相关方和主题专家，了解他们对所讨论的产品、服务或成果的期望和态度。

• 由一位受过训练的主持人引导大家进行互动式讨论

• 焦点小组往往比“一对一”的访谈更热烈

• 作用：有效的收集用户行为信息。

• 目的：发现什么是用户的真正需求。

• 注意：应有其他方式同时进行收集，不可成为唯一判断方法。

问卷调查

• 设计一系列书面问题，向众多受访者快速收集信息

• 非常适用于以下情况：受众多样化，需要快速完成调查，受访者地理位置分散，并且适合开展统计分析。

示例：

标杆对照

• 将实际或计划的做法与其他可比的做法进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据

• 所采用的可比做法可以是内部的，也可以是外部的

示例：

数据表现

亲和图

• 用来对大量创意进行分组的技术，以便进一步审查和分析。

思维导图

• 把从头脑风暴中获得的创意整合成一张图，用以反映创意之间的共性与差异，激发新创意

示例：

人际关系与团队技能

名义小组

• 用于促进头脑风暴

• 通过投票排列最有用的创意，以便进一步开展头脑风暴或优先排序

示例：

1
2
3
4

1.向集体提出一个问题或难题。每个人在沉思后写出自己的想法。
2.主持人在活动挂图上记录所有人的想法。
3.集体讨论各个想法，直到全体成员达成一个明确的共识。
4.个人私下投票决出各种想法的优先排序，通常采用5分制，1分最低，5分最高。为减少想法数量、集中关注想法，可进行数轮投票。每轮投票后，都将清点选票，得分最高者被选出。

引导

• 把主要干系人召集在一起，集中讨论来定义产品需求

• 快速定义跨职能需求、协调干系人差异

• 有助于参与者之间建立信任、改进关系、改善沟通、达成一致意见

• 联合应用设计/开发（JAD）、质量功能展开（QFD）、用户故事

示例：

• 作为一个<角色>，我想要<活动>，以便于<商业价值>

• 作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。”

系统交互图

• 是对产品范围的可视化描绘

• 显示业务系统（过程、设备、计算机系统等）及其与人和其他系统（行动者）之间的交互方式

示例：

原型法

• 先造出该产品的实用模型，据此征求对需求的早期反馈

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

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

示例：

9.5 定义范围

定义范围-定义、作用

定义范围是制定项目和产品详细描述的过程

主要作用是描述产品、服务或成果的边界和验收标准。

本过程需要在整个项目期间多次反复开展。

定义范围-ITTO

• 输入：项目章程、项目管理计划、项目文件、事业环境因素、组织过程资产

• 输出：范围说明书、项目文件更新

• 技术：专家判断、数据分析、决策、人际关系与团队技能、产品分析

数据流向图

定义范围-相关概念

项目范围说明书。

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

• 记录了整个范围，包括项目和产品范围。包括：产品范围描述；项目的可交付成果；验收标准；项目的除外责任。

产品分析。

• 可用于定义产品和服务，包括针对产品或服务提问并回答，以描述要交付产品的用途、特征及其他方面。首先获取高层级的需求，然后将其细化到最终产品设计所需的详细程度。

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

9.6 创建WBS

创建WBS-定义、作用

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

主要作用是为所要交付的内容提供架构。

它仅开展一次或仅在项目的预定义点开展。

创建WBS-ITTO

• 输入：项目管理计划、项目文件、事业环境因素、组织过程资产

• 输出：范围基准、项目文件更新

• 技术：分解、专家判断

数据流向图

范围基准

• 范围基准：批准的范围说明书、工作分解结构（WBS）和相应的WBS词典。

• WBS词典是针对每个WBS组件，详细描述可交付成果、活动和进度信息的文件。

• WBS词典包括：账户编码标识、工作描述、假设条件和制约因素、负责的组织、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献、协议信息。

创建WBS-相关概念

• 要把整个项目工作分解为工作包，通常需要开展如下活动：
  1、识别和分析可交付成果及相关工作；
  2、确定WBS的结构和编排方法；
  3、自上而下逐层细化分解；
  4、为WBS组成部分制定和分配标识编码；
  5、核实可交付成果分解的程度是否恰当。

• 分解需要注意的：
  1、WBS必须是面向可交付成果的。
  2、WBS必须符合项目的范围（100%原则）。
  3、WBS的底层应该支持计划和控制。
  4、WBS中的元素必须有人负责，而且只有一个人负责。
  5、WBS应控制在4~6层。
  6、WBS应包括项目管理工作，也要包括分包出去的工作。
  7、WBS的编制需要所有（主要）项目干系人的参与。
  8、WBS并非是一成不变的。

• WBS的结构可以采用多种形式：
  1、以项目生命周期的各阶段作为分解的第二层，产品和项目可交付成果放在第三层。
  2、以主要可交付成果作为分解的第二层。
  3、纳入由项目团队以外的组织开发的各种较低层次组件（如外包工作）。随后，作为外包工作的一部分，卖方须制定相应的合同WBS。

WBS

• 对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解

• 工作分解结构每向下分解一层，代表着对项目工作更详细的定义

• 是后续管理工作的主要依据，是项目时间、成本、人力等管理工作基础

• 形式：树形结构、列表形式

示例1：

• 按生命周期分解
  先做啥、再做啥、最后做啥…….

示例2：

• 按子项目分解
  方方面面都有啥

示例3：

WBS详细说明，见教程[89-95]页

特别注意：

1. WBS的层数，不是越多越好。要做到「因地制宜」

2. 理论≠实践，知识≠能力，这之间，需要不断地践行+复盘

9.7 确认范围

确认范围-定义、作用

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

本过程的主要作用：
1、使验收过程具有客观性；
2、通过确认每个可交付成果来提高最终产品、服务或成果获得验收的可能性。

确认范围过程应根据需要在整个项目期间定期开展。

确认范围-ITTO

• 输入：项目管理计划、项目文件、工作绩效数据、核实的可交付成果

• 输出：验收的可交付成果、变更请求、工作绩效信息、项目文件更新

• 技术：检查、决策

数据流向图

验收的可交付成果

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

• 应该从客户或发起人那里获得正式文件，证明干系人对项目可交付成果的正式验收。

确认范围-相关概念

确认范围应该贯穿项目的始终。

• 确认范围的一般步骤包括：
  1、确定需要进行范围确认的时间；
  2、识别范围确认需要哪些投入；
  3、确定范围正式被接受的标准和要素；
  4、确定范围确认会议的组织步骤；
  5、组织范围确认会议。

确认范围关注可交付成果的验收，控制质量关注可交付成果的正确性及是否满足质量要求。

控制质量过程通常先于确认范围过程，但二者也可同时进行。

• 需要检查的问题：
  1.可交付成果是否是确定的、可确认的
  2.每个可交付成果是否有明确的里程碑
  3.是否有明确的质量标准
  4.审核和承诺是否有清晰的表达
  5.项目范围是否覆盖了完成产品或服务的所有活动
  6.项目范围的风险是否太高，是否能够降低可预见风险对项目的冲击

• 不同干系人关注点

9.8 控制范围

控制范围-定义、作用

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

主要作用是在整个项目期间保持对范围基准的维护。

本过程需要在整个项目期间开展。

控制范围-ITTO

• 输入：项目管理计划、项目文件、工作绩效数据、组织过程资产

• 输出：工作绩效信息、变更请求、项目管理计划更新、项目文件更新

• 技术：数据分析

数据流向图

控制范围-相关概念

数据分析

• 偏差分析：用于将基准与实际结果进行比较，以确定偏差是否处于临界值区间内或是否有必要采取纠正或预防措施。

• 趋势分析：旨在审查项目绩效随时间的变化情况，以判断绩效是正在改善还是正在恶化。

蔓延
一般指未经变更控制的产品或项目范围的扩大；往往由客户导致

镀金
团队主动增加的项目范围以外的工作

9.9 本章练习

1.选择题

（1）在____生命周期中，项目开始时就对项目可交付成果进行定义，对任何范围变化都要进行变更管理。
A.预测型
B.适应型
C.敏捷型
D.迭代型

(2)____不是规划范围管理过程的输入。
A.项目章程
B.项目管理计划
C.质量管理计划
D.需求管理计划

（3）关于需求的理解，不正确的是____。
A.让干系人积极参与需求的探索和分解工作，并仔细确定、记录和管理对产品、服务或成果的需求，能直接促进项目成功
B.为更好地对项目进行了解，收集需求的过程应在整个项目期间定期开展
C.需求是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力
D.需求包括发起人、客户和其他干系人的已量化且书面记录的需要和期望

（4）数据收集技术中，____将实际或计划的产品、过程和实践，与其他可比组织的实践进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。
A.头脑风暴
B.焦点小组
C.亲和图
D.标杆对照

(5）____是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。
A.系统交互图
B.决策矩阵
C.需求跟踪矩阵
D.UC矩阵

(6）应根据____来编制详细的项目范围说明书。
①可交付成果
②假设条件
③制约因素
④WBS

A.①②③
B.①②④
C.①③④
D.②③④

（7）关于项目范围说明书的理解，不正确的是____。
A.项目范围说明书可明确指出哪些工作不属于本项目范围
B.项目范围说明书使项目团队能进行更详细的规划，并为评价变更请求或额外工作是否超过项目边界提供基准
C.项目范围说明书描述要做和不要做的工作的详细程度，决定着项目管理团队控制整个项目范围的有效程度
D.项目范围说明书不能代表项目干系人之间就项目范围所达成的共识

（8）范围基准包括____。
①经过批准的范围说明书
②项目章程
③WBS词典
④WBS
⑤项目管理计划

A.①②③
B.①②④
C.①③④
D.①④③

2.简答题

请简述确认范围过程与控制质量过程的不同之处。
参考答案：略

end