项目计划基线管理要解决的是“计划什么时候算定稿、定稿后怎么改、改完怎么证明还受控”。做法可以拆成三步：计划达到可执行程度时，冻结范围、里程碑、关键交付日期、资源承诺和验收口径，形成带版本号与审批记录的基线；此后每次调整都走变更申请、影响评估、审批、更新基线并通知相关角色的闭环；再用基线对比和里程碑核验判断计划是否仍受控。本文围绕建立、变更与核验展开，执行偏差的日常监控和具体任务排期不在讨论范围内。
要点总览（TL;DR）
- 基线是经评审批准、作为后续比较基准的那版计划；冻结范围、里程碑、关键交付日期、资源承诺和验收口径，日常任务排期与偏差分析不进入基线。
- 建立基线按计划评审、范围与日期确认、资源承诺确认、审批、打基线、发布通知六步走，每步都有负责人、输出和完成标志。
- 版本号采用“项目代号-基线类型-序号”结构，只增不改，历史版本保留可查；基线记录只保留一个权威存放位置。
- 影响里程碑、关键资源或验收口径的调整走变更单，经影响评估和分级审批后重基线；旧版本保留，变更单、审批意见与新版本互相关联。
- 用基线唯一性、可追溯性、变更走单率、差异可查、承诺一致性和通知到位六项清单核验，问题转化为整改动作并指定责任人。
基线管什么：先确定冻结对象与版本口径
基线是经过评审和批准、作为后续比较基准的那一版计划。普通计划版本可以随时保存，用于记录草稿和推演；基线一旦发布，就代表团队对范围、时间和资源的正式承诺，修改它需要走审批。把两者混在一起，会出现“计划天天在改，却说不清哪一版算数”的情况。
进入基线的对象应当是可承诺、可验收、可比较的内容。日常任务排期细节不必冻结，否则基线会变得过于沉重，任何一次任务挪动都要走变更。执行偏差的分析与纠偏属于进度管理的工作，基线只提供比较基准。
| 类别 | 对象 | 是否进入基线 | 说明 |
|---|---|---|---|
| 范围 | 交付物清单、WBS 顶层与关键工作包 | 进入 | 以可验收的交付物为粒度，不细化到个人每日任务 |
| 进度 | 里程碑、关键交付日期、阶段关口 | 进入 | 里程碑对应重要时间点、事件或决策点 |
| 资源 | 关键角色投入承诺、外部依赖交付时间 | 进入 | 只冻结已获得确认的承诺 |
| 质量 | 验收口径、评审节点 | 进入 | 与交付物一一对应 |
| 执行细节 | 日常任务排期、个人工作安排 | 不进入 | 在计划内正常调整，不触发变更 |
| 偏差分析 | 进度偏差原因、纠偏措施 | 不进入 | 属于进度管理范畴，基线只作为对比参照 |
版本命名建议采用“项目代号-基线类型-序号”的结构，例如 PRJ01-PB-01 表示项目 PRJ01 的计划基线第一版，重基线后依次为 PRJ01-PB-02。如果项目同时管理需求基线或产品基线，用类型段区分，避免不同对象的版本号互相混淆。每次发布基线时记录版本号、发布日期、审批人和生效范围，版本号只增不改，历史版本保留可查。
建立基线的操作步骤：从计划评审到发布
建立基线的输入前提有两个：计划已经细化到可以评审的程度，交付物、里程碑和关键工作包都有明确的责任人和时间；关键依赖已经识别，包括外部团队交付、采购到货和审批周期。前提不满足就发布基线，后面必然频繁返工。
| 步骤 | 输入 | 动作 | 负责人 | 输出 | 完成标志 |
|---|---|---|---|---|---|
| 1. 计划评审 | WBS、进度计划、依赖清单 | 组织评审会，检查交付物完整性、日期合理性和依赖闭环 | 项目经理 | 评审记录与问题清单 | 问题清单关闭或明确处理方案 |
| 2. 范围与日期确认 | 评审后的计划 | 与需求方确认交付物范围和验收口径，与各职能确认里程碑日期 | 项目经理、需求方 | 确认后的范围与里程碑清单 | 双方书面确认 |
| 3. 资源承诺确认 | 资源需求清单 | 逐项确认关键角色投入和外部依赖交付时间 | 职能负责人 | 资源承诺记录 | 每个关键角色有明确承诺人 |
| 4. 审批 | 范围、日期、资源确认结果 | 按权限提交审批，审批人核对承诺一致性 | 变更审批人 | 审批记录 | 审批通过并留痕 |
| 5. 打基线 | 审批通过的计划 | 在计划中设置基线，生成版本号 | 计划管理员 | 基线版本记录 | 基线可查询、可对比 |
| 6. 发布通知 | 基线版本记录 | 向相关角色发布基线说明，明确生效日期和变更入口 | 项目经理 | 发布通知与基线清单 | 相关角色确认知悉 |
发布时需要同步两类记录：一是基线清单，列明本次冻结的范围、里程碑、资源承诺和验收口径；二是系统内的版本记录，确保后续可以调出这一版计划做对比。两者内容一致，避免文档里的基线和系统里的基线对不上。
在工具层面，ONES 瀑布项目管理方案支持用「项目计划」创建工作分解结构、为任务设置前后置依赖并用里程碑标记重要时间点，也支持设置项目计划和里程碑基线、对比版本细节追溯变更。计划评审通过后，把确认的范围和日期固化为基线版本，后续调整就有了统一的比较对象。
角色与交付物分工：谁提、谁审、谁维护
基线管理常见的失效原因是职责悬空：有人改计划，没人管版本；有人提变更，没人做影响评估。把提出、审批、维护三类动作分到具体角色，并明确各自交付什么，机制才能运转。
| 角色 | 建立阶段职责 | 变更阶段职责 | 主要交付物 |
|---|---|---|---|
| 项目经理 | 组织评审、汇总范围与日期确认、发起审批 | 提出或接收变更申请，组织影响评估，执行发布通知 | 基线清单、变更单、发布通知 |
| 职能负责人 | 确认本职能资源投入和交付时间 | 评估变更对本职能资源和排期的影响 | 资源承诺记录、影响评估意见 |
| 变更审批人 | 审批首次基线 | 审批变更申请，决定通过或驳回 | 审批记录与审批意见 |
| 计划管理员 | 在系统中打基线、登记版本号 | 更新基线版本，保留旧版本 | 基线版本记录、版本对比说明 |
| 需求方或客户代表 | 确认交付范围与验收口径 | 确认范围类变更的业务影响 | 范围确认记录 |
审批权限建议按影响程度分级：只影响单个工作包内部排期、不改变里程碑和交付范围的调整，由项目经理审批后记录即可；影响里程碑日期、关键资源或验收口径的变更，由项目发起人或项目指导委员会审批；涉及合同交付承诺的变更，需要需求方或客户代表共同确认。分级规则在项目启动时写清楚，避免每次变更临时找人拍板。
基线记录应当只有一个权威存放位置，通常是与项目关联的计划系统和项目文档库，由计划管理员负责维护，项目经理对内容准确性负责。分散在个人表格和聊天记录里的版本不作为判断依据。
基线变更怎么走：申请、评估、审批与重基线
触发基线变更的典型情形包括：交付范围增加或删减、里程碑日期调整、关键资源撤出或替换、外部依赖交付时间变化、验收口径修改。日常任务挪动、人员内部调配不影响承诺的，在计划内调整即可，不必走变更单。
变更单需要填写以下字段，缺项会影响评估质量：
- 变更编号与关联基线版本号
- 变更内容：具体改什么，改前与改后对照
- 变更原因：业务需求变化、资源变化或风险应对
- 影响范围：涉及的交付物、工作包和下游依赖
- 对里程碑与关键日期的影响：是否导致里程碑移动，移动多少天
- 对资源的影响：需要增加、释放或替换哪些角色
- 对成本与验收的影响：如适用
- 申请人、评估人、审批人与日期
影响评估由项目经理组织，职能负责人评估资源可行性，技术负责人评估交付物连带影响。评估结论要给出可选方案，例如“接受延期两周”或“缩减次要交付物保住原日期”，供审批人决策。审批通过后，计划管理员更新计划并生成新的基线版本，旧版本保留；审批驳回则记录驳回理由，计划维持原基线，申请人可以补充信息后重新提交。
重基线时旧版本必须保留并可追溯，版本对比要能看出改了什么。ONES ALM 方案围绕需求、基线、版本和变更建立统一管理对象，支持变更影响分析和交付结果回溯；在计划基线场景中，这一思路同样适用于把变更单、审批记录和新版本关联起来，形成完整的变更链条。
示例：一个交付项目的基线建立与一次变更
以下为演示情景，用于说明填写方式，不对应真实项目。某系统交付项目计划在 6 个月内完成三个模块上线，团队 12 人，含一名外部集成商。
基线建立。项目经理组织评审，确认交付物为三个模块及配套文档，里程碑设为需求冻结、开发完成、集成测试完成、上线四个节点。职能负责人确认开发与测试人力投入，外部集成商书面确认接口联调时间。审批通过后，计划管理员发布 PRJ01-PB-01，基线清单列明四个里程碑日期、三个模块的验收口径和关键角色承诺，发布通知发至项目群。
变更申请。开发进行到第二个月，需求方提出在模块二增加一项报表导出功能。项目经理提交变更单 CR-007，关联基线 PRJ01-PB-01，变更内容写明新增功能及验收标准，原因标注为业务合规要求，影响范围包括模块二的设计、开发和测试工作包。
影响评估。技术负责人评估新增功能约需 8 人日，测试增加 3 人日；职能负责人确认现有资源无法吸收，集成测试里程碑需后移 5 个工作日；项目经理给出两个方案：接受里程碑后移，或把模块三的一项非关键功能延至二期以保住日期。
审批与重基线。审批人选择第二方案，批准缩减范围并保持里程碑不变。计划管理员更新计划，发布 PRJ01-PB-02，变更单、审批意见和新版本互相关联，PRJ01-PB-01 保留可查。发布通知说明范围调整内容和生效日期，需求方确认知悉。
完成检查：基线管理是否到位的核验项
判断基线管理是否真正运转，可以按以下清单逐项核对。建议在每个里程碑节点和项目收尾时各做一次。
| 核验项 | 通过标准 | 不通过时的整改动作 |
|---|---|---|
| 基线唯一性 | 当前生效基线只有一个版本号，团队认知一致 | 清理散落版本，明确权威存放位置并重新发布 |
| 可追溯性 | 每个基线版本有发布日期、审批人和变更来源 | 补齐版本记录，缺失审批的补走确认流程 |
| 变更走单率 | 影响范围、里程碑或资源的调整均有变更单 | 对已发生的口头变更补单，并在例会上重申规则 |
| 差异可查 | 当前计划与基线可做版本对比，差异项有对应变更单 | 建立对比机制，逐项核对差异来源 |
| 承诺一致性 | 基线与对外交付承诺、合同节点一致 | 与需求方核对，必要时发起变更修正基线 |
| 通知到位 | 相关角色能说出当前基线版本和最近一次变更内容 | 补发通知，把基线说明纳入项目例会固定议题 |
核验发现的问题应当转化为具体整改动作并指定责任人，而不是停留在检查记录里。连续两个里程碑都出现“变更未走单”的项目，需要检查审批分级是否过重、变更入口是否清晰，把流程成本降下来，规则才守得住。
常见问题
基线发布后，日常任务挪动也要走变更单吗？
不需要。基线冻结的是范围、里程碑、关键交付日期、资源承诺和验收口径，日常任务排期细节在计划内正常调整即可。判断标准是这次调整是否改变了对外的交付承诺：只影响单个工作包内部排期、不移动里程碑、不改变交付范围的，由项目经理确认后记录；一旦涉及里程碑日期、关键资源或验收口径，就应提交变更单。
项目刚启动、计划还很粗，可以先打一版基线吗？
不建议。建立基线的输入前提是计划已细化到可评审的程度，交付物、里程碑和关键工作包都有明确责任人和时间，关键依赖也已识别。前提不满足就发布基线，后续会频繁返工，基线也失去比较价值。如果管理层需要阶段性承诺，可以先发布一份计划说明或阶段目标，等计划细化并通过评审后再正式打基线。
变更被驳回后，原基线需要做任何处理吗？
原基线保持不变，继续作为当前生效版本。变更单记录驳回理由和审批意见，申请人可以补充信息后重新提交。需要避免的是驳回后私下调整计划却不留记录，这会让基线与实际计划脱节。计划管理员在核验时应确认被驳回的变更没有以其他方式进入计划。
多个项目并行时，基线版本号怎么避免混淆？
版本号里带上项目代号即可区分，例如 PRJ01-PB-01 与 PRJ02-PB-01 互不干扰。如果同一项目还管理需求基线或产品基线，用类型段区分，如计划基线用 PB、需求基线用 RB。关键是版本号规则在项目启动时统一约定并写入基线清单，跨项目汇总时按项目代号加类型段检索，避免只凭序号判断。
基线核验发现问题后，怎么推动整改而不是只留一张检查表？
每个不通过项都要转成具体整改动作、责任人和完成时间，并在下一次例会上跟踪关闭情况。如果连续两个里程碑都出现变更未走单，先检查审批分级是否过重、变更入口是否清晰，把流程成本降下来。核验结果也可以作为项目收尾复盘的材料，用于调整下一项目的基线管理规则。
