项目计划编制检查清单应覆盖五类可核验项目：范围与交付物、活动与依赖、资源与工期、里程碑与关键路径、基线与变更规则。它用在计划初稿完成到基线审批之间，由项目经理、技术负责人、职能资源负责人和评审人逐项判定通过或不通过。范围未冻结、关键依赖未确认、关键资源未落实、基线未审批属于阻断项，未关闭不得发布计划。
要点总览（TL;DR）
- 清单覆盖五类检查项：范围与交付物、活动与依赖、资源与工期、里程碑与评审、基线与变更，每项写明通过标准、证据和负责人。
- 清单在计划初稿完成到基线审批之间使用，由项目经理、技术负责人、职能资源负责人和评审人分工核对，逐项标记通过、不通过或不适用。
- 通过标准要写成可观察的完成状态，证据选择可归档的形式，负责人按角色填写，人员变动时不必重写清单。
- 范围未冻结、关键依赖未确认、关键资源未落实、基线未审批属于阻断项，未关闭时计划停留在草稿状态，不发布。
- 检查结果、里程碑记录和基线版本可以放进同一工作空间，评审与后续变更追溯使用同一份数据。
谁在什么时点使用这份清单
这份清单服务于计划发布前的评审动作，使用对象和职责需要先固定下来，否则检查容易变成项目经理一个人的自查。建议在计划初稿完成、准备提交基线审批时启用，到基线审批通过为止。检查结果按“通过”“不通过”“不适用”三种状态记录，不适用项要写明理由。
| 角色 | 职责 | 检查时点 |
|---|---|---|
| 项目经理 | 组织清单填写，汇总不通过项，推动关闭阻断项 | 初稿完成时自检，评审前完成整改 |
| 技术负责人 | 核对交付物技术内容、活动分解合理性与关键路径判断 | 初稿完成后、评审会前 |
| 职能资源负责人 | 确认关键角色投入比例、可用时间与外部资源安排 | 资源计划形成时 |
| 评审人（计划审批人） | 复核阻断项关闭证据，决定是否批准基线 | 基线审批会上 |
判定方式统一为逐项标记：每项检查都要有明确的通过标准、对应证据和负责人，评审人依据证据判定，不依据口头说明。阻断项未关闭时，计划停留在草稿状态，不进入发布。
范围与交付物检查项
范围检查解决的是“计划覆盖的工作边界是否清楚”。边界不清的计划，后续的活动、工期和资源都会失去参照，因此这一组检查项应最先完成。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 项目目标与验收标准 | 目标可衡量，验收标准写明判定条件和验收方 | 项目立项文档或计划首页的目标章节 | 项目经理 |
| 交付物清单及责任人 | 每个交付物有名称、完成形态和唯一责任人 | 交付物清单表 | 项目经理、技术负责人 |
| 范围外事项 | 显式列出本期不做的事项及原因 | 范围说明中的排除项 | 项目经理 |
| WBS分解深度 | 分解到可估算工期和资源的工作包，每个工作包有明确产出 | WBS结构或计划分解视图 | 技术负责人 |
WBS分解是否到位，可以用一个简单办法判断：拿到任一工作包，负责人能否直接说出需要几个人、做多久、产出什么。说不清楚，说明还需要继续分解。
活动、依赖与工期检查项
这一组检查确认计划中的活动来自已确认的工作包，依赖关系和工期估算有依据，关键路径经过识别。活动凭空补充或依赖遗漏，都会让后续排期失真。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 活动来源 | 每项活动都能对应到WBS工作包，无孤立活动 | 活动与工作包的对应关系 | 技术负责人 |
| 依赖关系 | 活动间依赖标注类型（如完成—开始），外部依赖写明提供方和交付时间 | 计划中的依赖设置或依赖清单 | 项目经理 |
| 工期估算依据 | 每项估算记录依据（历史数据、专家判断、类比）和估算人 | 估算记录或计划备注 | 技术负责人 |
| 关键路径 | 识别出关键路径，并说明关键活动延误的影响 | 计划中的关键路径标注或说明文档 | 项目经理 |
外部依赖需要单独关注：供应方交付时间、接口方确认时间这类依赖不在项目团队控制范围内，检查时要确认对方已给出明确时间，并有对应的跟进责任人。
资源、角色与成本检查项
资源检查的目的是避免计划建立在“人应该有空”的假设上。每个工作包都要落到具体负责人，关键角色的投入比例和可用时间要经过职能负责人确认。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 工作包负责人 | 每个工作包指定了负责人，无未分配项 | 计划中的负责人字段 | 项目经理 |
| 关键角色投入 | 关键角色的投入比例与可用时间经职能负责人确认 | 资源确认记录或排期表 | 职能资源负责人 |
| 外部资源与采购 | 外部服务、采购需求列入计划，注明到货或到位时间 | 采购清单或外部资源安排 | 项目经理 |
| 资源冲突 | 已识别的冲突有处理方式（调整时间、替换人员、增加投入） | 冲突清单及处理结论 | 职能资源负责人 |
资源冲突的处理结论要写进计划，而不是停留在会议记录里。处理方式涉及调整里程碑的，需要同步更新里程碑检查项。
里程碑、评审点与沟通安排检查项
里程碑是计划的可跟踪控制点。检查时确认每个里程碑对应明确的交付物、评审人和通过标准，同时确认例会和汇报节奏已写入计划。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 里程碑与交付物对应 | 每个里程碑日期对应至少一个交付物，日期与活动排期一致 | 里程碑清单 | 项目经理 |
| 评审人与通过标准 | 每个里程碑明确评审人和判定通过的条件 | 评审安排表 | 技术负责人 |
| 沟通节奏 | 例会频率、汇报对象、信息同步方式写入计划 | 计划中的沟通安排章节 | 项目经理 |
| 风险与问题上报路径 | 写明上报对象、时限和升级条件 | 沟通安排或风险管理说明 | 项目经理 |
评审人需要提前确认可参加评审的时间。里程碑日期与评审人档期冲突，属于计划编制阶段就应解决的问题，留到执行阶段再协调会压缩纠偏空间。
基线、变更与版本检查项
基线检查确认计划发布后有可追溯的版本和明确的变更规则。没有基线，后续的进度对比和变更追溯都缺少参照点。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 版本与基线日期 | 计划记录版本号和基线日期 | 计划版本记录 | 项目经理 |
| 基线审批 | 审批人已签字或书面确认 | 审批记录或确认消息 | 评审人 |
| 变更流程 | 写明变更申请、影响评估、批准权限的流程 | 变更管理说明 | 项目经理 |
| 变更后更新与通知 | 明确变更批准后计划更新责任人和通知范围 | 变更流程文档 | 项目经理 |
变更流程要写清谁有权批准哪一级变更。范围调整、里程碑移动、关键资源替换通常需要更高层级审批，普通活动日期微调可由项目经理处理，权限划分在计划发布前确定。
通过标准、证据与负责人怎么填
清单是否好用，取决于每一行能否被独立判断。填写时遵循三条规则：通过标准写成可观察的完成状态，证据选择可归档的形式，负责人按角色填写。
- 通过标准：写“每个工作包有唯一负责人且无未分配项”，不写“负责人基本明确”。能用数量、状态或确认动作描述的，优先用具体描述。
- 证据形式：文档、评审记录、确认消息、系统字段都可以作为证据，选择能随计划一起归档的形式。口头确认需要转成书面记录后再作为证据。
- 负责人：按角色填写，如“技术负责人”“职能资源负责人”，具体人名在项目启动时映射到角色，人员变动时不需要重写清单。
- 不通过处理：每项不通过时写明整改动作、责任人和复检时点，复检通过后才更新为“通过”。
示例行：检查项“关键角色投入已确认”，通过标准“关键角色投入比例与可用时间经职能负责人书面确认”，证据“资源确认记录”，负责人“职能资源负责人”，不通过时“由项目经理在评审前两个工作日内组织确认并补充记录”。
阻断项与计划发布条件
阻断项是从检查项中提炼出的不可放行条件。以下四项未关闭时，计划不发布、不进入执行跟踪。
| 阻断项 | 关闭证据 | 确认人 |
|---|---|---|
| 范围未冻结 | 范围说明经确认，范围外事项已列出 | 项目经理、评审人 |
| 关键依赖未确认 | 外部依赖提供方给出书面时间承诺，内部依赖已排入对方计划 | 项目经理 |
| 关键资源未落实 | 关键角色投入经职能负责人确认 | 职能资源负责人 |
| 基线未审批 | 审批人签字或书面确认基线版本 | 评审人 |
发布前的最终确认动作由项目经理执行：汇总全部检查项状态，确认无未关闭阻断项，将检查结果附在计划评审材料中，提交评审人批准基线。评审人批准后，计划版本和基线日期一并记录，作为后续变更对比的起点。
用ONES承载检查项与基线记录
清单里的检查项如果只停留在文档中，评审时容易出现证据分散、版本对不上的情况。把计划结构、检查结果和基线记录放进同一工作空间，可以让评审和后续追溯使用同一份数据。
在ONES中，可以用「项目计划」创建工作分解结构，按目标、交付物或项目阶段分解计划和工作，工作项承载活动、负责人和前后置依赖；里程碑用来标记重要时间点、事件或决策点，与评审记录关联。资源安排方面，项目经理可以通过工时日历查看资源饱和度，据此调整节点负责人。计划与里程碑可以设置基线，通过版本对比追溯变更细节。这样，检查清单中的“证据”可以直接指向系统中的工作项字段、里程碑记录和基线版本，评审人按同一口径核对，发布后的变更也有记录可查。
需要说明的是，以上承载方式适用于使用ONES项目管理相关方案的场景，具体模块配置和审批流程设置以团队实际环境为准。执行阶段的进度偏差处理不在本文检查范围，可在计划发布后按变更与跟踪流程另行管理。
常见问题
项目计划编制检查清单和计划评审会议是什么关系？
清单是评审会前的准备材料，评审会是依据清单做判定的场合。项目经理在初稿完成后组织填写，把不通过项和阻断项提前整改，评审人再按清单中的证据逐项复核，决定是否批准基线。两者顺序颠倒，评审会容易变成现场补材料。
小项目也要逐项填完整份清单吗？
可以按项目规模裁剪检查项，但阻断项不建议裁剪。范围、关键依赖、关键资源和基线审批这四项直接决定计划能否作为后续跟踪的参照，小项目同样需要确认。活动与依赖、里程碑与沟通等检查项可以合并简化，判定标准仍要写清楚，避免清单变成走过场。
检查项判定为“不适用”时怎么处理？
“不适用”需要写明理由和确认人，例如项目没有外部采购，外部资源与采购检查项可标为不适用，并注明由项目经理确认。不适用不等于跳过，评审人仍要看到理由，防止用“不适用”掩盖未完成的工作。
计划发布后发生变更，检查清单需要重新走一遍吗？
不需要整份重走，但变更涉及范围、里程碑或关键资源时，应回到对应检查项复核，并更新基线版本。变更流程中写明的评估和批准动作要留下记录，变更后的计划版本与基线日期一并更新，后续对比才有准确起点。
检查清单和基线记录放在文档里还是放进项目管理系统？
两种方式都能用，区别在证据是否集中。放在文档里，证据容易散落在邮件、会议记录和聊天消息中，评审时需要对多份材料。放进项目管理系统，工作项字段、里程碑记录和基线版本可以直接作为证据，评审人按同一口径核对。在ONES中，可以用「项目计划」创建工作分解结构，工作项承载活动、负责人和前后置依赖，里程碑与评审记录关联，计划与里程碑可设置基线并通过版本对比追溯变更。
