第13章 监控过程组 / 13.2
13.2 确认范围
一句话讲明白
把检查合格的成果摊开，请客户或发起人逐项签字确认："是我要的，收了。"
生活类比
装修完了，业主拿着当初签的《施工项目清单》走进屋子：地柜几个、插座几个、墙刷什么颜色，一项一项对，对一项划一个勾。划完在验收单上签字，装修公司才能要尾款。
注意顺序：是先让项目经理自己拿靠尺把墙量一遍披瑕清零（控制质量），再请业主来签字（确认范围）。要是墙还歪着就请业主来，那是自己找尴尬——所以教材说"通常情况下，在确认范围前，项目团队需要先进行质量控制工作"。
正经定义
确认范围是正式验收已完成的项目可交付成果的过程。主要作用是使验收过程具有客观性；同时通过确认每个可交付成果来提高最终产品、服务或成果获得验收的可能性。本过程应根据需要在整个项目期间定期开展。
核心一句话：由主要干系人，尤其是客户或发起人，审查从控制质量过程输出的"核实的可交付成果"，确认其已经圆满完成并通过正式验收。
拆解与流程
一、输入 / 工具与技术 / 输出
| 主要输入 | 主要工具与技术 | 主要输出 |
|---|---|---|
| 项目管理计划（范围管理计划、需求管理计划、范围基准）、项目文件（经验教训登记册、质量报告、需求文件、需求跟踪矩阵）、核实的可交付成果、工作绩效数据 | ① 检查（审查、评审、审计、巡检）② 决策（投票） | 验收的可交付成果、工作绩效信息、变更请求；另有项目文件更新 |
二、确认范围的五个步骤
- 确定需要进行范围确认的时间；
- 识别范围确认需要哪些投入；
- 确定范围正式被接受的标准和要素；
- 确定范围确认会议的组织步骤；
- 组织范围确认会议。
挣是阶段性的活：应该贯穿项目的始终，不是只在收尾做一次。
三、确认时该问的 6 个问题
① 可交付成果是确定的、可确认的吗？② 每个可交付成果有明确里程碑、里程碑有可辨别事件（如客户书面认可）吗？③ 有明确的质量标准、成果与标准之间有明确联系吗？④ 审核和承诺的表述是否清晰，发起人是否正式同意边界？⑤ 项目范围是否覆盖所有活动，有无遗漏或错误？⑥ 项目范围的风险是否太高，管理层能否降低其影响？
四、四类人关注点不同（案例题送分）
| 干系人 | 关注什么 |
|---|---|
| 管理层 | 关注项目范围：对进度、资金、资源的影响是否超过组织承受力，投入产出是否合理——甚至可能取消项目或要求压缩范围 |
| 客户 | 关注产品范围：可交付成果够不够完成产品或服务；客户往往想往当前版本里塞进所有功能，这是潜在风险 |
| 项目管理人员 | 关注项目制约因素：成果是否足够且必须完成，时间、资金、资源是否够 |
| 项目团队成员 | 关注自己负责的元素：自己的时间够不够、多项任务是否冲突 |
考试怎么考
- 必背：输入＝核实的可交付成果；输出＝验收的可交付成果（提交给结束项目或阶段过程）；确认范围贯穿项目始终。
- 常见问法：
- "某可交付成果已通过控制质量检查，下一步？" → 确认范围（让客户/发起人正式验收）。
- "客户认为某项已完成，项目经理认为未完成，应依据什么？" → 范围基准/需求文件与验收标准。
- "确认范围发现了偏差会怎么办？" → 提变更请求，走 13.12 实施整体变更控制。
- 陷阱词：把"确认范围"说成"检查质量"（那是控制质量）；把"正式验收"说成"内部验证"。
易混辨析
| 对比 | 控制质量 | 确认范围 | 结束项目或阶段 |
|---|---|---|---|
| 关注点 | 可交付成果是否正确、是否满足质量要求 | 可交付成果的验收（客户/发起人签字） | 最终移交与收尾（移交成果、释放资源、总结经验教训） |
| 谁来做 | 项目团队 | 客户/发起人 | 项目经理/发起人 |
| 先后 | 通常先（也可并行） | 后 | 最后 |
| 输出 | 核实的可交付成果 | 验收的可交付成果 | 最终产品移交、组织过程资产更新 |
另与 13.3 控制范围 区分：控制范围是管范围基准的变更（防止悄悄变大），确认范围是验收成果（签字）。
一秒记忆
"先自检（控制质量）、再签字（确认范围）、最后交钥匙（结束项目或阶段）。管理层看书（范围）、客户看产品、项目经理看制约、成员看自己的活。"