目录
- 1 项目范围管理概述
- 2 规划范围管理
- 3 收集需求
- 4 定义范围
- 5 创建 WBS
- 6 确认范围
- 7 控制范围
1 项目范围管理概述
项目范围管理包括确保项目做且只做所需的全部工作，以成功完成项目的各
个过程。管理项目范围主要在于定义和控制哪些工作应在项目内，哪些工作不应
在项目内。
核心概念
项目范围管理旨在保证做且只做为完成项目所需的全部工作。
◆ 明确项目边界
◆ 明确全部可交付成果
◆ 确保做了该做的事
◆ 预防范围蔓延
◆ 防止范围蔓延
◆ 及时对可交付成果进行实质性验收
范围蔓延导致的结果就是镀金——做了额外的工作，“镀金”的项
目是失败的，因为用于镀金的资源本可用于更有价值的事情。
项目管理的“范围”包含了产品范围和项目范围两个概念：
◆ 产品范围：某项产品、服务或成果所具有的特征和功能。
◆ 项目范围：为交付具有规定特性与功能的产品、服务或成果而必须完成
的工作，有时也包括产品范围。
产品范围决定项目范围，项目范围服务于产品范围。
广义的项目范围，由产品范围和狭义的项目范围构成。
项目范围管理是项目其他各方面管理的基础，项目范围、进度、成本、质量
是确定项目目标必不可少的要素。
在预测型生命周期中，在项目开始时就定义项目可交付成果，对任何范围变
化都要进行监督管理；在适应型或敏捷型生命周期中，通过多次迭代来开发可交
付成果，并在每次迭代开始时定义和批准详细的范围。
采用适应型或敏捷型生命周期，旨在应对大量变更，需要相关方持续参与项
目：
◆ 在一个迭代周期开始时，团队将努力确定产品未完项中的最优先项；
◆ 发起人和客户代表持续参与项目，随同可交付成果的创建提供反馈意见，
并确保产品未完项反映了他们的当前需求；
◆ 在每次迭代中，都会重复开展收集需求、定义范围、创建 WBS、确认范
围和控制范围。
在预测型项目中，经过批准的项目范围说明书、工作分解结构（WBS）和
WBS 词典构成了范围基准。
只有通过正式变更控制程序，才能变更项目基准。
确认范围是正式验收已完成可交付成果的过程，控制质量过程输出核实的可
交付成果，经控制范围、确认范围后，输出验收的可交付成果，并由授权的相关
方签字批准。
发展趋势和新兴实践
◆ 注重与商业分析专业人士的合作
◆ 确定问题并识别商业需求
◆ 识别并推荐能够满足这些需求的切实可行的解决方案
◆ 收集、记录并管理相关方需求，以满足商业和项目目标
◆ 推动项目集或项目的产品、服务或最终成果的成功应用
裁剪时考虑的因素
◆ 知识和需求管理
◆ 确认和控制
◆ 开发方法
◆ 需求的稳定性
◆ 治理
在敏捷/适应型环境中的考虑因素
对于需求不断变化、风险大或不确定性高的项目，在项目开始时通常无法明
确项目的范围，而需要在项目期间逐渐明确。不断涌现的需求往往导致真实的业
务需求与最初所述的业务需求之间存在差异。因此，敏捷方法有目的的构建和审
查原型，并通过多次发布版本来明确需求。在敏捷方法中，范围会在整个项目期
间被重新定义，并将需求列入未完项。
2 规划范围管理
规划范围管理为记录如何定义、确认和控制项目范围及产品范围，而创建项
目范围管理计划的过程。本过程的主要作用是，在整个项目期间对如何管理范围
提供指南和方向。
规划范围管理就是要编制范围管理计划和需求管理计划，范围管理计划是关
于如何定义、制定、监控和确认产品范围与项目范围的计划；需求管理计划是关
于如何收集、记录、分析和控制需求的计划。
需求管理计划规定收集需求过程如何开展，范围管理计划规定定义
范围、创建 WBS、确认范围和控制范围过程将如何开展。
4W1H
3 收集需求
收集需求是为实现目标而确定、记录并管理相关方的需要和需求的过程。本
过程的主要作用是，为定义产品范围和项目范围奠定基础。
收集需求过程是根据范围管理计划和需求管理计划，收集项目相关方对项目
的具体需求。把相关方对项目的需要（Needs）、想要（Wants）和期望（Expectations）
转变成具体的项目需求（Requirements），并记录下来。
收集需求旨在使需求明确化、具体化和书面化。需求必须是可测量的、文档
化的，将收集的需求记录并形成需求文件，同时编制需求跟踪矩阵。
需求的主要类型包括：
◆ 业务需求：这是最高层次的、整个组织的需求。
◆ 相关方需求：这是中间层次的、每个或每组相关方的需求。
◆ 解决方案需求：这是最低层次的、技术方面的需求，是为了实现商业需
求和相关方需求，项目产品必须具备的特性和功能。
◆ 功能需求：描述产品应具备的功能。
◆ 非功能需求：对功能需求的补充，描述了产品正常运行所需的环境
条件或质量要求。
◆ 过渡和就绪需求：描述了从“当前状态”过渡到“将来状态”所需的临
时能力。
◆ 项目需求：项目需要满足的行动、过程或其他条件。
◆ 质量需求：用于确认项目可交付成果的成功，或确认用于实现其他项目
需求的任何条件或标准。
用一定的解决方案去满足相关方需求，并通过满足相关方需求来实
现商业需求。
4W1H
标杆对照
将实际或计划的项目实践与可比项目的实践进行比较，可以识别最佳实践、
形成改进意见，从而为绩效考核提供依据。
德尔菲技术
在主持人的引导下，由一群人通过集体讨论、评审和匿名投票的方式对创意
进行唯一选择，能有效地减少个人偏见和不合理影响。
名义小组
由一群人通过集体讨论、评审和匿名投票的方式对创意进行排序。
观察/交谈
通过直接观察个人在各自环境中如何开展活动来进行了解。
联合应用开发
由项目开发团队和用户一起共同定义需求。
亲和图
对需求、问题或原因进行归类，将相似性的内容归纳为更大的要素。
思维导图
可以将各种条件、因素与某个核心质量要求联系起来，可以找出各原始需求
之间的顺序关系、因果关系或隶属关系。特别适合做群体发散性思维。
问卷调查
通过设计一系列的书面问题，向众多受访者快速收集信息。
系统交互图
以图形方式直观的展示该系统与其他系统之间的接口关系，从而确定该系统
应该满足什么需求。
用户故事
参会者一起创建关于相关方需求的故事，包括相关方角色、相关方想要什么、
相关方为什么想要它。
原型法
在实际生产前开发出产品模型，据此征求相关方的反馈意见。
质量功能展开
质量功能展开强调把功能和需求联合起来考虑，来确定各种功能满足用户需
求的程度，以便对功能进行优先级排序。
需求收集方法
“考虑潜在需求”与“镀金”之间有一个不易区分的灰色地带，项
目经理的一项重要工作，就是尽量识别项目相关方的明示和潜在需求，
并将它们表述成明确、具体的可操作的项目要求。
4 定义范围
定义范围是制定项目和产品详细描述的过程。本过程的主要作用是，描述产
品、服务或成果的边界和验收标准。
定义范围过程从需求文件中选取最终的项目需求，然后制定出关于项目及其
产品、服务或成果的详细描述，用于确定哪些需求必须在本项目上实现，并基于
这些需求编制项目范围说明书，明确项目范围边界。
项目范围边界包括：
◆ 产品范围描述
◆ 可交付成果
◆ 验收标准
◆ 除外责任
在定义范围过程中，还要细化项目章程所列出的制约因素和假设条件、更新
假设日志。
在风险管理知识领域分析风险之后，可能要根据风险登记册来调整
项目范围。
项目经理应该把必须由高层管理人员或职能经理负责的事情列为
假设条件，以便保护自己。
4W1H
产品分析
产品分析是用于定义产品和服务，描述要交付的产品用途、特征等信息。
5 创建 WBS
创建工作分解结构（WBS）是把可交付成果和项目工作分解成较小的、更易
于管理的组件的过程。本过程的主要作用是，为所要交付的内容提供架构。
根据范围管理计划，以及项目范围说明书和需求文件，编制 WBS 和 WBS 词
典，进而形成项目的范围基准。
WBS 是对项目团队为实现项目目标、创建所需的可交付成果而需要实施的
全部工作范围的层级分解。WBS 组织并定义了项目的总范围，代表着经批准的
当前项目范围说明书中规定的工作。
工作分解结构用来确定项目总范围。项目的全部工作都必须包含在工作分解
结构中，未含在内的工作都不是项目的组成部分且都不能做；子要素之和必须正
好等于相应的母要素，所有子要素都完成了，其相应的母要素也就同时完成了；
对于不产出可交付成果的辅助性工作，也需进行分解并添加到分解结构中，从而
得到完整的工作分解结构。
工作分解结构必须且只能包含 100%的工作
◆ 控制账户：是一种管理控制点，项目经理针对控制账户考核项目执行情
况。
◆ 工作包：工作包是 WBS 的最低层级的带有独特标识的组件，每个工作包
只与一个控制账户关联。
◆ 规划包：一个控制账户可以包含一个或多个规划包，它是一种低于控制
账户而高于工作包的工作分解结构组件。它表示工作内容已知，但详细
的进度活动未知，是项目活动中暂时无法分解的项目。随着项目的渐进
明晰，规划包最终将被分解成工作包和相应的进度活动。
规划包不能直接付诸执行，必须先分解成工作包。
项目的所有规划、执行、监控和收尾工作都必须基于工作分解结构，WBS
有助于实现：
◆ 促使人们在项目早期就考虑周全，防止遗漏。
◆ 促进相关方的统一认识。
◆ 是编制其他计划的基础。
◆ 是进行项目组织设计的依据之一。
◆ 是进行项目执行和监控的重要依据。
◆ 是考核项目是否完工的依据。
WBS 词典
在编制 WBS 的同时，也需要同步编制 WBS 词典，用于对每个 WBS 要素进
行解释。这些解释既可以很详细，也可以很简单，但必须足以让团队成员明白其
具体内容。
4W1H
分解
分解是一种把项目范围和项目可交付逐步划分为更小、更便于管理的组成部
分的技术。
6 确认范围
确认范围是正式验收已完成的项目可交付成果的过程。本过程的主要作用是，
使验收过程具有客观性；同时通过确认每个可交付成果，来提高最终产品、服务
或成果获得验收的可能性。
确认范围过程是由项目发起人、客户和其他主要相关方正式验收已完成并被
核实为质量合格的可交付成果。
符合验收标准的可交付成果应由客户或发起人正式签字批准，证明相关方对
项目可交付成果的正式验收，并将正式文件分发给其他项目相关方。
确认范围过程注重可交付成果的可接受性，控制质量过程注重可交
付成果的正确性。
必须在监控阶段完成对各个可交付成果的实质性验收，以便在还有
时间解决问题时发现并解决问题；在整个项目完工时，再开展项目产品
的整体验收（形式验收），办理移交手续。
4W1H
检查
检查是开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需
求和产品验收标准。
7 控制范围
控制范围是监督项目和产品的范围状态，管理范围基准变更的过程。本过程
的主要作用是，在整个项目期间保持对范围基准的维护。
控制范围过程是把项目范围执行的实际情况与项目计划中的范围要求做比
较，以确认是否符合项目范围要求，从而发现偏差、分析偏差、提出解决建议、
预测范围绩效。
控制范围是由项目团队在可交付成果的完成过程中开展的，确认范
围是由项目发起人或客户在可交付成果完成之后开展的。
4W1H
