范围控制例行检查清单
范围控制的目标是维持基准的可信度：确认已完成的部分有验收记录、所有变更都被登记、需求跟踪矩阵与最新版本一致、未批准的需求没有被悄悄开发、范围偏差已反映到进度与成本预测中。基准一旦失真，后续所有绩效分析都会失去意义，因此这类检查应固定周期执行并留痕。
基本信息
| 检查对象 | 范围基准的完整性与一致性 |
|---|---|
| 检查频率 | 每个报告周期或阶段关口一次 |
| 必备证据 | 验收记录、变更日志、需求跟踪矩阵、版本记录 |
| 关联产出 | 变更请求、纠正措施、基准更新 |
| 责任角色 | 项目经理执行，PMO 或质量人员抽查 |
典型使用场景
- 月度范围检查：核对本期交付物的验收记录是否齐全，条件验收是否有跟踪
- 变更密集期：抽查变更日志是否覆盖口头变更与紧急变更
- 测试与验收前：确认需求跟踪矩阵已更新到设计与测试阶段
- 发现多余功能时：反查未批准需求是否被误开发，追责并补登变更
- 绩效分析前：确认范围偏差已同步到进度与成本预测口径
检查清单
检查清单
1) 每个已完成交付物是否有验收记录（含条件与验证方式）
2) 变更日志是否覆盖全部口头与紧急变更
3) RTM 是否更新（需求 -> 设计 -> 测试 -> 验收）
4) 未批准需求是否明确标记、是否被误开发
5) 范围偏差是否同步反映到进度与成本预测
6) 交付物是否与 WBS 覆盖范围一致，有无额外工作
输出：检查结论、整改项、责任人与完成时点常见缺口与后果
| 缺口 | 后果 | 整改方向 |
|---|---|---|
| 验收记录缺失 | 进度完成度无法证明 | 补做验收并追加记录，条件项纳入跟踪 |
| 口头变更未登记 | 基准失真，结算争议 | 追溯登记并追认审批 |
| RTM 未更新 | 测试覆盖出现盲区 | 按最新需求版本刷新矩阵 |
| 未批需求被开发 | 资源浪费且引入未评审功能 | 隔离并走变更流程，评估是否回退 |
范围检查不是找茬：把发现的问题按「是否符合基准」而非「谁的失误」来定性，团队才会主动暴露缺口。
范围控制流于形式的典型信号是检查通过但验收时交付物不齐：说明验收记录只补文档未做验证。