关键路径实操方法：管理层提升任务依赖效率的落地方案方法与模板

去年Q4的一次项目复盘会上，一位事业部总经理问我一个问题：“这个新品导入项目原计划11月15日交付，为什么拖到12月初？中间哪一步卡住了？”在场的项目经理翻了两页甘特图，说“主要是认证环节延误”，采购负责人说“样品到货晚了三天”，研发负责人说“我们评估耽误了一周”。每个人说的都对，但拼在一起，没有一个答案能解释那多出来的17天。真正的原因其实很简单：这个项目的关键路径在中途换了两次，而管理层直到延期发生后才第一次听说这件事。

这不是个别现象。在我参与过或近距离观察过的几十个中大型组织项目里，延期很少是因为没人算关键路径，而是因为算了之后没人跟着它变化调整决策。关键路径从来不是一道计算题，它是一张告诉管理层“钱、人、时间该往哪压”的决策地图。这篇文章不讲ES、EF、LS、LF怎么算，那些是项目经理的基本功；我讲的是管理层怎么用关键路径做决策、怎么把任务依赖从“沟通问题”变成“管理动作”，以及可以直接复制走的3张表和1套会议流程。

一、先给结论：管理层的关键路径，是一张资源决策地图

在我服务过的组织里，管理层对关键路径的理解通常分成两派。一派认为它是项目经理的活，自己看结果就行；另一派认为它很重要，但每次都停留在“要重视关键路径”这种口号层面。两派的共同结果是：关键路径在项目里真实存在，却没有进入管理层的决策链条。

1. 管理层不需要会算，但必须会问三个问题

关键路径的本质，是项目网络图里最长的那条依赖链，它决定了项目理论上的最短工期。这个定义本身没有争议，争议在于管理层拿它做什么。

我的判断是：管理层不需要自己画网络图，但必须在任何一次项目汇报中问出三个问题。第一，当前的关键路径是哪几件事，和上周相比变了没有？第二，这条路径上有没有任务已经开始有延误迹象，谁负责，还剩多少缓冲？第三，如果要保住交付日，需要我现在做什么决策，是加人、调优先级，还是改范围？

这三个问题有一个共同特征：它们都不需要计算能力，但都需要管理层手里的资源调配权和跨部门协调权。这正是关键路径在管理层手里的价值所在。

2. 任务依赖效率，才是关键路径的真正瓶颈

很多人把关键路径管理的重点放在“找出最长链”，但我认为真正的管理杠杆在依赖关系上。任务本身的执行时间往往可以通过加班、并行、外包来压缩，但依赖关系是组织结构的映射，压缩难度高一个量级。

一个研发任务自己拖两天，项目经理催一催就能补救。但如果这个任务是“等采购确认物料规格”，而采购在等研发出图纸、研发在等市场确认客户需求，这条链上的每一个“等”都涉及不同的部门、不同的KPI、不同的汇报线。这时候关键路径已经不是技术问题，是组织协同问题。

所以我给管理层的第一条判断是：把注意力从“哪个任务工期长”转到“哪个依赖最不可控”。工期长的任务通常可预测，依赖链条上的交接点才是失效率最高的地方。

3. 一句话总结我的核心立场

关键路径管理的成熟度，不体现在网络图画得多漂亮，而体现在关键路径发生变化时，管理层多久知道、多久做出资源调整。如果这个时间超过一周，那么再精细的排期表也只是事后记录。

二、三个真实场景：关键路径为什么在管理层视野里消失了

下面三个场景是我在不同组织里反复见到的，它们分别代表了三类典型失效。我把它们写出来不是为了归类，而是为了让你对照自己的组织判断“我更像哪一类”。

1. 场景一：复盘会上，没人说得清卡在哪

第一个场景就是文章开头那次复盘会。项目延期17天，四个部门给出了四个解释，每个解释都只能覆盖2-3天。真正的原因是：项目在第5周和第9周各发生过一次关键路径转移，第一次是因为认证机构的排期意外延后，第二次是因为核心芯片到货延迟。

问题不在于这些意外本身，而在于每一次路径转移都没有触发管理动作。项目经理自己知道，但没有一个正式的渠道把这个信息传到能做决策的层级；管理层看到的始终是“整体进度完成72%”这类汇总数字，而汇总数字恰恰会掩盖路径转移。

2. 场景二：进度是绿灯，关键路径已经全红

第二个场景更隐蔽。某项目整体进度看板显示绿灯，因为80%的任务按时推进。但剩下的20%里，有三项正好全在关键路径上，而且浮动时间已经归零。

这就是“平均主义汇报”的陷阱：用完成率代表健康度，而完成率对关键路径完全不敏感。90%的任务按时完成，如果那10%全在关键路径上，项目照样延期。

我给管理层的建议很直接：不要再只看完成率这个指标，要看“关键路径上的任务完成率”和“关键路径浮动时间余额”这两个指标。前者反映执行，后者反映风险余量。

3. 场景三：资源被“更重要的事”抽走，而抽走的人不知道自己在关键路径上

第三个场景最伤。某次中层协调会上，另一个项目的负责人临时借走了两名测试工程师，理由是“他们那个项目还早”。事实上那两名工程师手上的任务正处在关键路径上，浮动时间只有1天。

结果是一周后，整个项目链条后移6天。这不是执行问题，而是信息问题：管理层的资源决策没有接入关键路径数据。资源调配这个动作本身没有错，错在决策时缺少“这个人是否在关键路径上”的判断依据。

三、四个常见误区，几乎每个管理层都踩过

在讲落地方案之前，我需要先清理几个高频误区。这些误区之所以顽固，是因为它们在表面上都像是“负责任的管理动作”。

1. 误区一：把关键路径当成一次性计算结果

很多组织在项目启动时认真做了一次关键路径分析，然后就把它当作一个静态结论使用到项目结束。这在依赖关系稳定的项目里勉强可行，但在研发、新品导入、系统迁移这类项目中几乎必然失效。

我的判断是：关键路径的变化频率，本身就是项目健康度的一个指标。一个十周的项目，如果关键路径一次都没变，可能说明你的依赖登记太粗；如果变了七八次都没人跟踪，说明流程缺失。合理的区间通常是每两周到三周识别到一次路径波动，并有一次正式的同步。

2. 误区二：把所有依赖当成同等重要

很多依赖登记表的通病是“登记了但不分级”。结果是项目经理每天要盯几十条依赖，精力被平均分配，真正危险的那三四条反而没有得到额外关注。

依赖必须有等级，等级由它是否在关键路径上、以及浮动时间余额决定。不在关键路径上、浮动时间大于5天的依赖，可以交给执行层自行协调；在关键路径上、浮动时间小于2天的依赖，必须进入管理层视野。

3. 误区三：只看浮动时间为零的任务，忽略“浮动时间被悄悄吃掉”

浮动时间归零是结果，不是过程。等到某个任务的浮动时间归零，通常已经晚了，因为它的缓冲在被消耗的过程中没有任何预警。

我更推荐看的是浮动时间的消耗速率。一个任务原本有5天浮动，一周后变成3天，再一周后变成1天，这个下降曲线比“现在浮动为0”有价值得多。它给了管理层两到三周的干预窗口。

4. 误区四：模板做得很漂亮，用一次就丢

我见过太多精美的项目管理模板，第一周填得满满当当，第三周开始空一半，第六周彻底没人更新。模板失败的原因几乎从来不是设计不好看，而是填写成本高于它带来的收益。

所以我在设计模板时的原则是：能用一行字段解决的，绝不用两行；能自动带出的，绝不让手工填。一张需要10分钟才能填完的依赖登记表，在真实项目里活不过一个月；一张3分钟能填完、且能直接拿去做周会依据的表，才有可能活下来。

四、专业判断逻辑：依赖效率的四层拆解

讲完误区，我需要给出我实际使用的判断框架。这个框架把“任务依赖效率”拆成四层，从最表层的依赖类型一直拆到依赖冲突的处理原则，每一层对应不同的管理动作。

1. 第一层：依赖类型决定管理动作，而不是决定网络图

教科书会告诉你依赖有四种类型：完成-开始、开始-开始、完成-完成、开始-完成。但管理层真正需要知道的是：不同依赖类型，对应的是完全不同的风险结构和管理动作。

我在实践中发现，中大型组织的项目里，FS占比通常最高，但出问题最多的往往是被忽略的SS。因为SS型依赖看起来“反正可以并行”，实际上它把两个任务的资源需求压在同一时间窗口，一旦人力不足就会同时卡住。

2. 第二层：跨部门依赖为什么最容易变成隐形关键路径

部门内部的依赖有共同的上级、共同的考核口径、共同的沟通习惯，协调成本低。跨部门依赖则同时缺少这三样东西。

更关键的是，跨部门依赖在项目网络图上的工期往往被填成一个“经验值”，比如“采购到货7天”。这个7天既不是供应商承诺，也不是历史统计，只是项目经理的估计。当关键路径经过这类估计值时，整条路径的可信度就已经打折了。

我的处理原则是：跨部门依赖不使用经验值，必须使用承诺值，且承诺值要落到具体人。“采购部”不是责任主体，“采购部张三，承诺10月18日前提供物料规格确认书”才是。这一个改动，能显著提升关键路径的可信度。

3. 第三层：浮动时间是授权工具，不是计算产物

这是我在这篇文章里最想强调的一个观点。浮动时间不只是判断任务紧急程度的指标，它还是管理层向下授权的分级依据。

具体做法是：把浮动时间分成三档，对应三种管理权限。浮动时间大于5天的任务，项目经理可自行调整顺序和资源，不必上报；浮动时间2到5天的任务，需要项目经理每周报备变化；浮动时间小于2天或在关键路径上的任务，任何调整都必须经过管理层。

这样做的好处是双向的。管理层从“每天盯几十件事”变成“只盯几件事”，项目经理获得了明确的自主空间，同时关键路径上的动作依然受控。这比一句“大家要重视关键路径”有用得多。

4. 第四层：依赖冲突的三种类型，处理原则完全不同

依赖冲突不是一种问题，我把它分成三类，因为它们的处理路径差别很大。

第一类是资源型冲突，两个任务都要用同一个稀缺资源，比如同一位架构师、同一台测试设备。这类冲突的解法是排序，而不是协调。管理层需要明确说“谁先谁后”，而不是让两个部门自己去谈。

第二类是时序型冲突，A的交付日比B的需求日还晚。这类冲突的解法是拆解，把A拆成“最小可用版本”和“完整版本”，先交付前者保证B能启动。

第三类是信息型冲突，双方对需求、标准、验收口径的理解不一致。这类冲突最容易被误判成执行力问题，实际上它的解法是固化接口物，把“沟通”变成“交付一份具体的文件或数据”。

五、一个真实感案例：100人以上组织的跨部门依赖治理

下面这个案例来自我参与过的一次咨询式陪跑。为保护商业信息，公司名和具体产品做了模糊处理，数据是按真实口径整理的观察值。

1. 项目背景与初期状态

这是一家硬件+软件一体化的公司，规模在300人左右，正在做一个新产品导入项目，涉及研发、采购、供应链、品质、市场、认证六个部门，计划周期14周。

项目启动时，项目经理用表格做了一份排期，依赖关系用箭头标在甘特图上。问题在第四周暴露：认证环节的样品寄送延误了5天，导致认证测试整体后移，而认证正好在关键路径上。

但更麻烦的是，没有人及时发现这件事。样品寄送由供应链负责，认证由品质负责，双方各自认为对方知道延误，直到第五周周会上才被发现。此时关键路径上的可用缓冲已经从4天降到0天。

2. 我们改了三件事

第一，建立依赖登记表，并强制要求“承诺人+承诺日期+接口物”三要素齐全。缺任何一个要素的依赖，不允许进入排期表。这个规则一上来就暴露了问题：最初登记的63条跨部门依赖里，有27条缺少明确的承诺日期或接口物。

第二，把关键路径的状态从甘特图里抽出来，做成独立的一页看板。用红黄绿三色标记，红色代表已经影响或即将影响关键路径，黄色代表浮动时间小于2天，绿色代表正常。管理层只看这一页，不再看完整甘特图。

第三，把周检会压缩到15分钟，且固定在每周一早上。会议只讨论红色项和路径变化，不讨论具体技术方案。

3. 数据观察

项目后10周的数据变化是这样的：跨部门依赖从提出到闭环的平均时间，从治理前的6.5天降到2.1天；关键路径的识别与同步周期，从原来平均9天一次缩短到3天一次；因为依赖交接不清导致的返工，从治理前每月7次降到每月2次。

最终这个项目比原计划晚了3天交付，而公司内部同类项目的历史平均延期是11天。需要说明的是，这些数据来自单一项目的观察，不能直接外推为普遍规律，但它至少说明：依赖治理的投入回报是可见的。

4. 工具层面的取舍：什么时候该从表格升级到平台

这个项目前四周用的是表格工具，第四周之后我们把它迁到了一个项目管理平台上。迁移的触发点不是“表格不好用”，而是一个很具体的信号：当依赖数量超过50条、涉及部门超过4个时，表格里的依赖关系已经无法反向查询。

也就是说，你想知道“如果张三这周请病假，会影响哪些下游任务”，在表格里需要人工翻查十几分钟，而在支持依赖图和关键路径自动计算的平台里，这是一个点击动作。这个查询能力的差别，才是升级的真正理由。

最终这个团队选择了 PingCode。原因是它在依赖关系管理和关键路径计算上是原生支持的，任务之间的前后置关系可以直接在界面上连，浮动时间能自动算出并预警。另外它支持私有化部署，这家公司有数据不出内网的要求；同时它支持从其他主流项目管理工具平滑迁移，导入历史任务和依赖关系不需要重建。

PingCode 主要服务中大型企业及100人以上的组织，这一点和这家300人规模、六个部门协同的场景是匹配的。但我要强调一个判断：工具解决的是“依赖关系可见、可查、可预警”的问题，它不解决“部门之间愿不愿意承诺”的问题。登记表的规则和升级机制必须先行，否则平台只是把混乱搬到了一个更漂亮的地方。

六、落地方案：管理层可执行的4步法

下面这四步是我实际用过、并且验证过能在一到两周内落地的方案。每一步我都会写清楚动作、负责人和输出物，你可以直接对照执行。

1. 第一步：依赖梳理，用一张登记表摸清家底

这一步的核心不是把依赖全部登记完，而是先把跨部门依赖登记完。部门内部的依赖可以交给项目经理处理，跨部门依赖必须上表。

1. 由项目经理列出所有跨部门交接点，每个交接点登记为一条依赖。
2. 每条依赖必须填写三要素：承诺人（具体到人）、承诺日期（具体到天）、接口物（具体到一份文件、一批物料或一次验收）。
3. 三要素不全的依赖，不进入排期表，直接标为“待确认”，并在周会上作为红色项处理。
4. 登记完成后，由项目经理做一次初步排序，标注哪些依赖在关键路径上。

这一步的产出是一张跨部门依赖登记表，时间成本通常在2到3小时，是整件事里投入产出比最高的一步。

2. 第二步：关键路径识别，用红黄绿三色快速判断

管理层不需要看完整网络图，需要看的是颜色。我给的做法是给每条关键路径上的任务打一个颜色标签。

• 红色：已经影响关键路径，或浮动时间已经归零。必须在24小时内给出处理动作。
• 黄色：浮动时间小于2天，或承诺日期在本周内。需要在本周周会上确认。
• 绿色：浮动时间大于2天，且承诺日期未临近。管理层不介入。

这个标记法的关键是只看颜色数量，不看任务名称。管理层要问的问题变成“这周有几个红的”，答案如果是0，会议可以三分钟结束；如果是3个，逐个过。

3. 第三步：资源决策，把资源优先给关键路径上的任务

这是管理层真正需要出手的一步。我建议在做资源调配决策时，加一条硬规则：任何从关键路径任务上抽调人力的决定，必须经过提出调配的那一方和管理层双重确认。

这条规则听上去很重，但它解决的是最常见的伤害源，未经确认的资源抽调。同时，为了保证规则不僵化，还要配套一条反向规则：如果关键路径上的任务确实可以延后且不影响交付日，管理层应主动释放资源，而不是机械地保护。

也就是说，资源决策的判断依据不是“这个任务重不重要”，而是“这个任务的浮动时间允不允许它等”。

4. 第四步：动态复盘，每周15分钟的关键路径检查会

最后一步是让整套机制活下来。我建议的会议形式是每周一次、固定15分钟、固定议程、只谈颜色和变化。

会议的三条纪律很重要：不讲技术方案，不讲历史原因，不追责。只回答三个问题：哪些变红了？路径有没有变？需要管理层做什么决定？

这三条纪律是让会议能持续开下去的关键。一旦会议变成技术讨论或责任追究，它很快就会变成没人愿意参加的负担。

七、模板包：3张表+1套会议流程

下面给出的模板都是文字结构，可以直接复制到表格工具或项目管理平台里使用。我特意去掉了所有装饰性字段，只保留能被实际使用的部分。

1. 模板1：跨部门依赖登记表

这张表最容易被省略的是最后两列：阻塞原因和升级路径。但恰恰是这两列，把“依赖管理”从记录变成了机制。

2. 模板2：关键路径状态看板

这张看板的行数应该控制在15行以内。如果关键路径上的任务超过15项，说明你的项目拆分粒度太细，或者关键路径识别做得太粗，两种情况都需要先调整再上会。

3. 模板3：一页纸关键路径汇报模板

这份模板是给管理层向上汇报或向团队传达用的，全部内容压缩在一页纸内，结构如下。

【项目名称】
【汇报周期】 第 X 周

项目健康度
关键路径任务完成率：__%

关键路径浮动时间总余额：__天

状态灯统计：红 __ 项 / 黄 __ 项 / 绿 __ 项

关键路径是否发生变化
是 / 否

若变化，变化原因：________

新增关键路径任务：________

需要管理层决策的事项（最多3条）

________（决策截止时间：__）
________（决策截止时间：__）
________（决策截止时间：__）
下周主要风险
风险1：________ 应对动作：________

风险2：________ 应对动作：________

本月已关闭的依赖
共 __ 条，其中延期关闭 __ 条，平均闭环 __ 天

这份模板的硬约束是“决策事项最多3条”。如果列了10条需要管理层决策的事项，说明这个项目的问题已经超出了关键路径管理的范畴，需要单独开专题会。

4. 会议流程：关键路径周检会标准议程（15分钟）

这套议程我用了很久，最大的价值在于“过颜色”和“承诺复述”这两个环节。前者让会议在2分钟内就能判断今天是否需要展开讨论，后者让每个人的承诺被公开记录，减少事后扯皮。

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

上面的方案是通用框架，实际落地时需要按组织情况调整。我按三种常见情况给出建议。

1. 情况一：项目少于3个、团队规模50人以下

这种情况我不建议上任何平台工具，也不建议建立复杂的依赖治理机制。用一张跨部门依赖登记表加每周15分钟站会就够了。

这个规模下，跨部门沟通主要靠面对面或群消息，协调成本本来就低。过度流程化反而会增加负担。真正需要做的只有一件事：把三要素（承诺人、承诺日期、接口物）这件事坚持下来。

2. 情况二：多项目并行、组织规模100人以上

这是依赖治理价值最大的场景，也是问题最集中的场景。我的建议是分两步走。第一步先在单个重点项目上跑通四步法，第二步再考虑平台化。

原因很简单：多项目并行时，真正的难题不是单项目内的依赖，而是项目之间的资源争抢。而资源争抢的解法不是一个工具，而是一个跨项目的资源评审机制。工具只是把这个机制变得可见。

在这个阶段，如果你的组织有数据不出内网的要求，或者正在考虑从其他项目管理工具迁移，那么支持私有化部署和依赖关系原生建模的平台会明显降低落地阻力。PingCode 在这类场景下比较合适，它主要服务100人以上的中大型组织，支持私有化部署，也支持从主流项目管理工具平滑迁移。但请记住，工具是第二步，机制是第一步。

3. 情况三：外部供应商多、跨组织依赖占比高

这种情况下的关键是把外部依赖变成有合同或书面确认的承诺。供应商的“尽快”“下周”不是承诺，只有写进采购订单或邮件确认的日期才是。

同时建议为外部依赖单独设置更长的浮动时间，或者准备替代方案。在我的经验里，外部依赖的准时率明显低于内部依赖，如果按内部标准给它留缓冲，几乎必然爆掉。

九、不同情况下的取舍

任何方法都有代价。下面三组取舍是我认为管理层必须提前想清楚的，否则落地到一半会遇到阻力。

1. 取舍一：表格的灵活 vs 平台的约束

表格的优势是自由，字段随便加，格式随便改，学习成本为零。劣势是无法做依赖关系的反向查询和自动预警。平台的优劣正好相反。

我的判断标准是看两个数字：跨部门依赖条数和涉及部门数量。依赖条数在50条以下、部门在3个以内，表格完全够用。一旦超过这个阈值，表格带来的查询成本会超过平台的学习成本。

另外还有一个容易被忽略的因素：数据合规要求。如果组织要求项目数据不出内网，那么是否支持私有化部署会成为硬性筛选条件，这一点在中大型企业和特定行业里经常直接决定选型结果。

2. 取舍二：精细度 vs 维护成本

任务拆得越细，关键路径越精确，但维护成本也越高。我的经验阈值是：单个项目的依赖登记条数控制在40到80条之间。

低于40条，可能遗漏了重要的跨部门交接点；高于80条，项目经理会花大量时间在维护表格上，而不是在解决问题上。如果确实需要更细的粒度，应该把项目拆成两个子项目分别管理，而不是在一张表里堆到200条。

3. 取舍三：强制机制 vs 自主授权

很多人担心引入关键路径管理会变成“什么都要审批”。实际情况恰恰相反，如果按浮动时间做好授权分级，管理层介入的任务比例可以控制在20%以内。

也就是说，这套机制本质上是一次放权：把80%的非关键任务完全交给执行层，换来对20%关键任务的强控制。如果你发现引入机制后审批反而变多了，那一定是授权分级没有做，而不是机制本身的问题。

十、常见问题与避坑指南

下面是我在被问得最多的几个问题，每个问题都附上我的实际判断。

1. 关键路径中途变了怎么办？

先判断变化原因，再决定动作。如果是外部约束导致的变化，比如供应商延期、审批延迟，动作是重新评估交付日并提前告知相关方；如果是内部资源导致的变化，动作是立即调整资源分配。

两种情况都不应该做的是：假装没变，继续按原计划汇报进度。这会直接导致我在第二个场景里描述的情况，进度是绿灯，关键路径已经全红。

2. 多个项目并行时怎么处理？

不要试图给每个项目都做完整的关键路径管理。先做一次跨项目的资源冲突排查，找出哪些人同时出现在多个项目的关键路径上，这些人就是真正的瓶颈。

然后对这些瓶颈资源做跨项目排期，明确每个项目占用他的时间段。这一步做完，再回到单项目做关键路径管理，效率会高很多。

3. 跨部门不配合、承诺日期随便填怎么办？

这是一个机制问题，不是态度问题。解法是让承诺日期具备后果：把“承诺准时率”纳入部门季度回顾的一个观察指标，不需要做考核，只需要被看见。

我在实践中观察到，仅仅是每周在管理层周会上公开一次各部门的承诺准时率，两三个月内就能显著改善随意承诺的情况。因为没有人愿意在一个公开列表里长期排在最后。

4. 表格工具够不够，什么时候需要专业平台？

三个信号出现任何一个，就说明该升级了。第一，依赖条数持续超过50条；第二，涉及部门超过4个；第三，管理层开始频繁问“如果某人这周不在，会影响哪些任务”，而这个问题每次都需要人工翻查才能回答。

第三个信号是最直接的。它说明你需要的已经不是记录能力，而是依赖关系的即时查询和预警能力。这也是为什么在规模较大的组织里，支持依赖图原生建模和关键路径自动计算的平台会比表格有明显优势。

5. 关键路径管理会不会让团队变得僵化？

如果执行得当，结果正好相反。关键路径管理的目的是把注意力集中到少数真正决定交付日的任务上，从而让其他任务获得更大的自由度。

只有当它被误用成“所有任务都要走审批”时，才会僵化。避免的方式就是前面反复强调的授权分级：浮动时间大于5天的任务，项目经理完全自主。

结语：关键路径不是项目经理的专属，是管理层的决策地图

回到文章开头那个问题：一个项目延期17天，为什么没人说得清卡在哪？答案不是团队能力不足，也不是工具落后，而是关键路径这个信息从来没有被翻译成管理层的决策语言。

我在这篇文章里想传递的最核心的一个观点是：关键路径管理的成败，不取决于你算得多准，而取决于路径变化时管理层多久知道、多久调整资源。而要做到这一点，需要的不是更复杂的公式，而是三张表、一套15分钟的会议流程，以及一条清晰的授权分级规则。

如果你现在就想开始，我建议的下一步只有三个动作，而且可以在本周内完成。

1. 本周内，让项目经理列出当前所有跨部门依赖，按三要素补齐。缺承诺人、缺承诺日期、缺接口物的，全部标红，作为下一次周会的必过项。
2. 下周的周会上，只过红黄绿三色，不看完整甘特图。先试一次，看看会议时间能不能压到15分钟以内。
3. 一个月内，把“浮动时间大于5天由项目经理自主决定”这条授权规则正式说清楚。这一步决定这套机制能不能长期活下去。

关键路径不会自动帮你把项目做完，它只是把“哪些事不能等”这个问题，变成一个所有人都看得见的答案。而当这个答案能被管理层每周看见一次时，延期这件事，就已经从意外变成了可以被管理的过程。