评估项目计划，对象应是计划基线本身，而非执行结果。判断一份计划是否可用，可以围绕质量、完整性、可执行性三组标准展开：质量看目标、范围、假设与里程碑是否站得住；完整性看范围、依赖、资源、风险、验收是否覆盖齐全；可执行性看任务粒度、资源可得性、依赖闭环与变更机制是否支撑落地。下文给出一套可复算、可核验的指标与步骤，并说明结果如何用于计划评审与基线调整。
要点总览（TL;DR）
- 评估对象是某一版本的计划基线，涵盖范围、进度、资源、风险与验收；执行阶段的进度偏差不在本篇口径内。
- 质量看目标与范围是否清晰、假设与约束是否记录、里程碑是否合理；完整性看工作范围、依赖、资源、风险、验收是否覆盖齐全；可执行性看任务粒度、依赖闭环、资源可得性与基线变更是否受控。
- 每个指标写清分子、分母、时间窗与单位；分母为零标注“不适用”，数据缺失标注“数据缺失”，均不按零值或满分计入汇总。
- 评估按确定基线与范围、计算指标、证据抽查、三档汇总、形成评审意见五步推进，关键路径任务、跨团队依赖与高影响风险全量核对，其余条目按不低于20%抽查。
- 指标反映计划编制层面的特征，不直接等同执行结果；不同项目类型与规模之间先统一口径与阈值，否则只做趋势观察。
评估目标：先明确要回答哪三个问题
评估开始前需要锁定对象：本次评估的是某一版本的计划基线，涵盖范围、进度、资源、风险与验收安排。执行过程中的进度偏差、成本超支属于执行分析，不在本篇口径内。把对象限定在基线，评估结论才能对应到“这份计划是否值得批准或继续作为执行依据”。
三组标准分别回答三个不同问题，评估时不宜混在一起打分：
| 标准 | 要回答的问题 | 典型判断落点 |
|---|---|---|
| 质量 | 计划是否说得清楚、立得住？ | 目标与范围表述、假设与约束记录、里程碑设置是否合理 |
| 完整性 | 该覆盖的内容是否都覆盖了？ | 工作范围、依赖、资源、风险、验收标准是否齐全 |
| 可执行性 | 按这份计划能否真正推进？ | 任务粒度、资源可得性、依赖闭环、基线变更是否受控 |
评估结果有三个直接用途：一是作为计划评审会的输入，把讨论从印象判断转到具体条目；二是作为基线确认的依据，明确哪些缺口必须在开工前补齐；三是作为变更决策的参照，当范围或资源发生调整时，用同一套口径判断新基线是否仍达标。评估结论服务于计划改进，不直接作为团队绩效结论。
指标与范围：计划基线要看哪些指标
指标设计的原则是每个指标只回答一个判断问题，并能对应到三组标准之一。下表给出建议的指标集合，单位与数据来源一并列出，便于后续取数。
| 指标 | 所属标准 | 计算口径 | 单位 | 数据来源 |
|---|---|---|---|---|
| 目标与范围明确度 | 质量 | 计划文档中目标、范围边界、主要交付物三项均写明且经评审确认的条目数 ÷ 应写条目数 | % | 计划文档、评审记录 |
| 假设与约束记录率 | 质量 | 已登记的假设与约束条数 ÷ 评审中识别出的假设与约束条数 | % | 计划文档、评审纪要 |
| 里程碑合理性 | 质量 | 满足“有明确交付物、有验收人、时间与关键路径一致”三项条件的里程碑数 ÷ 里程碑总数 | % | 进度计划、里程碑清单 |
| 工作范围覆盖率 | 完整性 | 已分解到工作包或任务的交付物数 ÷ 计划交付物总数 | % | WBS、交付物清单 |
| 依赖登记率 | 完整性 | 已登记前后置依赖的任务数 ÷ 存在外部或跨团队接口的任务数 | % | 任务依赖清单 |
| 资源覆盖情况 | 完整性 | 已明确负责人与投入量的关键任务数 ÷ 关键任务总数 | % | 资源计划、工时安排 |
| 风险覆盖情况 | 完整性 | 已登记应对措施的高影响风险数 ÷ 识别出的高影响风险数 | % | 风险登记册 |
| 任务粒度达标率 | 可执行性 | 工期与产出可在一周内核验的任务数 ÷ 任务总数 | % | 任务清单 |
| 依赖闭环率 | 可执行性 | 前后置依赖均有明确对接人与交付时间的依赖数 ÷ 已登记依赖总数 | % | 依赖清单 |
| 资源可得性 | 可执行性 | 关键任务所需资源已获承诺的工时 ÷ 关键任务所需总工时 | % | 资源承诺记录、工时计划 |
| 基线变更受控率 | 可执行性 | 经评审并留痕的基线变更数 ÷ 基线变更总数 | % | 变更记录、评审记录 |
指标与标准的对应关系需要在评估方案中固定下来，避免同一指标在不同评审中被归入不同标准。任务粒度达标率中的“一周”是示例阈值，实际使用时按项目节奏设定并在评估说明中写明，不同项目之间不直接套用同一阈值比较。
数据口径与证据：指标怎么取数、如何核验
每个指标都要写清分子、分母、时间窗和单位，否则同一名称的指标在不同人手里会算出不同结果。时间窗建议统一为“基线冻结日”这一时点，取该时点计划中的内容，不纳入之后新增的任务。以依赖闭环率为例：分子是已登记依赖中对接人与交付时间均明确的条数，分母是基线中全部已登记依赖条数，单位为百分比，取数时点为基线冻结日。
分母为零或数据缺失时，处理规则要事先约定：
- 分母为零表示该指标在本次评估中不适用，标注“不适用”，不按 0% 或 100% 计入汇总。
- 数据缺失表示无法判断，标注“数据缺失”并记录缺失原因，在结论中作为待补项列出。
- 同一指标既有不适用又有缺失时，分别标注，不合并为同一类问题。
定量指标之外，定性判断需要证据支撑。常用证据类型包括：计划文档及其版本记录、评审会议纪要、依赖清单、资源承诺记录、风险登记册、变更审批记录。证据核验采用抽查方式：对关键路径上的任务、跨团队依赖、高影响风险三类条目做全量核对，其余条目按不低于 20% 的比例随机抽查，抽查样本范围在评估说明中写明，便于复核。
当计划基线、依赖与变更记录集中在一个协作平台中管理时，取数会顺畅很多。以 ONES 为例，项目计划支持按目标、交付物或项目阶段分解工作并设置任务前后置依赖与里程碑；设置计划与里程碑基线后，可对比版本细节追溯变更。这些记录可以作为依赖登记率、里程碑合理性与基线变更受控率的取数来源，具体字段与导出方式以实际环境配置为准。
计算与评估步骤：从取数到形成结论
评估按固定顺序推进，保证结果可复算、可复核：
- 确定评估范围与基线版本。写明项目名称、基线版本号、冻结日期和评估人，明确本次评估覆盖哪些交付物与阶段。
- 按口径计算各项指标。逐项填写分子、分母、时间窗与结果，分母为零或数据缺失的按约定标注，不强行计算。
- 对关键项做证据抽查与交叉验证。关键路径任务、跨团队依赖、高影响风险全量核对；抽查中发现指标值与证据不一致时，以证据为准修正指标并记录修正原因。
- 按标准汇总为三档判断。每组标准下的指标结果与证据结论合并，形成“达标、有条件达标、不达标”三档判断，并写明支撑该判断的具体条目。
- 形成评审意见与基线调整建议。列出必须在开工前补齐的缺口、可带入执行阶段跟踪的观察项，以及需要调整基线的内容。
汇总时建议使用一张结论表，把标准、指标结果、证据结论、判断档位和改进动作放在同一行，评审会上逐行确认。判断档位的划分标准由项目组在评估前约定，例如“全部关键指标有证据支撑且无重大缺口”为达标，“存在缺口但有明确补齐计划与责任人”为有条件达标，“关键指标缺证据或缺口无补救安排”为不达标。
示例：一份计划基线的评估演算
以下为演示情景，用于说明计算与核验过程，数据为假设值。
某系统升级项目，基线冻结日为 3 月 1 日，计划包含 40 个交付物、120 个任务、18 条跨团队依赖、6 个高影响风险、5 个里程碑。
- 工作范围覆盖率：40 个交付物中 36 个已分解到任务，36 ÷ 40 = 90%。
- 依赖登记率：存在接口的任务共 20 个，已登记依赖的 16 个，16 ÷ 20 = 80%。
- 依赖闭环率：18 条已登记依赖中，对接人与交付时间均明确的 13 条，13 ÷ 18 ≈ 72.2%。
- 任务粒度达标率：120 个任务中 96 个可在一周内核验产出，96 ÷ 120 = 80%。
- 里程碑合理性：5 个里程碑中 4 个有明确交付物与验收人，4 ÷ 5 = 80%。
证据抽查发现三个问题：一是未分解的 4 个交付物中有 2 个属于关键路径，缺口影响可执行性判断；二是 5 条未闭环依赖中有 3 条涉及外部供应商，对接人未指定；三是有 1 个里程碑的时间与关键路径推算结果相差两周，需要复核。
据此形成判断：完整性为“有条件达标”，工作范围覆盖与依赖登记存在缺口，但缺口清单明确、可在两周内补齐；可执行性为“不达标”，关键路径交付物未分解且外部依赖未闭环，直接阻碍推进；质量为“有条件达标”，里程碑合理性需复核后确认。改进建议包括：开工前完成关键路径交付物分解、指定外部依赖对接人、复核里程碑时间并更新基线。
解读与限制：结果怎么用、哪些情况不可比
指标反映的是计划本身的特征，不能直接推导执行结果。一份覆盖率高的计划仍可能因外部条件变化而延期，评估结论只说明计划在编制层面的完备程度。把评估结果直接当作团队绩效结论，会误导管理动作，也会让后续评估失去真实性。
不同项目类型与规模之间不宜直接横向比较。研发项目与交付型项目在任务粒度、依赖密度上差异明显，同一阈值在小规模项目上可能过严、在大规模项目上可能过松。跨项目比较时应先确认指标口径、时间窗与阈值一致，否则只做趋势观察，不做排名。
分母为零与数据缺失会削弱结论的可靠性。当多个关键指标处于“不适用”或“数据缺失”状态时，三档判断应相应下调置信度，并在评审意见中列为待补事项，而不是用剩余指标强行给出达标结论。
评估结果的使用边界是计划评审与基线调整：用于确认基线是否可以批准、哪些缺口需要补齐、变更后的新基线是否仍满足标准。执行阶段的偏差跟踪、资源再分配属于另一套管理动作，需要结合执行数据单独分析。ONES 的项目计划与基线能力可以为上述评审提供版本对比与变更追溯的记录基础，评估口径与判断标准仍由项目组自行约定。
常见问题
计划基线冻结之后又新增了任务，评估时要不要算进去？
按基线冻结日这一时点取数，冻结之后新增的任务不计入本次评估的分子与分母，否则同一份基线在不同时间评估会得出不同结果。新增内容如果影响关键路径或外部依赖，可以作为观察项写入评审意见，并在下一次基线变更时纳入新版本重新评估。
关键指标大多处于“数据缺失”状态，还能给出达标结论吗？
不建议。多个关键指标无法判断时，三档判断应下调置信度，并在评审意见中列为待补事项，先补齐证据再确认基线。用剩余指标强行给出达标结论，会让评估结果失去复核价值。
任务粒度达标率里的“一周”阈值可以改吗？
可以，阈值由项目组在评估前约定并写入评估说明。研发项目与交付型项目节奏不同，同一阈值在小规模项目上可能过严、在大规模项目上可能过松。调整阈值后，跨项目比较需要先确认口径一致，否则只做趋势观察，不做排名。
评估结论能不能直接用于团队绩效考核？
不建议。指标反映的是计划编制层面的完备程度，覆盖率高的计划仍可能因外部条件变化而延期。评估结论的用途是计划评审与基线调整，包括确认基线能否批准、哪些缺口开工前必须补齐、变更后的新基线是否仍满足标准；执行偏差与绩效判断需要结合执行数据单独分析。
用协作平台管理计划，哪些评估数据可以直接取？
计划分解、任务前后置依赖、里程碑、基线与变更记录集中在平台中管理时，依赖登记率、里程碑合理性与基线变更受控率可以从这些记录取数。以 ONES 为例，项目计划支持按目标、交付物或项目阶段分解工作并设置任务依赖与里程碑，设置计划与里程碑基线后可对比版本细节追溯变更。具体字段与导出方式以实际环境配置为准，派生指标是否需要人工统计需在评估前确认。
