项目范围管理的宗旨就是做且只做所需的全部工作，以确保完成项目。
本章节包含了 6 个过程：
1、规划范围管理：制定项目范围管理计划
2、收集需求：收集、记录干系人需求，收集干系人想要什么？
3、定义范围：项目团队需要做什么来满足干系人的需求？
4、创建工作分解结构（创建 WBS）：把可交付成果和项目工作分解成较小的、更易于管理的组成部分。
5、控制范围：监督项目和产品的范围状态，管理范围基准的变更，确保范围不要有偏差。
6、确认范围：正式验收项目已完成的可交付成果。
5.1 规划范围管理
1、过程定义：创建范围管理计划，书面描述将如何定义、确认和控制项目范围的过程。在整个项目中对如何管理范围提供指南和方向。
2、规划范围管理的输出：范围管理计划：
描述将如何定义、制定、监督、控制和确认项目范围。指导如何制定项目范围说明书、如何创建 WBS、如何验收可交付成果、如何处理对范围说明书的变更等等。
3、规划范围管理的输出：需求管理计划：
如何分析、记录和管理需求。阶段与阶段间的关系对如何管理需求有很大影响。项目经理为项目选择最有效的阶段间关系，并将它记录在需求管理计划中。
5.2 收集需求
1、过程定义：为实现项目目标，记录、管理干系人的需要和需求。
收集需求，为定义和管理项目范围奠定基础。
收集需求，是收集“人”的需求，因此与人有关系，输入参考干系人参与计划、干系人登记册。
2、收集需求的工具：数据收集（问卷调查、标杆对照）
1）问卷调查：适用于干系人特别多、想要快速完成调查、受访者位置分散。
2）标杆对照 Benchmarking：将实际或规划中的项目实践与好的项目榜样对照，识别最佳实践。标杆来自组织内部或外部。
3、收集需求的工具：决策（投票、多标准决策分析）
1）投票
a、大多数原则：少数服从多数，40%的要服从 60%的
b、相对多数原则：适合候选超过 2 个的时候，没一个都没超过 50%。比如第一个 35%，第二个 20%，第三个 45%。这时服从相对多数的 45%
c、一致同意：德尔菲技术。一群专家主观预测，背靠背不见面以匿名形式回答问卷，然后交给主持人，经过多轮次的投票最后取得一致意见。
d、*：一个人说了算。
2）多标准决策分析：借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，从而对众多方案进行评估和排序的一种技术。
4、收集需求的工具：数据表现（亲和图、思维导图）
1）亲和图：将大量创意按照亲和性直观地进行逻辑分组。
2）思维导图：把头脑风暴中获得的创意，整合成一张图，目的在于激发思维、激发引导新的创意。
5、收集需求的工具：人际关系与团队技能（名义小组技术、观察/交谈、引导）
1）名义小组技术：头脑风暴产生的创意散乱无规律，通过投票排列头脑风暴中最有用的创意、排列优先顺序，小组成员各自先不通气（只是名义上的）。
2）观察/交谈：干系人难以或不愿意说明他们的需求时使用。
3）引导式研讨会：跨职能、跨部门召集主要干系人开会，定义产品需求。实际应用的实例，像联合应用开发 JAD、质量功能展开 QFD、用户故事等等。
用户故事，在敏捷方法中用的比较多，用户以诉说一个小故事的形式要表达自己的需求，pm和团队听这个故事来获取需求。
收集需求的工具：原型法
制造预期产品之前先造出这个产品的一个模型，然后来收集反馈意见。
输出：需求文件、需求跟踪矩阵。
1）需求文件：收集的需求都被记录在需求文件当中。包括了业务需求、干系人需求、项目需求等。
2）需求跟踪矩阵：把产品需求从其来源连接到能满足需求的可交付成果的一种表格 RTM 提供了在整个项目生命周期中跟踪需求的一种方法。
记录每一个需求产生的原因、需求存在的价值、目标是什么、产生哪个成果、怎么设计、怎么开发、怎么做测试？确保每个需求都能有商业价值。
5.3 定义范围
根据所收集的需求，确定项目团队应该做什么，明确范围边界。明确了范围边界之后，从而明确项目、成果的边界。
1、定义范围的工具：产品分析
用于把高层级的产品描述转变为有形的可交付成果。
比如产品分解：
2、产品设计之 KISS 原则
Keep It Simple and Stupid
KISS 是指在产品设计当中应当注重简约的原则
简约并不简单
比如：IPAD、微信
3、定义范围的输出：项目范围说明书
它记录了整个范围,包括项目和产品范围;详细描述了项目的可交付成果 。
项目范围说明书包括了：产品范围描述、验收标准、项目可交付成果、项目的除外责任（哪些工作该做、哪些不该做）。
1）产品范围描述：逐步细化在项目章程和需求文件中所述的产品、服务或成果的特征。
2）验收标准：可交付成果通过验收前必须满足的一系列条件。
3）可交付成果：在某一过程、阶段或项目完成时，必须产出的任何独特并可核实的产品、成果或服务能力。
4）除外责任：哪些工作不该做。
5.4创建 WBS：
1、定义：把项目可交付成果和项目工作分解成较小的、更易于管理的组成部分。
2、创建wbs的工具：分解
分解是把项目范围和可交付成果逐步划分为更小、更便于管理的组成部分的技术分解的程度取决于所需的控制程度，以实现对项目的高效管理
WBS是项目范围的最准确定义，WBS组织并定义了项目的总范围。项目范围说明书是文字层的大框架定义，WBS是结构化的视图。
1）创建WBS是以可交付成果为对象，自上而下进行分解，越往下越详细。
2）不同的可交付成果可以分解到不同的层次。
3）工作包是WBS最底层的工作，可对其进行成本和持续时间估算、管理。
4）项目管理、外包都要包含进WBS中。
5）WBS中的两个层级可交付成果：控制账户、规划包。
控制账户：是范围、时间、成本的综合管控点。每一个控制账户都可以包括一个或者多个工作包，但是每一个工作包只能属于一个控制账户。控制账户可以包括一个或者多个规划包。
滚动式规划：其实滚动式规划也是创建WBS的工具，只是PMBOK没有明确列出。它是一种渐进明细的方法，近期的要完成的可交付成果规划的详细一些，而远期的可交付成果规划的粗略一些。
100%原则：通过把WBS底层的所有工作逐层向上汇总，确保既没有遗漏的工作，也没有多余的工作。
3、创建WBS的输出：范围基准。
范围基准是经过批准的范围说明书、WBS和相应的WBS 词典，只有通过正式的变更控制程序才能进行变更，它被用作比较的基础。
WBS 词典：是针对每个WBS 组件，详细描述可交付成果、活动和进度信息的文件。
它对WBS 提供支持。
它和WBS配套使用的，对wbs图进行补充，文字的描写，显示了WBS中每个工作包的详细信息。
相当于是个名词解释的文档。
那么通俗来讲，WBS 词典是干什么的呢？
WBS 是个视图，光看图万一没看懂怎么办？
出来了一个词典，对图来进行补充和解释
比如一个 WBS 组件“水池”要做到什么程度？做多宽？多长？用什么材料？进展到哪一步了，这些在 WBS 词典里面进行了一个解释
所以，范围基准里的范围说明书、WBS、WBS 词典，三者缺一不可
5.5控制范围：
1、定义：监督项目和产品的范围，管理范围基准的变更
确保做、且只做范围内的事！
如果范围真的有变化，需要变更，确保必须走正式的变更管理流程来变基准
2、控制范围工具：数据分析（偏差分析、趋势分析）
1）偏差分析：把实际绩效与计划作对比，发现差异程度
2）趋势分析：看一段时间内的走势，分析未来会改善还是会恶化，含有预测的成分。
镀金、范围蔓延/范围潜变、渐进明细三者区别：
1）镀金：是项目人员为了“讨好”客户而“画蛇添足”做的项目活动。PMI觉得镀金的项目是失败的，反对镀金。
2）范围蔓延/范围潜变：没有得到控制的范围扩大、没有得到控制的变更，没有走变更管理流程。比如：客户和某个团队成员关系很好，他提出要加一个功能，这个成员直接就帮他加了。客户没正式提出变更请求，没走流程。团队成员私自帮他加了内容，这是范围蔓延。属于镀金的一种形式。
3）渐进明细是正常的，因为项目范围不可能在开始的时候就非常清晰，需要不断地细化、完善。比如计划买双鞋，没有确定颜色、款式、价位，到商场后看到了好多双鞋，慢慢的对自己要买的鞋的颜色、款式、价位都有了明确的认识。这是渐进明细。渐进明细是正常的，逐步细化。而范围蔓延和镀金都是不正常的，PMI主义反对镀金、反对范围蔓延。
5.6确认范围：
1、过程定义：正式验收已完成的项目可交付成果。
2、确认范围的输入：核实的可交付成果
是指已经完成，并被控制质量过程检查为正确的可交付成果
控制质量关注可交付成果的正确性以及是否满足质量要求，通常由项目团队参与；确认范围关注可交付成果的验收，通常由客户或发起人参与。一般来说，先做控制质量、后做确认范围
因为先是内部检验、再有外部验收
控制质量得到核实的可交付成果，作为了确认范围的输入，经过确认范围的外部检查，得到了输出“验收的可交付成果”
验收的可交付成果又作为了结束项目或阶段的输入，这是项目收尾的必要条件。
3、确认范围的输出：验收的可交付成果
符合验收标准的可交付成果应该由客户或者发起人正式签字批准
4、确认范围的输出：变更请求
未通过验收的可交付成果需要提出变更，开展缺陷补救。