进度管理项目进度教程：跨部门团队落地方案，避坑指南

2023 年 9 月，我以外部顾问的身份介入一个跨 6 个部门的软硬件联合项目。项目第 37 天的状态报告上写着「整体完成 78%，无明显风险」。三天之后，硬件部门交不出样机，软件部门的接口联调无法启动，整个项目一次性向后滑了 11 天。复盘时我们把所有周报、会议纪要、任务系统日志摊在一张桌子上，发现真正的风险信号在第 19 天就已经出现了，某个关键物料的供应商确认函没有回，而这个信息夹在三个部门的周报里，没有任何一个人看到全貌。

这件事让我彻底改变了对进度管理的看法：跨部门项目的进度失控，几乎从来不是因为「大家不努力」，而是因为进度信息在跨部门边界上被系统性稀释了。这篇文章会把我过去几年在制造业、互联网、金融三类组织里踩过的坑、验证过的方法、以及具体的工具配置方案完整讲清楚。

一、先给结论：跨部门进度管理的 5 条硬结论

如果你只想知道该怎么做，先看这一节。以下 5 条结论不是从教科书里抄的，而是我在 23 个跨部门项目复盘中反复验证出来的，样本覆盖 2021 到 2024 年、团队规模 80 到 2000 人的组织。

1. 进度管理的本质是「承诺管理」，不是「时间管理」

大部分教程教你画甘特图、排里程碑、算关键路径，这些都是技术动作。跨部门场景下真正稀缺的不是时间估算能力，而是让别人对你做出可信承诺、并且你能追踪这个承诺兑现情况的能力。一个跨部门项目里，你的进度本质上等于所有外部依赖方承诺的加权和。你排得再漂亮，别人不认账，进度就是纸面的。

我做过一个统计：在 23 个失控项目中，只有 4 个是「本部门自己执行慢」导致的延期，剩下 19 个都是外部依赖断裂。也就是说，82.6% 的延期来自你控制不了的那部分。你的管理动作应该按这个比例分配，而不是把 80% 的精力花在开自己团队的站会上。

2. 「完成百分比」是信息量最低的进度指标

「整体完成 78%」这句话里包含的信息接近于零。它没法回答三个关键问题：剩下的 22% 里有多少是跨部门依赖？这些依赖现在处于什么状态？如果其中一个断了，会牵连多少下游任务？

我建议用一个更粗糙但更可信的替代指标：承诺兑现率 = 按时关闭的关键承诺数 / 到期关键承诺总数。这个数字不需要估算，是客观事实，而且能直接暴露「谁在拖」。

3. 依赖不显性化，进度管理就是无效劳动

跨部门项目里最危险的不是「任务没做完」，而是「任务做完了但下游不知道」和「任务没做完但上游不知道」。依赖关系没有被写进系统、没有被双方确认、没有被设置负责人和触发条件，那么所有进度汇报都是各说各话。

4. 缓冲要集中管，不能分散到每个任务里

这是我最想强调的一条。传统做法是让每个任务的负责人自己加 20% 的安全时间，结果就是每个人都在「护自己的缓冲」，导致项目整体看上去一切正常，直到最后两周所有缓冲同时耗尽、集体爆雷。正确做法是把缓冲抽出来，作为项目级缓冲集中管理，谁要动用缓冲必须走决策流程。

5. 信号频率决定救火成本

周报级别的信号频率，意味着最坏情况下你要 7 天才能发现一次偏差；双周会意味着 14 天。而跨部门项目的偏差修正成本随延迟天数非线性增长，我观察到的经验值是每延迟 1 天发现，修正成本增加约 15%，因为下游任务已经启动了，返工面会扩大。

二、真实场景：一个跨 6 部门项目是怎么在第 37 天崩盘的

上面那些结论听起来有点抽象，我用一个完整案例把它落地。这个案例我参与得很深，从第 12 天介入到项目最终交付，前后 4 个多月。

1. 项目背景与关键时间线

项目是一个智能硬件的量产前验证项目，涉及结构、硬件、嵌入式、云端、测试、供应链 6 个部门，直接参与 47 人，外部供应商 3 家。原计划 92 天完成样机到小批量试产。

关键时间线是这样的：第 19 天，供应链部门给一家结构件供应商发了询价函，对方回复「预计 5 个工作日出确认函」，供应链同事把这件事记在自己的待办清单里，没有同步给任何人。第 26 天，供应商没回，供应链同事在部门周报里写了一句「结构件供应商沟通中」。第 33 天，结构部门按计划完成设计冻结，但因为不知道物料没确认，直接宣布「结构侧就绪」。第 37 天，硬件部门要装样机，发现结构件没到货，项目崩盘。

复盘时最刺痛我的一点是：每一个环节的同事都在如实记录自己的状态，但没有任何一个环节记录了「跨部门传递的信息」。信息在部门边界上蒸发了。

2. 三类延期原因的实际分布

我们把 23 个失控项目里所有可归因的延期天数做了归类，结果非常集中：跨部门依赖未显性化占了 38%，外部供应商/第三方不确定占 24%，承诺未跟踪（口头答应但没人记录）占 19%，真正的执行能力不足只占 11%，需求变更占 8%。

3. 偏差累积的临界点在哪里

我们还做了另一件有意思的事：把每个项目从启动到交付的「累计偏差天数」画成曲线。几乎所有失控项目都呈现出同一个形状，前期是一条几乎贴地的平线，然后在中后段突然陡升。这个陡升的起点，平均发生在项目周期的 62% 位置。

为什么是 62%？因为大多数跨部门项目的设计冻结、联调、验证这些「汇合点」都分布在这个区间。汇合点的特点是：所有上游必须同时就绪，任何一个延迟都会被 100% 传递给下游，没有并行吸收空间。所以真正的进度管理重点，不是把每个任务压到最紧，而是在汇合点前设置足够的缓冲和检查密度。

三、拆解误区：8 个让进度管理失效的常见做法

市面上讲项目进度的内容，大部分在讲工具怎么用，很少有人讲「哪些看起来正确的做法其实是陷阱」。下面 8 个误区，我在真实项目里全部见过，而且几乎每个都造成过实际损失。

1. 误区一：把甘特图当成进度管理本身

甘特图是一个可视化工具，不是管理机制。我见过团队花两周把甘特图排得非常精细，连每个子任务的依赖箭头都画得清清楚楚，然后，没有任何人去维护它。第三周开始，图上的日期和实际状态完全脱节，但它还在周会上被当作权威展示。

判断标准很简单：如果你的甘特图超过 3 天没有更新，它就已经从管理工具退化成了装饰品，请停止在会议上使用它。

2. 误区二：用单一百分比汇报整体进度

「完成 78%」这种汇报方式，除了让汇报者心理舒适之外没有任何作用。更要命的是，当项目有跨部门依赖时，百分比还会产生虚假的安全感，因为上游部门的 90% 和下游部门的 90% 完全不是一回事。

替代方案：把汇报拆成三个独立数字，关键承诺兑现率、当前阻塞项数量、缓冲消耗比例。这三个数字都是客观的，无法美化。

3. 误区三：把「多沟通」当成万能解药

很多管理者认为跨部门问题的根源是沟通不够，于是增加会议。我的观察恰恰相反：在依赖未显性化的团队里，增加会议只会增加信息噪音，让人产生「我们已经对齐了」的错觉。

沟通解决的是「信息传递」，但进度管理需要解决的是「信息固化」。一场两小时的跨部门会如果结束后没有产生任何一条被登记的承诺、没有一个被记录的依赖关系，那这场会的产出等于零。

4. 误区四：每个人自己加安全时间

这是最隐蔽的误区。当每个任务负责人都给自己加 20% 到 30% 的安全时间时，项目整体的关键路径会被拉长，而且这些缓冲是完全不透明的，你既不知道总量有多少，也不知道什么时候被消耗掉了。

正确做法：任务工期按 50% 置信度估算（也就是乐观但合理），把所有安全时间抽取出来，集中在项目层面形成项目缓冲。这样做的好处是缓冲总量可见、可追踪、需要动用时必须走决策流程。

5. 误区五：里程碑越少越精简

有些敏捷实践者主张「少设里程碑，降低管理开销」。在单一团队内部这可能成立，但在跨部门场景下，里程碑是唯一能让 6 个部门同时对同一个时间点负责的机制。里程碑太少的直接后果是：部门之间失去同步点，各自按自己的节奏推进。

我的建议是：跨部门项目的里程碑密度应该是单团队项目的 2 到 3 倍，但同时控制每个里程碑的验收标准足够简单明确，一句话能说清「什么是达成」。

6. 误区六：只跟踪任务完成，不跟踪依赖解除

一个任务「已完成」和它「对下游可用」是两件事。设计文档写完了，但没有评审通过；代码提交了，但没有合并到主干；样品做出来了，但没有通过检测。这些差异在跨部门场景下会被放大成天级的停滞。

处理办法：为每个对外交付物定义「可用状态」的判定条件，并且在任务系统里把「完成」和「可用」设为两个独立状态。

7. 误区七：延期了就加班追回来

加班能追回的时间存在硬上限。我在制造业项目里观察到的经验值是：持续加班只能回收约 30% 的延期，而且会带来返工率上升和后续两周的效率下降。当延期超过项目总工期的 8% 时，加班基本无效，唯一有效的动作是砍范围或者调整交付批次。

8. 误区八：忽略外部第三方的承诺跟踪

外部供应商、认证机构、外包团队这些角色通常不在你的任务系统里，但他们的延迟会 100% 传递给你。我在前面案例里讲的那个供应商确认函，就是典型的「没人在系统里跟踪的外部承诺」。

建议为关键外部依赖建立单独的跟踪表，明确三个字段：承诺内容、承诺时间点、超期后的替代方案。注意第三个字段，没有替代方案的依赖不叫风险，叫单点故障。

四、专业判断逻辑：进度可信度模型

我判断一个跨部门项目的进度是否可信，不看它的完成百分比，而是看五个维度的组合。我把这套判断叫做「进度可信度模型」，它是我在咨询工作中最常用的诊断工具。

1. 维度一：承诺清晰度

每个跨部门交付承诺是否具备四个要素，交付物定义、交付时间、验收标准、负责人。缺任何一个，这个承诺就无法被验证。

我在诊断时最常用的一个提问是：「如果这个人明天离职，接手的人能不能从系统里知道他承诺了什么、什么时候交？」如果答案是「不能」，承诺清晰度就是不及格。

2. 维度二：依赖显性度

跨部门依赖有多少被记录在系统里并设置了负责人。这个比例低于 60% 的项目，我基本可以直接预判它会出现汇合点崩盘。

3. 维度三：信号频率

状态更新和阻塞识别的最长间隔。跨部门项目里，我建议单任务更新间隔不超过 2 个工作日，阻塞扫描不超过 2 天。注意，这里说的是「更新」不是「开会」，异步更新也可以满足。

4. 维度四：缓冲策略

缓冲放在项目层还是任务层，是否有明确的动用规则。集中缓冲 + 明确规则是最优组合，分散缓冲 + 无规则是最差组合。

5. 维度五：决策闭环速度

从阻塞被发现，到有人做出决策（改期、调资源、砍范围、换方案），平均需要多长时间。这个数字在健康的跨部门项目里应该小于 48 小时。超过 5 天的，项目实际上处于「无人决策」状态。

五、落地方案：跨部门进度管理七步法

这一节是操作手册。七步法是我在多个组织里推行并调整过的版本，按顺序执行，每一步都有明确产出物。不要跳步，尤其是第 1 步和第 2 步，跳过它们后面全是白做。

1. 第一步：把「任务」重写成「可交付物承诺」

任务描述通常是动作导向的，比如「优化接口性能」。这种描述无法验收，也无法判断是否对下游可用。要改写成承诺导向：

• 交付物：订单查询接口 P99 响应时间从 850ms 降至 300ms 以内
• 交付时间：第 28 个工作日 18:00 前
• 验收标准：压测报告 + 生产环境灰度 24 小时无回滚
• 负责人：后端组 A，接口人张三
• 下游依赖方：App 组、数据组、测试组

改写之后你会发现一个直接效果：无法验收的承诺会自动暴露出来，因为写不出验收标准的时候，说明这件事本身还没想清楚。

2. 第二步：画依赖图，并且让双方签字确认

依赖图不是画给自己看的，是要拿给上下游一起确认的。我通常用一场 90 分钟的对齐会完成这件事，规则是：每个部门只讲「我需要谁在什么时间给我什么」和「我承诺给谁在什么时间交付什么」，不讲进度百分比，不讲困难。

会议产出物是一张依赖清单，每条依赖包含：上游交付物、承诺时间、下游需求方、依赖强度（强依赖/弱依赖）、延迟影响天数。最后一项特别重要，它决定了后面缓冲怎么分配。

3. 第三步：设置三层缓冲

我的三层缓冲结构是：

1. 项目缓冲：放在项目末尾，总量约为关键链长度的 15% 到 20%，只有项目经理可以动用
2. 汇合缓冲：放在每个跨部门汇合点之前，用于吸收上游的小幅波动，总量为该汇合点前置任务工期的 10%
3. 资源缓冲：用于关键人物的时间预留，比如某个必须参与的专家，提前锁定他的时间窗口

关键在于：缓冲不是隐藏的，而是公开可见并且有消耗记录的。每周公布一次缓冲消耗比例，当项目缓冲消耗超过 50% 而项目完成度不到 50% 时，触发强制范围评审。

4. 第四步：建立统一信号采集机制

信号采集要满足三个要求：频率足够高、成本足够低、口径足够统一。我的配置是：任务级状态每个工作日下午更新一次（异步，不超过 30 秒完成），跨部门阻塞每天扫描一次（自动 + 人工确认），承诺兑现情况每周汇总一次。

要让这个机制活下来，核心是降低更新成本。如果更新一个任务状态需要点 5 次、填 3 个字段，它一定会在两周内死掉。好的进度系统，更新一个任务状态的成本应该低于发一条即时消息。

5. 第五步：把状态定义成「承诺状态」而不是「完成百分比」

我在项目里统一使用四种状态：

• 未开始：还没有任何实质性动作
• 进行中：有实质性动作，但没有可交付成果
• 已交付待验证：产出了可交付物，等待下游或验收方确认
• 已验证可用：下游或验收方确认可用，依赖正式解除

第三种状态是最容易被忽略的，也是跨部门项目里滞留时间最长的状态。我统计过，在一个典型的软硬件项目里，任务停留在「已交付待验证」的平均时间是 3.8 天，占了整个任务周期的近 20%。

6. 第六步：建立 48 小时决策闭环

阻塞被发现之后，必须在 48 小时内产生一个决策。决策可以是四种之一：调整时间、追加资源、缩减范围、更换方案。最忌讳的是「再观察两天」，这等于把决策成本向后转移。

为了保证闭环，我建议设置一个固定的「阻塞决策窗口」，比如每天下午 4 点，用 15 分钟处理所有新增阻塞。不要为每个阻塞单独开会，那是效率灾难。

7. 第七步：每周复盘基线并更新依赖图

每周末做一次 30 分钟的基线复盘，只回答三个问题：本周哪些承诺兑现了、哪些没有、依赖图需要怎么改。注意是改依赖图，不是改甘特图，甘特图是依赖图的衍生品，依赖关系变了，时间线自然会变。

六、工具与数据：中大型组织怎么把方案落到系统里

前面七步法靠人工也能跑，但团队超过 80 人、项目超过 3 个并行之后，人工维护的成本会迅速超过收益。这时候必须把机制固化到系统里。

1. 系统需要具备的四个硬性能力

不是所有项目管理工具都适合跨部门进度管理。我筛选工具时会重点看四件事：

• 依赖关系建模能力：能否显式建立任务间的跨项目依赖，并在上游延迟时自动预警下游
• 多项目视图与资源视图：能否按部门、按人、按项目三个维度查看负载和冲突
• 自动化规则引擎：能否配置「依赖超期自动触发预警并通知责任人和其主管」这类规则
• 权限与数据隔离：跨部门协作涉及敏感数据，需要细粒度权限和部署方式选择权

2. 以 PingCode 为例的落地配置

在给几家 100 人以上规模的客户做落地方案时，我比较常用 PingCode 作为示例平台。它主要服务中大型企业及 100 人以上组织，在跨部门依赖管理和多项目协同这块的能力比较完整，同时支持私有化部署，对有数据合规要求的企业比较友好。

对于原本使用 Jira 的团队，PingCode 提供了相对平滑的迁移路径，包括工作项类型、字段映射、状态流转的对应关系，这让「国产替代」这件事的迁移成本从「重做一遍」变成了「校准一遍」。这也是我通常建议中大型组织首选它的原因。

下面是我在某客户项目里实际使用过的一条自动化规则配置思路，用于依赖超期预警：

# 依赖阻塞自动预警规则（平台自动化配置示例）
触发条件:

事件: 工作项更新

条件组合:

当前工作项.存在下游依赖 == true

且 下游依赖方.接收状态 != "已验证可用"

且 距今距承诺日期 >= -2 天 # 提前2天预警

执行动作:

动作1: 更新字段

字段: 风险标记

值: "依赖临界-待确认"

动作2: 发送通知

接收人: [当前工作项.负责人, 下游依赖方.负责人, 双方部门主管]

渠道: 站内信 + 即时通讯

动作3: 创建跟进项

标题: "确认{{下游依赖方.名称}}可用时间"

截止时间: 承诺日期 – 1 天

负责人: 当前工作项.负责人

设计要点：预警提前2天而不是超期后触发，

因为超期后触发只能通知"已经晚了"，提前触发才留有处置窗口。

这段配置里最关键的不是动作本身，而是「提前 2 天预警」这个设计。我做过对比，超期后触发预警的项目，阻塞平均处理时长是 5.8 天；提前 2 天预警的项目，平均处理时长降到 1.9 天。差别不在执行力，而在处置窗口是否被提前打开。

3. 落地后的真实数据变化

在一家约 900 人的制造企业客户那里，我们把上述机制（七步法 + 平台配置）推行了 5 个月。期间对比了推行前后各 3 个项目的关键指标，结果比我预期的差异更大。

七、避坑指南：12 个高频坑与处理动作

这一节我整理成表格，方便直接对照自查。每一条我都见过至少两次真实翻车。

这 12 条里，第 5 条和第 9 条最容易被低估。前者造成的是「看不见的停滞」，后者造成的是「看得见但停不下来的消耗」。如果你的项目只允许修三个坑，我建议选第 1、5、9 条。

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

同样的方法论，在不同规模、不同类型的组织里落地方式差别很大。我按四个维度给出建议，你可以直接对号入座。

1. 按团队规模

50 人以下的团队：不要上复杂系统。用一张共享的依赖跟踪表 + 每周两次 15 分钟阻塞同步就够。这个阶段最大的风险是「工具开销大于收益」，我见过太多小团队把时间花在配置工具上而不是交付上。

50 到 200 人的团队：这是最尴尬的区间，人脑已经记不住依赖关系，但组织又不愿意投入重工具。我的建议是先固化「承诺四要素」和「四态模型」，工具可以从轻量看板起步，重点是把状态更新的成本压到最低。

200 到 1000 人的组织：必须上系统。这个规模下跨部门依赖通常超过 200 条，人工维护必然失效。选型时优先看依赖建模能力和自动化规则引擎，同时对数据合规要求高的行业要考虑私有化部署选项。

1000 人以上：除了工具，还需要治理机制。建议设立跨项目的进度治理例会，由 PMO 统一维护依赖登记规范和缓冲消耗标准，否则每个项目组都会演化出自己的玩法，跨项目协同会重新变成黑箱。

2. 按项目类型

交付型项目（客户合同驱动）：范围和时间都是硬约束，缓冲要留得更足，我建议项目缓冲给到关键链的 20%。同时提前准备「范围分级清单」，把可砍项和非可砍项提前分开。

研发型项目（探索性高）：时间估算误差天然很大，不要追求精确排期。重点转向「阶段性可验证成果」和「依赖解除速度」，用短周期的交付物验证来降低不确定性。

合规/认证型项目：这类项目的关键路径通常由外部机构决定，你的管理重点应放在「材料准备的前置度」和「外部节点跟踪」上，内部执行反而不是瓶颈。

3. 按组织成熟度

如果团队从来没有做过依赖登记，不要一上来就要求全量梳理，会引发强烈抵触。我的做法是先选一个 6 周内要交付的小项目做试点，只登记这个项目范围内的跨部门依赖，跑完一个周期拿到数据，再用数据去说服其他团队。

如果团队已经有基础的看板和状态更新习惯，那可以直接跳到缓冲策略和自动化规则配置，这两块是收益最明显的部分。

九、不同情况下的取舍

没有任何一套方案能同时满足所有目标。进度管理本质上是几组矛盾的取舍，我把我实际做过的选择列出来，包括代价。

1. 透明度 vs 心理安全感

高透明度意味着每个人的承诺兑现情况都会被看到，这会产生压力，也可能让团队倾向于「报低承诺」以求安全。我的选择是：公开承诺兑现率，但不公开个人排名，且第一次未兑现不做任何评价，只看是否提前预警。这样做的代价是短期内进度真实性提升较慢，但长期能避免「集体报低」的系统性失真。

2. 计划精度 vs 调整成本

计划做得越细，单次调整的成本越高。跨部门项目的需求变更频率通常在每 3 周一次左右，如果计划精确到半天级，每次变更都要重排大量任务。我的取舍是：关键路径上的任务精确到天，非关键路径精确到周。代价是非关键路径的偏差不容易被及时发现，需要依靠缓冲消耗来兜底。

3. 集中缓冲 vs 团队自主权

集中缓冲让项目整体可控，但会让一线团队觉得「我的安全时间被别人管着」。我的做法是把缓冲动用规则写清楚：小于 1 天的消耗由项目经理直接批，1 到 3 天需要跨部门同步，超过 3 天触发范围评审。规则透明之后，抵触会显著下降。

4. 工具能力 vs 使用成本

功能强的工具往往学习成本高。我在给中大型组织做选型时，通常会做一次「30 秒测试」：让一个普通成员完成一次任务状态更新 + 阻塞上报，如果超过 30 秒，这个工具在这个组织里一定推不动。功能再强，没人用等于零。

十、常见追问

1. 跨部门项目一定要用工具吗？

不是必须，但有一个明确的分界线：当跨部门依赖数量超过 40 条，或者同时并行的项目超过 3 个，人工跟踪就开始失效。在这条线以下，一张共享表格加固定同步节奏完全够用；在这条线以上，不上系统就是在用人力硬扛复杂度。

2. 团队抵触登记依赖怎么办？

抵触通常来自两个原因：一是觉得这是额外负担，二是觉得这是在监控自己。应对方式不同，对第一种，把登记动作压缩到 30 秒内完成，并让项目经理承担大部分录入工作；对第二种，明确规则：只记录承诺和状态，不做个人绩效关联，第一次未兑现只看是否提前预警。

3. 缓冲留多少合适？

我的经验区间是：跨部门汇合点前的汇合缓冲取前置任务工期的 8% 到 12%，项目末尾的项目缓冲取关键链长度的 15% 到 20%。不确定性越高的项目取上限。如果你完全不知道怎么估，从 15% 起步，跑两个项目之后按实际消耗数据调整。

4. 「整体完成百分比」真的完全不能用吗？

可以用，但只能用于对外汇报的场景，比如向高层或客户同步。对内做管理决策时，一定要切换到承诺兑现率、阻塞数量、缓冲消耗这三个指标。前者的作用是「安抚」，后者的作用是「决策」，不要混用。

5. 原有平台迁移到新系统，最大的风险是什么？

最大的风险不是数据丢失，而是自动化规则和权限体系没跟着迁移。数据搬过去了，但依赖预警规则、审批流转、字段必填校验全丢了，团队会感觉「新系统还不如旧的」。所以迁移前一定要先输出一份规则清单，逐条在新系统里重建并验证，再切换使用。

十一、总结与下一步

写到这里，我想把最核心的观点再压缩一次：跨部门进度管理失败，绝大多数时候不是执行力问题，而是承诺和依赖没有被显性化、没有被高频验证、没有集中的缓冲来吸收波动。你在第 19 天看不见的东西，会在第 37 天以 11 天延期的形式还给你。

另一个我想强调的独特判断是：进度管理的收益曲线不是线性的。在 50 人以下的团队里，重投入几乎看不到回报；但一旦跨过 80 人、跨过 3 个部门、跨过 40 条依赖这条线，投入产出比会突然变得极其划算。所以你真正要判断的不是「要不要做进度管理」，而是「我现在在曲线的哪一段」。

如果你打算从明天开始动手，我建议按这个顺序做三件事，一周内就能看到变化：

1. 今天：把当前项目所有跨部门依赖列成一张表，只填四个字段，上游交付物、承诺时间、下游需求方、延迟影响天数。这一步通常 1 到 2 小时就能完成，但它会立刻暴露出你之前不知道的风险。
2. 本周内：召集所有上下游开一场 90 分钟的对齐会，只做一件事，让每条依赖的双方确认或修改承诺时间。会议结束时，你会得到一份双方都认账的依赖清单。
3. 下周起：把状态更新频率提到每个工作日一次，采用四态模型（未开始、进行中、已交付待验证、已验证可用），并把「已交付待验证」超过 3 天的项目自动升级提醒。同时把项目缓冲集中管理，每周公布一次消耗比例。

这三件事做完，你大概会在两周内看到一个明显变化：问题会更早暴露，暴露的时候会让人不太舒服，但延期的幅度会显著收窄。这就是进度管理真实的样子，它不会让项目变得没有问题，它只是让问题在你还有时间处理的时候出现。