项目进度管理要真正发挥作用，需要把建甘特图、识别关键路径、每周更新进展和偏差纠偏串成一条固定节奏的例行流程。本文按阶段给出每步的输入、动作、输出和完成标志，并明确项目经理、任务负责人、资源经理与发起人的分工，帮助团队把甘特图变成受控的进度基线，把关键路径变成每周复核对象。
要点总览（TL;DR）
- 进度管理按计划编制、基线确认、周期更新、偏差分析与纠偏、基线变更五个阶段推进，每个阶段都有明确的输入、动作、输出和完成标志。
- 建图时把活动拆到单一责任人可估算的粒度，工期由最熟悉工作的人估算，依赖设置要能对应实际约束，计划评审后冻结为基线。
- 任务负责人按周填报实际开始、实际完成和剩余工期，项目经理汇总后校验依赖并重新核对关键路径，更新责任不宜集中代填。
- 偏差按工期偏差和浮动消耗两类识别，纠偏动作限定赶工、快速跟进、调整范围或依赖，每项都要有责任人和下周复核时点。
- 纠偏后仍无法回到原基线或偏差超过约定阈值时，由项目经理发起基线变更，经发起人或评审方审批后发布新版本并保留对比记录。
一条例行流程包含哪几个阶段
进度管理可以拆成五个前后衔接的阶段：计划编制、基线确认、周期更新、偏差分析与纠偏、基线变更。前两个阶段把计划做扎实并冻结成可比较的基准，中间两个阶段按固定周期把实际进展填回计划并处理偏差，最后一个阶段只在原基线不再适用时启动。每个阶段都有明确的输入、动作、输出和完成标志，团队据此判断当前该做什么、做到什么程度算完成。
| 阶段 | 输入 | 主要动作 | 输出物 | 完成标志 |
|---|---|---|---|---|
| 计划编制 | 项目目标、交付物清单、范围说明、资源可用性 | 拆解活动、估算工期、设置依赖、计算关键路径、绘制甘特图 | 带依赖关系和关键路径的进度计划 | 每项活动都有负责人和工期，依赖关系完整，关键路径已标出 |
| 基线确认 | 进度计划草案 | 评审工期与依赖合理性，确认资源承诺，冻结基线 | 冻结的进度基线及版本记录 | 基线经发起人或评审方确认，版本号与冻结日期可查 |
| 周期更新 | 上周基线、任务负责人填报的实际进展 | 填写实际开始、实际完成、剩余工期，校验依赖 | 更新后的进度计划与更新记录 | 所有进行中活动字段齐全，更新在固定时点完成 |
| 偏差分析与纠偏 | 更新后的计划与基线对比结果 | 识别工期偏差与浮动消耗，记录原因，制定纠偏动作 | 偏差记录与纠偏动作清单 | 每条偏差都有原因、动作、责任人和复核时点 |
| 基线变更 | 纠偏后仍无法回到原基线的证据 | 评估影响、走审批、发布新基线 | 经审批的新基线及变更说明 | 变更获批并留档，新旧基线可对比 |
例行节奏上，周期更新按周进行，固定在每周同一时点截止填报；偏差分析与纠偏紧随更新之后，在同一周内完成；基线复核放在阶段末，判断是否需要正式变更。本文聚焦进度控制本身，项目综合状态汇报和里程碑达成情况属于相邻主题，不在此展开。
建甘特图与识别关键路径的具体做法
建图的目标是得到一张每项活动都能估算、能分配、能追踪的进度计划，并从中算出关键路径。做法可以按以下步骤推进。
活动拆解与工期估算
把交付物逐层拆到可估算、可分配给单一责任人的粒度：一项活动通常对应一个负责人和一段可判断完成与否的产出。拆得过粗会导致工期估算失真，拆得过细会增加更新负担，一般以“一名负责人一周左右能推进并报告进展”为参考粒度。工期由最熟悉该工作的人估算，项目经理汇总并检查口径一致性；估算依据要写明，例如历史同类工作量、资源投入天数或供应商承诺，避免只填一个数字。
依赖关系与提前滞后量
为活动设置前后置依赖，常用类型包括完成—开始、开始—开始、完成—完成和开始—完成。多数场景使用完成—开始即可，其余类型只在工艺或资源约束确实存在时使用。提前量和滞后量要谨慎设置：提前量表示后置活动可提前介入，滞后量表示必须等待的时间（如养护、审批周期）。每设置一个提前或滞后量，都应能说清对应的实际约束，否则会人为扭曲关键路径。
关键路径计算与零浮动识别
关键路径是项目网络中最长的一条路径，其上的活动浮动为零，任何延误都会直接推迟项目完成时间。计算方法是沿依赖关系正向推算每项活动的最早开始与最早完成，再反向推算最晚开始与最晚完成，两者之差即为浮动；浮动为零的活动连成的路径就是关键路径。实际操作中可借助甘特图工具自动计算，但项目经理需要核对结果是否符合对工艺顺序的判断。关键路径可能不止一条，也可能随进展发生转移，因此识别不是一次性动作。
基线冻结
计划经评审确认后冻结为基线，冻结内容包括活动清单、工期、依赖关系、关键路径和计划起止日期。冻结时点通常在项目启动会或阶段计划评审通过之后。基线一旦冻结，后续更新只改实际值和剩余工期，不改原计划值，这样才能持续对比计划与执行的偏差。
角色与交付物如何分工
进度管理最常见的失效方式是更新责任集中到项目经理身上，导致信息滞后且失真。合理分工是：任务负责人对自己负责的活动填报实际进展，项目经理负责汇总、复核关键路径和组织纠偏，资源经理保障人力投入，发起人或评审方对基线变更做决策。
| 角色 | 职责 | 交付物 | 例行时点 |
|---|---|---|---|
| 项目经理 | 组织建图、维护依赖与关键路径、汇总更新、识别偏差、组织纠偏、发起基线变更 | 进度计划、基线、周更新汇总、偏差记录、变更申请 | 建图期集中投入；每周更新后复核；阶段末基线复核 |
| 任务负责人 | 估算本人活动工期、按周填报实际开始、实际完成与剩余工期、说明偏差原因 | 活动工期估算、每周进展填报、偏差说明 | 每周固定截止时点前 |
| 职能/资源经理 | 确认人力可用性、协调资源冲突、支持赶工或调整投入 | 资源承诺、资源调整方案 | 建图期确认；纠偏需要时响应 |
| 项目发起人或评审方 | 确认基线、审批超出阈值的偏差处理与基线变更 | 基线确认记录、变更审批意见 | 基线冻结时；触发变更时 |
更新责任落在任务负责人，是因为只有执行者最清楚活动实际推进到哪一步、还剩多少工作。集中代填会让项目经理依赖二手信息，既增加沟通成本，也容易掩盖真实偏差。升级路径需要事先约定阈值，例如关键路径活动延误超过若干天、或非关键活动浮动被消耗到接近零时，由项目经理上报发起人决策；阈值大小按项目周期和风险承受度设定，写进项目章程或进度管理约定中。
每周更新实际进展的例行操作
一次标准的进展更新应固定时点、固定字段、固定校验动作，使更新结果能直接用于关键路径复核。
更新时点与周期
以周为更新周期，设定每周固定截止时点（例如周四下班前），任务负责人完成填报，项目经理在次日完成汇总与校验。周期过短会增加填报负担，过长会让偏差发现滞后，周更新适合多数中等规模项目；周期很短或活动粒度很细的项目可加密到两三天一次。
必填字段与口径
- 实际开始：活动实际启动的日期，未启动则留空并说明预计启动时间。
- 实际完成：活动实际完成的日期，只有产出经确认后才填写。
- 剩余工期：从更新时点起完成该活动还需的工作天数，由任务负责人重新评估。
- 完成百分比：作为辅助参考，口径需统一，例如按已确认的交付物比例或工作量比例，不能凭感觉填写。
剩余工期应优先于完成百分比，因为完成百分比在返工或范围微调时容易失真，而剩余工期直接对应后续排程和关键路径计算。一项活动即使显示完成百分之八十，如果剩余工作仍需五天，排程就应按五天推进。
更新后的校验与留痕
项目经理汇总后做两项校验：一是检查依赖是否被违反，例如前置活动未完成而后置活动已开始；二是重新计算关键路径，确认是否发生转移。每次更新保留版本记录，记录更新日期、更新人和主要变化，便于回溯。使用ONES时，可在项目计划中按WBS分解活动并设置前后置依赖，通过甘特图查看进度，并在更新后与基线对比识别偏差；工作项状态由任务负责人自行更新，形成自下而上的进度反馈。
偏差分析与纠偏动作怎么落地
更新本身不产生控制效果，偏差分析和纠偏才把更新转化为控制。每周更新完成后，项目经理应逐项比对更新结果与基线。
偏差识别口径
主要看两类指标：一是工期偏差，即活动预计完成日期相对基线完成日期的前后差异；二是浮动消耗，即非关键活动的剩余浮动是否被快速吃掉。关键路径上任何正偏差都直接威胁项目完成日期，需要优先处理；非关键活动浮动消耗到接近零时，说明它即将变成新的关键活动，也应提前干预。
原因分类与记录
偏差原因按可复用的类别记录，例如需求变更、资源不到位、估算偏差、外部依赖延迟、质量问题返工。每条偏差记录应包含活动名称、偏差天数、原因类别、具体说明、影响判断和提出人。分类的价值在于阶段末能看出偏差集中在哪类原因，为后续估算和计划改进提供依据。
纠偏动作类型与复核
- 赶工：增加人力或加班压缩关键活动工期，需评估成本与质量影响。
- 快速跟进：将原本顺序进行的活动改为并行或部分并行，需评估返工风险。
- 调整范围：与发起人协商缩减或推迟非核心交付物。
- 调整依赖：改变活动顺序或提前介入条件，需确认工艺上可行。
每项纠偏动作都要指定责任人和复核时点，通常在下一周更新时复核效果。当纠偏后仍无法回到原基线，或偏差累计超过约定阈值时，触发基线变更：由项目经理提交变更申请，说明偏差原因、已采取的纠偏动作、新基线的活动与日期，经发起人或评审方审批后发布，并保留新旧基线对比记录。
一个完整示例：三周进度控制循环
以下为演示情景，用于说明流程如何运转，不对应真实客户项目。某内部系统上线项目拆出需求确认、接口开发、前端开发、联调测试、上线准备五项活动，其中需求确认—接口开发—联调测试—上线准备构成关键路径，前端开发有三天浮动。
建图与基线。项目经理组织拆解活动，任务负责人分别估算工期，设置完成—开始依赖，计算出关键路径并绘制甘特图。评审会上发起人确认工期与资源承诺，基线冻结，版本记为V1。
第一周更新。接口开发负责人填报实际开始晚于计划两天，原因是外部接口文档延迟，剩余工期由原定八天调整为十天。项目经理校验发现关键路径因此顺延两天，记录偏差原因“外部依赖延迟”，与接口开发负责人商定赶工方案：增加一名开发人员并行处理部分模块，复核时点定在第二周更新。该动作由项目经理上报发起人备案，未触发基线变更。
第二周更新。接口开发剩余工期回落至五天，关键路径回到原计划日期附近；前端开发负责人报告浮动已消耗两天，原因是联调环境准备延迟。项目经理判断前端开发即将进入关键路径，安排资源经理协调环境支持，并将该活动列入下周重点复核。
第三周更新。联调测试负责人报告测试环境问题导致测试启动推迟三天，赶工已无法完全消化，关键路径预计顺延三天。项目经理整理三周偏差记录，发现外部依赖和环境问题合计造成五天延误，超过约定的三天阈值，提交基线变更申请，说明原因、已采取的纠偏动作和新基线日期。发起人审批通过，发布V2基线，旧基线保留可对比。
三周中，任务负责人负责填报与原因说明，项目经理负责校验、纠偏组织和变更发起，资源经理响应资源协调，发起人确认阈值内的备案与超阈值变更，角色动作与前述分工一致。
完成检查：这套流程是否跑起来了
流程是否真正执行，可以用以下清单逐项核对。每项都应能拿出对应记录，而不是凭印象判断。
- 进度基线已冻结，有版本号和冻结日期；此后每次基线调整都有变更申请与审批记录。
- 关键路径在每次周更新后都重新核对过，关键路径转移有记录说明。
- 所有进行中活动的实际开始、实际完成、剩余工期字段齐全，完成百分比口径在项目内一致。
- 每条偏差都有原因类别、具体说明、纠偏动作、责任人和复核时点。
- 上周制定的纠偏动作在本周更新中被逐项复核，未完成的说明原因。
- 周更新在固定时点完成，任务负责人自行填报，项目经理汇总记录可查。
- 阶段末做过一次基线复核，判断是否需要正式变更。
清单中多数项目能勾选，说明例行流程已经运转；若更新字段长期缺失或纠偏动作无人复核，则需要回到角色分工和更新时点约定上找原因，而不是继续增加汇报频次。
常见问题
项目周期很短或活动粒度很细时，周更新还适用吗？
周更新适合多数中等规模项目，但周期很短或活动粒度很细时，一周的间隔会让偏差发现滞后。这类项目可以把更新周期加密到两三天一次，同时保持固定截止时点和固定字段不变。调整的是频率，不是口径：实际开始、实际完成、剩余工期仍按原定义填报，项目经理的汇总与关键路径复核紧随更新完成。周期加密会增加填报负担，应同步检查活动粒度是否拆得过细，必要时合并更新对象。
任务负责人填报的剩余工期与项目经理的判断不一致时怎么处理？
剩余工期由任务负责人重新评估，因为他最清楚活动实际推进到哪一步。项目经理如果认为估算明显偏离，应要求负责人说明依据，例如剩余工作量、资源投入或外部依赖，而不是直接代改数字。双方无法达成一致时，可请资源经理或技术负责人参与判断，并把结论和依据记入更新记录。关键路径上的活动出现这类分歧时优先处理，因为它直接影响项目完成日期。
基线变更审批通过后，原来的偏差记录还需要保留吗？
需要保留。新基线发布后，旧基线和对应的偏差记录是解释进度为何调整的依据，也是阶段末分析偏差集中原因的数据来源。变更说明中应写明偏差原因、已采取的纠偏动作和新基线日期，并与旧基线版本建立对应关系，便于后续对比。保留记录的目的在于让下一次估算和计划编制有可参考的历史，而不是追究责任。
非关键路径上的活动出现延误，是否也要进入偏差分析和纠偏流程？
要进入，但处理优先级不同。非关键活动有浮动，判断重点是浮动被消耗的速度：延误在浮动范围内且消耗缓慢时，记录原因并持续观察即可；浮动被消耗到接近零时，该活动即将成为新的关键活动，应按关键路径活动的标准提前干预。项目经理在每周复核关键路径时一并检查浮动消耗情况，把接近耗尽的活动列入下周重点复核对象。
用工具承载这套流程时，哪些环节最需要系统支持？
最需要支持的是三处衔接：活动与依赖关系的维护、基线与实际进展的对比、更新记录的留痕。以ONES为例，可在项目计划中按WBS分解活动并设置前后置依赖，通过甘特图查看进度，设置计划基线后对比计划与执行的偏差，工作项状态由任务负责人自行更新，形成自下而上的进度反馈。工具承载的是记录和对比动作，更新时点、字段口径、偏差阈值和角色分工仍需团队事先约定并执行。
