很多项目看起来管理得非常精细：几十甚至上百个Task，每周更新状态，红黄绿标得清清楚楚，会议一个接一个。但项目最后还是延期。问题往往不是团队不努力，而是管理者没有识别Critical Path。一个项目有100项任务，并不意味着100项任务对最终交付日期同等重要。有些任务晚一周，最终Milestone完全不受影响；另一些任务只晚两天，整个项目就必须晚两天。真正决定项目最早完成时间的那串依赖关系，就是Critical Path。

Critical Path Method（CPM）的逻辑其实很简单。先把项目拆成Activities，为每项任务估算Duration，再明确Dependencies：哪些任务必须等前面的任务完成才能开始。接着进行Forward Pass，计算Earliest Start和Earliest Finish；再从最终交付日期反向进行Backward Pass，计算Latest Start和Latest Finish。两者之间的差就是Float。Float越小，任务对最终时间线越敏感；Float为0的一系列任务，通常构成Critical Path。

真正重要的不是把公式算出来，而是它改变了资源配置方式。假设项目原计划13周完成，现在管理层要求11周交付。最常见的做法是要求所有团队“提速”，结果每个人都更忙，项目却未必提前。因为如果被加速的工作不在Critical Path上，即使从4周压缩到2周，最终交付日期也可能一天不变。更有效的方法，是找到真正控制13周周期的任务，通过增加资源、Fast Tracking或Crashing，把关键环节各压缩1周。

这背后其实是一种很重要的管理思维：不要平均管理所有事情，而要管理Constraint。项目经理看到某个任务延期，第一反应不应该只是把状态改成红色，而应该追问：它有多少Float？是否位于Critical Path？会不会影响下一个Milestone？如果影响，能否通过资源调整、并行工作或改变Dependency把时间追回来？同样一个“延期5天”，在不同任务上的管理意义可能完全不同。