判断一份项目计划是否不合理，评估对象是计划本身，而非执行结果。可以从六个维度逐项核验：活动完整性、依赖关系、资源与工期假设、基线一致性、可验证的验收与里程碑、风险与假设的记录。每个维度都要落到可核对的对象上，例如活动清单、依赖图、资源分配表、基线版本和里程碑验收条件。发现缺口时，先确认是计划本身缺失，还是记录口径不一致，再判断是否构成不合理。
要点总览（TL;DR）
- 判断计划是否合理，评估对象是计划文档本身：活动清单、依赖图、资源分配表、基线版本、里程碑条件和风险假设记录，执行阶段的进度偏差不在其中。
- 六个维度可逐项核验：活动完整性、依赖关系、资源与工期假设、基线一致性、可验证的验收与里程碑、风险与假设的记录。
- 定量项要写明公式、分母和时间窗，例如活动覆盖率、依赖完整率、资源负载率；定性项要落到文档位置，材料缺失统一记为待确认。
- 结论按缺口严重程度分级：阻断级（如循环依赖、关键路径缺失）、需修正级（如资源负载超限、里程碑缺完成条件）、可接受级，单维度缺口不直接等于整体不合理。
- 计划发生变更后结论需重新评估，评估记录应与计划版本绑定，在版本变更时复核关键维度。
评估目标：判断计划不合理要回答什么问题
评估计划合理性，回答的是一个具体问题：这份计划在现有信息下，能否支撑项目按预期交付。判断依据来自计划文档本身，包括范围分解、依赖安排、资源与工期估算、基线记录、里程碑条件和风险假设。执行过程中出现的进度落后、成本超支，属于进度管理的分析对象，不纳入本文判断范围。
“不合理”在这里指计划在三个方面存在缺口：完整性，即该有的活动、依赖、条件是否齐全；一致性，即计划各组成部分之间是否互相矛盾，例如工期与资源负载对不上、当前版本与批准基线不一致；可执行性，即计划是否具备可落地的前提，例如里程碑有明确完成条件、关键假设有记录。三者缺一，计划的可信度就会下降。
需要区分两类工作：执行偏差的原因分析归进度管理，具体任务的排期与依赖排布操作归任务排期与依赖管理。本文只处理“拿到一份计划，如何判断它是否站得住”这一任务，输出的是评估结论和待确认项，不替代排期操作。
六个判断维度与核验范围
六个维度覆盖计划的主要构成部分，每个维度对应一类可核验对象。评估时逐项对照，避免只凭整体印象下结论。
| 维度 | 核验对象 | 核验范围 |
|---|---|---|
| 活动完整性 | 交付物清单、工作分解结构（WBS）、活动清单 | 每项交付物是否有对应活动，每项活动是否有明确产出 |
| 依赖关系 | 依赖图、任务前后置关系记录 | 前置后置是否成对记录，是否存在循环依赖，起始活动是否被误设为可并行 |
| 资源与工期假设 | 资源分配表、工时估算、人员技能与可用时间 | 工期与工作量是否匹配，同一人同期负载是否超过可用工时，估算是否有依据 |
| 基线一致性 | 当前计划版本、已批准基线、变更记录 | 范围、里程碑日期、关键依赖的改动是否走变更记录 |
| 验收与里程碑 | 里程碑清单、验收标准 | 每个里程碑是否有可验证的完成条件，而非只有日期 |
| 风险与假设 | 风险登记、假设清单、应对措施 | 关键假设是否记录，风险是否有对应应对 |
活动完整性关注范围覆盖。把交付物清单与WBS逐项对照，找出没有对应活动的交付物，以及没有明确产出的活动。依赖关系关注逻辑闭环，重点看是否存在循环依赖，以及关键路径上的活动是否被遗漏前置条件。资源与工期假设关注数字之间是否自洽，工期明显短于工作量、同一人同期被分配超过可用工时，都是需要核实的信号。
基线一致性关注版本纪律。当前计划与已批准基线之间的差异，应能对应到变更记录；范围、里程碑日期、关键依赖被改动却无记录，说明计划版本管理存在缺口。验收与里程碑关注可验证性，只有日期没有完成条件的里程碑，无法判断是否真正达成。风险与假设关注前提是否显性化，外部依赖、审批周期、人员到位这类关键假设若未记录，计划的可执行性就缺少支撑。
数据口径与证据：每个维度看什么材料
每个维度都需要明确的证据来源和判断口径。定量项给出公式和单位，定性项给出证据类型和通过标准，材料缺失统一记为待确认。
| 维度 | 指标或证据 | 口径 |
|---|---|---|
| 活动完整性 | 活动覆盖率 | 有对应活动的交付物数 ÷ 交付物总数；分母为零时记为待确认 |
| 依赖关系 | 依赖完整率 | 已记录依赖的任务数 ÷ 应存在依赖的任务数；需先界定“应存在依赖”的范围 |
| 资源与工期 | 资源负载率 | 分配工时 ÷ 可用工时，按同一时间窗计算，单位为人时或人天 |
| 基线一致性 | 差异项清单 | 逐条列出与基线的差异，标注是否对应变更记录，不只给总数 |
| 验收与里程碑 | 里程碑条件完备性 | 定性证据：每个里程碑是否写明交付物、验收标准或决策点 |
| 风险与假设 | 关键假设记录情况 | 定性证据：关键假设是否列明，是否有对应应对措施 |
定量指标需要注明时间窗和分母口径。活动覆盖率的分母是交付物总数，若计划尚未列出交付物清单，分母为零，此时不能算出覆盖率，应记为待确认，而不是判为不合理。依赖完整率依赖“应存在依赖”的界定，通常以活动之间的输入输出关系为依据，界定不清时先缩小范围再计算。资源负载率按同一时间窗统计，跨周或跨月汇总会掩盖峰值，评估时应看关键时间窗内的负载。
定性项的证据要具体到文档位置。里程碑条件完备性看的是每个里程碑条目下是否写有可验证的完成条件；风险与假设看的是关键假设是否被显性记录。材料缺失时统一记为待确认，既不推断为不合理，也不推断为合理。这一处理方式能避免因资料不全而误判，也为后续补充材料留出空间。
评估步骤：从取数到给出结论
评估按固定顺序推进，先锁定对象，再逐维度取数，最后交叉验证并分级。这样得出的结论可复算、可追溯。
- 确定评估范围与计划版本。明确评估的是哪一份计划、哪个版本、覆盖哪个时间段，避免拿不同版本的材料混用。
- 按维度取数并记录证据。每个维度记录证据来源、计算过程和结果，定量项写明公式与分母，定性项写明判断依据。
- 交叉验证。检查维度之间是否互相矛盾，例如工期估算与资源负载是否冲突，里程碑日期与依赖关系是否一致，基线差异是否解释了当前版本的变化。
- 按缺口严重程度分级。阻断级缺口指关键路径缺失、存在循环依赖等使计划无法成立的问题；需修正级指资源负载明显超限、里程碑缺少完成条件等需要调整的问题；可接受级指个别活动描述粒度粗等不影响整体判断的问题。
- 形成结论并标注待确认项。结论写明各维度核验结果、缺口分级和待确认材料，便于后续复核。
交叉验证是判断计划是否自洽的关键一步。单看工期数字可能正常，但把同一批活动的人力分配叠加到同一时间窗，负载可能已经超出可用工时；单看里程碑日期可能合理，但对照依赖关系会发现某个里程碑的前置活动尚未排入计划。这类矛盾比单维度缺口更能说明计划存在问题。
在计划版本与基线记录的管理上，ONES 瀑布项目管理解决方案支持设置项目计划和里程碑基线，并对比版本细节以追溯变更；ONES Plan 支持制定项目里程碑和甘特图，多时间跨度查看进度。评估时可以把当前计划与基线版本逐项比对，把差异项对应到变更记录，作为基线一致性维度的证据来源。资源负载方面，ONES 提供工时日历和饱和度报表，可用于核对同一时间窗内的分配工时与可用工时。这些能力服务于取数和比对动作，结论仍由评估者依据证据作出。
示例：一份计划如何被判为不合理
以下为演示情景，用于说明核验与计算过程，不代表真实项目数据。
某系统升级项目计划版本为V2.3，交付物清单列出8项交付物，WBS中记录活动22项，里程碑4个，计划周期为10周。评估按六个维度逐项核验。
| 维度 | 核验结果 | 计算或证据 | 分级 |
|---|---|---|---|
| 活动完整性 | 7项交付物有对应活动，1项“上线培训材料”无对应活动 | 活动覆盖率 = 7 ÷ 8 = 87.5% | 需修正 |
| 依赖关系 | 发现“接口联调”与“环境准备”互为前置，形成循环 | 依赖图中存在闭环 | 阻断 |
| 资源与工期 | 第4周两名开发人员分配工时合计120人时，可用工时为80人时 | 资源负载率 = 120 ÷ 80 = 150% | 需修正 |
| 基线一致性 | 里程碑“联调完成”日期较基线提前5天，无变更记录 | 差异项1条，未对应变更记录 | 需修正 |
| 验收与里程碑 | 4个里程碑中2个只有日期，未写完成条件 | 条件完备的里程碑为2个 | 需修正 |
| 风险与假设 | “第三方接口按期提供”未记录为假设，也无应对 | 关键假设缺失1项 | 待确认 |
计算过程中出现两类需要特殊处理的情况。活动覆盖率的分母为8，可以正常计算；若该项目未列交付物清单，分母为零，则应记为待确认，不能判为不合理。资源负载率按第4周这一时间窗计算，若改为10周整体汇总，峰值会被摊薄，掩盖超载问题，因此口径必须注明时间窗。
综合结论：依赖关系存在循环，属阻断级缺口，计划在当前版本下无法成立；活动完整性、资源负载、基线一致性和里程碑条件存在需修正缺口；风险与假设记录缺失，记为待确认。整体判断为不合理，主要依据是阻断级缺口，其余缺口需在修订时一并处理。
解读与限制：结论怎么用、哪里会误判
评估结论用于判断计划是否具备支撑交付的基础，不能直接等同于执行结果。单维度缺口不必然说明计划整体不合理，需要结合缺口严重程度判断。例如个别活动描述粒度粗，属于可接受级问题；而关键路径缺失或循环依赖，则会使计划无法成立。结论应写明分级依据，便于读者理解判断的分量。
计划详细程度因项目类型而异，不能套用统一达标线。小型项目可能不需要逐项列出所有依赖，大型复杂项目则需要更完整的分解和记录。评估时应结合项目规模、复杂度和组织惯例设定核验深度，把“缺少某项记录”与“该项记录在本项目中不必要”区分开。
指标反映的是计划质量的线索，不保证执行结果。活动覆盖率高，说明范围分解较完整，但不代表执行不会出现偏差；资源负载率在合理区间，也不代表人员技能匹配。评估结论应作为修订计划的输入，而非对项目成败的预判。
计划发生变更后，结论需要重新评估。基线更新、范围调整、资源变化都会改变各维度的核验结果，原有结论随之失效。把评估记录与计划版本绑定，在版本变更时复核关键维度，能让判断持续有效。
常见问题
计划里没有列出交付物清单，活动完整性还能判断吗？
可以判断，但结论要换一种写法。活动覆盖率的分母是交付物总数，没有交付物清单时分母为零，算不出覆盖率，此时应把活动完整性记为待确认，而不是直接判为不合理。可行的替代做法是拿范围说明书、合同附件或需求清单作为临时对照物，逐项检查是否有对应活动；如果连这些材料也没有，就先把“缺少交付物清单”本身作为一项待确认缺口记录下来，等材料补齐后再核验。
循环依赖为什么算阻断级缺口，而不是需修正？
循环依赖意味着两个或多个活动互为前置，按计划逻辑没有任何一个可以先行启动，计划在依赖层面无法成立，因此归为阻断级。需修正级缺口通常是计划可以成立但需要调整的问题，例如资源负载超限、里程碑缺少完成条件。实际评估时，发现循环依赖后应先确认是记录错误还是真实逻辑冲突：如果是依赖录入方向写反，修正记录后重新核验；如果是业务逻辑本身冲突，则需要重新设计活动顺序，再判断其余维度。
资源负载率按周算还是按月算，结论会不一样吗？
会不一样。资源负载率是分配工时除以可用工时，必须注明时间窗。按月汇总会把峰值摊薄，掩盖某一周的集中超载；按周计算更容易暴露短期冲突。评估时建议以关键路径所在的时间窗为准，对负载接近或超过可用工时的周单独列出。如果同一人在多个项目间共享，还需要把其他项目的分配工时一并计入，否则负载率会偏低。口径一旦确定，应在评估记录中写明，便于复核时复算。
计划与基线不一致，是否一定说明计划不合理？
不一定。基线一致性核验的是差异项是否对应变更记录。如果范围、里程碑日期或关键依赖发生改动，且变更有审批记录、差异可追溯，这属于正常的计划演进；如果改动没有记录、无法说明来源，才构成版本管理缺口。核对时逐条列出差异项并标注是否对应变更记录，比只给一个差异总数更有判断价值。差异项较多但都有记录，与差异项很少但无记录，两种情况的结论分量不同。
评估结论出来后，计划修订了，原来的结论还能用吗？
不能直接沿用。基线更新、范围调整、资源变化都会改变各维度的核验结果，原有结论随之失效。建议把评估记录与计划版本绑定，在版本变更时至少复核受影响的关键维度：范围变了重查活动完整性，依赖调整了重查依赖关系，资源变化了重算负载率。对于未受影响的维度，可以保留原结论并注明对应的计划版本，避免每次变更都全量重做。
