范围管理

范围管理涵盖哪些内容

施工单位会在施工现场周围设置围栏，以标明场地边界。界定项目范围的作用也是如此。范围管理明确项目必须完成的工作，确保团队做完所有这些工作，并始终遵守约定的边界。

提前规划如何确定、管理和控制范围。收集所有相关方的需求，并取得对明确定义的范围的正式批准。只向发起人或少数人收集需求，可能导致范围定义有误。大型项目需要花费更多时间、精力和资源来收集需求，因此清晰定义范围尤为重要。

根据已批准的范围开展工作，遵守范围管理计划。禁止镀金，即擅自增加额外内容。持续监控范围，让所有人都能辨别哪些工作在项目范围内，哪些在范围外。

评估范围变更对时间、成本、风险、质量、资源、客户满意度及其他相关方面的影响。通过整体变更管理来审批变更。变更发起人更新变更请求表，并在变更控制登记册中跟踪变更。

打开完整尺寸图表 ↗

打开完整尺寸图表 ↗

产品范围

产品范围回答“客户想要什么？”这一问题。组织可以另行立项来定义产品范围，也可以在为当前项目收集需求时定义。

以软件项目为例，产品范围可能是“满足内外部客户需求的新工作流应用程序”。要判断项目是否满足产品范围，可将完成的应用程序与需求文档和项目范围说明书中记录的需求进行比较。

项目范围

项目范围是实现产品范围所需的工作。在软件示例中，项目范围既包括开发应用程序的工作，也包括为交付应用程序开展的规划、协调和管理活动，例如开会和编写报告。这些工作都纳入项目管理计划及其范围管理计划。项目或阶段结束时，将已完成的工作与项目管理计划中的范围基准进行比较，确认是否符合约定的范围。

范围管理计划

范围管理计划涵盖范围的规划、执行和控制。在本课所用的过程框架中，团队在项目管理规划过程中制定范围管理计划，并将其纳入项目管理计划。它包含以下内容。

• 项目将如何实现其范围。
• 团队需要哪些工具来完成范围内的工作。
• 团队需要考虑哪些事业环境因素。
• 团队需要哪些组织过程资产。
• 团队在整个项目期间将如何管理和控制范围。

组织应具备范围管理模板、表格或标准，它们对项目工作至关重要。计划中的部分内容可以标准化，每个项目仍需制定自己的计划。项目经理以范围管理计划为参照，指导并衡量项目工作，直至收尾。

可分阶段制定计划，并在规划期间修订。先确定如何定义范围。项目整体规划完成后，再决定如何实施和控制范围，并将这些决定纳入范围管理计划。后续规划工作，例如人力资源规划，可能会发现新增范围，届时需要再次修订计划。

项目经理需要充分理解范围，才能编制计划。开始工作前先识别产品范围和项目范围。制定范围管理计划是项目管理的必要环节。

范围管理过程

1. 确定需求。根据项目章程中描述的商业论证，检查每项需求是否支持项目。
2. 在定义产品范围和项目范围时，考虑相关方的需求。
3. 用工作分解结构（WBS）将范围分解为更小、更易管理的部分。
4. 从客户的角度设计过程。
5. 在整个项目期间衡量范围绩效，并按需调整。

做好拒绝不必要工作的准备。额外范围会增加成本、时间和工作量。

收集需求

需求说明项目或产品需要具备哪些条件才能实现既定目标。需求可以涉及质量、业务流程、法规、合规、项目管理等领域。收集需求涵盖产品需求和过程需求。在纳入某项请求之前，先对照目标进行检查。

启动期间，项目章程记录高层级的项目和产品需求。收集需求过程从所有相关方处收集更具体的信息及有关假设。遗漏需求可能导致项目失败、反复变更或整个项目期间持续出现冲突。

先识别相关方，并将其记录在相关方登记册中。一个项目可能有数百位相关方，对不同群体可能需要采用不同的方式征询意见。在项目工作开始前，留出时间和精力收集需求。收集不全可能导致耗资且费力的变更。历史信息和经验教训可提供帮助。选择适合项目和相关方的方法。这些方法也可用于风险管理中的风险识别。

查阅历史记录

历史记录和经验教训可以说明类似项目需要什么，并有助于识别相关过程。它们能帮助新加入项目的人员了解不同团队的期望，也可能揭示其他项目经理在定义范围时犯过的错误，从而让你找到这些项目遗漏的需求。

访谈

访谈有时也称专家访谈，可以帮助项目经理识别相关方的产品或过程需求。可以一对一或分组访谈，也可以采用电子邮件、电话、信函或其他方式。

焦点小组

主持人或引导者向选定的一组相关方或领域专家收集意见和需求。讨论可以围绕产品或项目的某个方面展开。

引导式研讨会

引导式研讨会召集观点不同的相关方，共同定义产品或服务的需求。

头脑风暴

头脑风暴让参与者在彼此想法的基础上继续发挥，从而在短时间内产生许多创意。例如，一名参与者提出一种定义范围的方法，激发了另一人的想法，进而引发更多想法。应邀请来自组织内外、职能、背景和视角各不相同的人。

名义小组技术

头脑风暴结束后，由参与者对最好的想法进行排序。

德尔菲技术

在这种达成共识的方法中，专家匿名参与且不见面。向他们发出信息征询，汇总答复，再把结果发给他们复审。重复这一过程，直到专家达成共识。

思维导图

思维导图有助于产生想法，并把想法按逻辑分组。将主要想法画成中心想法的分支，再从这些分支延伸出相关想法。

亲和图

将用其他需求收集方法得到的想法按相似程度分组，并为每组需求加上标题。

打开完整尺寸图表 ↗

问卷与调查

问卷用于收集人们对一组问题的回答。问卷与调查可以覆盖大量人群。

观察

观察潜在产品用户如何开展工作。

原型

原型是拟议产品的模型。向相关方展示原型，并征求反馈。团队可能需要制作多个版本，才能收集所有需求，并敲定和批准模型。

群体决策

众多相关方的意见可能带来相互竞争的想法，造成混乱或引发冲突。逐一审查和分析想法，决定采纳或拒绝，并对获准的想法进行排序，再记录到项目文件中。

• 一致同意。 所有人都同意该需求，因而很容易作出决定。
• 独裁。 一个人代表全体作决定。这种方式决策较快，但其他相关方可能有异议。
• 大多数同意。 采纳半数以上成员支持的决定。
• 相对多数同意。 如果没有任何选项得到过半数支持，则采纳支持人数最多的选项。
• 达成共识。 群体达成一个大家都能接受的决定。原本倾向其他选项的成员也愿意接受大多数成员支持的决定。

需求文档

团队收集完需求后，应以清晰、明确的方式记录。需求文档是收集需求过程的输出。表达不清的需求容易被误解。请相关方确认文档中的需求是否符合既定目标。他们的反馈有助于核实团队是否收集了正确的需求，以及最终的可交付成果能否获得认可。

平衡相关方需求

对需求进行排序并解决冲突，使项目能够达成目标。如果无法满足所有需求，应设法平衡范围、时间、成本、质量、资源、风险和客户满意度方面相互竞争的诉求。

收集完成后仍要持续平衡各项需求。之后，一些相关方的需求可能与项目要求或其他相关方的需求发生冲突。项目经理需权衡这些需求和项目利益，并解决冲突。

明确项目目标，在收集需求过程中识别来自所有相关方的全部需求，并确定其优先级。这两项工作都是平衡需求的前提。

解决相互冲突的需求

各部门对项目的利益诉求可能不同。例如，风险团队发现风险后可能希望放慢项目进度，运营团队却希望尽早完成。应寻找两个部门都能接受的解决方案。

复杂冲突需要管理层介入。项目经理检查哪些需求支持商业论证，并审查项目章程、范围说明书和制约因素。

拒绝超出项目目标或已批准章程范围的请求，即使它们与项目最初立项的原因相关。项目章程的任何拟议变更都应与发起人讨论并报请审批。如果成本是首要制约因素，增加成本的请求不太可能获批。能够控制成本且对其他制约因素影响较小的请求更可能被接受。超出这些原则的请求可留待未来项目考虑。

需求管理计划

本章将需求管理计划描述为收集需求过程的输出。这份计划回答以下问题。

• 用哪些方法识别需求？
• 每项需求需要进行哪些分析？
• 如何确定需求的优先级？
• 如何管理需求？
• 如何跟踪需求？
• 需求跟踪矩阵必须提供哪些信息？

需求跟踪矩阵

在大型项目中，文档记录不佳可能导致需求遗失。一个需求可能衍生出多项细化要求或澄清事项，使人难以记得各项要求的来源。忘记某项需求的由来，可能使项目无法达成目标。

需求跟踪矩阵是收集需求过程的另一项输出。它将需求与项目目标及／或其他需求关联起来，以支持战略目标。在整个项目期间，用它来分析拟议的产品或项目范围变更。

打开完整尺寸图表 ↗

定义范围

根据收集需求过程生成的需求文档、项目章程，以及项目风险、假设条件和制约因素等信息，定义产品范围和项目范围。明确项目及其可交付成果包含和排除哪些内容。

规划是一个迭代过程。明确需求后，据此制定进度计划和预算。如果其中任何一项未达到管理层或发起人的期望，应重新审查制约因素，并权衡需求、预算和进度。向管理层提供实现范围、时间和成本目标的备选方案，例如压缩进度、寻找完成工作的其他方式，以及调整预算或范围。目标是制定切实可行的进度计划和预算，以完成约定范围内的工作。

产品分析

分析客户和发起人提供的产品目标与说明。根据分析确定具体的可交付成果。

项目范围说明书

项目范围说明书是定义范围过程的一项主要输出。编制说明书需要时间，可能要征求多位相关方的意见，包括外部专家。应明确指出两类排除项。

1. 未获批准的范围。 列明有人提出、但从未获准纳入的工作。
2. 无需纳入的范围。 澄清容易被误解的边界。

项目范围说明书、WBS 和 WBS 词典共同构成范围基准。范围基准属于项目管理计划的一部分。说明书可以包括以下内容。

• 产品范围。
• 项目范围。
• 可交付成果。
• 产品验收标准。
• 范围外的活动。
• 制约因素和假设条件。

创建工作分解结构（WBS）

无论项目大小，都需要 WBS。它把完整的项目范围划分为易于管理的可交付成果。没有 WBS，项目就会超过计划完工时间，项目经理也可能遗漏重要活动。

打开完整尺寸图表 ↗

大多数项目经理都会列出行动事项。清单太长会难以使用，可能遗漏可交付成果，也让大型项目难以分解成易于管理的部分。阅读者可能难以理解项目，或难以确认具体是谁编制了清单。

WBS 涵盖每一项行动事项。它的层级结构展示如何把工作划分为工作包，以及各项可交付成果如何关联。吸收相关方和团队的意见，有助于争取支持并改善绩效。创建 WBS 能让团队在脑海中预演项目全过程并改进计划。这会使执行更顺利、风险更低，鼓励参与，也让人们认识到项目目标可以实现。

WBS 看起来可能像组织结构图，其目的是把项目及其可交付成果所需的工作拆分为可以规划、组织、管理和控制的部分。从最高层开始，把可交付成果和工作分解为称为工作包的较小单元。

创建 WBS 的规则

1. 让团队参与。
2. 完成第一层，再进一步分解工作。
3. 每一层都是上一层的细分。
4. WBS 的各层合在一起，应能让人理解整个项目。
5. 只纳入本项目的可交付成果。

工作包和控制账户

当可交付成果满足以下条件时，可以视为工作包。

1. 能作出切合实际且可靠的估算。
2. 能在短时间内完成。
3. 能连续完成，无需中断或等待进一步的信息。
4. 在适当时可外包或交由承包商完成。

完成 WBS 后，对各层编号，使每个工作包都有标识符。有些项目在 WBS 中更高的层级管理成本，该层级称为控制账户。

在规划期间，团队使用范围说明书、WBS 和 WBS 词典，将工作包细分为产出可交付成果所需的活动。活动清单在时间管理的定义活动过程中编制。

WBS 是后续各项项目规划的基础。其图示层级结构识别每项可交付成果。某项活动必须与 WBS 所涵盖的工作有关，才属于该项目。WBS 有助于团队全面考虑项目的各个部分，也可在其他项目中复用。用 WBS 展示层级结构，用进度网络图展示活动之间的依赖关系。

项目经理使用 WBS 拆分项目。在这里， 拆解 以及 分解 描述的是同一过程。

打开完整尺寸图表 ↗

WBS 词典

WBS 词典描述每个工作包所包含的工作，是创建 WBS 过程的输出。它有助于防止范围蔓延，让所有人都能清楚了解可交付成果。词典可用于以下用途。

• 用作工作授权系统，标明工作包何时启动。
• 记录进度里程碑、验收标准和工作包的其他详情。
• 帮助控制实际开展哪些工作。
• 帮助相关方了解完成工作包所需的工作量。

打开完整尺寸图表 ↗

范围基准

基准是项目管理计划某个组成部分获批的最终版本。范围基准包括范围说明书、WBS 和 WBS 词典。开工前，管理层和相关方必须批准这三项。将实际进展与范围基准进行比较。

如有任何偏离范围基准的情况，应提出变更请求。通过实施整体变更控制处理请求。若获批准，则更新范围说明书、WBS、WBS 词典和其他受影响的文件或组成部分。满足需求并达到范围基准是衡量项目是否成功的依据。

核实范围

核实范围能确保项目按批准的范围推进。定期与客户或发起人沟通，并请对方验收已完成的可交付成果。

核实范围的输入

• 实施质量控制所得的已确认可交付成果。
• 范围说明书、WBS 和 WBS 词典。
• 需求跟踪矩阵。
• 需求文档。

核实范围的输出

• 验收的可交付成果。
• 变更请求。
• 项目文件更新。

核实范围可在各阶段结束时开展，也可作为监控工作贯穿整个项目。它由客户正式验收阶段性可交付成果。结束项目或阶段过程则对整个项目或阶段进行最终验收或签字确认。

控制范围

控制范围有两项主要职责：衡量项目及／或产品的范围绩效，以及管理范围基准的变更。定期检查范围，确认工作是否按计划推进。

两项必需的输入是项目管理计划中的范围基准和迄今已完成的工作。需求文档和需求跟踪矩阵也能提供帮助。识别任何偏离基准的情况，并建议采取纠正或预防措施。如需变更，则提出变更请求，通过实施整体变更控制处理，并更新必要的文件。

项目经理主动对照项目管理计划中的各项基准控制项目。所有范围变更都必须遵循变更管理流程。