进度基线是经批准、用于对照实际进展的进度版本。建立基线时，先确认范围与工作分解，再排定活动、依赖、工期和资源，经评审批准后冻结为基线版本；发生变更时，提交申请、评估影响、按授权审批，批准后发布新基线并保留旧版本与变更记录，让后续偏差分析始终有可比对的参照。
要点总览（TL;DR）
- 建立进度基线前，先确认范围与工作分解已细化到可排期粒度，活动依赖、工期估算、资源与日历约束、关键里程碑和批准角色都已明确。
- 基线建立按排期、校验、评审、定版四步推进，定版时记录版本号、批准人和生效日期，使实际进展有唯一可比对的参照。
- 基线变更走申请、评估、审批、发布四步：申请写明原因、影响范围与替代方案，评估落到工期、关键路径、里程碑和资源，按授权层级审批。
- 批准后发布新基线并归档旧版本，偏差分析以当前有效基线为参照，历史版本用于追溯和复盘。
- 用版本可追溯、变更记录完整、偏差可计算、范围与里程碑一致、旧版本可查五项检查，判断基线是否可用。
建立进度基线前要准备什么
基线一旦定版，就会成为后续判断“提前还是滞后”的标尺。因此定版前要确认输入已经稳定到可以排期的程度。范围还在频繁调整、工期估算主要靠拍脑袋时冻结基线，后续偏差会混杂范围变化和估算误差，难以判断真实进度。
可以把准备事项整理成一份输入清单，逐项确认后再进入排期：
- 范围与工作分解：范围说明已确认，工作分解结构（WBS）拆到可以分配责任人和估算工期的粒度。分解过粗会导致活动无法排期，过细会增加维护成本。
- 活动清单与依赖关系：每项活动有明确的前置、后置关系，外部依赖（如供应商交付、审批节点）单独标注。
- 工期与资源估算：工期估算有依据，资源需求（人力、设备、环境）与可用资源匹配，关键资源冲突已识别。
- 日历与约束条件：项目日历、节假日、非工作时间已设置；强制日期、外部截止时间等约束条件记录在案。
- 关键里程碑：里程碑对应重要时间点、事件或决策点，数量控制在可管理范围，每个里程碑有明确达成标准。
- 批准角色与定版时点：明确谁有权批准基线、在哪个评审节点定版，避免排期完成后无人拍板或反复修改。
这份清单的完成标志是：任一活动都能回答“做什么、依赖谁、多久、谁来做、何时必须完成”。达不到这个状态，建议先补充分解和估算，再进入定版流程。
进度基线的建立步骤
建立基线可以按“排期—校验—评审—定版”四步推进，每一步都有明确的输入、动作和输出，便于检查是否做到位。
第一步：排定活动顺序与依赖，形成初始进度计划
输入是已确认的WBS、活动清单和依赖关系。动作是把活动按逻辑顺序排列，确定每项活动的开始与完成时间，形成初始进度计划。输出是一份包含活动、工期、起止时间和责任人的计划表。完成标志是计划中不存在未排期的活动，依赖关系没有断点。
第二步：识别关键路径与里程碑，检查资源与日历约束
输入是初始进度计划。动作是识别关键路径，确认关键路径上的活动没有资源超载或日历冲突；核对里程碑时间是否与外部约束一致。输出是关键路径说明、资源负荷检查和里程碑清单。完成标志是关键路径上的活动资源已落实，里程碑日期经过相关方确认。
第三步：组织评审，确认范围、工期与假设
输入是排期结果和估算依据。动作是组织项目经理、职能负责人和相关干系人评审，重点确认范围是否完整、工期估算是否合理、假设条件是否成立、风险是否已识别。输出是评审记录和修订后的计划。完成标志是评审意见已闭环，遗留问题有明确处理人和期限。
第四步：批准后冻结为基线版本，记录版本信息
输入是评审通过的计划。动作是由授权角色批准，将计划冻结为基线版本，记录版本号、批准人、生效日期和基线所依据的计划版本。输出是基线定版记录。完成标志是基线版本可被查询，批准人和生效日期齐全，后续实际进展可以对照该版本计算偏差。
在ONES中，可以使用「项目计划」创建工作分解结构，按目标、交付物或项目阶段分解计划和工作；为任务设置前后置依赖，用里程碑标记重要时间点、事件或决策点；并设置项目计划和里程碑基线，实时对比计划与执行的偏差。这些能力对应上述排期与定版动作，具体设置入口和版本字段以实际产品为准。
基线变更的申请、评估与批准流程
基线变更的目标是让调整受控，而不是禁止调整。合理的变更流程包含申请、评估、审批、发布四个环节，每个环节都有对应的控制点。
变更申请：写清原因、影响范围与替代方案
申请人需要说明变更触发原因（如需求增加、资源到位延迟、外部约束变化）、涉及的活动或里程碑范围，以及是否考虑过替代方案（如压缩非关键路径活动、调整资源投入）。申请单是后续评估和追溯的依据，原因描述应具体到可核对的事实。
影响评估：落到工期、关键路径、里程碑与资源
评估由项目经理牵头，相关职能负责人参与。评估内容包括：变更对总工期的影响天数、是否改变关键路径、受影响里程碑及其达成日期、资源需求变化、对后续阶段和外部交付的连带影响。评估结论应给出量化结果和假设条件，避免只写“影响较大”。
审批：按授权层级决定批准或驳回
审批权限按变更影响程度分级：影响范围小、不改变关键里程碑的变更可由项目经理批准；影响总工期或关键里程碑的变更需提交更高层级审批者。批准条件通常是影响已评估清楚、替代方案已比较、资源已落实；驳回条件包括影响未量化、替代方案未考虑或变更理由不充分。审批记录应包含审批人、审批意见和日期。
发布新基线：旧版本归档，变更记录保留
批准后，更新进度计划并发布新基线版本，记录新版本号、生效日期和对应的变更申请单。旧基线版本归档保留，变更记录与新版本关联。后续偏差分析以当前有效基线为参照，历史版本用于追溯和复盘。ONES支持通过对比版本细节追溯变更，可作为版本留存的承载方式。
角色分工与各环节交付物
基线管理涉及多个角色，职责不清会导致定版拖延或变更失控。下表按环节列出主要职责和交付物，便于对照执行。
| 环节 | 主要角色 | 职责 | 交付物 |
|---|---|---|---|
| 基线建立 | 项目经理 | 组织WBS分解、排期、估算，汇总评审意见 | 进度计划、基线定版记录 |
| 基线建立 | 职能负责人 | 确认本领域活动工期、资源投入和依赖 | 资源与工期确认意见 |
| 基线评审 | 项目经理、职能负责人、干系人 | 评审范围、工期、假设和风险 | 评审记录、修订后的计划 |
| 基线批准 | 授权审批者 | 批准定版，确认版本号和生效日期 | 批准记录 |
| 变更申请 | 申请人（项目经理或职能负责人） | 提交变更原因、影响范围和替代方案 | 变更申请单 |
| 变更评估 | 项目经理、职能负责人 | 评估工期、关键路径、里程碑和资源影响 | 影响评估说明 |
| 变更审批 | 授权审批者 | 按影响程度批准或驳回 | 审批记录 |
| 版本维护 | 项目经理 | 发布新基线、归档旧版本、维护变更记录 | 基线版本记录、变更台账 |
| 偏差对照 | 项目经理、任务负责人 | 对照基线计算实际进展偏差，识别风险 | 偏差分析记录 |
基线与实际进展的对照责任落在项目经理和任务负责人身上：任务负责人反馈实际完成情况，项目经理汇总偏差并判断是否需要触发变更或纠偏。ONES提供从项目到任务的多层级管理能力，支持自下而上的进度反馈和自上而下的进度监控，可作为偏差对照的承载方式。
示例：一次工期压缩引发的基线变更
以下为演示情景，用于说明变更流程如何落地。
某项目已定版基线V1.0，总工期20周，关键路径为“需求确认—开发—集成测试—上线”，其中集成测试计划4周，上线里程碑定在第20周。项目执行到第10周时，客户要求提前2周上线，触发基线变更。
申请内容
项目经理提交变更申请，写明原因（客户要求提前上线）、影响范围（上线里程碑及后续验收活动）、替代方案（压缩集成测试至3周并增加测试人力，或将部分非关键功能移至二期）。申请单附客户沟通记录和初步影响判断。
影响评估
评估结论：压缩集成测试会使关键路径缩短1周，但测试人力需增加2人；将部分功能移至二期可再缩短1周，但需产品负责人确认范围调整。两项措施合计可将上线里程碑提前至第18周，关键路径变为“需求确认—开发—集成测试（压缩）—上线”，资源成本增加。评估说明列出量化结果和假设条件。
审批与发布
由于变更影响关键里程碑和总工期，提交至项目指导委员会审批。审批结论为批准，条件是测试人力在第11周前到位、二期功能范围经产品负责人书面确认。项目经理更新计划，发布基线V2.0，记录生效日期、批准人和对应变更申请单。
旧版本保留与后续对照
V1.0归档保留，变更记录与V2.0关联。后续偏差分析以V2.0为参照：第12周检查时，集成测试实际进度比V2.0计划滞后3天，项目经理据此判断是否需要纠偏；复盘时可对比V1.0与V2.0的差异，评估工期压缩措施的实际效果。
完成检查：基线是否可用
基线建立和变更完成后，可用以下清单逐项核对，判断是否达到可用状态。
| 检查项 | 核对内容 | 通过标准 |
|---|---|---|
| 版本可追溯 | 基线版本号、批准人、生效日期是否齐全 | 每个基线版本都能查到批准人和生效日期 |
| 变更记录完整 | 每次变更是否有申请、评估和审批记录 | 变更申请单、影响评估说明、审批记录三者对应 |
| 偏差可计算 | 实际进展能否对照当前基线计算偏差 | 能按活动或里程碑算出进度偏差，并识别关键路径影响 |
| 范围与里程碑一致 | 基线与已确认范围、里程碑是否保持一致 | 基线中的活动和里程碑与范围说明无冲突 |
| 旧版本可查 | 历史基线版本是否归档保留 | 旧版本可查询，并与变更记录关联 |
五项全部通过，说明基线具备对照和追溯能力；存在缺项时，优先补齐版本记录和变更审批记录，再用于进度控制。ONES的瀑布项目管理方案支持设置项目计划和里程碑基线、对比计划与执行偏差，并通过版本对比追溯变更细节，可作为上述检查项的承载工具，具体能力范围以实际使用版本为准。
常见问题
范围还在调整时，可以先冻结进度基线吗？
不建议。范围频繁变动时冻结基线，后续偏差会同时包含范围变化和进度执行两类原因，难以判断真实进展。更稳妥的做法是先把范围确认到可排期粒度，完成工作分解和工期估算，再进入评审定版。如果业务上必须先行排期，可以保留计划版本用于内部协调，待范围稳定后再正式定版为基线。
基线变更被驳回后，原基线还能继续用吗？
可以。变更被驳回意味着调整未获批准，当前有效基线保持不变，团队继续按原基线执行和对照偏差。驳回时应在审批记录中写明理由，例如影响未量化、替代方案未比较或变更理由不充分。申请人补充评估后可以重新提交；如果实际情况已无法按原基线推进，应把偏差和风险记录清楚，作为下一次变更申请的依据。
小范围调整也要走完整的变更审批吗？
审批层级可以按影响程度分级。不改变关键路径和关键里程碑、影响范围小的调整，可由项目经理批准并记录；影响总工期或关键里程碑的变更，提交更高层级审批者。分级的关键是事先在流程中写清各级权限和判断标准，避免临时争论。无论哪一级批准，变更申请、影响评估和审批记录都应保留，保证后续可追溯。
旧基线版本要保留多久，保留哪些内容？
保留期限按项目周期和组织的审计、复盘要求确定，通常至少覆盖项目执行期和收尾复盘阶段。需要保留的内容包括旧基线版本本身、对应的变更申请单、影响评估说明和审批记录。旧版本与变更记录关联后，复盘时可以对比不同版本的差异，评估调整措施的实际效果。项目结束后如需长期归档，按组织文档管理要求执行。
基线和实际进展的偏差由谁负责对照？
任务负责人反馈实际完成情况，项目经理汇总偏差并判断是否需要纠偏或触发变更。对照时按活动或里程碑计算进度偏差，重点关注关键路径上的活动是否滞后。偏差超出预设阈值时，先分析原因属于执行问题还是基线本身需要调整，再决定纠偏措施或提交变更申请。
