项目变更审批要解决的是“变更该不该做、由谁定、做完怎么落到基线”这三个问题。本文围绕单项目的范围、计划、预算三类变更，给出从分级授权、提交申请、影响评估、审批决策到基线更新与关闭的完整操作步骤，并附角色分工、填写示例和完成检查清单，帮助项目经理或PMO把审批从签字环节变成有依据的决策过程。
要点总览（TL;DR）
- 先按对基线的影响幅度把变更分为轻微、一般、重大三级，并为每级配好审批人、会签角色、决策时限和升级条件，审批才有可执行的路径。
- 变更单要写清变更对象、触发源、不变更的后果、期望生效时间和涉及工作项，并附支撑材料，让审批人仅凭单据就能判断是否进入评估。
- 影响评估由项目经理组织，覆盖范围、进度、成本、资源、质量五个维度，结论用变更前后差值和前提假设表达，评估不充分时标注缺失信息或按最不利假设给出区间。
- 审批结论分为批准、驳回、暂缓三种，都要写明理由或生效条件；超出授权范围的变更按分级表升级，原审批意见保留在记录中。
- 批准后按变更对象分派责任人更新范围、计划、预算基线，同步受影响工作项与相关方，四项关闭条件同时满足后才归档。
先定变更分级与审批授权表
审批流于签字，通常源于两个前置设计缺失：所有变更走同一条审批路径，以及审批人不知道自己能定多大的事。在受理第一张变更单之前，先把变更按影响程度分级，并为每一级配好审批人、会签角色和决策时限，后续每张单子才能快速找到该走的路径。
分级依据建议取“对基线的影响幅度”，而不是变更单的金额或字数。轻微变更指不影响里程碑和总预算、只在单个工作包内调整；一般变更指影响一个阶段计划或单项预算科目，但不改变项目总目标；重大变更指影响里程碑节点、项目总预算或交付范围边界。三级之外可再设“紧急变更”通道，用于必须立即处置的情况，但仍需在事后补全评估与记录。
授权额度要与分级对应。例如一般变更由项目经理审批、职能经理会签；重大变更由项目发起人或变更控制委员会决策。额度写具体数字或比例，并注明“超出本级额度自动升级至上一级”，避免审批人在边界上自行解释。
| 变更等级 | 典型情形 | 审批人 | 会签角色 | 决策时限 | 升级条件 |
|---|---|---|---|---|---|
| 轻微 | 单个工作包内调整，不影响里程碑与总预算 | 项目经理 | 无需会签 | 2个工作日 | 评估后发现影响外溢至阶段计划 |
| 一般 | 影响一个阶段计划或单项预算科目 | 项目经理 + 职能经理 | 财务或资源负责人 | 3个工作日 | 影响项目总预算或关键路径 |
| 重大 | 影响里程碑、总预算或交付范围边界 | 项目发起人 / 变更控制委员会 | 项目经理、财务、客户代表（如适用） | 5个工作日 | 超出项目发起人授权，提交上级治理机构 |
变更单的必填字段也应在此时定下来，作为后续所有申请的统一格式：变更编号、申请人、申请日期、变更对象（范围/计划/预算）、变更内容、变更原因、不变更的后果、期望生效时间、涉及工作项、影响评估结论、审批结论、基线更新记录。字段一旦确定，表单就不再因人而异。
变更申请：变更单要写清哪些内容
申请环节的目标是让审批人仅凭变更单就能判断“要不要进入评估”。申请人需要完成三件事：说清改什么、说清为什么改、说清不改会怎样。缺少任何一项，审批人都无法做出有依据的决策，只能退回补充。
变更对象要明确到具体条目。范围变更写明增加或删减的交付物及其验收标准；计划变更写明受影响的阶段、里程碑和工作项编号；预算变更写明科目、原额度与申请额度。只写“调整项目计划”无法支撑评估。
变更原因要区分触发源：客户要求、法规或标准变化、上游交付延迟、技术方案调整、估算偏差。不变更的后果同样要写，例如“若不调整测试阶段排期，上线日期将推迟两周”或“若不追加预算，第三方接口联调无法在合同期内完成”。这一栏是审批人判断紧迫性的主要依据。
期望生效时间与涉及工作项要具体。生效时间影响排期冲突判断，涉及工作项决定影响评估的范围。附件用于承载支撑材料：客户邮件、需求文档修订页、供应商报价、技术评估结论。没有附件的变更单，评估人只能凭口头信息推断。
提交前建议按以下清单自检：
- 变更对象是否指向具体交付物、里程碑或预算科目；
- 变更原因是否写明触发源，不变更的后果是否可判断；
- 期望生效时间是否与现有排期对照过；
- 涉及工作项是否已列出编号或名称；
- 支撑材料是否齐全，关键结论是否能在附件中找到出处；
- 是否已按分级表初判变更等级，并确认审批人正确。
影响评估：把范围、进度、成本算清楚
影响评估由项目经理组织，是审批决策的事实基础。评估要回答一个问题：如果批准这项变更，项目的范围、进度、成本、资源和质量分别会发生什么变化。评估结论应尽量量化，并写明前提假设，让审批人看到数字背后的条件。
五个维度各有对应的评估角色和产出：
| 评估维度 | 评估内容 | 主要参与角色 | 量化表达示例 |
|---|---|---|---|
| 范围 | 交付物增减、验收标准变化、关联工作项 | 项目经理、业务分析 | 新增2个接口交付物，影响5个工作项 |
| 进度 | 关键路径变化、里程碑偏移、依赖调整 | 项目经理、技术负责人 | 测试阶段延后8个工作日，上线里程碑偏移 |
| 成本 | 人力投入、采购支出、返工成本 | 财务、项目经理 | 增加人力投入约15人天，追加采购预算若干 |
| 资源 | 人员占用、技能缺口、外部依赖 | 职能经理、资源负责人 | 需临时投入1名后端工程师，持续3周 |
| 质量 | 测试覆盖、缺陷风险、验收风险 | 测试负责人、质量角色 | 回归测试范围扩大，需补充用例约20条 |
评估结论建议采用固定结构：变更前基线值、变更后预计值、差值、评估前提、剩余风险。例如“进度：当前测试阶段计划10个工作日，变更后需18个工作日，差值8个工作日；前提是测试环境按期就绪；剩余风险为环境延迟将同步推迟上线”。这种写法让审批人可以直接比较代价与收益。
评估时限应与分级挂钩：轻微变更1个工作日内完成，一般变更2至3个工作日，重大变更可延长至5个工作日。若在时限内无法完成充分评估，处理方式有两种：一是标注“评估不充分”并列出缺失信息，由审批人决定是否暂缓；二是按最不利假设给出区间结论，供审批人判断风险承受度。两种方式都要在变更单上留痕，不能以“评估中”长期挂起。
审批决策：批准、驳回与暂缓怎么处理
审批人依据影响评估做决策，而不是依据申请人的职位或变更的紧急程度。决策前应确认三件事：评估是否覆盖五个维度、结论是否有量化依据、变更等级与审批权限是否匹配。三项确认后，给出三种结论之一。
批准适用于变更收益明确、影响在可接受范围内、资源可以落实的情形。批准意见要写明生效条件，例如“批准，自下个迭代起生效，预算追加需在财务系统中同步立项”。驳回适用于变更理由不成立、影响超出项目承受能力、或存在更优替代方案的情形，驳回必须写明理由，便于申请人调整后重新提交。暂缓适用于信息不足、时机不成熟或需等待外部决策的情形，暂缓要设定复核时间点和补充材料要求，避免无限期搁置。
超出审批人授权范围的变更，按分级表升级：由审批人在变更单上签署“建议批准/建议驳回”的意见，连同影响评估一并提交上一级审批人。升级不改变评估结论，只改变决策层级，原审批人的意见应保留在记录中。
决策记录至少包含：变更编号、审批人、决策结论、决策时间、决策依据（引用评估结论）、生效条件或补充要求。决策完成后，由项目经理在1个工作日内通知申请人和受影响的相关方，通知内容与决策记录保持一致。
基线更新与变更关闭
批准不等于落地。基线更新是把审批结论转化为项目新基准的动作，缺少这一步，变更会在执行中失真，后续偏差分析也失去参照。
基线更新按变更对象分派责任人：范围基线由项目经理更新交付物清单和验收标准；计划基线由项目经理调整工作项、依赖关系和里程碑，并记录调整前后的版本；预算基线由财务或预算负责人更新科目额度。每项更新都要留下记录：更新人、更新时间、更新前后对照。若组织使用项目管理工具承载计划与里程碑基线，可在工具中完成版本对比，使变更前后的差异可追溯。
同步动作包括：更新受影响的工作项状态与负责人；修订相关文档并标注版本；通知受影响的团队、客户代表和职能经理；在项目例会上通报变更内容与生效时间。同步完成的标志是所有受影响工作项的负责人确认知悉，且文档版本与基线一致。
变更关闭的完成标志建议设为四项同时满足：基线已更新并有记录、相关方已确认知悉、变更单状态标记为关闭、归档材料齐全。归档内容包括变更单、影响评估、审批记录、基线更新记录和通知记录，按变更编号存放，供后续复盘和审计追溯。
在ONES中，变更单可以作为工作项按状态流转，从提交、评估、审批到关闭形成完整记录；项目计划与里程碑基线支持计划与执行的偏差对比和版本细节追溯，变更相关文档与工作项关联后，影响范围和后续更新可以在同一处查看。具体表单字段与审批节点配置需按团队实际流程设置。
角色分工与交付物清单
把前面各步骤的职责按角色横向汇总，可以看清每个角色在什么节点交付什么，交接时依据什么确认。
| 角色 | 主要职责 | 输入 | 输出 | 交接节点 |
|---|---|---|---|---|
| 变更申请人 | 提出变更、填写变更单、提供支撑材料 | 变更需求、客户或上游信息 | 完整变更单及附件 | 提交给项目经理受理 |
| 项目经理 | 受理变更、组织影响评估、执行基线更新、通知相关方 | 变更单、项目基线数据 | 影响评估结论、基线更新记录、通知记录 | 评估结论交审批人；批准后组织更新 |
| 评估参与角色（技术、测试、财务、职能经理） | 按维度提供评估意见 | 变更内容、涉及工作项 | 各维度量化评估意见 | 汇总至项目经理形成评估结论 |
| 审批人 / 变更控制委员会 | 依据评估做批准、驳回或暂缓决策 | 变更单、影响评估 | 审批决策记录 | 决策结果交项目经理执行 |
| 配置管理员 | 维护基线版本、归档变更记录 | 审批记录、基线更新内容 | 基线版本记录、归档清单 | 关闭前核对归档完整性 |
交接的关键在于“带材料交接”：申请人交单时附支撑材料，项目经理交评估时附量化结论，审批人交决策时附理由，配置管理员关闭前核对归档。每个交接点都有可核对的产物，责任就不会在角色之间悬空。
一个变更审批的完整示例
以下为演示情景，用于说明各环节的记录写法，不代表真实项目数据。
背景：某系统建设项目处于测试阶段，客户要求新增一项数据导出功能，涉及范围与进度变化。
变更单填写示例：变更编号CR-021；申请人：业务分析；变更对象：范围与计划；变更内容：新增数据导出功能，包含2个导出模板和权限控制；变更原因：客户合同补充条款要求；不变更的后果：验收无法通过，尾款支付延后；期望生效时间：下个迭代开始；涉及工作项：导出模块开发、权限配置、回归测试；附件：客户补充条款、技术方案说明。
影响评估结论示例：范围：新增2个交付物，影响5个工作项；进度：开发增加6个工作日，测试增加2个工作日，上线里程碑偏移8个工作日；成本：增加人力投入约12人天；资源：需临时投入1名后端工程师，持续2周；质量：回归测试范围扩大，需补充用例15条。前提：客户在3个工作日内确认导出字段清单。剩余风险：字段确认延迟将同步推迟开发启动。
审批与基线更新记录示例：审批人：项目发起人；结论：批准；依据：影响评估覆盖五个维度，进度偏移在合同允许的缓冲期内；生效条件：客户确认字段清单后启动开发。基线更新：项目经理更新范围清单与测试阶段计划，配置管理员记录基线版本变更，财务同步追加人力预算，项目经理向客户与测试团队发出变更通知，变更单状态关闭并归档。
完成检查：变更审批是否做到位
每次变更关闭前，按以下清单逐项核对，任何一项不满足都应补齐后再关闭。
- 变更单字段完整：变更对象、原因、不变更后果、期望生效时间、涉及工作项、附件均已填写；
- 影响评估覆盖范围、进度、成本、资源、质量五个维度，结论有量化数值和前提假设；
- 变更等级判定与审批授权表一致，审批人权限覆盖本次变更影响幅度，超权变更已按升级路径处理；
- 审批结论为批准、驳回或暂缓之一，并写明理由或生效条件；
- 批准后的基线已更新，范围、计划、预算的更新均有责任人和更新前后记录；
- 受影响工作项、文档和相关方已同步，负责人确认知悉；
- 变更单、评估、审批、基线更新和通知记录已按编号归档，可追溯至具体版本。
这套检查清单也可以反过来用于流程体检：抽取若干已关闭的变更单，逐项核对，缺失集中的环节就是下一轮流程改进的重点。
常见问题
变更单提交后，审批人迟迟不决策怎么办？
先看分级表里是否为该等级设了决策时限，以及变更单是否已附完整的影响评估。审批人无法决策，常见原因是评估结论缺少量化依据或前提假设，此时应由项目经理补充后再提交，而不是反复催办。
若评估齐全仍超时，可按分级表约定的升级条件处理：由项目经理将变更单连同评估结论提交上一级审批人，并在记录中注明原审批人未在时限内决策。时限和升级规则在流程设计阶段就写进授权表，执行时才有依据。
紧急变更来不及走完整评估，怎么处理才不留隐患？
可以设紧急通道，但紧急只改变顺序，不取消记录。做法是先由有权审批人做临时处置决定，在变更单上注明“紧急处置”及理由，同时明确补全评估的截止时间。
事后补全的内容包括影响评估的五个维度、正式审批结论和基线更新记录。若补评估发现影响超出原授权，按升级路径重新决策。紧急变更单同样要归档，否则复盘时无法解释基线为何变化。
变更被驳回后，申请人还能重新提交吗？
可以。驳回意见应写明理由，例如变更理由不成立、影响超出项目承受能力或存在更优替代方案。申请人根据驳回理由调整变更内容、补充支撑材料或缩小变更范围后，可作为新变更单重新提交，并关联原变更编号便于追溯。
重新提交的单据仍需走完整的申请与评估流程，不能因为“之前审过”而跳过影响评估。若驳回原因是信息不足，也可先按暂缓处理，待材料补齐后再决策。
变更批准了，但基线没有同步更新，会带来什么问题？
基线不更新，后续的进度偏差、成本偏差就失去参照，团队会按旧基准判断自己是否延期，偏差分析结果失真。同时，未更新的文档和工作项会让新加入的成员按旧版本执行。
处理办法是把基线更新设为变更关闭的必要条件：范围、计划、预算的更新都要有责任人和更新前后对照记录，受影响工作项负责人确认知悉后才允许关闭变更单。检查时抽取已关闭变更单，核对基线版本与审批结论是否一致。
小团队项目少，也需要建变更控制委员会吗？
不一定。变更控制委员会适用于重大变更较多、涉及多职能决策的项目。小团队可以把重大变更的决策权交给项目发起人，一般变更由项目经理审批、相关职能负责人会签，轻微变更由项目经理直接决定。
关键是授权边界写清楚，并保留升级条件：一旦评估发现影响超出本级额度，就提交上一级决策。组织方式可以简化，变更单、影响评估和基线更新记录这三样不能省。
