项目计划完整性检查清单覆盖八个维度：范围与交付物、活动分解、依赖与逻辑、里程碑与时间、资源与责任、成本与预算、风险与假设、审批与基线。每个维度都要落到可核验的字段，并写明通过标准、证据、负责人和检查时点。缺少交付物验收口径、关键依赖未确认或审批记录缺失，应列为阻断项，补齐后才能进入执行。下文按维度给出可直接使用的检查表，并说明检查记录与审批如何留痕。
要点总览（TL;DR）
- 清单覆盖八个维度：范围与交付物、活动分解、依赖与逻辑、里程碑与时间、资源与责任、成本与预算、风险与假设、审批与基线，每个维度落到可核验字段。
- 每项检查写明通过标准、证据、负责人和检查时点，评审人依据证据判断，避免口头确认。
- 交付物缺验收标准、关键依赖未确认、审批记录缺失属于阻断项，未关闭不得放行。
- 放行需同时满足四项：阻断项关闭、一般整改项有责任人和期限、评审人签署、计划形成基线版本。
- 检查记录可落到工作项与文档状态上，ONES 的项目计划、里程碑与基线能力可作为承载参考，具体以实际版本与套餐为准。
谁在什么时点使用这份检查清单
这份清单服务于计划定稿前的完整性评审，使用对象是项目经理、职能负责人和独立评审人。项目经理负责准备材料并逐项自检，职能负责人确认本职能范围内的资源、交付物和依赖，评审人依据证据判断是否通过。三类角色在同一张表上留下结论，避免计划评审变成口头确认。
检查时点有两个：计划首次定稿前，以及基线变更前。首次定稿前的检查决定计划能否进入执行；基线变更前的检查决定变更后的计划能否重新冻结。两个时点使用同一套检查项，区别在于变更时只需重点复核受影响维度，并确认未受影响部分仍然有效。
检查前需要准备三类前置输入：项目章程，用于核对目标与授权；范围说明，用于核对交付物与边界；资源可用性信息，用于核对角色、投入比例和档期。缺少前置输入时，相关检查项无法判断通过，应记为待补而非默认通过。
这份清单与执行阶段的进度跟踪保持边界。清单只回答“计划是否完整、是否可放行”，执行阶段的进度偏差分析、纠偏措施和排期调整不在检查范围内。执行中出现偏差时，应回到变更流程，而不是用本清单替代进度管理。
| 使用对象 | 检查时点 | 主要动作 | 输出 |
|---|---|---|---|
| 项目经理 | 计划定稿前 | 准备前置输入，逐项自检并附证据 | 自检记录与待整改项 |
| 职能负责人 | 计划定稿前 | 确认本职能的资源、交付物与外部依赖 | 职能确认意见 |
| 评审人 | 计划定稿前、基线变更前 | 依据证据判断通过与否，标记阻断项 | 评审结论与放行签署 |
| 项目经理与评审人 | 基线变更前 | 复核受影响维度，确认变更影响已评估 | 变更后重新基线记录 |
范围与交付物维度：检查哪些字段
范围维度的核心判断是：每个交付物都能被验收，范围边界能被说清。交付物清单要逐项列出名称、验收标准和交付时点，验收标准应具体到可判断的程度，例如文档通过哪一级评审、系统通过哪类测试、培训覆盖哪些岗位。只写“完成开发”“交付报告”这类描述，无法在验收时形成一致判断。
范围边界要同时写明做什么和不做什么。不做事项不是可有可无的备注，它决定了后续变更申请的判断基准。交付物责任人和交付时点要落到具体角色，避免出现多个部门都以为对方负责的情况。范围变更的登记方式也要在计划中约定，包括由谁提出、记录在哪里、何时评估影响。
| 检查项 | 通过标准 | 证据 | 负责人 | 阻断 |
|---|---|---|---|---|
| 交付物清单完整 | 每个交付物有名称、验收标准、交付时点 | 交付物清单文档 | 项目经理 | 是（缺验收标准时） |
| 范围边界明确 | 写明纳入范围与不做事项 | 范围说明 | 项目经理 | 否 |
| 交付物责任到人 | 每项交付物有明确责任角色 | 责任分配表 | 职能负责人 | 否 |
| 变更登记方式约定 | 写明提出渠道、记录位置与评估时点 | 变更管理约定 | 项目经理 | 否 |
活动分解与依赖逻辑维度：检查哪些字段
活动分解要细到可以估算工期和分配责任的程度。判断粒度是否合适，可以看每个活动能否给出一个工期区间、一个责任角色和一项可交付成果。分解过粗会让工期估算失去依据，分解过细会增加管理成本，通常以“一个责任人在一个汇报周期内可完成”作为参考尺度。
依赖检查要覆盖依赖类型和前后置关系。完成到开始、开始到开始等依赖类型应写明，前置活动和后置活动要能对应上。工期估算要附依据，例如历史数据、专家判断或类比估算，只写天数而不写来源，评审时无法判断合理性。关键路径或关键链要在计划中标识出来，让评审人知道哪些活动的延误直接影响交付时点。
外部依赖与接口方单独列出。外部依赖包括供应商交付、其他团队接口、第三方审批等，每项要写明接口方、约定时间和当前确认状态。外部依赖未确认，属于典型阻断情形，因为它的不确定性不在项目团队控制范围内。
| 检查项 | 通过标准 | 证据 | 负责人 | 阻断 |
|---|---|---|---|---|
| 活动分解粒度 | 每个活动有工期、责任角色、可交付成果 | 工作分解结构 | 项目经理 | 否 |
| 依赖关系完整 | 依赖类型与前后置活动一一对应 | 依赖关系表 | 项目经理 | 是（关键依赖未确认时） |
| 工期估算有依据 | 每项估算注明方法或参考数据 | 估算说明 | 职能负责人 | 否 |
| 关键路径已标识 | 计划中标注关键路径或关键链 | 进度计划 | 项目经理 | 否 |
| 外部依赖已确认 | 接口方、时间、确认状态齐全 | 接口确认记录 | 职能负责人 | 是 |
里程碑、时间与资源维度：检查哪些字段
里程碑要对应验收节点或决策点，而不是把普通任务改个名字。每个里程碑应写明达成标志、验收人和计划日期。计划开始与完成日期要覆盖全部活动，并检查是否存在无日期的活动或日期倒挂。时间基准一旦确定，后续变更应通过变更流程处理。
资源检查关注角色、投入比例和可用性三件事。每个角色要写明投入比例，例如某角色在项目期内投入百分之五十，并核对同期其他项目是否占用同一资源。责任分配矩阵用于确认每项活动都有唯一责任人，避免共同负责变成无人负责。资源冲突与调配约定要提前写明，包括冲突由谁协调、调配优先级如何确定。
| 检查项 | 通过标准 | 证据 | 负责人 | 阻断 |
|---|---|---|---|---|
| 里程碑定义清晰 | 每个里程碑有达成标志、验收人、日期 | 里程碑清单 | 项目经理 | 否 |
| 日期完整无倒挂 | 全部活动有起止日期，逻辑顺序正确 | 进度计划 | 项目经理 | 否 |
| 资源投入已确认 | 角色、投入比例、可用档期齐全 | 资源计划 | 职能负责人 | 否 |
| 责任分配矩阵完整 | 每项活动有唯一责任人 | 责任分配矩阵 | 项目经理 | 否 |
| 资源冲突有约定 | 写明协调人与调配优先级 | 资源调配约定 | 职能负责人 | 否 |
成本、风险与假设维度：检查哪些字段
成本检查先看预算口径是否统一。预算科目要与活动或交付物对应，估算口径要写明是人力成本、采购成本还是其他费用，避免不同部门用不同口径汇总。成本责任人和审批人要明确，预算调整走哪条审批路径也要在计划中约定。
风险登记要包含风险描述、影响、概率、应对措施和责任人。只列风险不写应对措施，登记就失去意义。关键假设要单独列出并写明验证方式，例如“假设接口方在某一时点前提供测试环境”，验证方式可以是定期确认或书面回复。假设失效的触发条件也要写明，触发后由谁启动应对、是否需要变更计划。
| 检查项 | 通过标准 | 证据 | 负责人 | 阻断 |
|---|---|---|---|---|
| 预算科目与活动对应 | 科目可追溯到活动或交付物 | 预算表 | 项目经理 | 否 |
| 估算口径统一 | 写明成本类型与估算方法 | 估算说明 | 职能负责人 | 否 |
| 成本审批明确 | 有成本责任人与审批路径 | 审批约定 | 项目经理 | 否 |
| 风险有应对措施 | 每项风险有影响、概率、措施、责任人 | 风险登记表 | 项目经理 | 否 |
| 假设有验证方式 | 关键假设写明验证方式与失效触发条件 | 假设清单 | 项目经理 | 否 |
审批、基线与变更控制维度：检查哪些字段
审批检查要确认审批人和审批记录都存在。审批人应覆盖项目发起人、职能负责人和必要的质量或财务角色，审批记录要能追溯到具体版本和时间。只有口头同意而没有记录，不能视为审批完成。
基线检查关注版本与冻结时点。计划冻结后应形成基线版本，记录冻结日期和冻结范围。变更申请要写明变更内容、原因和影响评估，影响评估至少覆盖范围、时间、资源和成本四个方面。变更获批后需要重新审批并更新基线，未重新审批的变更不应直接进入执行。
| 检查项 | 通过标准 | 证据 | 负责人 | 阻断 |
|---|---|---|---|---|
| 审批链完整 | 审批人覆盖必要角色，记录可追溯 | 审批记录 | 项目经理 | 是（审批缺失时） |
| 基线已冻结 | 有基线版本号与冻结时点 | 基线记录 | 项目经理 | 否 |
| 变更影响已评估 | 覆盖范围、时间、资源、成本 | 变更申请单 | 变更提出人 | 否 |
| 变更后重新审批 | 获批变更完成重新审批并更新基线 | 变更审批记录 | 评审人 | 是（未重新审批时） |
阻断项与完成条件
阻断项的判定规则是：该项缺失会导致计划无法被执行或被验收，且无法在执行中低成本补救。按此规则，交付物没有验收标准、关键依赖未确认、审批记录缺失属于典型阻断项。一般整改项则包括表述不清、证据不完整但不影响执行判断的问题，可在限定时间内补齐。
整改闭环要求每项未通过检查都记录整改责任人、整改期限和复检方式。复检由原评审人或其指定人员执行，复检通过后在检查表上更新状态。阻断项必须全部关闭，一般整改项可以带条件放行，但要在放行记录中写明补齐期限。
完成条件包括：全部阻断项关闭，一般整改项有明确责任人和期限，评审人签署放行结论，计划形成基线版本。四项同时满足，计划才可进入执行。缺少签署或基线记录，放行结论不成立。
| 类别 | 判定规则 | 处理方式 | 放行影响 |
|---|---|---|---|
| 阻断项 | 缺失导致无法执行或验收，执行中难以补救 | 限期补齐并复检 | 未关闭不得放行 |
| 一般整改项 | 不影响执行判断，但证据或表述不完整 | 记录责任人与期限 | 可带条件放行 |
| 放行条件 | 阻断项关闭、整改项有期限、评审签署、基线形成 | 评审人签署结论 | 满足后方可执行 |
用ONES承载检查记录与审批流转
检查表落地时，可以把每个检查项建成工作项或检查单条目，字段对应检查项、通过标准、证据、负责人和检查时点。这样每项检查都有独立状态，评审时按状态汇总，未通过项自然形成整改清单，不需要另建表格维护。
证据以附件或文档关联的方式挂在对应检查项下，交付物清单、依赖关系表、风险登记表都可以作为关联文档保留版本。审批流转通过状态变更体现，从待检查到已通过或已驳回，每次变更留下操作人和时间。基线版本在计划冻结时形成，后续变更对比可以追溯到具体版本，检查记录与审批结论随之保留。
ONES 的项目计划支持按目标、交付物或阶段分解工作，任务可设置前后置依赖，里程碑用于标记重要时间点，计划和里程碑可设置基线并对比版本细节。资源方面可通过工时日历查看饱和度并调整节点负责人。这些能力可作为检查表落地的承载参考，具体可用性以实际版本与套餐为准。检查清单本身仍需按本文维度自行搭建，并在评审前确认审批链配置方式。
常见问题
计划评审时，一般整改项可以带条件放行吗？
可以。一般整改项指不影响执行判断、但证据或表述不完整的问题，例如某份估算说明缺少方法备注。处理方式是记录整改责任人和补齐期限，由评审人在放行记录中写明条件，计划即可进入执行。阻断项不适用这一处理，必须全部关闭并复检通过。
带条件放行后，补齐期限到期时应安排复检，避免整改项长期挂账。复检结论同样记入检查表，与放行记录一并保留。
基线变更前，检查清单需要全部重跑一遍吗？
不需要全部重跑。基线变更前的检查重点是受影响维度，例如范围变更重点复核交付物清单、验收标准和依赖关系，资源调整重点复核投入比例与责任分配矩阵。未受影响的维度确认仍然有效即可，并在检查记录中注明复核范围。
变更获批后仍需重新审批并更新基线，未重新审批的变更不应直接进入执行。
外部依赖由供应商或其他团队控制，检查时如何判断是否通过？
判断依据是确认状态，而不是依赖本身是否已经交付。检查项要求写明接口方、约定时间和当前确认状态，并有书面确认记录，例如邮件回复、接口确认单或会议纪要。只有口头承诺、没有约定时间的依赖，应记为未确认。
关键外部依赖未确认属于阻断项，因为它的不确定性不在项目团队控制范围内，执行中难以低成本补救。
检查记录和审批结论放在哪里，才能在执行阶段追溯？
常见做法是把每个检查项建成工作项或检查单条目，状态体现待检查、已通过、已驳回，证据以附件或关联文档挂在对应条目下。审批通过状态变更留痕，记录操作人和时间。
ONES 的项目计划支持按目标、交付物或阶段分解工作，任务可设置前后置依赖，里程碑用于标记重要时间点，计划和里程碑可设置基线并对比版本细节，可作为检查记录与审批留痕的承载参考，具体可用性以实际版本与套餐为准。
成本与预算维度在检查表里要写到什么程度？
检查表关注的是口径是否统一、责任是否明确，不要求给出精确的财务核算方法。至少确认三点：预算科目能追溯到活动或交付物，估算口径写明成本类型与估算方法，成本责任人与审批路径明确。预算调整走哪条审批路径，也应在计划中约定。
如果组织已有财务口径要求，检查项应与该口径对齐，避免计划中的预算表与财务汇总表使用不同标准。
