项目延期从来不是突然发生的，是周例会上一周一周攒出来的

项目周期 12 个月，最危险的往往不是哪天出了大事，是周例会上每周都有人说：「这周有点问题，下周追回来。」

追着追着，一个节点就过去了。

我们有一个项目就是这样差点延期，最后把周点检改成日点检，才把节点救回来。这篇讲：风险清单盯什么，进度盯哪三个节点，延期了先做哪两件事。

一、项目风险清单：最常见的是两类

风险清单要覆盖各个方面，但实际最常出事的是两类：

• 进度风险：需求蔓延，越做越多；人员资源不足，人手跟不上；业务管理方不管事，该拍板的不拍、该派人的不派
• 成本风险：需求变更，做好的要改；实际要求偏离了蓝图设计，当初签的和现在要的不是一回事

这两类风险，根子常常是同一个：需求。 需求没管住，进度会拖，成本也会涨。所以前面几篇反复说，标准和需求要在立项、蓝图阶段写清楚、签下来。

二、项目进度只盯三个节点，上线推进表按六层拆

项目一般走六段：立项、蓝图设计、系统实现、上线准备、上线试运行、验收。上线试运行还可以分两期，先上业务模式，再上自动化。

进度表上我只盯三个节点：蓝图设计、功能实现、上线试用。 这三个都是交接点：蓝图要签字，功能要交给测试，上线要交给现场。过了就很难回头，所以要在节点前就看出能不能按时到。

快到上线时，事情会一下子变多，我们用一张上线推进表来管，按六层拆：

• 数据层：PFEP 表、开仓初始数据、库存地对应、历史库存盘点
• 计划层：生产订单什么时候切到新系统
• 人员层：内部仓储人员、外部物流人员的操作培训
• 供应商层：教供应商在系统里备货、打单、发货，物料贴码
• 系统层：MES、SRM、QMS 这些周边系统同步上线
• 硬件层：网络接入，打印机、手持终端联调

每一条都有责任人和日期，进展和状态写清楚，周例会就照着这张表过。

表要配着沟通节奏用。我们是这样排的：

• 每天：项目小组碰一次，汇总当天的实施问题
• 每周：周例会，过周工作总结、遗留问题、下周计划和资源协调
• 按需：专题会，围绕一个问题讨论到底；阶段汇报，向领导和管理委员会汇报成果
• 每周或每月：邮件通报，让不参会的人也知道进度

怎么提前看出要延期？看推进表：同一条连续两周状态没变，就是信号。

三、项目延期了：先书面预警，再改节奏

看出要延期，第一件事是书面预警：写下来，升级给业务方的主要领导，让他知道。这不只是汇报，也是把风险和责任摆在明面上。口头说过一声，出了事等于没说。

第二件事是改节奏。我们那次是这么救回来的：

• 周点检改成日点检：问题当天暴露、当天处理，不再攒一周
• 集中报工：大家集中起来，每天把进度报一遍
• 增加资源：缺人的地方补人
• 领导督战：领导到现场盯

最后把节点救了回来。

---

延期预警，你们是口头说一声，还是发书面的？