项目变更审批最容易出问题的地方，是申请、评估、批准、更新基线几个动作落在谁身上说不清楚。本文用一个演示情景——客户要求把交付日期提前两周——给出一份填好的责任分工表，覆盖谁提出、谁评估、谁批准、谁更新基线、谁通知五个动作，并逐项解释每个责任格的填写依据，便于迁移到预算调整、范围缩减等场景。
要点总览（TL;DR）
- 责任分工表按“提出、评估、批准、更新基线、通知”五个动作组织，每个动作只设一个责任人，并配套交付物与完成标准。
- 申请人与评估人分离：项目经理写清想要什么，技术负责人独立测算要付什么代价，批准人才能看到完整信息。
- 批准层级随影响程度上升：只动内部排期的微调可由项目经理批准，涉及交付承诺、预算增加或关键里程碑移动的上升到项目发起人。
- 基线更新由PMO核对审批结论与评估数据一致后执行，并保留旧版本；通知与基线更新成对出现，对外口径以更新后的基线为准。
- 示例仅适用于单项目范围、计划、预算调整；需求对象修改、跨研发资产变更治理与多项目组合排序需换用对应流程。
示例要回答的问题：一次变更里谁对什么负责
这个示例演示的是单项目层面的计划变更：交付日期调整，同时牵动部分工作量和资源安排。它不涉及需求对象的版本修改，也不涉及跨项目组合的优先级重排。之所以用责任分工表来呈现审批责任，是因为变更审批的争议往往不在“要不要批”，而在“谁该在什么时候交出什么”。把动作、责任人、交付物和完成标准放进同一张表，审批过程就有了可核对的依据。
示例覆盖五个动作，每个动作只设一个责任人：
- 提出：说明变更内容、原因和期望结果，形成变更申请。
- 评估：分析变更对工期、工作量、成本和相关交付物的影响，给出评估结论。
- 批准：依据影响程度和授权范围作出批准、驳回或退回补充的决定。
- 更新基线：核对批准结论与评估数据一致后，修改计划基线并留存版本记录。
- 通知：把变更后的口径同步给受影响的相关方，确认对方已知悉。
以下角色、日期、金额和审批结论均为演示情景设定，用于说明填写方法，不对应任何真实客户或真实项目。
完整示例：交付日期提前两周的变更审批
变更背景与申请内容
演示项目原计划在6月30日完成交付，客户因自身业务安排要求提前至6月16日。项目经理判断该调整会影响开发排期、测试窗口和部分外部采购到货时间，于是发起变更申请。申请中写明：变更类型为计划变更，涉及交付日期提前14天，初步判断需要增加并行开发资源，测试周期可能压缩。申请提交后进入评估环节。
责任分工表（已填写）
| 动作 | 责任人 | 具体职责 | 交付物 | 完成标准 |
|---|---|---|---|---|
| 提出 | 项目经理 | 填写变更申请，说明变更内容、原因、期望交付日期和初步影响判断 | 变更申请单 | 申请单包含变更前后日期对比、变更理由、受影响范围初判，并已提交至评估人 |
| 评估 | 技术负责人 | 分析工作量变化、测试窗口压缩风险、资源缺口，给出可行性与代价结论 | 影响评估说明 | 列出受影响的工作包、所需增加的人力或并行安排、无法压缩的环节及原因 |
| 批准 | 项目发起人 | 依据评估结论和授权范围，决定批准、驳回或退回补充评估 | 审批意见 | 审批意见写明结论、附加条件（如增加资源上限）和生效日期 |
| 更新基线 | PMO | 核对审批意见与评估数据一致，修改计划基线并保留变更前后版本 | 更新后的计划基线及版本记录 | 基线中的里程碑日期与审批结论一致，旧版本可追溯，变更记录关联申请单编号 |
| 通知 | 项目经理 | 向客户对接人、测试负责人、采购对接人同步新日期和各自需调整的事项 | 通知记录 | 受影响相关方逐一确认知悉，通知内容引用审批结论而非评估阶段的初步判断 |
审批结论与基线更新结果
演示情景中，项目发起人批准了变更，附加条件是并行开发增加的人力不超过两人，且测试窗口不得少于十个工作日。PMO据此核对评估说明中的资源测算，确认与审批条件一致后，将里程碑日期从6月30日调整为6月16日，测试阶段起止日期同步前移，并在版本记录中注明变更依据为本次申请单。基线更新完成后，旧版本保留可查，便于后续回溯偏差来源。
相关方通知记录
项目经理在基线更新当日发出通知，内容包含新交付日期、测试窗口安排、采购到货时间要求和审批附加条件。客户对接人、测试负责人、采购对接人分别确认。通知中引用的是审批结论，评估阶段“可能压缩测试周期”的初步判断不再作为对外口径，避免相关方按未定稿的信息安排工作。
逐项解释：每个责任格为什么这样填
申请人与评估人分离
项目经理最了解变更的来龙去脉，适合提出申请；但他同时承担交付压力，如果由他评估工作量影响，容易低估代价或高估团队承受能力。把评估交给技术负责人，是因为工作量、技术可行性和测试窗口的判断需要技术视角的独立测算。分离的价值在于：申请书写的是“想要什么”，评估说明写的是“要付什么代价”，两者分开，批准人才能看到完整信息。
批准权限与影响程度挂钩
示例中由项目发起人批准，是因为交付日期提前两周牵动资源投入和对外承诺，超出项目经理的授权范围。一般规律是：只影响本项目内部排期、不增加成本的微调，可由项目经理批准；涉及交付承诺、预算增加或关键里程碑移动的，上升到项目发起人或更高层级。审批层级写在责任表里，批准人就不必每次临时判断自己该不该签字。
基线更新由PMO核对而非申请人自行修改
基线是后续判断进度偏差的参照物，如果由提出变更的人自行修改，等于让被考核方调整考核基准。PMO的角色是核对：审批结论是否明确、评估数据是否支撑新日期、附加条件是否已写入计划。核对通过后再更新，并保留旧版本。这样做的结果是，任何人回看基线变化时，都能找到对应的申请单和审批意见，而不是只看到日期被改过。
通知动作归项目经理
通知的难点不在发出消息，而在确认每个相关方知道自己要调整什么。项目经理掌握变更全貌和各方接口关系，适合承担这个动作；PMO负责基线准确性，不必重复对外沟通。把通知与基线更新排成先后两步，是为了保证对外发布的口径来自已更新的基线，而非评估阶段的草稿。
当这类变更在项目管理工具中流转时，申请单、评估说明、审批意见和基线版本可以作为同一条工作项记录留存。ONES 瀑布项目管理方案支持设置项目计划和里程碑基线，并通过对比版本细节追溯变更细节，适合把上述责任动作的交付物挂在同一处，减少审批结论与计划版本对不上的情况；具体功能可用性以实际产品版本与套餐为准。
可迁移规律：换成别的变更怎么套用
这份示例的价值在于结构，而非具体角色名称。换一种变更类型时，调整的是审批层级和评估内容，五个动作的框架保持不变。
| 变更类型 | 评估重点 | 审批层级调整 | 需同步调整的责任格 |
|---|---|---|---|
| 预算追加 | 追加金额、资金来源、对后续阶段预算的挤占 | 按金额阈值上升至有预算审批权的角色 | 评估人可改为财务对接人牵头，技术负责人提供工作量依据 |
| 范围缩减 | 被移除交付物的依赖关系、验收标准变化、合同义务 | 涉及对外承诺时上升至项目发起人 | 通知对象增加客户对接人与验收负责人 |
| 关键里程碑移动 | 前后置任务连锁影响、资源冲突 | 按影响的项目数量确定层级 | 基线更新需同时核对关联计划的依赖日期 |
套用时把握四条规律：
- 按影响类型确定审批层级：先判断变更动的是工期、成本还是交付范围，再对照授权表找批准人，避免所有变更都找同一个人签字。
- 评估人与批准人职责分离：评估人给代价，批准人做取舍，同一人兼任时要在记录中说明，便于事后复盘。
- 基线更新与通知成对出现：更新后立即通知，通知内容以更新后的基线为准；只更新不通知，相关方仍按旧日期工作。
- 责任格只写一个责任人：需要多人参与时，写清主责人和协助人，完成标准挂在主责人身上，避免“共同负责”变成无人负责。
适用边界：哪些情况不套用这份示例
这份示例针对单项目内的范围、计划或预算调整，以下情形需要换用其他管理口径：
- 需求对象本身的修改：需求内容、验收标准的变更涉及版本管理和需求基线，应按需求变更与版本管理的流程处理，本文的责任表只覆盖项目约束调整。
- 跨研发资产的变更治理：当变更同时影响需求、设计、代码、测试用例等多个研发资产时，需要沿关联关系分析受影响对象，属于研发变更控制范畴。ONES ALM 方案围绕需求、基线、版本和变更建立统一管理对象，可支撑这类影响分析与过程追踪，与单项目审批责任划分不是同一层问题。
- 多项目组合层面的变更排序：多个项目争夺同一资源时的优先级调整，涉及组合决策，超出单项目审批表的范围。
- 紧急变更：生产故障等情形允许先处理后补记录，但补记录时仍要补齐提出、评估、批准、基线更新和通知五个动作的痕迹，不能因为紧急而省略责任归属。
判断是否套用这份示例，可以问三个问题：变更是否发生在单个项目内？影响的是工期、成本或交付范围而非需求内容？批准人是否在项目治理链条内？三个问题都是肯定回答时，直接按表填写；任一为否，先确认对应的管理流程再动手。
常见问题
变更申请被批准后，评估阶段的初步判断还能对外使用吗？
不建议继续使用。评估说明中的判断是决策依据，审批意见才是生效口径。示例中项目经理发出通知时引用的是审批结论和附加条件，评估阶段“可能压缩测试周期”的表述不再对外，避免相关方按未定稿信息安排工作。如果审批时修改了评估建议，通知内容以审批意见为准，评估说明作为附件留存备查。
项目经理可以同时担任申请人和批准人吗？
在授权范围内可以，但要留下说明。只影响本项目内部排期、不增加成本、不改变对外承诺的微调，通常由项目经理批准；此时申请与批准为同一人，应在变更记录中注明授权依据，便于事后复盘。涉及交付日期、预算或关键里程碑的变更，批准权应上移到项目发起人或更高层级，避免申请人自行拍板。
紧急变更来不及走完整流程，责任怎么记？
紧急情形允许先处理后补记录，补记录时仍要补齐五个动作的痕迹：谁提出、谁做的快速评估、谁口头或书面批准、基线何时更新、相关方何时被告知。补记录的价值在于事后能还原决策链，而不是补一份形式文件。若紧急变更频繁出现，应回头检查常规审批是否层级过多或响应过慢。
基线更新后，旧版本还需要保留吗？
需要。旧版本是判断后续进度偏差的参照物，也是回溯变更来源的依据。示例中PMO更新基线时保留变更前后两个版本，并在记录中关联申请单编号，任何人回看日期变化都能找到对应的审批意见。若旧版本被覆盖，后续出现延期时就难以区分是原计划不合理还是执行偏差。
多个相关方对变更通知内容有异议时怎么处理？
先回到审批意见核对。通知内容以已批准的结论为准，相关方的异议如果涉及日期、资源或验收标准本身，应作为新的变更申请重新评估，而不是在通知环节协商修改。若异议只涉及各自内部的衔接安排，由项目经理在通知记录中注明各方调整事项即可。这样处理可以避免已批准的基线被口头承诺悄悄改动。
