1. 创建工作分解结构WBS

1.1. 自上而下的分解结构

1.2. 把项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程

1.3. 用来确定项目范围的

1.3.1. 包括分包出去的工作

1.3.1.1. 【21上选40】

1.4. 输入

1.4.1. 项目范围管理计划

1.4.2. 项目范围说明书

1.4.3. 需求文件

1.4.4. 事业环境因素

1.4.5. 组织过程资产

1.5. 工具与技术

1.5.1. 分解

1.5.1.1. 在层次上保持项目的完整性，避免遗漏必要的组成部分

1.5.1.2. 一个工作单元只能从属于某个上层单元，避免交叉从属

1.5.1.3. 相同层次的工作单元应用相同性质

1.5.1.4. 工作单元应能分开不同的责任者和不同的工作内容

1.5.1.5. 便于项目管理计划和项目控制的需要

1.5.1.6. 最底层工作应该具有可比性，是可管理的，可定量检查的

1.5.1.7. 应包括项目管理工作，包括分包出去的工作

1.5.2. 专家判断

1.6. 输出

1.6.1. 范围基准

1.6.1.1. 【21下选43】

1.6.1.2. 经过批准的范围说明书、工作分解结构(WBS)和相应的WBS词典组成了范围基准

1.6.2. 项目文件更新

1.6.2.1. 更新需求文件

1.7. 项目管理的基础

1.7.1. 项目的所有规划和控制工作都必须基于工作分解结构

1.7.2. 后续管理工作的主要依据

1.7.3. 有助于防止需求和范围蔓延

1.8. 需要所有项目干系人的参与

1.9. 逐层向下分解的

1.9.1. 应控制在3〜6层为宜

1.10. 各要素应该是相对独立的，要尽量减少相互之间的交叉

1.10.1. 【21下选40】

1.11. 一般用图表形式表达

1.11.1. 分级的树型结构

1.11.1.1. 一些小的、适中的应用项目中用得较多

1.11.2. 表格形式

1.11.2.1. 一些大型的、复杂的项目中使用还是较多的

1.12. 里程碑

1.12.1. 某个可交付成果或者阶段的正式完成

1.12.2. 具体时间+在这个时间应完成的事件

1.12.3. 关注事件是否完成

1.13. 最低层的工作单元被称为工作包

1.13.1. 位于工作分解结构每条分支最低层的可交付成果或项目工作组成部分

1.13.2. 8/80规则（80小时原则）建议工作包的大小应该至少需要8个小时来完成，而总完成时间也不应该大于80小时

1.13.3. 分配到一个控制账户

1.13.3.1. 控制账户是一个管理控制点

1.13.3.1.1. 【22上选40】

1.13.3.2. 设置在WBS中选定的管理节点上

1.13.3.3. 可能包括一个或多个工作包

1.13.3.3.1. 【19下选39】

1.13.4. 一个工作包只能属于一个控制账户

1.13.5. 工作分解结构词典

1.13.6. 从逻辑上讲，不能再分了

1.14. WBS编码设计

1.14.1. 任何等级的一位项目要素，是其余全部次一级项目要素的总和

1.14.2. 所有子项目的编码第一位数字是相同的，再下一级的工作单元的编码依此类推

2. 确认范围

2.1. 正式验收已完成的可交付成果

2.2. 正式验收己完成的项目可交付成果的过程

2.3. 控制质量过程通常先于确认范围过程

2.4. 由于范围的确认可以是阶段性的，所以交付物可能是中间交付物。这涉及到系统集成项目的验收问题，即可先分批验收，最后再终验，但是每一次验收都需要客户的书面确认

2.4.1. 【22下选40】

2.5. 使验收过程具有客观性；同时通过验收每个可交付成果，提高最终产品、服务或成果获得验收的可能性

2.5.1. 【19下选41】

2.6. 确认范围过程与控制质量过程的不同之处在于，前者关注可交付成果的验收，而后者关注可交付成果的正确性及是否满足质量要求

2.6.1. 【21下选41】

2.6.1.1. 【21上选41】

2.7. 应该贯穿项目的始终，从WBS的确认或合同中具体分工界面的确认，到项目验收时范围的检验

2.8. 输入

2.8.1. 项目管理计划

2.8.2. 需求文件

2.8.3. 需求跟踪矩阵

2.8.4. 核实的可交付成果

2.8.5. 工作绩效数据

2.8.5.1. 【22上选42】

2.9. 工具与技术

2.9.1. 检查

2.9.1.1. 【20下选41】

2.9.1.2. 审查、产品审查、审计和巡检

2.9.2. 群体决策技术

2.9.2.1. 【19上选44】

2.10. 输出

2.10.1. 验收的可交付成果

2.10.1.1. 以书面的形式正式签字批准

2.10.1.2. 没有被客户接受的交付物也应当记录下来，同时还要记录未被客户接受的原因

2.10.1.3. 可以是阶段性的

2.10.1.3.1. 可能是中间交付物

2.10.2. 变更请求

2.10.3. 工作绩效信息

2.10.4. 项目文件更新

2.10.5. 【22上选41】

3. 范围控制

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

3.2. 问题

3.2.1. 未经控制的产品或项目范围的扩大（未对时间、成本和资源做相应调整）被称为范围蔓延

3.2.1.1. 【21上选42】

3.2.2. 得不到投资人的批准

3.2.2.1. 【21下选42】

3.2.2.2. 客户通常只能提出范围变化的要求，但却没有批准的权力

3.2.2.2.1. 【19上选45】

3.2.3. 项目小组未尽责任

3.3. 需求变更及项目范围变更一定要遵循由变更控制委员会制定的变更控制流程

3.3.1. 【19下选42】

3.4. 缺乏沟通有可能导致范围或需求不符合客户要求，有可能导致范围变更

3.4.1. 【22下选41】

3.5. 在整个项目期间保持对范围基准的维护

3.6. 输入

3.6.1. 项目管理计划

3.6.2. 需求文件

3.6.3. 需求跟踪矩

3.6.4. 工作绩效数据

3.6.5. 组织过程资产

3.7. 工具与技术

3.7.1. 偏差分析

3.7.1.1. 一种确定实际绩效与基准的差异程度及原因的技术

3.8. 输出

3.8.1. 工作绩效信息

3.8.2. 变更请求

3.8.3. 项目管理计划更新