项目基线更新要把变更从口头讨论变成可追溯的受控动作：先确认动的是范围、进度还是成本基线，再提交变更申请，评估对工期、成本和关联交付物的连带影响，由有权限的角色批准或驳回，批准后更新基线版本并通知相关方，最后归档记录。本文面向项目经理和PMO，覆盖单项目约束调整的完整流程；需求对象本身的修改属于需求变更与版本管理，不在本文展开。ONES在变更申请流转、基线设置与版本对比上可以承载部分管理动作，具体配置需结合团队实际环境确认。
要点总览（TL;DR）
- 先判定本次变更触碰的是范围、进度还是成本基线；同时影响多条时按范围、进度、成本的因果顺序处理。
- 流程分六步：提交变更申请、影响评估、审批、基线重定版、发布通知、归档复盘，影响评估必须在审批之前完成。
- 影响评估覆盖工期、成本、资源和关联交付物四个维度，给出量化口径、估算依据和不确定性区间。
- 发起人、评估人、审批人、基线管理员、受影响方各留交付物；影响较大的变更建议评估人与审批人分离。
- 闭环以版本可对比、受影响方确认知悉、未批准变更已反馈为判断标准。
基线更新前先分清：改的是哪条基线
基线是经过批准、作为后续执行和考核参照的那一版计划。基线更新意味着这条参照线本身要移动，因此第一步是判断本次变更触碰的是哪条基线。判断错了，后续的评估口径、审批层级和通知对象都会跟着错。
三类基线各有明确的定义和典型触发场景：
| 基线类型 | 定义 | 典型触发情形 | 是否属于本文范围 |
|---|---|---|---|
| 范围基线 | 经批准的工作范围与交付物清单，是判断“做没做完”的依据 | 客户新增或删减交付物、验收标准调整、合同工作说明书修订 | 属于，处理的是项目约束层面的范围调整 |
| 进度基线 | 经批准的项目计划与里程碑时间点，是判断“是否按期”的依据 | 外部依赖延迟、关键资源到位推迟、里程碑节点重新排定 | 属于 |
| 成本基线 | 经批准的分阶段预算，是判断“是否超支”的依据 | 范围或进度变化带来的预算追加、人力投入结构调整 | 属于 |
| 需求对象修改 | 需求条目本身的内容、属性或版本变化 | 需求描述细化、优先级调整、需求版本迭代 | 不属于，走需求变更与版本管理 |
一次变更同时影响多条基线是常态。例如外部依赖延迟既推迟里程碑，又可能因工期拉长增加人力成本。处理顺序建议按因果链推进：先定范围，再定进度，最后定成本。范围变化会直接推导出工作量和时间的变化，进度变化又会推导出资源投入和费用的变化。反过来先调成本再倒推进度，容易出现预算与计划对不上的情况。
需求修改与基线更新的边界要提前说清。需求条目改了内容，先在需求变更流程里完成评审和版本升级；只有当这个需求变化导致已批准的范围、进度或成本约束需要重新确定时，才进入基线更新流程。两者可以前后衔接，但不能合并成一张单子，否则追溯时无法区分“需求为什么改”和“计划为什么动”。
核心操作步骤：从变更申请到基线重定版
基线更新按六个步骤推进，每一步都有明确的输入、动作、输出和完成标志。步骤顺序不宜颠倒，尤其是影响评估必须在审批之前完成，否则审批人拿到的只是结论而非依据。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 提交变更申请 | 变更动因、当前基线版本、初步影响判断 | 填写变更申请单，写明变更内容、动因、影响范围、期望生效时间 | 变更申请单 | 申请单字段完整，已指定发起人和拟评估人 |
| 2. 影响评估 | 变更申请单、当前计划与预算、关联交付物清单 | 分别估算工期、成本、资源和关联交付物的连带影响，注明估算依据 | 影响评估说明 | 四类影响均有量化结论或明确说明无法量化的原因 |
| 3. 审批 | 变更申请单、影响评估说明 | 按变更影响大小匹配审批层级，审批人给出批准、驳回或暂缓意见 | 审批结论与意见 | 审批记录留有结论、理由和审批人 |
| 4. 基线重定版 | 批准的变更申请、原基线版本 | 更新范围、进度或成本基线，生成新版本并标注版本号与生效时间 | 新基线版本 | 新版本可查，旧版本保留可对比 |
| 5. 发布通知 | 新基线版本、受影响方清单 | 向受影响团队、干系人通知变更内容、生效时间和执行要求 | 通知记录 | 受影响方确认知悉 |
| 6. 归档复盘 | 全流程记录 | 归档申请、评估、审批、新版本与通知记录，定期复盘变更频次与原因 | 变更档案 | 档案可按项目或时间检索 |
变更申请单要写清什么
申请单是整条流程的起点，字段缺失会直接拖慢评估和审批。必填内容包括：变更内容（具体动哪条基线、动多少）、变更动因（外部依赖、资源变化、范围调整等客观原因）、影响范围（涉及哪些交付物、团队和关联工作）、期望生效时间。动因部分建议写事实而非判断，例如“供应商接口交付由3月15日推迟至4月10日”，比“供应商配合不力”更便于评估和追溯。
影响评估怎么量化
影响评估要覆盖四个维度，每个维度给出量化口径和估算依据：
- 工期：受影响任务和里程碑的推迟天数，关键路径是否改变，后续节点是否连锁顺延。
- 成本：新增人力投入的人天与单价、外部采购或违约成本、因工期拉长产生的固定费用分摊。
- 资源：需要新增或释放的角色与人天，是否与其他项目争抢同一批人。
- 关联交付物：受影响的上下游交付物清单，以及需要同步调整的验收安排。
估算结果建议标注不确定性，例如“预计推迟10至15个工作日，取决于供应商第二批交付时间”。只给一个确定数字，会让审批人误以为风险已经锁定。
审批权限与路径怎么设
审批层级应与变更影响匹配，常见做法是按影响幅度分档：影响在预设阈值内、不改变关键里程碑的，由项目经理审批；影响关键里程碑或超出成本阈值的，上升到项目发起人或变更控制委员会。审批人与评估人分离是有效的控制手段，适用于影响较大或合规要求较高的项目；小规模低风险变更可以简化路径，但简化条件要写进流程文件，避免每次临时判断。
批准后的更新与通知
批准不等于基线已更新。基线管理员需要按批准内容修改基线，生成新版本，保留旧版本以便对比，然后向受影响方发布通知。通知内容至少包含变更事项、新版本生效时间、对各团队执行要求的变化。驳回或暂缓的变更同样要记录：写明驳回理由、是否需要补充材料、何时可以重新提交，并反馈给发起人，避免申请石沉大海。
在工具承载上，ONES瀑布项目管理方案支持设置项目计划和里程碑基线，实时对比计划与执行的偏差；版本细节对比可用于追溯变更内容。变更申请与审批流转的具体字段和路径需结合团队配置确定。
角色分工与各环节交付物
流程能否跑通，取决于每个环节是否有人负责、有产物留下。基线更新涉及五类角色，职责和交付物如下：
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 变更发起人 | 识别变更需求，提交申请，补充评估所需信息 | 变更申请单、动因说明 |
| 影响评估人 | 对工期、成本、资源和关联交付物做量化评估 | 影响评估说明 |
| 审批人 | 依据评估结论决定批准、驳回或暂缓 | 审批结论与意见 |
| 基线管理员 | 维护基线版本，执行重定版，发布通知 | 新基线版本、发布通知记录 |
| 受影响方 | 确认知悉变更，按新基线调整自身工作安排 | 知悉确认、调整后的团队计划 |
审批人与评估人分离的必要性在于控制利益冲突。发起人往往对变更获批有诉求，如果由其自行评估影响，容易低估工期和成本。让熟悉计划与资源的第三方（如PMO或计划经理）出具评估，审批人再基于评估做判断，结论更经得起复盘。团队规模较小时，评估人可以由项目经理以外的人兼任，但评估结论仍需独立成文。
基线管理员的角色常被忽略。基线版本由谁维护、旧版本由谁保管、通知由谁发出，如果没有明确到人，批准后的更新容易停留在会议纪要里。ONES ALM方案围绕需求、基线、版本和变更建立统一管理对象，可用于承载基线记录与变更追溯；具体角色权限配置需按团队实际情况设定。
示例：一次进度基线延期变更的完整走法
以下为演示情景，用于说明流程走法，数据不代表真实项目。
背景。某系统集成项目原定6月30日完成联调并进入验收，进度基线中联调里程碑为6月20日至6月30日。外部供应商的接口文档交付由5月10日推迟至6月5日，导致联调启动时间顺延，项目经理判断需要调整进度基线。
申请。发起人填写变更申请单：变更内容为联调里程碑由6月20日至6月30日调整为7月10日至7月20日，验收节点相应顺延；动因为供应商接口文档交付推迟26天；影响范围为联调阶段的两个开发小组、测试团队和验收安排；期望生效时间为审批通过后立即生效。
评估。评估人给出四组结论：工期方面，联调推迟约20个工作日，关键路径顺延，验收节点由7月初调整至7月下旬；成本方面，两个开发小组延长投入约20人天，按内部结算口径折算费用，另需评估验收延后是否触发合同中的节点条款；资源方面，测试团队原定7月初投入，需与另一项目协调排期；关联交付物方面，联调报告、验收材料和培训计划的时间安排需同步调整。评估说明中注明：若供应商第二批文档在6月5日前到位，顺延可压缩至15个工作日。
审批。该变更影响验收节点，超出项目经理审批阈值，提交项目发起人审批。发起人依据评估结论批准，并要求同步确认合同节点条款的处理方式。
更新与通知。基线管理员更新进度基线，生成新版本并标注生效日期，旧版本保留。随后向开发、测试、验收相关方发布通知，说明新里程碑时间和各团队的调整要求，受影响方逐一确认知悉。
归档。归档内容包括变更申请单、影响评估说明、审批意见、新旧基线版本、通知记录和知悉确认。复盘时可将本次变更与同类供应商依赖问题合并分析，作为后续项目排期的参考。
这个例子中，范围基线未变，成本影响作为进度变更的连带结果一并评估。如果评估发现验收范围也需要缩减，则应先走范围基线调整，再更新进度和成本，顺序不能颠倒。
完成检查：基线更新是否做到位
流程走完后，用下面这份清单逐项核对，确认本次基线更新形成闭环：
- 变更申请单字段完整，变更内容、动因、影响范围和期望生效时间均有明确记录。
- 影响评估覆盖工期、成本、资源和关联交付物，量化结论附有估算依据和不确定性说明。
- 审批记录包含结论、理由和审批人，审批层级与变更影响相匹配。
- 新基线版本已生成，版本号和生效时间清晰，旧版本保留且可与新版本对比差异。
- 受影响方已收到通知并确认知悉，各团队计划已按新基线调整。
- 变更前后的基线差异可以逐项对比，能够说明动了哪些节点、动了多少。
- 驳回或暂缓的变更已记录理由并反馈发起人，明确后续处理方式。
- 全部材料已归档，可按项目或时间检索，供后续复盘使用。
清单中任何一项缺失，都意味着这次更新还停留在“会上定了”的阶段。尤其是版本对比和通知确认两项，直接决定后续执行和审计时能否说清基线为什么变、变成了什么样。ONES的项目列表视图可用于查看项目状态、资源投入和当前进展，版本对比能力可辅助追溯变更细节；具体使用方式以团队实际配置为准。
常见问题
变更影响很小，还需要走完整的六步流程吗？
可以简化，但简化条件要事先写进流程文件，而不是每次临时判断。常见做法是按影响幅度分档：不改变关键里程碑、成本影响在预设阈值内的变更，可由项目经理一人完成评估与审批，跳过独立评估环节；基线重定版、通知和归档三步仍应保留，否则后续无法说清基线为什么变。影响关键里程碑或超出成本阈值的变更，按完整流程执行。
变更申请被驳回后，发起人下一步该做什么？
驳回结论要连同理由一起反馈给发起人，并说明是否需要补充材料、何时可以重新提交。发起人根据反馈补齐影响评估或调整变更方案后重新提交，形成新的申请记录，原申请保留在档案中。暂缓与驳回的处理类似，区别在于暂缓需要写明恢复审议的条件或时间点，避免变更长期悬置。
范围、进度、成本三条基线同时要动，能不能合并成一张变更申请单？
可以合并申请，但评估和审批要按因果顺序展开：先确认范围调整，再据此推导进度变化，最后由进度和范围变化推导成本影响。合并成一张单子便于审批人看到全貌，但单子内部应分条列出三类基线各自的变化量和依据。如果范围调整本身尚未获批，进度和成本的调整就缺少前提，此时宜先完成范围变更的审批，再推进后续基线更新。
需求条目修改后，什么情况下才需要触发基线更新？
需求条目内容、属性或版本的变化，先在需求变更流程中完成评审和版本升级。只有当这个需求变化导致已批准的范围、进度或成本约束需要重新确定时，才进入基线更新流程。两者前后衔接但分开记录，追溯时才能区分需求为什么改、计划为什么动。需求对象本身的修改与版本管理不在本文范围。
基线更新完成后，怎么向审计或复盘说明变更的合理性？
依靠完整的过程记录：变更申请单写明动因和影响范围，影响评估说明给出量化结论与估算依据，审批记录留有结论、理由和审批人，新旧基线版本可逐项对比，通知记录和知悉确认证明相关方已同步。复盘时可把同类原因的变更合并分析，例如反复出现的供应商依赖问题，作为后续排期和风险预案的输入。
