计划基线的建立，先划定纳入基线的范围与版本口径，再冻结关键日期、里程碑、交付物和资源假设，经项目经理提交、职能负责人会签、项目负责人批准后登记编号归档；变更时按申请、影响评估、审批、发布新版本、通知相关方五步执行，旧版本保留可追溯。ONES 可用于承载基线版本登记与变更审批记录，本文按这一口径说明操作步骤、角色分工与检查清单。
要点总览（TL;DR）
- 建立基线前先划定范围：里程碑、关键交付日期、主要交付物、资源与工期假设纳入基线，任务级排期和执行偏差跟踪留在基线外，并确定编号规则。
- 建立基线按准备、冻结、会签、批准、发布归档五步执行，项目经理提交，职能负责人确认资源承诺，项目负责人批准，登记编号后归档。
- 基线变更走申请、影响评估、审批、发布新版本、通知同步五步，按影响程度分级审批，旧版本保留可追溯。
- 角色职责要分开写明：项目经理组织编制与提交变更，职能负责人会签，项目负责人批准，配置管理角色登记归档，相关方接收通知并反馈。
- 检查时重点核对两类遗漏：只改计划不升版本、变更未评估下游影响。
建立计划基线前先定清哪些内容纳入基线
基线的作用是给项目计划提供一个经批准、可比较的参照点。范围划得太宽，日常排期一有调整就要走变更，流程会被拖垮；范围划得太窄，关键承诺没有冻结，基线就失去参照意义。动手冻结之前，先把“哪些内容进基线、哪些留在基线外”写成一份范围说明，并由项目负责人确认。
纳入基线的计划要素
进入基线的内容应当是项目对外或对内的正式承诺，通常包括四类：里程碑及其计划日期；关键交付日期，如阶段评审、验收、上线窗口；主要交付物清单及其完成标准；资源与工期假设，包括关键角色投入、外部依赖的前置条件。这四类要素一旦批准，后续调整就需要走变更流程。
不纳入基线的要素
日常任务排期细节和执行偏差跟踪留在基线之外。任务级排期可以随执行情况滚动调整，偏差跟踪属于进度管理的日常工作，两者都不需要每次变动都触发基线变更。把它们排除在外，是为了让基线聚焦承诺，而不是变成一份需要频繁维护的全量计划。
版本命名与编号规则
基线编号建议包含项目标识、基线类型和序号，例如“项目代号-BL-01”，变更后生成“项目代号-BL-02”，序号递增、旧号不复用。版本说明中记录建立或变更日期、批准人、变更摘要。编号规则要在项目启动时确定，避免不同人各自命名导致版本混乱。
口径与项目类型、合同或阶段评审的对应
基线口径需要与项目所处的外部约束对齐。合同型项目，合同约定的交付节点和验收条件应全部纳入基线；按阶段评审推进的项目，每个阶段结束时的评审通过条件可作为该阶段基线的冻结内容；内部研发项目可以按版本或迭代节点设定基线。口径确定后写入项目计划管理约定，后续建立与变更都按同一口径执行。
这一节的交付物是一份基线范围与版本口径说明，至少包含纳入清单、排除清单和编号规则三部分，作为后续建立基线的依据。
计划基线的建立步骤：从计划冻结到批准发布
基线建立是一个有明确输入、动作和完成标志的过程。下面按五个步骤拆解，每一步都说明谁来做、产出什么、什么状态算完成。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 | 负责人 |
|---|---|---|---|---|---|
| 1. 准备 | 已评审的项目计划、WBS或阶段划分、资源与工期假设 | 核对计划完整性，确认范围说明已批准 | 待冻结的计划版本 | 计划通过评审，范围口径明确 | 项目经理 |
| 2. 冻结 | 待冻结的计划版本 | 锁定关键日期、里程碑、交付物和资源假设，核对跨团队依赖 | 基线草案 | 关键要素无遗漏，依赖关系已确认 | 项目经理 |
| 3. 会签 | 基线草案 | 职能或资源负责人确认资源投入与交付承诺 | 会签记录 | 相关职能负责人完成确认 | 职能负责人 |
| 4. 批准 | 会签后的基线草案 | 项目负责人或变更控制角色审批 | 批准记录 | 审批通过并留痕 | 项目负责人 |
| 5. 发布归档 | 批准后的基线 | 登记基线编号，归档版本，通知相关方 | 基线版本记录 | 版本可查，相关方已收到通知 | 项目经理、配置管理角色 |
冻结环节最容易出问题的是依赖核对。一个里程碑日期背后往往挂着其他团队的交付，冻结时要把这些前置依赖逐条确认，否则基线批准后很快就要变更。会签环节的重点是让资源负责人对投入做出明确承诺，而不是被动知会。批准之后，基线版本进入只读状态，后续调整通过变更流程产生新版本。
在协作工具中承载这一过程时，可以把基线版本作为项目计划的一个受控版本登记，会签与批准记录随版本留存。ONES 的项目管理能力支持将计划与里程碑纳入项目工作项管理，版本与审批记录可随项目文档归档，便于相关方按编号查询当前有效基线。
计划基线变更的流程与审批口径
基线变更的目标是让调整有据可查、影响可控，同时避免把每一次小调整都升级为高层审批。流程分五步：申请、影响评估、审批、发布新版本、通知同步。
变更申请应包含的内容
申请由提出方填写，至少写明变更原因、影响范围、涉及的里程碑与交付日期。原因要具体到触发事件，例如需求调整、外部依赖延期、资源变动；影响范围要列出受影响的交付物和下游团队。信息不全的申请退回补充，不进入评估环节。
影响评估
评估围绕工期、资源、成本和下游依赖四个维度展开。工期看关键路径是否变化、总工期顺延多少；资源看是否需要追加投入或调整投入节奏；成本看变更带来的额外支出；下游依赖看其他团队的交付计划是否需要联动调整。评估结论形成书面记录，作为审批依据。
审批分级
| 变更影响程度 | 典型情形 | 审批层级 |
|---|---|---|
| 轻微 | 不影响关键里程碑日期，资源与成本在已批准范围内调整 | 项目经理审批，记录备案 |
| 中等 | 影响单个里程碑日期或阶段性交付，需要职能侧配合调整 | 项目经理提交，相关职能负责人会签，项目负责人批准 |
| 重大 | 影响项目总工期、合同交付节点或整体预算 | 项目负责人审核后提交变更控制角色或更高层级批准 |
分级标准在项目启动时确定并写入管理约定，避免每次变更临时判断审批层级。审批人应在约定时限内给出结论，超时未处理的变更按约定升级提醒。
发布新版本与通知同步
审批通过后生成新基线版本号，旧版本保留、不覆盖，版本记录中注明变更摘要和批准信息。随后向相关方发布变更结果，同步更新计划中的日期、交付物和依赖安排。通知范围覆盖受影响的职能团队和下游依赖方，通知内容包含新版本编号、变化点和生效时间。
角色分工与各环节交付物
基线建立与变更涉及多个角色，职责不清时容易出现“计划改了但没人知道”“会签走过场”的情况。下表按角色列出职责与交付物。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 项目经理 | 组织基线编制，提交变更申请，维护版本记录，组织通知 | 基线范围说明、基线草案、变更申请、版本记录 |
| 职能或资源负责人 | 确认资源承诺与交付可行性，参与变更影响评估 | 会签记录、资源确认意见 |
| 项目负责人或变更控制角色 | 批准基线与重大变更，裁定审批分级争议 | 批准记录、审批结论 |
| 配置或文档管理角色 | 登记版本编号，归档基线记录与变更记录 | 版本登记台账、归档记录 |
| 相关方 | 接收通知，反馈对自身工作的影响 | 接收确认、影响反馈 |
角色可以由同一人兼任，但职责要分开写明。例如小型项目中项目经理可能同时承担配置管理职责，此时版本登记仍要按规则执行，不能因为人手少就省略编号和归档。相关方的反馈环节常被忽略，实际上它是发现下游影响遗漏的最后一道关口，通知发出后应留出反馈窗口。
示例：一个阶段交付项目的基线建立与一次变更
以下为演示情景，用于说明操作过程，不对应具体真实项目。
某阶段交付项目分为需求确认、开发实现、联调测试、验收交付四个阶段，关键里程碑为需求评审通过、开发完成、测试通过、验收完成。项目启动时确定基线口径：四个里程碑日期、各阶段主要交付物、关键角色投入纳入基线，任务级排期不纳入，编号规则为“项目代号-BL-序号”。
基线建立过程：项目经理整理已评审的计划，冻结四个里程碑日期和交付物清单，核对联调测试阶段对外部环境的依赖；职能负责人会签确认开发与测试人力投入；项目负责人批准后登记为 BL-01，归档并向相关方发出通知。
一次变更：开发实现阶段中，需求方提出接口调整，导致联调测试启动时间顺延。项目经理提交变更申请，写明原因、受影响的测试通过和验收完成两个里程碑；影响评估显示总工期顺延，测试资源投入时段需相应后移，下游验收安排需联动调整。该变更影响阶段性交付，按分级由职能负责人会签、项目负责人批准。批准后生成 BL-02，BL-01 保留可查，版本记录注明变更摘要；项目经理向需求方、测试团队和验收相关方发出通知，更新计划中的里程碑日期和依赖安排。
这个示例的关键点在于：变更只调整了受影响的里程碑和依赖，没有重写整份计划；旧版本保留，任何人可以查到变更前后的差异；通知覆盖了下游团队，验收安排的联动调整在变更阶段就完成了。
完成检查：基线建立与变更是否做到位
以下检查清单可用于项目自检或阶段评审，逐项核对并留存证据。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 基线范围与编号规则 | 纳入与排除清单已批准，编号规则已写入管理约定 | 基线范围说明 | 项目经理 |
| 会签与批准 | 相关职能负责人已确认，批准人已签字或系统留痕 | 会签记录、批准记录 | 项目经理 |
| 版本登记与归档 | 基线编号唯一，版本记录完整，旧版本可查 | 版本登记台账 | 配置管理角色 |
| 变更申请与影响评估 | 每次变更均有申请记录和书面影响评估 | 变更申请单、评估记录 | 项目经理 |
| 审批分级执行 | 变更按影响程度匹配审批层级，无越级或漏批 | 审批记录 | 项目负责人 |
| 通知与同步 | 相关方已收到变更通知并有反馈窗口 | 通知记录、反馈记录 | 项目经理 |
常见遗漏有两类：一是只改计划不升版本，计划内容变了但基线编号没变，导致参照点失真；二是变更未评估下游影响，本团队的日期调整了，依赖方的安排没有同步，问题在后续阶段才暴露。检查时对这两项要重点核对，发现后补走变更流程并更新版本记录。
常见问题
基线范围划得太宽或太窄，分别会带来什么问题？
范围太宽时，日常排期一有调整就要走变更，流程负担会压过基线本身的价值；范围太窄时，关键承诺没有被冻结，基线无法作为参照点。判断标准是看某项内容是否属于经批准的正式承诺：里程碑日期、关键交付日期、主要交付物和资源假设属于承诺，应纳入；任务级排期和执行偏差跟踪属于执行层调整，留在基线外。范围说明写好后由项目负责人确认，后续建立与变更都按同一口径执行。
小型项目人手少，能否省略会签或版本登记？
角色可以兼任，职责仍要分开写明。小型项目中项目经理可能同时承担配置管理职责，此时版本登记仍按编号规则执行，会签也可以简化为关键职能负责人的书面确认，但确认记录要留存。省略会签或版本登记会让基线失去可追溯性，后续出现日期争议时无法说明哪一版是批准过的承诺。
变更申请信息不全时怎么处理？
信息不全的申请退回补充，不进入影响评估环节。一份可评估的申请至少写明变更原因、影响范围、涉及的里程碑与交付日期。原因要具体到触发事件，例如需求调整、外部依赖延期或资源变动；影响范围要列出受影响的交付物和下游团队。退回补充的规则应在项目启动时写入管理约定，避免提出方与审批方反复拉扯。
变更审批通过后，旧版本的计划还要保留吗？
要保留。审批通过后生成新基线版本号，旧版本不覆盖、可查询，版本记录中注明变更摘要和批准信息。保留旧版本的作用是让相关方能对比变更前后的差异，也便于阶段评审时说明计划调整的依据。通知相关方时一并告知新版本编号、变化点和生效时间，覆盖受影响的职能团队和下游依赖方。
基线建立后，执行中出现进度偏差是否都要走变更？
不必。执行偏差的跟踪与纠偏属于进度管理的日常工作，在已批准的关键日期和里程碑范围内调整任务安排，不需要触发基线变更。当偏差导致里程碑日期、关键交付日期、主要交付物或资源假设发生变化时，才按变更流程申请、评估、审批并发布新版本。这条界线在基线范围说明中写清楚，可以减少不必要的变更申请。
