里程碑延期后，影响评估要先把“延了多久”换算成“影响了什么”：固定原定日期与当前预测日期，沿依赖链找出受影响的下游关键节点，再计算关键路径顺延天数、资源增量人天和交付窗口变化，最后按影响范围与不可逆程度确定升级层级。评估结论需要写明口径、分母与假设，并区分已确认影响和待验证影响。
要点总览（TL;DR）
- 评估对象是关键节点及其下游依赖：先固定原定里程碑日期与当前预测完成日期，算出延期天数，再沿依赖链找出受影响的下游关键节点。
- 核心指标包括延期天数、关键路径顺延天数、受影响关键节点数及占比、资源增量人天和交付窗口变化天数，每项都要写明公式、单位、分母和时间窗。
- 升级层级按三个维度组合判定：受影响关键节点数与占比、是否触发对外承诺或合同节点、处置窗口剩余时间，不单看延期天数。
- 结论要区分已确认影响与待验证影响，并约定复核触发条件，预测日期或依赖关系变化时重新计算并保留版本记录。
- 指标反映影响范围，不直接等于交付失败；分母为零或口径不可比时只报绝对数并注明，避免横向误比。
评估目标：延期影响要回答哪三个问题
里程碑延期影响评估的对象是里程碑所代表的关键节点及其下游依赖，不把单个任务的完成时间当作评估起点。评估要回答三个问题：后续哪些关键节点会被推迟、需要额外投入多少资源、整体交付窗口是否发生变化。这三个问题分别对应进度影响、资源影响和交付影响，构成评估结论的三类输出。
评估结论直接服务于升级决策。项目经理或交付负责人拿到结论后，需要判断这件事由项目组自行消化、提交部门协调，还是上升到项目集或管理层处理。因此评估输出不能停留在“延期5天”这样的单一数字，而要给出受影响节点清单、关键路径顺延天数、资源增量以及建议的升级层级和处置时限。
评估与延期原因复盘是两件事。原因复盘回答“为什么延期”，影响评估回答“延期带来什么后果、需要谁在多长时间内处理”。两者可以先后进行，但影响评估不必等根因查清才开始，否则会错过处置窗口。
评估输出清单
- 受影响下游关键节点清单，标注是否在关键路径上。
- 关键路径顺延天数与整体交付窗口变化。
- 资源增量人天，按角色和时间窗拆分。
- 影响分级结果、建议升级层级与处置时限。
- 数据口径说明，包括基准日期来源、假设与待验证项。
指标与范围：用哪些量衡量延期影响
影响评估需要一组可复算的指标，每个指标都要有公式、单位、分母和时间窗，否则不同人算出的结果无法比较。核心指标包括延期天数、关键路径顺延天数、受影响关键节点数、资源增量人天和交付窗口变化天数。
延期天数是起点指标，公式为“当前预测完成日期减原定里程碑日期”，单位为自然日或工作日，需在评估开始前明确采用哪一种并全篇统一。关键路径顺延天数衡量延期对整体进度的影响，公式为“延期后关键路径总时长减原关键路径总时长”，分母是原关键路径总时长，用于计算顺延比例。受影响关键节点数统计依赖链上完成日期被迫后移的关键节点数量，分母为评估范围内全部关键节点数，可得到受影响比例。
资源增量人天按“延期后完成受影响节点所需人天减原计划人天”计算，需注明统计的角色范围和时间窗。交付窗口变化用“延期后预计交付日期减原承诺交付日期”表达，若涉及对外承诺，应单独标注。统计范围要事先写清：纳入哪些里程碑、依赖关系取到哪一层、评估时间窗从哪天到哪天。
指标定义表
| 指标 | 公式 | 单位 | 分母/基准 | 时间窗 |
|---|---|---|---|---|
| 延期天数 | 当前预测完成日期 − 原定里程碑日期 | 工作日 | 原定里程碑日期 | 评估当日 |
| 关键路径顺延天数 | 延期后关键路径总时长 − 原关键路径总时长 | 工作日 | 原关键路径总时长 | 至下一里程碑 |
| 受影响关键节点数 | 完成日期后移的关键节点计数 | 个 | 评估范围内关键节点总数 | 评估时间窗内 |
| 资源增量 | 延期后所需人天 − 原计划人天 | 人天 | 原计划人天 | 受影响节点执行期 |
| 交付窗口变化 | 延期后预计交付日期 − 原承诺交付日期 | 工作日 | 原承诺交付日期 | 至交付节点 |
数据口径与证据：延期事实从哪里取、怎么核
延期事实的取数要成对出现：原定里程碑日期来自已批准的计划或基线，当前预测完成日期来自执行中的进度记录或负责人确认。两者若来自不同系统或不同版本，需要注明版本和确认时间。基线一旦设定，评估期间不随执行调整而改动，否则延期天数会被稀释。
依赖关系与关键路径需要证据支撑。依赖关系应以计划中登记的前后置关系为准，关键路径应能说明路径上各节点的时长来源。若组织没有正式的关键路径记录，可以按依赖链人工推导，但要在结论中标注“人工推导、未经计划确认”，并将相关影响列为待验证。
缺失值的处理规则要提前约定。预测完成日期缺失的节点，不默认按原计划日期计算，而应标记为“未确认”，单独列出；依赖关系缺失的节点，按最保守假设纳入影响范围并注明。影响结论分为两级：有基线、有进度记录、有依赖证据的列为已确认影响；仅有口头判断或推导的列为待验证影响。升级决策可以依据已确认影响先行启动，待验证影响在复核时补充。
计算与评估步骤：从延期天数到升级层级
评估按五步推进，每一步都有明确产物，前一步的产物是后一步的输入。
步骤一：确认延期事实与基准。核对原定里程碑日期、当前预测完成日期和延期天数，确认三者口径一致，记录数据来源和确认人。产物是一行延期事实记录，包含基准版本和确认时间。
步骤二：沿依赖链识别受影响关键节点。从延期里程碑出发，沿前后置依赖向下游逐层查找，判断每个下游节点的完成日期是否被迫后移。位于关键路径上的节点计入关键路径顺延，非关键路径节点先看浮动时间是否被消耗完，消耗完才计入受影响。产物是受影响节点清单及路径归属。
步骤三：计算关键路径顺延与资源增量。按指标定义表逐项计算，关键路径顺延天数以原关键路径总时长为分母，资源增量按角色和时间窗拆分。产物是指标计算结果表，附计算过程。
步骤四：按影响范围与不可逆程度定级。定级不只看延期天数，而看三个维度：受影响关键节点数及占比、是否已触发对外承诺或合同节点、处置窗口还剩多少时间。三个维度组合后落到升级层级。
步骤五：输出结论与处置时限。结论写明已确认影响、待验证影响、建议升级层级、责任人和处置截止时间，并约定复核触发条件，例如预测完成日期再次变化或依赖关系调整。
升级层级判定表
| 层级 | 影响范围 | 不可逆程度 | 处置时限 | 处置主体 |
|---|---|---|---|---|
| 一级：项目组内消化 | 受影响关键节点占比低，关键路径顺延在浮动时间内 | 未触及对外承诺 | 3个工作日内调整计划 | 项目经理 |
| 二级：部门协调 | 关键路径顺延，受影响节点跨团队 | 对外承诺尚未变更，但窗口收窄 | 2个工作日内提出资源或范围方案 | 部门负责人 |
| 三级：项目集/管理层决策 | 多个关键节点受影响，整体交付窗口变化 | 已触发或即将触发合同、对外承诺节点 | 1个工作日内启动决策 | 项目集负责人或管理层 |
表中的时限是示例口径，组织应结合自身决策节奏设定并在评估前公布，避免每次评估临时商定。
例子：一次里程碑延期的影响评估演算
以下为演示情景，用于说明计算过程，数据为虚构。
某项目原定6月30日完成“系统集成测试”里程碑，当前预测完成日期为7月9日，按工作日计延期7天。该里程碑下游有两个关键节点：“用户验收测试”原定7月15日、“上线发布”原定7月31日。依赖关系记录显示，集成测试完成后才能启动验收测试，验收测试完成后才能发布。原关键路径总时长为40个工作日。
步骤二识别影响：集成测试延期7天，验收测试完成日期后移至7月24日，上线发布后移至8月11日，两个下游节点均在关键路径上，受影响关键节点数为2，评估范围内关键节点总数为5，受影响占比40%。
步骤三计算：关键路径顺延7天，顺延比例7÷40＝17.5%。资源增量方面，验收测试阶段需增加2名测试人员投入5个工作日，计10人天；发布阶段增加1名运维人员3个工作日，计3人天，合计13人天。交付窗口变化为8月11日减7月31日，即7个工作日。
步骤四定级：受影响关键节点占比40%，关键路径顺延7天，上线发布日期后移7个工作日，已接近对外承诺的8月初窗口，属于“窗口收窄且即将触发对外承诺”。按判定表落到二级偏三级，因上线日期涉及对外承诺，建议按三级启动决策，同时由部门在2个工作日内提交压缩验收测试周期的方案。
步骤五输出：结论写明已确认影响为两个下游节点后移、资源增量13人天、交付窗口后移7个工作日；待验证项为验收测试周期能否压缩，需在2个工作日内由测试负责人确认。处置时限按三级执行，1个工作日内启动决策。
解读与限制：结论怎么用、哪里不能过度推断
影响评估的指标反映的是影响范围和程度，不直接等于交付失败。关键路径顺延7天、受影响节点占比40%，说明需要协调资源和调整承诺，是否最终导致交付失败还取决于后续处置效果。把评估结果当作绩效结论或责任认定依据，会偏离它的用途。
分母为零和不可比的情况要单独处理。评估范围内没有关键节点时，受影响占比没有意义，应改为直接列出受影响节点；原关键路径总时长缺失时，顺延比例无法计算，只报绝对天数并注明。不同项目、不同阶段的延期天数不宜直接横向比较，除非基线口径、工作日定义和统计范围一致。
评估结论需要复核与更新。预测完成日期变化、依赖关系调整、资源方案落地后，都应重新计算受影响节点和顺延天数，并在结论中保留版本记录，便于追溯判断依据的变化。评估中的人工推导和口头判断应明确标注为待验证，在复核时转为已确认或剔除。
当评估需要频繁复算时，承载方式会影响效率。ONES 支持用项目计划建立工作分解结构并设置任务前后置依赖，用里程碑标记重要时间点；支持设置项目计划和里程碑基线，对比计划与执行的偏差并追溯变更细节；项目列表可查看项目状态、资源投入和进展，工时日历与饱和度报表可用于核对资源增量。将这些记录放在同一套计划与基线中，评估时的取数、复算和版本追溯会更顺畅，具体能力范围以实际版本配置为准。
常见问题
里程碑延期后，根因还没查清，能不能先做影响评估？
可以，而且通常应当先做。影响评估回答的是“延期带来什么后果、需要谁在多长时间内处理”，根因复盘回答的是“为什么延期”，两者可以并行推进。等根因查清再评估，容易错过处置窗口，尤其是涉及对外承诺的节点。
先做影响评估时，把依据不足的部分标注为待验证影响，升级决策可以依据已确认影响先行启动，待验证项在复核时补充或剔除。
下游节点很多，怎么判断哪些算受影响？
沿前后置依赖从延期里程碑向下游逐层查找，看每个节点的完成日期是否被迫后移。位于关键路径上的节点直接计入关键路径顺延；非关键路径节点先看浮动时间是否被消耗完，只有浮动时间耗尽、完成日期真正后移的才计入受影响。
这样处理可以避免把全部下游节点都算作受影响，导致影响范围被高估、升级层级被抬高。
组织没有正式的关键路径记录，评估还能做吗？
可以做，但要降低结论的可信度等级。可以按依赖链人工推导路径，并在结论中标注“人工推导、未经计划确认”，把相关影响列为待验证。依赖关系以计划中登记的前后置关系为准，路径上各节点的时长来源要能说明。
如果后续补上了正式的关键路径记录，应重新计算顺延天数并更新结论版本。
升级层级的处置时限应该由谁定？
时限属于组织决策节奏的一部分，应在评估开始前由管理层或项目管理办公室统一公布，而不是每次评估临时商定。判定表中的时限是示例口径，组织可以按自身决策周期调整。
统一公布的好处是同类延期的影响评估结果可以直接比较，也便于事后检查处置是否按时启动。
评估结论多久需要复核一次？
复核由触发条件驱动，而非固定周期。常见触发条件包括：预测完成日期再次变化、依赖关系调整、资源方案落地或范围变更。触发后重新计算受影响节点、顺延天数和资源增量，并在结论中保留版本记录，便于追溯判断依据的变化。
没有触发条件时，已确认影响可以维持原结论，待验证项按约定时间点转为已确认或剔除。
