整体变更控制是什么
实施整体变更控制（PMBOK 第 6 版 4.6）为项目建立唯一的变更入口：所有变更请求都必须被记录、评估、审批、跟踪，批准后还要更新计划与基准并通知相关方。它属于监控过程组，价值在于让范围、进度、成本、质量与风险的影响被一起评估，而不是各条线分别拍板。
基本信息
| 所属过程组 | 监控（4.6 实施整体变更控制） |
|---|---|
| 覆盖对象 | 所有变更请求，含纠正措施、预防措施、缺陷补救与更新 |
| 决策主体 | 项目经理、发起人或变更控制委员会，按影响面与金额分级 |
| 主要输出 | 批准的变更请求、更新后的项目管理计划与基准、变更日志 |
典型使用场景
- 客户提出新增功能：先做多维影响评估，再交 CCB 决策
- 执行中发现的缺陷补救：走加急通道但仍需留痕归档
- 基准调整：范围、进度或成本基准的任何改动都必须经批准并记录版本
- 紧急抢修：先处置再补录，事后必须补齐影响评估与审批凭证
- 合同变更：涉及外部供应商时同步启动合同变更与采购管理流程
变更处置四种结果
| 结果 | 含义 | 后续动作 |
|---|---|---|
| 批准 | 按提交内容执行 | 更新计划与基准，通知全部相关方 |
| 有条件批准 | 满足前提才能执行 | 记录前置条件并逐项验证 |
| 拒绝 | 不执行 | 记录理由并回复提出人 |
| 推迟 | 暂缓决策 | 明确补件要求与决策截止时间 |
| 升级 | 超出项目经理权限 | 按治理路径提交上级决策并登记 |
变更评估检查表
变更评估检查表
1) 变更内容与理由（业务必要性） # 先问为什么，再看怎么做
2) 对范围/进度/成本/质量/风险/资源的影响 # 六个维度都要给结论
3) 备选方案与不做的影响 # 不加变更会损失什么
4) 受影响的交付物、接口与合同条款 # 避免遗漏外部连带责任
5) 审批层级（按金额或影响面确定） # 事先约定，临时找领导最慢
6) 批准后的执行跟踪与验证方式 # 谁验证、何时验证、留什么证据变更日志字段
变更日志字段
变更编号 | 提出人 | 提出日期 | 变更描述
影响评估结论 | 审批人 | 审批日期 | 批准结论
基准版本变化 | 通知记录 | 执行状态 | 验证结果
# 变更日志是审计与索赔时的第一手证据，缺字段等于没有记录先执行后补审批，等于让变更控制形同虚设：事后追认时，成本已发生、进度已消耗，审批只是走过场。
只评估单一维度（例如只看工期）就放行，是偏差累积的主要来源。多维度评估未必让决策更慢，但能让代价显性化。
变更被拒绝同样要留记录。没有拒绝记录，同一诉求会在几周后以另一个名目重新提出，团队反复返工做同样的分析。
评审颗粒度应与变更规模匹配：小变更用清单快速评估，涉及基准或合同条款的变更走完整评审。所有变更都进重流程会把评审会变成瓶颈，最终逼出绕过流程的做法。