延期流程与规范：管理层延期管理协同管理关键指标

延期管理最危险的时刻，通常不是项目已经晚了两周，而是管理层第一次听到“可能延期”时，团队还没有统一口径：有人说只是测试缓冲，有人说关键依赖尚未到位，有人则已经在私下调整发布日期。延期流程的价值，不是让每个项目都按时，而是让风险尽早显形、让决策有据可依，并把延期造成的损失控制在可接受范围内。

一、先讲结论：延期管理不是审批日期，而是管理承诺与影响

1. 延期申请不等于延期管理

很多组织把延期流程理解成“项目负责人填表、上级批准、项目日期改掉”。这只能完成一次日期变更，不能回答管理层真正关心的问题：为什么会晚、晚多久、影响哪些承诺、有没有替代方案、需要谁做什么决策。

我建议把延期管理定义为一套闭环机制：识别偏差，判断影响，比较方案，明确决策，调整承诺，持续验证。流程不是为了追究谁犯错，而是为了让项目状态从“看起来还行”转变为“风险、代价、责任和下一步都可解释”。

一个成熟的流程至少要把三件事分开管理：预测日期、对外承诺日期、经管理层批准的基线日期。它们含义不同，混在一起，项目团队就容易通过反复改日期制造“按期完成”的假象。

2. 管理层要审批的是取舍，而不是借口

“开发工作比预期多”是原因描述，不是管理决策。有效的延期申请应把问题翻译成选择题：按原范围延期四周，还是保留发布日期、缩小首发范围；增加两名测试人员，还是接受部分质量风险；压缩内部验收，还是调整客户交付承诺。

管理层的责任不是替团队估算每个任务，而是明确资源优先级、跨部门依赖和风险容忍度。项目负责人的责任，则是提供可信事实、提出可执行选项，并在决策后更新计划和相关方预期。

3. 流程成效要看风险是否更早、更准、更可控

只看“延期项目占比”容易误导。一个组织可能通过把日期不断后移，把延期率做得很好看；也可能为了避免延期记录，直到交付前才暴露问题。比起单一结果指标，我更关注预警提前量、预测误差、延期后影响、决策周期和重复延期率。

核心判断：流程质量不是“审批通过率高不高”，而是管理层能否在损失扩大之前做出正确取舍。申请被批准不代表管理成功，申请被驳回也不必然代表管理失败；真正重要的是决定是否基于事实，执行后是否验证结果。

二、背景与真实场景：延期是项目系统的症状，不只是进度表上的红色标记

1. 典型场景：局部任务晚了，交付承诺却没有同步变化

设想一个跨部门产品项目：研发认为核心功能已完成，测试团队表示关键环境尚未就绪，业务团队仍按原日期安排客户验收，采购则预计某项外部组件晚到十天。每个团队都能解释自己的状态，但没有人掌握完整的交付链路。

如果此时只在任务表里把测试开始日往后挪，问题不会消失。测试压缩可能造成缺陷逃逸，客户验收可能需要重新预约，后续版本也可能被占用。延期不是一个日期变化，而是多个承诺之间的依赖关系发生变化。

在延期复盘中，我通常先把“任务进度”与“交付可用性”分开。任务完成百分比并不等于交付准备度：代码完成，不代表环境、数据、验收标准、培训材料和发布窗口都准备好了。管理层需要看的不是一条进度线，而是通往交付的关键路径是否仍然成立。

2. 为什么规模越大，延期越容易被低估

组织规模扩大后，项目依赖通常跨越研发、产品、运营、法务、采购、信息安全和外部供应商。一个团队的局部调整，可能改变其他团队的资源安排。复杂度并非简单等于团队数量，而是取决于依赖数量、交接次数和决策等待时间。

此外，组织里的信息通常分散在计划表、会议纪要、缺陷系统、邮件和个人判断中。负责人可能知道风险，但并未把它转成正式预测；管理者可能听到过风险，却不知道它已经影响对外承诺。流程设计的第一步，不是增加审批层级，而是建立共同的事实口径。

3. 先定义“延期”，避免不同团队各说各话

建议组织至少区分三类延期：任务延期是单项工作未按计划完成；里程碑延期是关键阶段日期发生变化；承诺延期则是对客户、监管、合同或经营目标造成影响。三者的严重程度、升级对象和沟通时限并不相同。

还要明确比较基准：延期是相对最初批准的基线，还是相对最近一次批准的变更基线？如果每次改期都覆盖原日期，组织就无法判断计划稳定性；如果所有预测日期都被当成正式承诺，也会使团队不敢诚实更新。

可操作的做法是保留三条时间线：原始基线用于审计和复盘，当前批准基线用于责任与承诺管理，最新预测用于日常决策。每次变更都记录原因、审批人、影响范围和新旧日期，不能只保存一个“最新日期”。

三、常见误区：看似规范的流程，为什么仍会制造坏消息

1. 误区一：只允许“确定延期”才能上报

很多团队习惯等到延期几乎不可避免时才提交申请，因为担心预测不准会被视为能力不足。结果是组织把“风险管理”做成了“事故登记”：等事实确定，能做的选择已经很少。

更好的规则是把状态分成风险预警、延期预测和正式变更。预警阶段允许存在不确定性，但必须说明触发条件、概率区间和复查日期；预测阶段需要给出最可能日期及依据；正式变更阶段才更新批准基线和外部承诺。

2. 误区二：审批层级越多，控制越严

层层签字并不自动带来更好的判断。若每个审批人看到的都是同一段原因说明，流程只是在排队；真正需要不同层级判断的，是决策权限和影响范围。

建议按影响分级：项目内部可吸收的任务偏差，由项目负责人处理；影响单一里程碑或跨团队资源的，由项目治理负责人协调；涉及客户承诺、合同节点、监管要求或重大经营目标的，升级至有权调整优先级的管理层。审批人要与风险相匹配，不宜所有延期一律上会。

3. 误区三：把“赶工”当作默认补救方案

加人、加班、并行开发都可能缩短日历时间，但会带来协调成本、缺陷风险和团队负荷。尤其在知识密集型工作中，新增人员需要熟悉上下文，短期未必能立刻增加有效产出。

每份延期申请都应至少比较三种方案：调整日期、调整范围、调整资源或交付方式。必要时可以采用分批上线、先交付高价值功能、推迟非关键能力等方案。“不延期”不是免费选项，它往往意味着范围、质量、成本或风险由某一方承担。

4. 误区四：延期获批后，只更新项目计划

延期批准后，常见遗漏包括客户未获通知、依赖项目未重排、资源仍按旧计划锁定、验收人员档期未调整。项目计划被更新，不代表组织承诺同步更新。

批准动作应触发一份变更清单：基线更新、相关方通知、依赖项目评估、资源计划调整、风险登记册更新、合同或合规审查，以及下一次预测复核。没有这些动作，延期只是表格上的日期变化。

5. 误区五：用延期原因分类代替根因分析

“需求变化”“资源不足”“技术问题”是分类，不是根因。需求变化可能来自需求冻结机制缺失，也可能来自客户法规变化；资源不足可能是临时请假，也可能是组织同时启动过多项目。

复盘时应把原因拆成可验证的因果链。例如：需求变更增加了哪些工作量，变更是谁提出的，为什么未在基线建立前澄清，影响了哪条关键路径，未来可以在哪个节点提前发现。若原因无法导向控制措施，分类再细也只是统计装饰。

四、专业判断逻辑：怎样判断延期是否成立、该由谁决策

1. 判断延期申请的五个维度

我会用五个维度审视申请：事实可信度、关键路径影响、承诺影响、替代方案质量、风险与收益的可接受性。五项不必机械打分，但必须逐项回答，否则管理层很难分辨这是经过分析的请求，还是压力下的日期修改。

2. 用关键路径而非任务数量判断影响

延期任务越多，不一定意味着交付一定延期；一个处于非关键路径的任务晚三天，可能完全可吸收。相反，一个仅有一项的外部依赖，如果位于关键路径且没有缓冲，就可能直接改变上线日期。

因此，延期分析应追问：受影响任务是否阻塞后续工作？可否调整顺序？剩余浮动时间是多少？是否存在并行验证或替代供应？关键路径判断要基于任务依赖，而不是负责人对“这个任务很重要”的主观描述。

组织若暂时没有成熟的网络计划工具，也可以先用简化依赖表管理：上游交付物、下游使用者、最迟需要日期、缓冲天数、责任人和升级条件。先把依赖显性化，再逐步提高计划精度，比一开始追求复杂模型更有效。

3. 区分风险概率、影响大小与紧迫程度

“很可能延期”不等于“必须马上升级”。风险判断至少包含发生概率、影响范围和距决策节点的时间。低概率但影响极大的合规风险，可能需要立即准备预案；高概率但可在团队内吸收的小偏差，则不必占用高层会议时间。

可以用风险矩阵做筛选，但不要把矩阵分值当作真相。评分适合帮助组织形成一致语言，不能替代定性判断。尤其是对客户信誉、法规要求、数据安全和不可逆发布窗口，需设置硬性升级条件，而不是任由平均分稀释严重风险。

4. 让决策权限跟影响范围匹配

小范围、可逆、无外部承诺的调整，可授权项目负责人快速处理；涉及多个团队资源的变更，由项目治理机制协调；影响经营目标或客户承诺的事项，应由能调整优先级、预算和外部沟通策略的管理者决策。

权限边界应写清楚：什么情况下项目负责人可以动用缓冲，什么情况下必须升级，谁批准基线变化，谁批准对外承诺变化。若“谁都能提、谁都不能定”，延期流程就会变成会议循环。

5. 预测日期要带置信度，而不是伪精确

项目团队常把“预计某月某日完成”说得非常精确，但如果依赖尚未确认、测试缺陷仍在快速增长，精确到某一天并不代表可靠。建议把预测日期与置信度、关键假设和更新时间一起呈现。

例如：“在外部接口本周五稳定、严重缺陷不再增加的前提下，预计三周后具备验收条件，当前置信度中等；若接口再晚一周，发布日期需重新评估。”这样的表达比单个日期更能支持管理决策。

五、具体案例与数据观察：把一份延期申请变成可决策的业务方案

1. 情景案例：原定上线日不变，关键验证时间被挤压

以下是用于说明方法的模拟案例，不代表特定企业的真实经营数据。某企业内部系统计划在八周内上线，涉及产品、研发、测试、信息安全和业务验收五个团队。距计划上线还有三周时，外部接口晚到八天，测试环境也比计划晚四天可用。

项目负责人最初提出“整体延期两周”。这句话无法直接支持决策：两周从哪里算起？是否所有功能都受影响？测试能否并行？业务验收窗口是否可调整？我会要求申请人先把问题拆成依赖、范围和影响，再给出可比较方案。

2. 申请材料应包含哪些内容

一份高质量延期申请不需要写成报告长文，但必须让未参与日常项目的人快速理解事实。核心字段包括原批准日期、当前预测日期、偏差首次出现时间、关键原因、影响链路、备选方案、资源需求、风险等级、对外影响、决策期限和建议选项。

• 事实与证据：列出已发生的偏差和可核验来源，区分事实、预测与假设。
• 影响链路：说明哪些任务、里程碑、客户承诺或下游项目受影响。
• 方案比较：至少比较延期、缩小范围、分阶段交付或资源调整等可行选项。
• 成本与风险：说明每种方案的时间、预算、质量、合规和信誉代价。
• 决策请求：明确需要谁在何时决定什么，不要只写“请领导支持”。
• 后续复核：列出新日期的关键假设、负责人和下一次检查点。

3. 三种方案对比：日期、范围与风险不能同时假装不变

在模拟案例中，项目组提出三种选择：方案甲是整体延期两周，保持范围并保留完整验证；方案乙是按原日期上线，但将低优先级报表和自动化能力放入后续版本；方案丙是增加测试资源并压缩部分验证窗口，争取少延迟一周。

从管理角度看，方案乙往往比“按原范围硬赶”更值得认真评估，但它成立的前提是范围可拆、客户能理解阶段交付、后续版本有明确负责人。方案丙并非必然错误，却必须证明新增资源真正进入关键路径，而不是只增加沟通负担。

最终选择应由业务价值和风险承受度决定，而不是由谁的声音最大决定。若核心业务在原日期具有不可替代的窗口，范围裁剪可能优于整体延期；若系统涉及高风险数据或不可逆迁移，保留验证时间可能比追赶日期更重要。

4. 数据观察：预测日期的稳定性比预测次数更重要

情景模拟中，项目组从计划开始到上线前共发布四次预测：第一次与原日期相差两天，第二次改为晚一周，第三次又推迟五天，第四次才形成两周延期方案。若只看最后一次预测，管理层会觉得问题突然出现；若保留每次预测及其依据，就能看见风险已经逐步恶化。

建议至少跟踪预测日期误差、预测变更次数、首次预警提前量和批准后再次延期率。注意，预测变更次数本身不是越少越好：合理地随新证据调整预测，优于为了稳定数字而不更新。真正需要关注的是变更是否有依据、是否及时、是否反复推翻此前判断。

5. 用决策日志补上“为什么这样决定”

延期获批后，建议保留一份简短决策日志：决策日期、参会角色、采纳方案、未采纳方案及原因、关键假设、责任人、复核时间。它不是为了增加文书，而是为了避免几周后团队只记得“管理层说过可以延期”，却没人记得当时有哪些条件。

复核时要问：关键假设是否仍成立？新增资源是否到位？缩小范围的清单是否落实？客户是否接受新窗口？若假设失效，是否需要再次升级？这样，审批才真正成为有条件的决策，而不是一次性盖章。

六、可执行流程：从第一次预警到变更落地

1. 第一步：设定触发规则，降低上报心理成本

流程应明确什么情况必须预警，而不是等负责人自行判断“严重不严重”。触发条件可包括关键路径缓冲耗尽、重要依赖晚于最迟需求日、关键缺陷数量连续上升、验收窗口无法锁定、供应商交付承诺失效等。

触发预警不代表项目已经失败，也不自动意味着必须改期。它只是启动事实核实和方案准备的信号。组织要明确：早报风险不会自动带来惩罚，隐瞒已知风险、反复报喜不报忧，才应纳入管理问责。

2. 第二步：用统一模板形成可核验的事实

模板要短而有约束。建议包含项目与里程碑、原始基线和当前批准基线、当前预测、风险发现日期、偏差事实、影响链路、根因假设、可选方案、请求决策、关联方和复核条件。

模板不应要求项目负责人填一堆无法验证的“完成百分比”。对于工作量判断，应附交付物清单、未完成项、缺陷趋势或依赖状态。对于预测，应说明关键前提，避免把估计包装成确定承诺。

3. 第三步：在升级前先做影响分析

项目团队需要先回答三个问题：哪些承诺会变？有哪些工作能够并行或裁剪？如果不调整，最可能发生什么？影响分析应覆盖内部资源、客户体验、合同条款、后续项目、质量安全和运营准备，而不仅是开发工作。

若影响跨越多个团队，应指定一名协调人统一收集信息，避免每个团队分别估算、口径不一。协调人不替代职能负责人作专业判断，但要确保重要依赖和冲突进入同一份决策材料。

4. 第四步：按权限矩阵做决策

决策会议应围绕选择展开，而不是逐人汇报状态。会议材料提前提供，会上确认未知项、方案差异、风险承担方和决策截止时间。能够在会上决定的，会议结束前明确负责人；无法决定的，要写清缺失信息、补充责任人和下一次决策时间。

审批可以采用分级处理：无外部影响、在授权缓冲内的调整，由项目负责人记录；影响跨团队但不改变经营承诺的，由治理负责人协调；影响客户、合同、合规或重大资源优先级的，由对应授权管理者决策。实际阈值应结合项目风险和组织制度设定。

5. 第五步：批准后同步更新所有承诺

批准延期后，先更新当前批准基线，同时保留原始基线；再更新里程碑、依赖计划、资源安排、验收窗口和相关方通知。若涉及客户或供应商，应由有权沟通的负责人统一说明，不能让多个团队各自发送不同版本。

新计划必须包含复核点和失败条件。例如：“接口在某日期前稳定，测试用例覆盖率达到约定门槛，才维持新上线日；若任一条件未满足，提前五个工作日重新评估。”这能避免新日期变成下一轮沉默等待的起点。

6. 第六步：复盘机制，而不是只复盘个人

延期结束后，复盘要检查计划假设、依赖管理、需求变更、资源冲突、决策延迟和预警行为。区分偶发事件与系统性原因：一次供应商突发故障可能难以避免，但若所有项目都低估供应周期，就属于计划机制问题。

改进措施必须可验证。比如“加强沟通”无法验收；“所有关键外部依赖在计划批准前确认交付人、最迟日期和升级联系人”则可以检查。每项措施应有负责人、完成时间和后续抽查方式。

七、关键指标体系：少而能行动，比多而无人负责更有效

1. 指标分层：领先指标、过程指标与结果指标

指标不宜全部围绕最终延期结果。领先指标用于提前发现风险，过程指标衡量流程是否有效运行，结果指标反映延期造成的影响。三类指标放在一起，才能避免只在项目结束后统计“晚了几天”。

2. 统一口径，才能让指标可比较

“延期项目数”必须明确统计单位：按项目、里程碑还是承诺事件？一个项目有十个里程碑，晚一个和晚十个不能随意合并。还要明确暂停、范围取消、客户主动改期和法规变化如何处理，否则不同部门的数据无法比较。

预测日期误差也要规定取哪一次预测。可以使用里程碑前某个固定检查点的预测，或者保留每次预测并分析误差分布。若只挑最接近实际的一次，数据会过度乐观；若总拿最早预测作比较，又可能忽略后续合理变更。

3. 不要把指标直接绑定个人惩罚

预警提前量、延期率等指标一旦直接决定个人绩效，团队可能通过不报风险、重置基线或缩小统计范围改善数字。指标应先用于发现流程薄弱点，再结合事实调查和职责边界判断责任。

对于团队绩效，建议关注可控行为：是否按规则及时预警，是否提供有证据的预测，是否完成已批准的措施，是否及时通知受影响方。不能把所有延期简单归咎于项目负责人，因为依赖、优先级和资源决策往往并不由其单独控制。

4. 建议从最小指标集开始

组织刚启动延期管理时，不必一次建立几十个指标。可以先选六项：预警提前量、预测日期误差、决策周期、关键依赖确认率、重复延期率和外部承诺影响率。连续收集两个到三个管理周期，再根据实际问题调整口径。

指标必须对应具体责任人和行动阈值。例如决策周期持续变长，检查审批权限和材料返工；重复延期率偏高，检查新基线是否有证据支撑；关键依赖确认率偏低，优先改善计划启动和跨团队承诺机制，而非要求项目团队“提高执行力”。

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

1. 项目尚未确定延期，但关键假设开始失效

此时不要急着修改基线，也不要等待结果彻底确定。先登记预警，明确假设、触发条件、负责人和复查日期；并行评估可替代依赖、可裁剪范围和资源冲突。如果风险涉及外部承诺，提前告知决策者风险状态，但避免把不成熟预测直接包装成正式改期通知。

取舍重点是信息透明与避免过度反应。太早宣布确定延期，会损伤计划可信度；太晚预警，则失去调整机会。用“可能性、影响、下一次确认时间”描述早期风险，比给出一个看似准确的日期更诚实。

2. 延期已基本确定，但影响范围可控

优先确认新日期是否有证据支撑，再选择项目内授权或治理层审批。评估是否有缓冲可吸收、是否可以调整内部顺序、是否需要同步更改相关里程碑。影响范围可控，不代表可以省略记录；历史基线仍应保留，以便后续分析预测质量。

取舍重点是流程速度与治理完整度。低风险变更可用快速授权，避免为小偏差召开高层会议；但若同一项目多次申请小幅改期，应该把它们合并审视，检查是否存在系统性低估，而不是每次都当成孤立事件。

3. 延期影响客户、合同或监管节点

立即建立跨部门工作组，统一事实口径和沟通责任。由业务、交付、法务或合规角色评估合同与监管影响，项目团队负责提供技术和进度证据。对外沟通要说明已确认事实、当前影响、正在采取的措施和下一次更新时间，不承诺尚未验证的新日期。

取舍重点是信誉、法律风险与交付可行性。组织可能倾向于先不通知客户，希望尽快追回进度；但如果客户的资源和验收窗口也需要调整，迟报会把内部延期变成合作关系问题。是否提前沟通应依合同和业务策略决定，不宜由项目负责人单独承担。

4. 延期源于范围膨胀或需求持续变化

建立明确的变更入口和影响评估，区分必须满足的要求、可延后能力和新增请求。每项变更都记录业务价值、开发成本、测试影响、依赖变化及批准人。若变更不能增加时间或资源，就必须明确减少其他范围或接受风险。

取舍重点是价值完整与日期稳定。冻结范围并不意味着拒绝一切变化，而是要求变化显式支付成本。对于法规、安全或重大客户问题，范围变化可能比守日期更优先；对于低价值体验优化，则适合排入后续版本。

5. 延期源于资源不足或多项目冲突

不要只向项目临时加人。先核实资源瓶颈是否位于关键路径、人员技能是否匹配、交接成本多大，再由有权者调整项目优先级。必要时暂停低优先级项目、释放共享专家或重新安排工作顺序。

取舍重点是局部最优与组织整体产能。把所有项目都标成最高优先级，最终会让关键资源不断切换，导致每个项目都慢。管理层应明确哪些目标可以推迟，不能把资源冲突包装成团队加班问题。

6. 项目已经多次延期

此时不应只审批下一次新日期。要求团队重新验证范围、工作量、依赖、资源和质量准备度，必要时邀请未直接参与原估算的专业人员做独立审查。对连续变动的预测，要检查计划是否基于不完整需求、乐观估算或未经确认的外部承诺。

取舍重点是快速恢复可控性与完整重估的时间成本。全面重估需要投入，但重复批准不可靠的日期，会持续侵蚀组织信任。若项目价值已变化，还应评估暂停、缩减或终止，而不是把“继续做”视为默认答案。

九、延期管理机制如何落地：从规则文本到日常动作

1. 先选一类项目试运行，不要一口气覆盖所有工作

建议先选择跨团队、里程碑清晰、对外承诺较明确的一类项目试点。试运行一个管理周期，观察预警触发是否可操作、模板是否过重、审批权限是否清晰、指标能否稳定获取。高成熟度团队和探索性研究项目的管理方式可能不同，不必强行统一成同一套表格。

试点阶段应邀请项目负责人、职能代表和管理层共同复盘流程体验。重点问：哪些字段没有帮助决策？哪些风险已经知道却没有升级？哪些审批本可授权？哪些批准后的动作无人负责？根据这些反馈改规则，比先发布厚重制度更有效。

2. 把规则嵌入现有工作流

延期申请若要求团队在多个系统重复录入，数据迟早会失真。尽量让预警、基线变更、依赖和决策记录与现有项目计划、工单或协作流程关联，减少重复维护。工具只是载体，关键是字段定义、权限边界、变更历史和提醒机制。

对中大型组织而言，某项目管理平台可以承担统一项目视图和变更记录的作用，但不要把采购工具当作流程建设的替代品。上线前先确定谁维护数据、哪些数据具有权威性、不同部门如何同步、旧系统如何迁移和核验。若涉及私有化部署或历史计划迁移，还要在试点中验证权限、审计记录、字段映射和数据完整性。

3. 让管理会议聚焦异常，不重复朗读状态

管理层例会不应逐个项目听完整进度汇报，而应围绕异常和决策展开：哪些关键假设失效、哪些新风险需要升级、哪些延期方案需要取舍、哪些批准措施尚未执行。没有需要决策或协调的项目，可以通过书面状态更新，减少会议时间消耗。

会议材料建议展示原始基线、当前批准基线、最新预测、关键依赖、影响范围、方案对比、决策请求和责任人。每个风险只需讲清事实与下一步；若状态长期不变，应确认是否已关闭，而不是在每次会议中重复占用注意力。

4. 建立健康的问责方式

合理的问责关注行为和证据：是否按规定及时升级，是否基于事实预测，是否按决策执行，是否主动识别超出权限的风险。不可控的外部事件不能被简单归责于个人，但可控的预警迟滞、隐瞒风险、未经批准修改承诺，应有明确处理机制。

管理者也要承担责任。如果团队多次指出依赖风险却没有得到决策，或多个项目持续争抢同一资源，问题不应只记在项目负责人名下。延期治理只有上下游责任都清晰，才能减少“要求团队负责、却不给决策权和资源”的失衡。

十、结语：好的延期流程，让坏消息更早到达，让承诺更值得相信

我对延期管理的核心判断是：管理层不需要项目永不延期，需要的是团队不把风险藏到最后、决策者不把日期当成唯一目标、组织不把改基线当成问题已经解决。一套流程真正成熟，表现为坏消息更早出现，方案更可比较，责任边界更清楚，批准后的行动有人验证。

下一步可以从一件具体工作开始：选取最近发生的三到五个延期案例，分别还原首次风险信号、首次正式预测、决策时间、基线变化和实际影响。不要先追责，先找出风险在哪个环节失去可见性、哪些信息缺失、谁拥有决策权。随后确定一页申请模板、三档升级规则和六项核心指标，试运行一个周期再调整。

延期不能总被消灭，但延期带来的意外、沉默和连锁损失可以被管理。把日期管理升级为承诺管理，管理层才能真正把项目进度转化为业务决策。