进度跟踪进展全流程：PMO数据分析与一文讲清

我做过一次不太体面的复盘。项目预算 800 万，计划周期 11 个月，项目周报连续 14 周显示“进度正常”，进度偏差从未超过 5%，但最终它延期 92 天交付、超支 17%。

会后我把那 14 周的周报重新拉了一遍，数据一条不缺，问题在于没有一条数据被验证过。90% 的进度数字来自任务负责人自己填的完成百分比，而“完成”在不同团队里分别指“代码提交”“自测通过”“部署到测试环境”三种状态。

这就是大多数 PMO 做进度跟踪的真实处境：不是缺数据，而是数据不可比、不可信、不可行动。进度跟踪全流程的核心不是把周报做漂亮，而是把零散的进度信息变成可信的决策依据，再把决策变成有人负责、有期限、有验收标准的行动项。

下面这套方法，是我在 2023 到 2025 年参与复盘的中大型研发项目里逐步磨出来的，涉及数据口径治理、偏差分析、预警升级、会议机制和工具选型。文中数据标注了来源，脱敏案例做了模糊处理，指标阈值是可以直接拿去用的建议基准。

一、先给结论：进度跟踪是一套“数据，判断，决策，行动”闭环

在展开细节之前，我把结论放在最前面。如果你只记住一段话，就记这一段。

1. 结论一：进度跟踪的产出物不是报表，是行动项

我见过太多 PMO 把 KPI 定成“每周按时提交周报的项目数”“报表覆盖率”“看板访问量”。这些指标全部指向报表生产，没有一条指向结果。

真正能衡量进度跟踪有效性的指标只有一个：本周由进度分析触发、并在承诺期限内关闭的行动项占比。我的经验基线是，一个健康的 PMO 进度跟踪机制，每周产生的有效行动项应该在 3 到 12 条之间，闭环率不低于 80%。低于 3 条说明分析没有穿透力，高于 20 条说明你在用行动项掩盖优先级缺失。

2. 结论二：没有基线，就没有进度

进度是一个相对量，必须有一个可对比的承诺才能算出来。很多团队实际上没有基线，只有一张不断被修改的排期表，改到最后所有人都不知道原计划是什么。

基线不是排期表本身，它是在某个时间点被正式承诺、并被冻结版本号的一组里程碑和交付日期。基线可以变更，但每次变更要走变更流程、留痕、并在报表里同时展示原基线和当前基线，否则“偏差”这个词毫无意义。

3. 结论三：PMO 的价值在判断，不在统计

统计是工具能做的事。任务完成率、逾期数量、燃尽曲线，任何一个项目管理平台都能自动算出来。PMO 不可替代的部分是判断：这个偏差是正常波动还是趋势性失控？是执行问题还是估算问题？需要谁在什么时间做什么决定？

所以我在设计任何进度跟踪机制时，第一步不是选工具，而是回答三个问题：谁负责判断、判断依据是什么、判断完后谁必须行动。

二、背景与真实场景：进度跟踪为什么总是变成催周报

理解了闭环逻辑，再看现实中的三个典型场景，就能明白问题出在哪一环。

1. 场景一：周报流水线，全员都在生产数据，没人做判断

我调研过一家 1200 人的软硬件混合研发企业。PMO 有 4 个人，每周四到周五的全部工作时间都在收周报、核对数字、美化 PPT。周五下午 6 点发出，管理层周一上午看 5 分钟。

我问他们的 PMO 负责人：过去半年，有多少条决策是因为这份报告做出的？他想了很久说，好像主要是让大家知道项目在跑。

这就是典型的“报表生产型 PMO”。它的特征是：数据采集量巨大，分析深度极浅，决策产出接近零。4 个人每周 40 个工时投进去，换来的是管理层 5 分钟的浏览。

2. 场景二：多项目资源冲突，每个项目都说自己缺人

多项目环境下最常见的抱怨是“人不够”。但如果追问一句“谁在哪个项目上投入了多少比例”，往往没人答得上来。

根因是资源投入数据没有和进度数据关联。一个开发同时挂在 3 个项目上，每个项目的任务都排到 100% 负荷，加起来就是 300%。这种情况下任何进度预测都是假的，因为它的前提不成立。

我在一次复盘中做过统计：某研发中心 137 名工程师，同时参与 2 个以上项目的有 61 人，其中 23 人的累计任务负荷超过 150%。这 23 人所在的项目，平均延期天数是非超载人员所在项目的 2.4 倍。

3. 场景三：里程碑验收拖延，任务完成了但价值没交付

“任务进度 100%，里程碑延期 3 周”，这句话听起来矛盾，但在现实里非常常见。原因是任务完成的定义是“执行者认为做完了”，而里程碑完成的定义应该是“交付物通过验收”。

这两个定义之间隔着一整个验收流程：提测、测试通过率、缺陷收敛、文档提交、业务方签字。很多时候任务在系统里早就标了完成，验收流程还没开始走。

三、拆解六个常见误区

上面的场景背后，是六个人人都在犯、但很少被明确指出的误区。

1. 误区一：把完成百分比当成进度

完成百分比是自评数据，最大的问题是不可验证。一个任务填 80% 可以维持三周不动，因为没人能证明它不是 80%。

我在一个项目里做过对照：让同一个团队用“完成百分比”和“剩余工作量小时数”两种方式各报一次进度，结果 31 个任务里有 12 个的口径冲突超过 20%。也就是说，三分之一的进度信息在两种口径下自相矛盾。

修正做法是用可验证的事件代替百分比：任务是否提测、是否通过评审、交付物是否入库。这些是离散事件，有明确证据，不可含糊。

2. 误区二：指标口径不一致，跨部门数字永远对不上

“逾期任务”这个词，在开发团队指“超过计划完成日期的任务”，在测试团队指“超过提测日期的任务”，在 PMO 报表里指“超过基线里程碑的任务”。三个数字放在一张表里对比，得出的结论必然错误。

口径问题不是文档问题，是治理问题。它需要有人有权定义、有权裁决、有权要求所有人按同一口径取数。这个角色通常只能是 PMO。

3. 误区三：只报不决，报表成了事后通知

报表发出去，没人提问，没人做决定，下周继续发。这种机制运行半年后，所有人都会形成条件反射：报表是可以不看的。

判断标准很简单：如果一份周报连续四周没有触发任何一次追问或决策，它就应该被砍掉。留着只会稀释注意力。

4. 误区四：指标越多越好，28 个指标等于 0 个指标

我见过一份 9 页的 PMO 月报，包含 43 个指标、17 张图。我问管理层最常看哪几个，答案是“前面三个”。

指标数量和管理层阅读深度呈倒 U 型关系。我的观察是，管理层级看板控制在 5 到 7 个指标最合适，PMO 层级 15 到 20 个，项目组层级可以到 30 个以上但必须分屏呈现。

5. 误区五：用工具替代治理

换了新平台，进度问题就解决了吗？不会。工具解决的是数据的采集、存储和呈现，解决不了“完成是什么意思”“谁有权改基线”“偏差到什么程度要升级”这些问题。

反过来，治理做好了，Excel 也能跑得不错；治理没做好，再贵的平台也只是一个更贵的 Excel。

6. 误区六：预警只标颜色，没有升级路径

红色代表高风险，然后呢？谁来响应、多长时间内响应、响应不了往谁那里升级、升级后必须做什么决定？这些没有定义，红色就只是视觉装饰。

我现在设计预警机制时，会强制要求每个颜色等级都绑定三样东西：响应时限、责任人角色、升级触发条件。缺一样，这个等级就不成立。

四、专业判断逻辑：口径、基线、偏差、预警、升级

误区讲完，接下来是正面方法论。我把进度跟踪的专业判断拆成五个必须固定下来的组件。

1. 组件一：指标口径字典，每个指标七个要素

口径字典不是指标清单，它必须能回答“两个人独立取数，结果是否一致”。我在每个项目里推行的是七要素版本：指标名称、业务含义、计算公式、数据来源、更新频率、责任人、预警阈值。

下面是我实际在用的一份口径字典片段，用的是 YAML 格式，可以直接放进文档库或配置进 BI 工具。

metric: milestone_on_time_rate
name: 里程碑准时达成率

meaning: 统计周期内，按基线日期或经批准的新基线日期完成验收的里程碑占比

formula: 准时通过验收的里程碑数 / 应达成的里程碑总数

source: 里程碑表(状态=已验收) JOIN 基线版本表(版本=当前生效)

frequency: 每周一 09:00 更新，统计范围为上周一至周日

owner: PMO 项目治理岗

threshold:

green: 大于等于 0.90

yellow: 0.75 到 0.90

red: 小于 0.75

note: 里程碑日期变更须走变更单，未走变更单的延期一律计入不准时

注意最后一行 note。口径字典里最容易被忽略、又最关键的部分，就是例外规则。它决定了数据可不可以被“操作”。

2. 组件二：基线治理，冻结、变更、留痕

基线治理有三个动作。第一是冻结：项目启动评审通过后，里程碑和关键交付日期形成 v1.0 基线并锁定。第二是变更：任何日期调整必须提交变更单，说明原因、影响和补偿措施。第三是留痕：报表同时展示 v1.0 和当前生效版本，让所有人看到漂移了多少。

我的经验是，一个健康的项目在生命周期内的基线变更次数应该控制在 2 到 4 次。超过 6 次，说明前期估算或范围管理存在系统性问题，需要上升到组织级复盘。

3. 组件三：偏差分析，四种视角缺一不可

只有“延期 5 天”这一个数字，是没法做判断的。我在分析时固定用四种视角。

• 绝对偏差：当前日期与基线日期的差值，单位是天。回答“晚了多少”。
• 相对偏差：绝对偏差除以计划工期。回答“晚了多少比例”，用于跨项目比较。
• 关键路径偏差：只看关键路径上的任务偏差。回答“是否真的影响交付”。
• 趋势外推：按当前速度推算完工日期。回答“如果不变，最终会怎样”。

这四种视角会给出不同结论。一个非关键路径任务延期 10 天，绝对偏差很大，但关键路径偏差是 0，交付风险其实很低。反过来，关键路径上延期 2 天，绝对偏差很小，趋势外推却可能显示最终延期 3 周。

下面这段是计算偏差的基础逻辑，用 SQL 伪代码表达，可以直接对应到大多数项目管理平台的数据表结构。

SELECT
t.project_id,
t.task_id,
t.is_critical_path,
DATEDIFF('day', b.baseline_end_date, t.forecast_end_date) AS deviation_days,
ROUND(
DATEDIFF('day', b.baseline_end_date, t.forecast_end_date)
/ NULLIF(DATEDIFF('day', b.baseline_start_date, b.baseline_end_date), 0)
, 3) AS deviation_ratio
FROM task t
JOIN baseline_task b ON b.task_id = t.task_id AND b.version = 'current'
WHERE t.status NOT IN ('closed', 'cancelled')
ORDER BY t.is_critical_path DESC, deviation_days DESC;

这里有一个容易踩的坑：不要用“计划完成日期”当基线，要用基线表里的日期。计划日期会随着任务调整被改写，一旦改写，偏差就永远等于零。

4. 组件四：分级预警，每个等级绑定响应时限

我用的分级是三级，但不是简单的红黄绿，而是“绿灯，黄灯，橙灯，红灯”四级的简化版。每个等级必须绑定响应时限和升级对象，否则预警形同虚设。

这套阈值不是标准答案，是起点。业务节奏快的团队可以把黄灯调成 2 天，硬件类项目可以放宽到 5 天。关键是阈值一旦定了，就不能因为某个人说“这次特殊”而临时修改，否则预警体系三个月内就会失效。

5. 组件五：会议机制，输入输出必须写死

进度跟踪最终要通过会议完成决策。我固定了两类会议：项目周会（执行层，30 分钟）和项目集进度评审会（决策层，60 分钟）。

这两类会议的输入必须提前 24 小时发出，输出必须在会后 4 小时内形成行动项清单。行动项清单的字段固定为六项：事项描述、责任人、承诺完成日期、验收标准、关联风险、升级路径。

{
"action_id": "ACT-2026-0312-007",

"description": "完成支付网关接口的联调环境准备",

"owner": "张XX(后端组)",

"due_date": "2026-03-16",

"acceptance": "联调环境可提交测试单，且通过冒烟用例 100%",

"related_risk": "RISK-118 第三方接口文档延迟",

"escalation": "逾期 1 个工作日自动升级至项目集经理"

}

注意 acceptance 字段。没有验收标准的行动项，等于没有行动项。它会在下一次会议上被反复提起，但永远无法确认关闭。

五、PMO 数据分析指标体系与看板设计

组件定义清楚后，接下来是指标本身。我把它分成三层：结果指标、过程指标、预测指标。这三层回答的是不同问题，不能混用。

1. 结果指标：回答“做到了没有”

结果指标是滞后指标，用来对账，不用来做早期干预。它包含里程碑准时达成率、按时交付率、进度偏差率、范围变更率。

其中“按时交付率”和“里程碑准时达成率”容易混淆。前者以项目或版本为单位，后者以里程碑为单位。一个项目可以有 8 个里程碑，其中 7 个准时，但最后一个延期导致项目整体延期，此时里程碑达成率是 87.5%，按时交付率是 0%。两者必须同时呈现。

2. 过程指标：回答“过程中哪里堵住了”

过程指标是同期指标，用于早期发现。我在实践中保留四个：任务逾期率、平均阻塞时长、关键路径浮动天数、需求变更率。

“平均阻塞时长”是我特别看重的一个指标，它衡量的是任务从被标记阻塞到解除阻塞的平均小时数。这个数字如果超过 40 小时，说明跨团队协同机制有问题，而不是某个人的问题。

3. 预测指标：回答“如果不干预，最终会怎样”

预测指标用于推动决策。我使用完工预测日期（EAC Date）、燃尽趋势斜率、风险敞口金额三项。

完工预测的算法不需要多复杂。用最近 4 周的已完成工作量除以总工作量，得到速度，再推算剩余工作量所需时间。简单，但比任何复杂的挣值模型都更容易被业务方理解和接受。

关于 SPI、CPI 这类挣值管理指标，我的判断是：它们适合固定范围、固定预算的合同型项目，不适合需求高频变化的产品研发。在后一种场景下，PV 和 EV 的口径几乎无法稳定维护，算出来的数字反而误导决策。

4. 三层看板：不同层级看不同指标

同样的数据，面向不同角色要重新组织。管理层看趋势和风险，PMO 看异常和归因，项目组看任务和阻塞。

六、真实案例与数据观察：从人工填报到系统化进度治理

指标和看板讲完了，我用一个完整的脱敏案例把它们串起来。这是我认为最能说明问题的一次实践。

1. 背景：一家 1200 人研发组织的进度治理困境

这家企业的主营业务是智能硬件加配套软件平台，研发人员约 1200 人，符合中大型企业及 100 人以上组织的典型特征。项目形态包括硬件迭代、嵌入式固件、移动端应用和云端服务，跨部门依赖极多。

他们当时的状况是：任务数据分散在三个系统里，一部分在旧的项目管理工具里，一部分在自建的任务看板，还有一部分在部门自己的 Excel。PMO 每周要花 2 个人天做数据汇总，汇总出来的结果部门之间还对不上。

更麻烦的是他们面临国产化替代和信息安全合规要求，需要支持私有化部署，同时希望能从既有的 Jira 平滑迁移，不希望在迁移过程中损失历史数据。这类需求在中大型组织里非常普遍。

2. 选型判断：为什么最终落地在 PingCode

我们评估了五种方案，包括继续自建、使用通用办公协作工具、以及三类专业项目管理平台。评估维度是：私有化部署能力、历史数据迁移成本、需求到交付的全链路覆盖度、报表自定义能力、组织级权限模型。

最终落地的是 PingCode。判断依据有三个。

第一，它支持私有化部署，满足这家企业的数据不出内网要求，这是硬门槛，不满足的方案在第一轮就被排除了。

第二，它支持从 Jira 平滑迁移，包括工作项、字段映射、历史评论和附件。这一点对中大型组织至关重要，因为历史数据一旦断裂，趋势分析就没有基线可对比。迁移过程中我们保留了原工作项的创建时间，让燃尽曲线能够追溯。

第三，它覆盖需求、迭代、测试、缺陷、发布的全链路，不需要在多个系统之间做数据拼接。之前那份周报里有 40% 的时间花在跨系统对齐口径上，现在这部分工作直接消失。

需要说明的是，我不认为工具本身能解决问题。这家企业在换工具之前，已经先完成了指标口径统一和基线治理，工具只是让执行成本大幅下降。如果口径没定好就换工具，结果只会是“用新工具犯旧错误”。

3. 六个指标在治理前后的变化

治理动作分三批推进，每批间隔一个月。我记录了六个可对比的指标，数据来自平台内置报表加上人工核对，统计周期为治理前 12 周与治理后 12 周的对比。

我认为最值得关注的不是里程碑达成率的提升，而是行动项闭环率从 46% 提升到 83%。这个数字才真正说明进度跟踪从“生产报表”转向了“推动行动”。

另外要诚实说明：这组数据也受到同期组织调整的正面影响，包括新增了 2 名专职 PMO 和一次范围冻结。我不会把这些改善全部归功于工具或方法。

4. 一个细节：数据采集方式决定了数据可信度

迁移前，约 30% 的进度数据靠人工填写。迁移后，这个比例降到 8%，主要剩下的是交付物验收状态和风险等级评估这类必须人工判断的字段。

我专门统计过不同采集方式下的口径偏差率。人工填报的偏差率在 15% 到 22% 之间，系统自动采集低于 3%，自动化采集加定期抽样校验可以压到 5% 以内。

所以我的建议是：凡是系统能采集的字段，绝不允许人工填写。人工只负责判断类字段，比如风险等级、优先级、验收结论。

七、不同情况下的行动建议

方法讲清楚后，落地时要看组织规模和管理成熟度。我给四类典型情况分别给出建议。

1. 情况一：50 人以下团队，没有专职 PMO

这个阶段不要建体系。你唯一要做的是把“完成”的定义统一，然后固定一张 8 行的周表，只记录五件事：本周里程碑、关键路径任务状态、阻塞项、下两周风险、需要谁做决定。

工具用现成的任务看板就够了，不要采购重平台。每周花 30 分钟过一遍，重点是阻塞项和不决策项，不要做燃尽图，没人看。

2. 情况二：100 到 500 人，有 1 到 3 人 PMO

这个阶段的重点是口径字典和基线治理。先选定 8 到 12 个核心指标，写清七要素，然后用一个季度的时间把基线变更流程跑通。

这一阶段最容易犯的错是指标数量膨胀。我建议给自己设一个硬约束：每新增一个指标，必须删掉一个旧指标，直到指标总数稳定在 15 个以内。

3. 情况三：500 人以上，PMO 具备治理职能

这个阶段必须做三件事：建立三层看板、上线分级预警机制、把行动项闭环率纳入 PMO 自己的考核指标。

同时要考虑系统化承载能力。当项目数量超过 30 个、跨部门依赖超过 200 条时，靠 Excel 维护依赖关系会迅速失效。这时候评估像 PingCode 这类支持私有化部署、能覆盖需求到发布全链路的平台是合理的，特别是当组织还有 Jira 迁移或国产化替代需求时，迁移方案和平滑度会成为选型的关键权重。

4. 情况四：多项目资源冲突严重

这类组织的第一步不是优化进度，而是做资源可视化。先把每个人的项目投入比例算清楚，找出累计负荷超过 130% 的人员，然后做资源再平衡。

我通常建议采用“资源承诺制”：项目立项时必须明确承诺投入的人数和比例，超出组织总人力的立项申请不予通过。没有资源承诺的项目，进度计划从一开始就不可信。

八、不同情况下的取舍

进度跟踪没有最优解，只有取舍。下面是我认为最需要提前想清楚的五组权衡。

1. 取舍一：数据精度与采集成本

如果你要求所有任务每天更新剩余工时，采集成本会高到无法持续，而且数据质量会迅速下降，因为人们在应付填报。我的建议是按任务粒度分层：关键路径任务每日更新，普通任务每周更新，非关键任务只在状态变更时更新。

2. 取舍二：指标数量与决策效率

指标不是越多越全面，而是越多越模糊。取舍的判断标准是：这个指标能不能对应一个具体的决策动作。对应不上，就砍掉。

3. 取舍三：预警灵敏度与警报疲劳

预警设得过敏感，红灯遍地，所有人都会开始忽略。我在实践中会定期统计红灯数量，如果某个季度红灯项目占比超过 20%，就说明阈值过严，需要回调。

健康的分布大致是：绿灯 60%，70%，黄灯 20%，30%，橙灯 5%，10%，红灯低于 5%。

4. 取舍四：集中管控与团队自主

集中管控能保证口径统一，但会拖慢响应速度。我的做法是“口径集中、执行分散”：指标定义、基线变更规则、预警阈值由 PMO 统一制定；任务怎么拆、迭代怎么排、日常怎么跟踪，交给团队自主。

5. 取舍五：自建与采购

自建的优点是贴合度高，缺点是需要持续的研发和维护投入，而且很容易在两年后变成一个没人维护的黑盒。采购的优点是成熟度高、迭代快，缺点是个性化需求响应慢。

我的判断线是：如果团队没有 3 人以上的持续投入能力，不要自建。同时，如果有私有化部署或数据合规要求，选型时要把这一点放在功能之前评估，因为它是一票否决项。

九、30/60/90 天落地路线

如果你打算开始做这件事，下面的节奏是我验证过比较稳的版本。它可以按组织规模压缩或延长，但顺序不建议打乱。

1. 第 1 到 30 天：统一口径和模板

这个阶段只做三件事：确定 8 到 12 个核心指标的七要素口径、冻结一次基线、推行统一的周报模板。

不要在这个阶段买工具、不要做看板、不要开新的会议。先让所有人对“什么叫完成”“什么叫逾期”形成一致理解。

2. 第 31 到 60 天：跑通采集、分析和预警

这个阶段的重点是让数据流动起来。把数据源接入，跑通偏差分析，建立三级预警规则，并开始记录每周产生的行动项数量。

这一阶段会出现大量口径争议，这是正常的。每次争议都是一次口径细化机会，记下来，更新字典版本。前两个月口径字典从 v1.0 迭代到 v1.3 是健康状态，停在 v1.0 说明没人认真用。

3. 第 61 到 90 天：形成会议决策和复盘机制

最后阶段把会议机制固定下来，同时开始统计行动项闭环率。如果第 90 天时这个数字低于 60%，需要回头检查是什么环节断了：是行动项没有验收标准，还是升级路径没有执行。

到第 90 天，你应该能回答一个问题：过去三周，有多少条决策是因为进度分析做出的？如果答不上来，说明机制还没真正跑起来。

十、常见问题速答

1. 数据不准怎么办，是清理数据还是换工具？

先判断不准的根因。如果是口径不一致，改工具没有用，必须先写口径字典。如果是采集方式问题，把人工填报字段尽量换成系统自动采集。只有确认这两项都做完了，数据仍然散乱不可整合，才考虑工具层面的事情。

2. 跨部门不配合，拿不到数据怎么办？

这通常不是态度问题，是收益问题。让对方看到数据能帮他们减少被追问、减少返工，配合度会明显改善。另外，如果组织有立项和验收流程，把“按时提供进度数据”写进立项评审条件，比反复沟通有效得多。

3. 周报要写多长？

我建议一页。好周报的标准不是信息全，而是能让读者在 3 分钟内找出一件需要他做的事。信息全但不指向行动，是另一种形式的信息缺失。

4. 项目数量多，PMO 人手不够怎么办？

不要靠加人解决。先把指标压缩到 10 个以内，再按风险分层管理：红灯项目每周深度跟进，橙灯项目双周跟进，绿灯项目只在月度看板里体现。80% 的 PMO 精力应该放在 20% 的高风险项目上。

5. 已有的历史数据能从旧工具迁移过来吗？

这取决于工具。如果组织正在评估国产替代方案，务必把历史数据迁移能力作为重要权重。选择像 PingCode 这类支持从 Jira 平滑迁移的平台，可以保留工作项、字段映射和历史评论，让趋势分析有连续基线；同时它支持私有化部署，适合对数据合规有明确要求的中大型企业。但要注意，迁移前必须先完成字段映射设计，否则迁过来的数据仍然不可用。

十一、结尾：从下周一开始的三件事

回到开头那个延期 92 天的项目。复盘到最后，我们得出的结论不是“周报要写得更细”，而是“周报里的每一个数字都必须能被验证，每一个异常都必须对应一个决定”。

这就是我对进度跟踪最核心的判断：它是一次数据治理和决策机制的联合工程，而不是一项报表工作。数据只是原料，判断是 PMO 的核心能力，行动才是最终产出。

如果你只打算做一件事，就从自测开始。下面五个问题，答不上来三个以上的，说明你的进度跟踪机制还停在采集层。

1. 你们组织里“任务完成”和“里程碑完成”的定义是否明确且一致？
2. 当前基线是什么版本，从启动到现在变更过几次？
3. 过去一个月，有几条决策是因为进度分析做出的？
4. 预警触发后，谁在多少小时内必须响应？
5. 上一周产生的行动项，闭环率是多少？

下一步的三件事，我建议按这个顺序做：第一，召集项目负责人用一小时把核心指标的七要素口径写出来，哪怕只写三个指标；第二，找出最近一个延期项目，用四种偏差视角重新分析一遍，看看当时是不是能更早发现；第三，把下周的周会输出改成行动项清单，六个字段一个都不能少。

做完这三件事，你会得到两个东西：一份真正能用的口径定义，和一批能验证的数据。进度跟踪的全流程，就从这里开始。