控制范围是监督项目和产品的范围状态，管理范围基准变更的过程。
本过程的主要作用是，在整个项目期间保持对范围基准的维护，且需要在整个项目期间开展。
控制项目范围确保所有变更请求、推荐的纠正措施或预防措施都通过实施整体变更控制过程（见 4.6 节）进行处理。
在变更实际发生时，也要采用控制范围过程来管理这些变更。
控制范围过程应该与其他控制过程协调开展。
未经控制的产品或项目范围的扩大（未对时间、成本和资源做相应调整）被称为范围蔓延。
变更不可避免，因此在每个项目上，都必须强制实施某种形式的变更控制。
确认范围是正式验收已完成的项目可交付成果的过程。
本过程的主要作用是，使验收过程具有客观性；同时通过确认每个可交付成果，来提高最终产品、服务或成果获得验收的可能性。
本过程应根据需要在整个项目期间定期开展。
由客户或发起人审查从控制质量过程输出的核实的可交付成果，确认这些可交付成果已经圆满完成并通过正式验收。
本过程对可交付成果的确认和最终验收，需要依据：
从项目范围管理知识领域的各规划过程获得的输出（如需求文件或范围基准），以及从其他知识领域的各执行过程获得的工作绩效数据。
确认范围过程与控制质量过程的不同之处在于，前者关注可交付成果的验收，而后者关注可交付成果的正确性及是否满足质量要求。
控制质量过程通常先于确认范围过程，但二者也可同时进行。
符合验收标准的可交付成果应该由客户或发起人正式签字批准。
应该从客户或发起人那里获得正式文件，证明相关方对项目可交付成果的正式验收。
这些文件将提交给结束项目或阶段过程（见 4.7 节）。
分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术；工作包是 WBS 最低层的工作，可对其成本和持续时间进行估算和管理。
分解的程度取决于所需的控制程度，以实现对项目的高效管理；工作包的详细程度则因项目规模和复杂程度而异。
要把整个项目工作分解为工作包，通常需要开展以下活动：
创建 WBS 的方法多种多样，常用的方法包括自上而下的方法、使用组织特定的指南和使用 WBS模板。
自下而上的方法可用于归并较低层次组件。WBS 的结构可以采用多种形式，例如：
对 WBS 较高层组件进行分解，就是要把每个可交付成果或组件分解为最基本的组成部分，即可核实的产品、服务或成果。
如果采用敏捷方法，可以将长篇故事分解成用户故事。
WBS 可以采用提纲式、组织结构图或能说明层级结构的其他形式。
通过确认 WBS 较低层组件是完成上层相应可交付成果的必要且充分的工作，来核实分解的正确性。
不同的可交付成果可以分解到不同的层次。
某些可交付成果只需分解到下一层，即可到达工作包的层次，而另一些则须分解更多层。
工作分解得越细致，对工作的规划、管理和控制就越有力。
但是，过细的分解会造成管理努力的无效耗费、资源使用效率低下、工作实施效率降低，同时造成 WBS 各层级的数据汇总困难。
要在未来远期才完成的可交付成果或组件，当前可能无法分解。
项目管理团队因而通常需要等待对该可交付成果或组成部分达成一致意见，
才能够制定出 WBS 中的相应细节。
这种技术有时称做滚动式规划。
WBS 包含了全部的产品和项目工作，包括项目管理工作。
通过把 WBS 底层的所有工作逐层向上汇总，来确保既没有遗漏的工作，也没有多余的工作。
这有时被称为 100% 规则。
关于 WBS 的详细信息，可参考《工作分解结构实践标准》（第 2 版）[15]。
该标准列举了一些具体行业的 WBS 模板，可以在裁剪后应用于特定领域的具体项目。
创建工作分解结构（WBS）是把项目可交付成果和项目工作分解成较小、更易于管理的组件的过程。
本过程的主要作用是，为所要交付的内容提供架构，它仅开展一次或仅在项目的预定义点开展。
WBS 是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解。
WBS 组织并定义了项目的总范围，代表着经批准的当前项目范围说明书中所规定的工作。
WBS 最低层的组成部分称为工作包，其中包括计划的工作。
工作包对相关活动进行归类，以便对工作安排进度、进行估算、开展监督与控制。
在“工作分解结构”这个词语中，“工作”是指作为活动结果的工作产品或可交付成果，而不是活动本身。
范围基准是经过批准的范围说明书、WBS 和相应的 WBS 词典，只有通过正式的变更控制程序才能进行变更，它被用作比较的基础。范围基准是项目管理计划的组成部分，包括：
WBS 词典中的内容可能包括（但不限于）：
产品分析可用于定义产品和服务，包括针对产品或服务提问并回答，以描述要交付的产品的用途、特征及其他方面。
每个应用领域都有一种或几种普遍公认的方法，用以把高层级的产品或服务描述转变为有意义的可交付成果。
首先获取高层级的需求，然后将其细化到最终产品设计所需的详细程度。
产品分析技术包括（但不限于）：
定义范围是制定项目和产品详细描述的过程。
本过程的主要作用是，描述产品、服务或成果的边界和验收标准。
由于在收集需求过程中识别出的所有需求未必都包含在项目中，所以定义范围过程就要从需求文件（收集需求过程的输出）中选取最终的项目需求，然后制定出关于项目及其产品、服务或成果的详细描述。
准备好详细的项目范围说明书，对项目成功至关重要。
应根据项目启动过程中记载的主要可交付成果、假设条件和制约因素来编制详细的项目范围说明书。
在项目规划过程中，随着对项目信息的更多了解，应该更加详细具体地定义和描述项目范围。
此外，还需要分析现有风险、假设条件和制约因素的完整性，并做必要的增补或更新。
需要多次反复开展定义范围过程：在迭代型生命周期的项目中，先为整个项目确定一个高层级的愿景，再一次针对一个迭代期明确详细范围。
通常，随着当前迭代期的项目范围和可交付成果的进展，而详细规划下一个迭代期的工作。
项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。
它记录了整个范围，包括项目和产品范围；详细描述了项目的可交付成果；还代表项目相关方之间就项目范围所达成的共识。
为便于管理相关方的期望，项目范围说明书可明确指出哪些工作不属于本项目范围。
项目范围说明书使项目团队能进行更详细的规划，在执行过程中指导项目团队的工作，并为评价变更请求或额外工作是否超过项目边界提供基准。
项目范围说明书描述要做和不要做的工作的详细程度，决定着项目管理团队控制整个项目范围的有效程度。
详细的项目范围说明书包括以下内容（可能直接列出或参引其他文件）：
虽然项目章程和项目范围说明书的内容存在一定程度的重叠，但它们的详细程度完全不同。
项目章程包含高层级的信息，而项目范围说明书则是对范围组成部分的详细描述，这些组成部分需要在项目过程中渐进明细。表 5-1 显示了这两个文件的一些关键内容。
原型法是指在实际制造预期产品之前，先造出该产品的模型，并据此征求对需求的早期反馈。
原型包括微缩产品、计算机生成的二维和三维模型、实体模型或模拟。
因为原型是有形的实物，它使得相关方可以体验最终产品的模型，而不是仅限于讨论抽象的需求描述。
原型法支持渐进明细的理念，需要经历从模型创建、用户体验、反馈收集到原型修改的反复循环过程。
在经过足够的反馈循环之后，就可以通过原型获得足够的需求信息，从而进入设计或制造阶段。
故事板是一种原型技术，通过一系列的图像或图示来展示顺序或导航路径。
故事板用于各种行业的各种项目中，如电影、广告、教学设计，以及敏捷和其他软件开发项目。
在软件开发中，故事板使用实体模型来展示网页、屏幕或其他用户界面的导航路径。