延期流程与规范：项目成员任务执行制度设计关键指标

我最近一次被问到延期流程，是在一个 300 人规模的研发组织里。对方的 PMO 负责人把最新版《项目延期管理制度》发给我，一共 11 页，申请、审批、签证、归档一个不缺，措辞规范到可以直接进 ISO 文件包。但他补了一句让我印象很深的话：“流程执行率挺高，延期率一点没降。”

这不是个例。过去八年我参与梳理过 40 多个项目型组织的延期与任务执行制度，一个反复出现的规律是：制度写得越像“审批说明书”，执行效果越差。因为延期治理的难点从来不在“批不批”，而在“能不能提前知道、能不能算清楚影响、能不能在批准之后追回来”。

这篇文章我想换个角度讲延期流程与规范：不给你一份可以抄的模板，而是拆开“项目成员任务执行制度”里真正起作用的那些关键指标，讲清楚每个指标的口径怎么定、谁负责、触发什么动作，以及在什么阶段该做取舍。文中涉及的数据，一部分来自我参与的项目复盘，一部分是标注过的示意与样本推演，你可以按自己组织的基线去校准，但不要直接照抄阈值。

一、先给结论：延期制度的分水岭不在流程长度，而在指标闭环

把话放在最前面：一份延期制度有没有用，不看它写了几个审批节点，而看它有没有把“延期”变成一组可以被持续观测的指标。没有指标，延期就只能靠人喊；有了指标，延期才可能被提前发现、被量化评估、被分级干预。

1. 我判断一份延期制度是否合格的三条硬标准

第一条，是否能在交付日之前发出信号。如果一份制度只在“任务已经逾期”时才启动，那它本质上是事故处理流程，不是延期管理流程。真正有效的制度，至少要能回答“还剩 5 天时，这个任务的风险等级是什么”。

第二条，是否能算清楚延期的代价。延期 3 天和延期 15 天，对关键路径、资源占用、客户承诺的影响完全不是一个量级。制度里如果没有影响评估的量化口径，审批就必然退化成“领导拍板”。

第三条，是否在批准之后还有后续动作。我见过太多制度，审批通过就等于流程结束。但延期真正的成本发生在批准之后，资源怎么补、范围怎么砍、依赖怎么重排、追不回来怎么办。没有恢复计划的延期审批，等于把风险从“有记录的延期”变成“无记录的烂尾”。

2. 指标闭环的四个组成

我通常把延期治理的指标闭环拆成四块：事前预警指标、事中过程指标、事后结果指标、以及贯穿全程的证据完整度指标。这四块缺任何一块，制度都会倾斜。

只有结果指标（比如延期任务占比），你会发现团队只知道“又延了”，但不知道怎么防；只有过程指标（比如任务按时完成率），管理者容易陷入“数字好看但关键节点照样崩”的错觉；只有预警指标而没有结果指标，预警会逐渐变成狼来了。

二、为什么延期制度总是失效：三个我亲历的场景

在讲设计方法之前，我想先把失效的样子描述清楚。制度设计得对不对，往往取决于你有没有见过它坏掉时的具体形态。

1. 场景一：到期那天才知道要延期

某交付型团队曾经有过一条我至今记得的记录：一个关键集成任务的计划完成日是周五，周四晚上的日会上，负责人说“明天应该差不多”，周五上午变成“可能要延两天”，周五下班才正式提交延期申请。整个链条从“风险”到“确认”中间隔了 14 个小时，而这 14 小时里没有任何人做资源准备。

问题不在负责人不诚实。问题在于制度只定义了“逾期”这个触发条件，没有定义“风险”这个触发条件。任务只剩 20% 剩余工作量而剩余时间只剩 10%，这在数据上早就可识别了，但制度没有要求任何人看这个比值。

2. 场景二：证据后补，责任说不清

工程类项目对这一点会更敏感。我参与过一次延期责任复盘，争议点是“供应商到货延迟了几天”。甲方记录是 4 天，供应商记录是 2 天，双方都没有当天的现场签署记录，最后只能各让一步。

更常见的情况是：延期发生当天没人记录，一周后补材料时，当事人已经记不清当时的判断依据。证据不是为了让谁背锅，而是为了在三个月后复盘时，还说得清当时发生了什么。证据后补的成本，远高于当天填一张表。

3. 场景三：审批通过了，任务还是没追平

这是我见过最普遍、也最被低估的一类失效。延期审批通过之后，大家心理上松了一口气，默认“已经处理完了”。结果三周后看整体进度，原本延 3 天的任务变成了实际延 9 天，因为延期期间又叠加了新的并行任务，被延的那个任务优先级悄悄被降了。

延期不是一次审批事件，而是一段需要被管理的恢复期。制度里如果没有“恢复计划 + 追平确认”这两步，延期审批就只是把问题从台面移到桌下。我在多个项目群做过统计，未定义恢复计划的延期记录中，最终实际延期天数平均是批准天数的 2.4 倍。

三、拆解常见误区：七种我反复见到的写法

下面这七种问题，我几乎在每个需要重构制度的组织里都能看到至少三种。它们不是文笔问题，而是设计问题。

1. 只写审批流，不写预警机制

典型写法是“任务延期须提前 3 个工作日提交申请，经项目经理审批”。这句话看起来严谨，实际是把识别责任推给了执行成员个人。执行成员天然倾向于“我再努力一下就好了”，这不是态度问题，是信息问题。

改法是：把预警从“人的自觉”变成“系统的规则”。比如剩余工作量与剩余工时的比值低于某个基线时自动标记，任务负责人收到提醒后必须在规定时限内给出“可完成 / 有风险 / 需延期”的明确判断。不是要求人主动报风险，而是让风险自己浮出来。

2. 所有延期同权处理

把“关键路径任务延 1 天”和“一个非关键文档任务延 3 天”放进同一个审批层级，是常见的资源浪费。前者可能需要立即升级到项目级甚至客户级，后者只要任务负责人内部调整排期就能消化。

我通常建议引入两个维度做加权：关键性（是否在关键路径上）× 影响范围（是否影响对外承诺）。两个维度都高的走升级通道，都低的走简化通道，中间地带走常规通道。

3. 照抄别人的硬阈值

“延误超过 10% 即红色预警”这类阈值在网上流传很广。问题在于，10% 对一个周期两周的任务意味着 1.4 天，对一个周期半年的项目意味着 18 天，两者的管理含义完全不同。

阈值必须来自三样东西：自己的历史基线、合同或承诺的硬约束、以及关键路径的浮动时间。没有这三样，任何阈值都是装饰。

4. 指标越多越好

我见过一份制度列了 19 个延期相关指标，从“任务延期频次”到“延期沟通满意度”。结果半年后，数据完整率超过 60% 的只有 4 个，其余全部靠估算。

指标的价值不在于覆盖全面，而在于每一个都能触发一个明确动作。如果某个指标异常时你不知道该做什么，这个指标就该删掉。

5. 把证据后补当成常态

“先干活，材料后面补”是项目管理的经典陷阱。我的判断是：如果证据要求在流程上位于决策之后，它就一定会被后补。正确顺序是把关键证据作为审批的前置输入，材料不完整，审批流程走不下去。

6. 把工程签证术语直接搬到研发或职能项目

“甲方”“监理”“见证”“签证期限”这套话术在工程语境里非常精确，但直接搬到软件研发、市场交付或内部职能项目上，会让人产生强烈的“这不是给我看的”疏离感。

本质是同一个动作，但表达要换：工程里的“现场见证记录”，在研发语境里叫“风险确认记录”或“决策留痕”；工程里的“签证期限”，在研发语境里叫“影响确认时限”。术语要跟着组织语义走，不然制度第一天就会被绕过。

7. 只罚不析，只统计不干预

把延期次数直接挂钩个人绩效，短期数据会变好看，代价是团队开始隐藏风险、拆小任务、把延期改名叫“计划调整”。制度一旦让说真话变贵，数据质量就会崩。

更健康的做法是：对“未按流程识别和上报”追责，而不是对“发生延期”追责。延期本身是项目常态，瞒报才是管理事故。

四、专业判断：延期流程的五个设计原则

误区讲完之后，说清楚我实际做方案时的判断逻辑。这五条原则是我在多个行业反复验证后保留下来的一套骨架，顺序也重要。

1. 关键路径优先原则

项目里绝大多数的管理注意力应该放在关键路径上，这在理论上没有争议，难的是执行。因为非关键路径的任务一旦延误会挤占共享资源，间接把关键路径拖下水。

所以我的做法是：关键路径任务享受最高预警灵敏度，非关键路径任务享受资源占用监控。前者盯时间，后者盯资源。这样既不会漏掉真正的致命延误，也不会因为非关键任务的资源外溢而失守。

2. 证据先行原则

我把证据分成三类：事实证据（发生了什么）、判断证据（当时怎么判断的）、共识证据（谁同意了）。事实证据记录时间点和状态，判断证据记录依据和假设，共识证据记录双方的确认动作。

很多制度只要求第一类，导致复盘时只能说“确实延了”，说不清“为什么当时判断能按时完成”。判断证据才是组织学习的原材料。

3. 分级审批原则

分级不是官僚主义，而是稀缺注意力的分配机制。我通常按“影响是否超出单个任务、是否影响对外承诺、是否消耗额外资源”三个问题划分层级。

三个问题都为否，任务负责人自主调整即可记录备案；有一个为是，进入项目经理审批；有两个以上为是，进入项目级或变更委员会审批。让审批层级跟着影响走，而不是跟着任务金额或行政级别走。

4. 恢复计划前置原则

这是我个人最坚持的一条：延期申请里不写恢复计划，就不进入审批。原因很简单，人在提出申请时对补救方案的思考质量最高，一旦批准完成，注意力立刻转向下一件事。

恢复计划不需要很复杂，三个字段就够：新的完成日期、需要什么额外支持、如果再次延期的触发条件是什么。第三个字段尤其重要，它相当于给自己设了第二道预警。

5. 指标必须触发动作原则

每个指标都要配一句“当它异常时，谁在多久内做什么”。如果这句话写不出来，说明这个指标是为了好看而存在的。

举个例子，“预警响应时效”异常的定义可以是“超过 48 小时未更新风险判断”，对应动作是“项目经理在日会上点名确认，并在任务上加风险标记”。指标和动作之间必须是一条不用思考就能执行的通路。

五、关键指标卡：8 个指标的口径、责任人与触发动作

下面这 8 个指标是我在多个组织里反复筛选后留下的组合。筛选标准很简单：要么能提前发现问题，要么能衡量处理质量，要么能暴露资源瓶颈。三者都不沾的指标一律不要。

1. 过程指标：任务按时完成率、延期任务占比、预警响应时效

任务按时完成率的口径必须写死：分子是按原计划完成日完成的任务数，分母是当期计划完成的任务数，不含当期新增任务。如果分子分母口径变来变去，这个指标就废了。

延期任务占比是延期任务的“发生率”，我建议按周统计而不是按月，因为按月统计会让问题暴露太晚。它的用途不是考核，而是看趋势拐点。

预警响应时效是我最看重的过程指标。它衡量的是“从风险被识别到有人给出明确判断”的时间。这个指标直接反映团队的风险文化，如果它长期偏高，说明大家都在拖。

2. 结果指标：关键路径延误天数、工期延误比例、延期后追平率

关键路径延误天数是唯一一个可以直接和交付承诺挂钩的指标，它应该被单独跟踪，不和普通任务混在一起统计。

工期延误比例的口径是“实际工期超出计划工期的天数 ÷ 计划工期”，它更适合在项目层面看，不适合放在个人层面，否则会诱导任务负责人把估算放大。

延期后追平率是我认为最被低估的指标。它衡量的是“批准延期之后，有多少比例真的按恢复计划追回来了”。这个数字如果在 50% 以下，说明恢复计划形同虚设。

3. 资源指标：资源缺口率、证据完整率

资源缺口率的定义是“完成任务所需的额外人天 ÷ 原计划人天”。它异常通常意味着两个问题之一：估算偏乐观，或者资源被别处抽走。区分这两种情况，要看同期是否有资源调配记录。

证据完整率是制度健康度的体检指标。它等于“证据材料齐全的延期记录数 ÷ 延期记录总数”。我建议这个指标在制度推行初期只做统计不做考核，避免为了凑材料而造假。

4. 阈值设定的三步法

很多读者问我具体阈值。我从来不给具体数字，给的是方法。

第一步，取历史基线。把过去 6 到 12 个月的延期数据拉出来，算出每个指标的中位数和 75 分位数。中位数作为绿色上限，75 分位数作为黄色触发线，90 分位数作为红色触发线。这是自校准的方式，不依赖任何外部模板。

第二步，叠加硬约束。合同约定的对外交付节点、监管要求的固定截止日、以及其他不可谈判的时间点，必须单独设定更严格的阈值。这些点的预警灵敏度应当高于其他任务。

第三步，用浮动时间做最后校准。看关键路径上有多少总浮动时间，如果浮动时间很少，阈值就应该收紧。浮动时间充裕的任务可以适当放宽，避免预警噪音。

六、真实案例与数据观察：一个 300 人研发组织的延期治理改造

下面这个案例来自我参与的一次制度重构，组织规模约 300 人，多项目并行，交付节奏以双周迭代为主。文中数据为改造过程的样本推演与观察记录，用于说明方法，不作为行业基准。

1. 改造前的状态：三张互不相通的表

改造前，他们的延期信息分散在三处：任务系统里的状态变更记录、项目经理各自的 Excel 台账、以及周报里的文字描述。三张表的口径都不一致，PMO 每次统计延期率都要花两到三天做数据对齐。

更麻烦的是，同一个延期事件在三处可能有三种描述。任务系统记录“状态变更”，Excel 记录“延期 3 天”，周报写“因依赖方原因顺延”。数据不是缺失，而是互相矛盾，这比缺失更麻烦。

2. 改造动作：把制度规则写进工具，而不是写进文档

这次改造最关键的决策是：不再把制度当成一份文档来维护，而是把它变成任务系统和项目管理平台里的规则配置。具体做了四件事。

1. 把关键路径任务打上专用标签，让关键路径延误天数可以被自动统计，而不是靠人工摘录。
2. 把预警规则配置成系统提醒：剩余工作量与剩余工时比值低于基线时，自动生成风险标记并要求负责人在规定时限内响应。
3. 把延期申请做成结构化表单，证据字段设为必填，材料不齐则无法提交审批。
4. 把恢复计划作为审批的必填项，并设置二次触发条件，到期未追平自动升级预警等级。

这个组织当时正在做工具链的统一，最终选择了 PingCode 作为研发项目管理底座。PingCode 主要服务中大型企业及 100 人以上组织，这一点和他们的规模与多项目并行特征比较匹配；同时 PingCode 支持私有化部署，满足他们对交付数据不出内网的要求，也支持从 Jira 平滑迁移，让已经在用的历史数据和工作流能延续下来，这也是他们把它作为国产替代方案评估的重要原因。

3. 工具化前后的管理耗时对比

我想特别强调一个容易被忽略的成本：制度运行的隐性人工成本。改造前，PMO 每月花在延期数据汇总、证据归集和复盘报告上的时间接近 55 人时；改造后降到约 8 人时。省下来的时间被投入到延期原因分析和流程优化上，这部分才是真正产生价值的工作。

4. 三个月的指标变化观察

改造后有四点观察值得记录。第一，延期任务占比从 23% 降到 10% 左右，但前两个月几乎没动，第三个月才出现明显下降，说明制度效果有滞后。

第二，预警响应时效从平均 4.5 天降到 1.4 天，这是最早改善的指标，因为它直接取决于提醒机制而不是人的习惯。第三，延期后追平率从 34% 提升到 67%，主要归功于恢复计划成为必填项。

第四，也是我没想到的：延期事件的报告数量在第一个月上升了 40%。不是延期变多了，而是原来被隐藏的小延期被暴露出来了。这个阶段的指标恶化是好事，需要提前和管理层沟通，否则很容易被误判为制度失败而叫停。

七、分级预警与阈值机制：不要照抄别人的百分比

分级预警是延期制度里最容易写、也最容易写错的部分。写错的方式通常有两种：层级太多导致没人记得住，或者触发条件太模糊导致形同虚设。

1. 三级预警的定义方式

我用三级，不用五级。三级是人能在日会上快速沟通的极限，五级必然退化成“这个算什么级别”的讨论。三级的划分依据不是单一指标，而是三个问题的组合答案。

黄色预警：任务存在风险，但还有内部调整空间，不涉及对外承诺变化。橙色预警：任务大概率无法按原计划完成，需要额外资源或调整依赖关系，可能影响里程碑。红色预警：关键路径或对外承诺受影响，需要项目级甚至客户级介入。

2. 阈值校准的三个输入

前面讲过三步法，这里补充一个操作细节：阈值不要一次定死，先跑一个月的观察期。观察期内只记录不触发升级动作，月底看预警分布，如果黄色预警占比超过 30%，说明阈值太松，需要收紧；如果红色预警一个月出现超过 3 次，说明要么阈值太紧，要么项目本身已经失控，两种情况要分别处理。

3. 触发后的升级动作必须具体

“加强关注”这种表述等于没有动作。我要求每一级预警都必须对应三个具体动作：谁在多久内做什么、需要什么输入、产出什么记录。

八、最小表单与规范：一页纸跑通延期闭环

制度落地失败最常见的原因不是设计不好，而是表单太重。我见过一份延期申请单有 32 个字段，实际填写完整率不到 15%。我的做法是：核心表单控制在一页纸以内，字段必须能直接生成指标数据，否则就是纯粹的文书负担。

1. 延期申请单：九个字段

下面是我实际在用的字段结构。注意每个字段都能对应到前面说的某个指标，这是“表单即数据源”的设计思路。

延期申请单（最小字段集）

delay_id 延期编号（唯一）

task_id 关联任务编号

trigger_type 触发类型：预警触发 / 到期未完成 / 主动上报

reason_category 原因分类：需求变更 / 上游依赖 / 资源冲突 / 估算偏差 / 外部环境

impact_scope 影响范围：仅本任务 / 影响里程碑 / 影响对外承诺

critical_path 是否关键路径：是 / 否

delay_days 预计延期天数

recovery_plan 恢复计划：新完成日 + 所需支持 + 二次触发条件

evidence_refs 证据引用：记录编号或附件标识

2. 证据记录：回答三个问题

证据记录不要写成情况说明，写成三个问题的答案就够了：当时观察到的事实是什么、基于什么假设做出了判断、谁确认了这个判断。三个问题对应前面说的事实证据、判断证据、共识证据。

3. 影响评估表：只算两个数字

影响评估最常见的失败是算得太复杂。我建议只算两个数字：关键路径是否受影响、需要多少额外人天。这两个数字决定了审批层级和资源动作，其他的可以放在复盘阶段慢慢分析。

4. 恢复计划表：重点是二次触发条件

恢复计划里最容易被省略、但价值最高的字段是“二次触发条件”。比如“如果到 3 月 20 日进度仍低于计划的 80%，自动升级为橙色预警”。这一步相当于给恢复计划装了一个自检装置，避免计划失效后无人发现。

5. 复盘模板：只记录可复用的结论

复盘模板不需要记录全过程，只需要记录三件事：延期的根因分类、当时如果提前 N 天预警能做什么、下一次遇到同类情况应该在哪一步设置检查点。第三件事才是组织学习的产出。

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

同一套方法在不同规模、不同项目类型下，落地方式差别很大。下面按四种典型情况给建议，你可以对号入座。

1. 二十人以下小团队

不要建立分级审批，不要引入复杂表单。只做两件事：在任务上标出关键路径，以及要求延期必须提前一个工作日说。小团队的信息传递成本很低，沟通本身就是最好的机制，过度制度化反而是负担。

指标只保留两个：任务按时完成率和延期后追平率。前者看整体节奏，后者防止“批了就忘”。

2. 五十到两百人的项目型组织

这个规模是制度化的最佳起点，因为信息开始不对称，靠口头同步已经不够了。建议完整建立八指标体系，但先用简化审批通道跑三个月，验证数据质量后再引入完整分级。

重点投入在证据完整率和预警响应时效上。这两个指标改善之后，其他指标会跟着好转。

3. 三百人以上多项目并行

这个规模必然需要工具化支撑，因为数据量已经超出手工处理能力。核心动作是把制度规则配置到项目管理平台里，让指标自动产生。像 PingCode 这类面向中大型组织的研发项目管理平台，通常会把任务、迭代、缺陷、需求放在同一条链路上，使得关键路径数据和资源占用数据可以直接被延期指标复用，这比在多个系统之间做数据拼接要可靠得多。

同时这个规模需要明确的 PMO 角色，专门负责指标校准和阈值调整，避免各部门各自定义口径。

4. 强监管、工程与交付类项目

这类项目对外部证据和时限的要求更高，建议把证据完整率设为否决性指标：证据不完整，延期记录不计入正式统计，也不进入审批通道。同时对外承诺相关的时间节点要单独设更严格的预警阈值，不受内部基线影响。

另外建议把工程语境里的签证、见证、监理等术语，翻译成组织内部通用的表达，否则执行成员会觉得这是“甲方文件”而不是“自己的工作规范”。

十、不同情况下的取舍：没有全面最优，只有阶段性最优

制度设计本质上是一连串取舍。我把最容易纠结的五组取舍摊开讲，每组的答案都取决于你当前的主要矛盾。

1. 预警灵敏度与噪音之间的取舍

灵敏度调高，预警数量会迅速上升，团队容易产生预警疲劳；调低，又可能漏掉真正的风险。我的经验是：在制度推行初期宁可偏灵敏，等团队形成响应习惯后再逐步收紧。因为早期漏报的代价远高于误报。

2. 审批层级与响应速度之间的取舍

层级多，责任清晰但慢；层级少，快但容易失控。判断依据是延期的可逆性。如果延期一旦发生就很难挽回（比如对外交付节点），宁可牺牲速度换取多层确认；如果延期可以在几天内追回，就应该走最简通道。

3. 指标数量与数据质量之间的取舍

这个取舍很直接：指标数量和数据完整率通常成反比。与其做 15 个指标但只有 5 个可信，不如做 8 个指标全部可信。判断标准是，如果这个指标的数据需要额外人工整理超过 30 分钟，就不要它。

4. 制度刚性与执行成员体验之间的取舍

制度太硬，团队会想办法绕开；太软，又形同虚设。我的判断是：证据和上报的刚性必须强，处理方式和资源分配的弹性可以大。也就是说，必须报，但报完之后怎么解决可以灵活讨论。

5. 自建与采购之间的取舍

这个取舍取决于两件事：你的制度规则是否已经稳定，以及你的数据敏感性有多高。规则还在频繁变动时，工具化会把不成熟的规则固化下来，反而增加改造成本；规则稳定且有强内网要求时，支持私有化部署的平台通常比自建更划算。

十一、落地路线与下一步：30/60/90 天怎么走

最后给一条我自己用过的落地路线。它不是标准答案，但至少经过验证，能避免最常见的“一次性大改然后失败”的路径。

1. 第一个月：只做定义和基线

这个阶段不要动流程，也不要发新制度文件。只做三件事：梳理关键节点和关键路径、把八指标的口径写成一页纸、拉出过去 6 到 12 个月的历史基线。

口径这一步必须产出书面定义，包括分子分母、统计周期、数据来源。我在多个项目里见过因为口径不一致导致整个指标失效的情况，这一步省不得。

2. 第二个月：小范围试运行

选一到两个项目试运行，只走指标统计和预警，不引入考核。重点观察两件事：预警数量和分布是否符合预期、证据完整率能否达到基线以上。

这个月大概率会出现延期上报数量上升的情况，这是暴露存量问题的正常现象，需要提前和上级沟通，避免被误判。

3. 第三个月：校准阈值并纳入常规例会

根据试运行数据校准阈值，把延期指标纳入项目周会的固定议题，同时开始做规律性的复盘。这一步之后制度才算真正活了，因为它进入了日常管理节奏，而不是一份挂在共享盘里的文件。

如果组织规模在 300 人以上，这个阶段通常需要把规则固化到项目管理平台里，让指标自动产生、预警自动触发。手工维护的指标在这个规模下一定会退化。

十二、总结：延期制度真正要解决的，是让风险在还来得及的时候被说出来

回到开头那个 300 人的组织。他们那 11 页制度的真正问题，不是写得不好，而是它把延期当成一个需要被批准的事件，而不是一段需要被观测和管理的过程。审批只能决定“允不允许延期”，只有指标能回答“现在还来得及吗”。

我的核心判断可以压缩成一句话：延期流程与规范的质量，取决于它能不能在交付日之前给出信号、能不能算清代价、能不能在批准之后追回来。这三件事分别对应预警指标、影响评估和恢复计划，缺一件，制度就会退化成一纸文书。

另一个容易被忽略的观点是：延期制度不只是保护甲方或项目经理的，它同样在保护合理延期的执行成员。一个只有追责没有证据留痕的制度，会让说真话的人承担最大风险，最终结果是所有人都不再提前说。

下一步我建议你做三件很具体的事。第一，把过去半年的延期记录拉出来，按需求变更、上游依赖、资源冲突、估算偏差、外部环境五类做一次分布统计，看看你的主要矛盾在哪一类。

第二，选两到三个指标先跑起来，优先选预警响应时效和延期后追平率，因为它们分别对应制度的前半场和后半场，改善最快也最能说明问题。

第三，把延期申请单压缩到一页纸以内，字段设计成能直接生成指标数据的结构，然后交给一到两个项目试运行一个月。制度不是写出来的，是跑出来的。