项目计划合理性评审适合放在计划投入执行之前，用来检查目标、范围、里程碑、资源和依赖是否自洽。正式评审通常出现在立项后形成基线计划、重大变更、跨团队交付、外部承诺和高风险节点；范围小、结构简单、影响面有限且可快速回退的计划，可以由负责人按关键字段做轻量检查并留痕。判断依据是计划错误的代价和不确定性，项目名称和规模标签只作参考。
要点总览（TL;DR）
- 正式评审适合放在计划即将成为执行依据的节点：立项后形成基线计划、重大范围或里程碑变更、跨团队交付与外部承诺前、高风险或强依赖节点前。
- 范围小、结构简单、影响面有限、可快速回退且不涉及外部承诺的计划，可由负责人按目标、里程碑、责任人、关键依赖四项自查并留痕。
- 取舍依据是计划错误的修正成本与不确定性：修正成本明显高于组织一次正式评审的成本时选正式评审，反之选轻量检查，并保留从轻量升级到正式的通道。
- 计划信息尚不完整时先补齐再评审；执行偏差归进度管理，具体任务排期与依赖编排归排期机制，不靠计划合理性评审解决。
- 分级规则是否合适可用一两个项目试点验证，观察评审发现的问题类型与投入是否匹配，再细化触发条件的具体描述。
先判断值不值得评审：计划错误的代价有多大
计划合理性评审要回答一个具体问题：这份计划在进入执行前，是否具备可执行的基础。检查对象包括目标是否清晰、范围边界是否明确、里程碑是否对应可交付成果、资源是否与工作量匹配、关键依赖是否已识别并有人负责。评审的价值来自提前发现那些返工代价高的错误，例如目标理解偏差导致整段工作方向错误、里程碑设置遗漏关键交付物、资源明显不足却按满负荷排期、外部依赖未确认就对外承诺时间。
是否值得正式评审，可以用两个维度判断。第一个维度是错误代价：计划缺陷一旦进入执行，修正需要多少返工、是否影响外部承诺、是否波及多个团队。第二个维度是不确定性：目标、范围、资源或依赖中是否存在尚未确认的关键假设。代价高且不确定性大的计划，正式评审的投入更容易被证明合理；代价低且假设清楚的小计划，轻量检查足以覆盖主要风险。
这个判断起点也解释了为什么不能按项目名称或预算规模一刀切。一个金额不大的对外交付项目，可能因为承诺日期固定而需要正式评审；一个内部工具改造项目，即使工作量不小，如果范围清晰、可分批上线、失败可回退，也可以先做轻量检查。评审分级应围绕“错了会怎样”和“现在有多少没确认的事”来设定。
哪些阶段需要正式评审
正式评审适合安排在计划即将成为执行依据的节点上。以下四类阶段或场景，通常值得组织一次有明确参与角色的正式评审。
- 立项后形成基线计划时。项目从意向进入执行，需要把目标、范围、里程碑、资源和依赖固化为可对比的基线。此时正式评审可以确认计划要素是否齐全、假设是否成立，并为后续变更提供参照。
- 重大范围或里程碑变更时。范围明显扩大或收缩、关键里程碑前移或后移、交付物定义发生变化，都会改变原有计划的可行性。变更后的计划需要重新检查资源与依赖是否仍然匹配，避免在旧计划上叠加新要求。
- 跨团队交付与外部承诺前。当计划涉及多个团队的交接、共同交付节点，或需要向客户、合作方承诺时间与范围时，正式评审可以把各方对交付物、接口和时间点的理解对齐，减少执行中的责任模糊。
- 高风险或强依赖节点前。计划中包含技术验证、外部供应商、审批许可、关键人员到位等强依赖时，正式评审应重点检查依赖的确认状态、备选方案和触发条件，确认计划没有建立在未验证的假设上。
这些节点的共同特征是：计划一旦确定，后续调整的成本明显上升。正式评审不必覆盖计划的所有细节，但应围绕目标一致性、范围边界、里程碑可交付性、资源可行性和关键依赖确认状态形成明确结论，并记录需要补齐的事项。
什么情况可以只做轻量检查
轻量检查适用于计划错误代价较低、不确定性可控的场景。典型条件包括：范围小且边界清楚，工作结构简单，参与角色少，影响面限于一个团队或一个明确模块，出现问题时可以快速回退或调整，不涉及外部承诺和强依赖。这类计划如果套用完整正式评审，参与成本和准备材料可能超过计划本身的风险。
轻量检查不需要完整评审会，但也不能省略关键字段。负责人可以按以下检查项逐条确认并留下记录：
- 目标：计划要达成的结果是否可以用一句话说清，完成标志是否可观察。
- 里程碑：关键时间点是否对应具体交付物或决策点，是否存在只有日期没有产出的空里程碑。
- 责任人：每项主要工作是否有明确负责人，负责人是否知晓并接受该安排。
- 关键依赖：计划依赖的外部输入、其他团队产出或前置条件是否已确认，未确认的是否有跟进人和时间点。
轻量检查由计划负责人自查并留痕即可，记录方式可以是一份简短检查表、一条计划说明或评审记录。留痕的目的在于让后续执行有据可查，也便于在问题出现时判断是计划假设有误还是执行偏差。若自查中发现目标模糊、关键依赖未确认或资源明显不足，应升级为正式评审，而不是在轻量路径上勉强通过。
正式评审与轻量检查的投入差异
两种方式的差别主要在参与角色、准备材料和结论形式，取舍时应把投入与计划风险放在一起看。
| 对比项 | 正式评审 | 轻量检查 |
|---|---|---|
| 适用条件 | 错误代价高、不确定性大，或处于基线形成、重大变更、跨团队交付、外部承诺、高风险节点 | 范围小、结构简单、影响面有限、可快速回退、不涉及外部承诺 |
| 参与角色 | 计划负责人、执行团队代表、依赖方、资源负责人，必要时包括业务或客户方代表 | 计划负责人为主，必要时请关键依赖方确认 |
| 准备材料 | 计划说明、范围与交付物清单、里程碑与基线、资源估算、依赖清单及确认状态 | 简版计划或检查表，覆盖目标、里程碑、责任人、关键依赖 |
| 时间投入 | 需要协调多方时间，通常包括材料准备、评审会和结论整理 | 负责人按检查项逐条确认，可在较短时间内完成 |
| 结论形式 | 形成评审结论、待办事项和责任人，必要时调整计划后再确认 | 检查记录留痕，发现高风险项时升级为正式评审 |
取舍依据可以归纳为一句话：当计划错误的修正成本明显高于组织一次正式评审的成本时，选择正式评审；当计划可以在短时间内调整且影响范围有限时，选择轻量检查。两种方式之间应保留升级通道，轻量检查发现目标、资源或依赖存在重大不确定时，及时转入正式评审。
在协作工具中承载这套分级时，重点是把检查项和结论留痕。以ONES为例，项目计划可以按目标、交付物或项目阶段分解工作，任务之间可设置前后置依赖，里程碑用于标记重要时间点、事件或决策点；计划和里程碑基线可用于后续对比计划与执行的偏差。这些能力适合承载评审所需的计划要素和记录，评审分级规则本身仍需组织自行定义。
哪些情况应暂缓评审或改用其他机制
评审不是越早越好，也不是所有问题都能靠评审解决。以下情况应暂缓正式评审，或改用其他管理机制。
- 计划信息尚不完整。目标、范围、关键交付物或资源估算还停留在口头阶段时，正式评审容易变成信息补充会，结论也难以落地。应先由负责人补齐计划要素，再进入评审。
- 问题属于执行偏差。计划已经通过评审并进入执行，实际进度与计划出现偏差，这类问题应归入进度管理，通过跟踪、纠偏和变更控制处理，不需要重复做计划合理性评审。
- 问题属于具体任务排期与依赖编排。任务先后顺序、资源日历、依赖关系调整属于排期与依赖管理的工作，评审应关注计划整体是否自洽，具体排期细节由日常排期机制处理。
暂缓不等于取消。暂缓时应明确补齐信息和重新评审的时间点，避免计划在信息不完整的状态下直接进入执行。把评审边界划清，也能减少评审会承载过多议题、结论分散的情况。
用试点验证评审分级是否合适
分级规则是否合适，靠实际运行来检验。可以选择一两个项目试行：一个按正式评审路径执行，一个按轻量检查路径执行，观察两类计划在评审中发现的问题类型、投入时间和后续执行中的计划变更情况。
试点时重点观察三件事：正式评审发现的问题是否确实属于返工代价高的类型，还是大量集中在可以通过自查解决的基础信息缺失；轻量检查是否漏掉了后来造成明显返工的计划缺陷；两种路径的实际投入与参与角色的时间成本是否与预期相符。若轻量检查频繁出现需要升级的情况，说明分界偏松；若正式评审大量时间用于补齐基础信息，说明触发条件偏早或准备材料要求不清晰。
根据试点结果调整分界时，优先修改触发条件的具体描述，例如把“跨团队交付”细化为“涉及两个以上团队共同交付且存在交接节点”，把“高风险”细化为可判断的依赖未确认或外部承诺已发出。调整后再运行一轮，确认正式评审与轻量检查各自覆盖的计划类型稳定，分级规则即可作为常规机制使用。
常见问题
轻量检查由负责人自查，如何避免变成走过场？
轻量检查要留下可核对的记录，而不是口头确认。负责人按目标、里程碑、责任人、关键依赖逐项填写结论，每项写明依据或待确认事项。记录的作用有两个：一是执行中出现问题时，可以回看当时的计划假设是否成立；二是当自查发现目标模糊、关键依赖未确认或资源明显不足时，有明确依据触发升级为正式评审。若连续多个项目的轻量检查记录都只有结论没有依据，说明检查项设计或执行方式需要调整。
项目已经进入执行，发现计划本身有问题，应该补做评审吗？
先区分问题性质。如果是实际进度与计划出现偏差，属于进度管理范畴，通过跟踪、纠偏和变更控制处理。如果是计划的前提假设被推翻，例如范围定义错误、关键依赖确认失败、资源估算明显偏离实际，这类问题已经超出执行偏差，应针对受影响的计划部分重新检查，必要时组织正式评审确认调整后的计划是否自洽。补做评审的范围可以限定在变更部分，不必重走完整流程。
跨团队交付一定要正式评审吗？
跨团队交付通常涉及交接节点和共同交付物，各方对范围、接口和时间点的理解不一致时，修正成本较高，因此默认倾向正式评审。但如果交付内容简单、接口清晰、参与团队少且可以分批交付，也可以先做轻量检查，重点确认各团队的交付物、交接时间和责任人。判断的关键是交接环节是否存在未确认的假设，以及理解偏差一旦发生是否会影响多个团队。
试点验证分级规则时，观察多久比较合适？
试点周期应覆盖至少一个完整的计划制定到执行阶段，让正式评审和轻量检查各自经历一次计划变更或偏差处理。观察指标包括：正式评审发现的问题中，有多少属于返工代价高的类型，有多少属于自查即可发现的基础信息缺失；轻量检查的计划中，是否出现后来造成明显返工的缺陷；两种路径的实际投入时间与参与角色成本。试点结束后根据结果调整触发条件描述，再运行一轮确认分界稳定。
计划评审的检查项和记录可以放在协作工具里吗？
可以。以ONES为例，项目计划可以按目标、交付物或项目阶段分解工作，任务之间可设置前后置依赖，里程碑用于标记重要时间点、事件或决策点；计划和里程碑基线可用于后续对比计划与执行的偏差。这些能力适合承载评审所需的计划要素和记录。评审分级规则、检查项内容和结论标准仍需组织自行定义，工具承载的是计划信息与留痕。
