项目总是延期交付，PMP里的进度和风险管理怎么真正用起来？

项目延期几乎是所有项目经理绕不开的痛。更让人郁闷的是，很多团队并不懒，每天都在加班，可交付日期还是一推再推。问题通常不在努力程度，而在四件事没管住：任务拆得不够细、估算太乐观、依赖关系没理清、变更来者不拒。PMP考纲里过程领域占了半壁江山，讲的正是这套处理顺序，可惜不少人考完就把它们留在了证书里。

一、进度计划的颗粒度决定成败

很多人做计划，就是把需求文档里的模块名抄成一行行任务，然后拍个时间。这种计划做完基本没法跟踪，因为一个任务横跨三周，中间到底有没有进展，从计划表上完全看不出来。

合理的做法是把工作分解到能估准的粒度。经验值是单个任务控制在两到五天，最长不超过一周。到了这个颗粒度，你才能回答"这周完成了多少"这类问题，也才有依据判断要不要调整。同时把里程碑单独标出来——里程碑是给领导和干系人看的进度锚点，不是给你自己排活用的。

二、估算偏乐观是可以被修正的

人的直觉估算天生偏乐观，越是自己熟悉的活越容易估少。PMP里的三点估算给了一个简单可用的修正办法：分别问团队最乐观、最可能、最悲观三种情况下的工期，再按（乐观 + 4×最可能 + 悲观）÷ 6 算出期望值。

举个例子。一个接口联调，乐观估计2天，最可能3天，悲观情况要8天（对方系统文档缺失、测试环境排队）。代入公式：（2 + 4×3 + 8）÷ 6 ≈ 3.67天。这个数字未必精确，但它比拍脑袋的3天更接近真相。更重要的是，在讨论三种情况的过程中，团队会自然把"为什么会拖到8天"的理由讲出来，这些理由本身就是风险清单的原料。

另外，计划里要留缓冲，但不要平均撒在每个任务上。把缓冲集中放在关键交接点前后，谁卡住谁用，比每个任务都留10%更有效，也更容易向领导解释。

三、依赖关系和关键路径不能靠感觉

延期的第二大成因是等。A等B交文档，B等C确认口径，C在等外部供应商报价。如果计划里只有任务和日期，这些等待关系全部隐形，一旦出事就是连锁反应，而且事后复盘时往往已经来不及。

做法并不复杂：把任务之间的依赖关系明确写出来，找出最长的那条链，重点盯它。同时识别"别人都在等的那个人"——通常是某个技术负责人或者外部审批方。他一个人卡住，整个项目都慢。对这类节点，要么提前预支时间，要么增加并行度，要么直接找他的上级推动。盯关键节点，比盯所有人的每日工时有用得多。

四、风险管理的重点在动作，不在清单

很多项目的风险登记册写完就锁进抽屉里，等到出事才想起来有这份文件。PMP对风险管理的要求其实很朴素：识别、评估概率与影响、制定应对、指定责任人、定期复查，一步都不神秘。

真正让它有用的是把风险写成"如果……就……"的触发式预案。比如"如果外部接口在第三周还没提供测试环境，就先用数据桩完成前端联调"。这样写清楚之后，风险真正发生时团队不需要开会讨论，直接执行即可。责任人也必须落到某个具体的人头上，写"项目组"等于没人负责。

节奏上，建议每周例会上花十分钟只讨论排在前三位、且影响最大的风险。不要贪多，把最可能发生、影响最大的三个盯住，比列三十条无人跟进的条目有价值得多。

五、变更管理要落到"换时间"上

需求变更是延期的头号推手。客户加需求的时候，如果只回答一句"好，我们加班做"，延期其实已经注定了。

走变更流程不是走形式，它真正的价值是让所有人看清代价：这个需求加进来，哪项任务要顺延、哪个里程碑要动、需要增加多少人天。把影响评估摆出来之后，再把选择权交还给提需求的人——要么砍掉别的需求，要么延后交付时间，要么增加资源，三者选一。多数情况下，对方会自己放弃不那么重要的那一个。

六、明天就能做的三件事

如果你手上正有一个延期风险很高的项目，可以立刻做这三件事：把当前计划里超过一周粒度的任务全部拆细；找出三个决定性节点，逐一确认它们的依赖方和承诺时间；在下一次与客户或领导沟通时，把最近一次变更的代价明确说出来。

PMP的知识体系不是用来应付考试的，它的真正用处是在项目乱成一团的时候，给你一套有顺序的处理方法。证书是入场券，这套方法才是你能带走、能反复使用的东西。