项目计划编制检查清单应包含哪些项目

项目计划编制检查清单应覆盖五类可核验项目：范围与交付物、活动与依赖、资源与责任、里程碑与时间、基线与变更规则。清单在计划初稿完成、评审会前和基线确认前三个时点使用，每项写明通过标准、证据和负责人，并给出通过、不通过或阻断的结论。本文给出一套可直接用于评审的检查表，并在范围、依赖、里程碑与基线环节说明如何借助ONES承载对应的管理动作。

要点总览（TL;DR）

• 项目计划编制检查清单覆盖五类项目：范围与交付物、活动与依赖、资源与责任、里程碑与时间、基线与变更规则。
• 清单在计划初稿完成、评审会前、基线确认前三个时点使用，每项给出通过、不通过或阻断的结论，并记录证据与负责人。
• 通过标准要写成可观察的事实，例如依赖登记表含提供方与承诺日期；证据缺失按不通过处理。
• 关键交付物无验收标准、关键路径活动无责任人、外部依赖无承诺时间、基线无审批人，这四类问题会阻断基线确认。
• 计划放行需同时满足：全部检查项有结论、阻断项清零、基线版本与审批记录齐全。

谁在什么时点使用这份清单

这份清单解决的是“计划编完了没有、能不能拿去评审和确认基线”，不评估执行阶段的进度偏差。使用前先明确三类角色和三个时点，避免自查、复核和终检混在一起做。

角色	使用时点	检查范围	判定结论
计划编制人（项目经理）	计划初稿完成时	全部检查项逐项自查	通过 / 不通过 / 阻断
技术负责人、资源负责人	评审会前	活动分解、依赖、资源投入与技能匹配	通过 / 不通过，附证据
评审人（项目发起人或计划评审组）	计划评审会中	范围、里程碑、基线内容与变更规则	通过 / 不通过 / 阻断
项目经理与审批人	基线确认前终检	阻断项是否清零、证据是否齐全	放行 / 不放行

判定采用三档：通过表示证据齐全且符合标准；不通过表示存在缺口但可在约定时间内补齐；阻断表示该问题不解决就不能进入基线确认。每项结论都要记录证据位置和负责人，口头确认不计入通过。清单的边界停在“计划是否编制完整”，执行中的偏差分析与纠偏属于项目进度管理的范围，具体任务的排期算法与依赖操作属于任务排期与依赖管理的范围。

范围与交付物检查项

范围部分是计划的起点。这一节确认工作边界和产出物定义清楚，后续的活动分解、资源估算才有依据。以下五项逐条核对。

检查项	通过标准	证据	负责人
项目目标与验收标准	目标写明可判断完成的结果，验收标准列出判定条件与判定人	计划文档中的目标与验收章节	项目经理
交付物清单	每个交付物有名称、形态（文档、系统、实物等）、接收方	交付物清单表	项目经理、技术负责人
范围边界	明确写出包含项与不包含项，不包含项至少覆盖易混淆的相邻工作	范围说明章节	项目经理
关键假设与外部依赖	假设逐条记录并注明不成立时的影响；外部依赖写明提供方	假设与依赖登记表	项目经理
范围变更路径	写明变更由谁提出、谁评估、谁确认，确认后如何更新计划	变更规则说明或流程记录	项目经理、审批人

在ONES中，项目计划可按目标、交付物或项目阶段等维度分解计划和工作，形成工作分解结构（WBS），范围边界与交付物清单可以对应到同一份计划结构里，评审时按结构逐层核对，减少清单与计划脱节的情况。

活动、依赖与排期检查项

这一节确认计划中的活动可执行、依赖可追溯。活动粒度太粗会导致责任无法分配，依赖缺失会让排期在评审后被反复推翻。

检查项	通过标准	证据	负责人
工作分解粒度	每项活动可估算工期、可分配到具体责任人，通常控制在两周以内可完成	WBS 或任务清单	项目经理、技术负责人
紧前紧后依赖	每项活动的依赖已标注，并写明类型（完成—开始、开始—开始等）	依赖登记表	技术负责人
外部依赖	写明提供方、交付内容与承诺时间，承诺时间有书面确认	依赖登记表、确认邮件或会议记录	项目经理
关键路径	关键路径或关键链条已识别，路径上的活动有责任人和工期	进度计划中的路径标注	项目经理
排期依据	记录工期估算方法（类比、参数、专家判断等）及所依据的历史数据	估算说明或评审记录	技术负责人

依赖登记表建议至少包含以下字段，便于逐条核对：依赖编号、前置活动、后置活动、依赖类型、提供方（内部或外部）、承诺时间、当前状态、确认人。字段齐全的登记表本身就是通过证据，缺提供方或缺承诺时间的条目直接判为不通过。

ONES支持为项目任务设置前后置依赖，使任务关联清晰可查；项目计划中也可关联迭代和研发任务，便于在评审时把研发侧的活动与依赖一并核对。

资源、责任与成本检查项

活动分解完成后，要核对人力、设备、预算是否与活动匹配，责任是否落到具体角色。这一节的常见问题是“活动有人名但没有投入量”，导致排期看似完整、执行时才发现资源冲突。

检查项	通过标准	证据	负责人
责任人与配合角色	每项活动有唯一责任人，配合角色列明	任务清单中的责任人字段	项目经理
投入量与工期匹配	人员投入量（人天或投入比例）与活动工期一致，不出现同一人同期超配	资源投入表	资源负责人
关键技能与稀缺资源	关键技能人员的可用时间已确认，冲突项已登记	资源日历或确认记录	资源负责人
外部采购、设备与场地	需求已列入计划，注明到位时间与责任人	采购或资源需求清单	项目经理
成本与预算	成本口径（人力、采购、其他）写明，预算审批状态已记录	预算表与审批记录	项目经理、审批人

资源冲突项不必在编制阶段全部解决，但必须登记为待确认项，写明冲突的活动、涉及人员和拟解决时点，否则不能判为通过。ONES的工时日历可用于查看资源饱和度并据此调整节点负责人，成员工时报表与饱和度报表可用于分析资源利用情况，适合在评审前核对投入量与工期是否匹配。

里程碑、基线与变更规则检查项

这一节确认计划具备可跟踪、可比较的基准。里程碑若只是时间点，执行中无法判断是否真正达成；基线若没有版本和审批记录，后续变更就无从追溯。

检查项	通过标准	证据	负责人
里程碑定义	每个里程碑对应可验证的交付结果或决策点，而非单纯日期	里程碑清单
里程碑日期一致性	里程碑日期与关键依赖、评审节点一致，无前后矛盾	进度计划与里程碑清单对照	项目经理
基线内容	基线包含范围、进度、资源三类内容，并注明版本号	基线版本登记表	项目经理
基线审批	审批人与确认时间已记录	审批记录	审批人
变更流程	变更申请、评估、批准、重基线的步骤与责任人已写明	变更管理规则	项目经理

基线版本登记表建议包含：版本号、基线日期、包含范围、进度与资源版本、审批人、确认时间、变更说明。ONES支持设置项目计划和里程碑基线，并可通过对比版本细节追溯变更，适合在基线确认后保留可比较的记录。

通过标准、证据与负责人如何填写

清单能否起作用，取决于每一项是否写成可观察的事实。填写规则有三条：通过标准描述“看到什么算通过”，证据写明确切位置，负责人按检查动作分配而非按职位笼统分配。

• 通过标准写成可观察的事实，例如“依赖登记表含提供方与承诺日期”，避免“已考虑”“基本明确”这类无法判定的表述。
• 证据形式包括文档链接、评审记录、确认邮件、系统字段截图；证据要能定位到具体条目，而不是只给一个文档名。
• 负责人区分编制人自检与评审人复核：编制人对全部条目负责自查，评审人只对分配到的条目出具复核结论。
• 未通过项记录整改责任人与复检时点，复检时重新判定，不在原结论上直接改写。
• 证据缺失时按不通过处理，不按默认通过处理。

一条完整填写示例：检查项“外部依赖写明提供方与承诺时间”；通过标准“依赖登记表中每条外部依赖均有提供方名称和书面承诺日期”；证据“依赖登记表第 3—7 行，附供应商确认邮件”；负责人“项目经理（自检）、技术负责人（复核）”；结论“不通过，第 6 行缺承诺日期，整改责任人项目经理，复检时点为评审会前一日”。

阻断项与计划可发布条件

阻断项是必须清零才能确认基线的问题。以下四类问题出现任一项，计划不进入基线确认：关键交付物没有验收标准；关键路径上的活动没有责任人；外部依赖没有承诺时间；基线没有审批人。

非阻断项可以带条件通过，但需登记整改期限和责任人，并在基线确认记录中注明。整体完成条件为三条同时满足：全部检查项有明确结论；阻断项清零；基线版本与审批记录齐全。

判定结果	条件	后续动作
放行	全部检查项有结论，阻断项为零，基线版本与审批记录齐全	确认基线，按分发范围发布计划，进入执行跟踪
带条件放行	无阻断项，存在已登记整改期限的不通过项	确认基线并注明待整改项，到期复检
不放行	存在任一阻断项	退回编制人整改，整改后重新终检

基线确认后，移交动作包括两项：按约定范围分发计划与基线版本，明确执行跟踪的入口和责任人。此后计划进入执行阶段，偏差对比与纠偏按项目进度管理的流程处理，本清单不再重复检查。

常见问题

计划评审会上被退回的常见原因有哪些，清单能提前拦住哪些？

评审退回多集中在几类可提前核对的问题：交付物没有可判断完成与否的验收标准；关键路径上的活动没有落到具体责任人；外部依赖只有口头时间、没有书面承诺；基线内容缺版本号或审批人。这些在清单中已列为阻断项，编制人自查阶段就能发现并补齐。

另一类退回原因是活动粒度太粗，评审时无法判断工期估算是否合理。清单要求活动分解到可估算、可分配责任人的粒度，评审前先按这一条自查，能减少会上反复讨论。

小型项目也要做完整基线和变更流程吗？

基线的作用是留下可比较的参照，项目规模小并不意味着可以省略。范围、进度、资源三类内容可以简化记录，但版本号和确认人应当保留，否则后续调整时无法说明改了什么、由谁确认。

变更流程可以按项目复杂度裁剪步骤，例如合并评估与批准环节，但提出、评估、批准、重基线的路径要写明。清单检查的是路径是否存在、责任人是否明确，不要求所有项目采用同一套审批层级。

清单里的证据一定要是系统截图吗？

不一定。证据的作用是让复核人能定位到具体条目，文档链接、评审记录、确认邮件、系统字段截图都可以。关键是能指向具体内容，例如依赖登记表的第几行、哪封确认邮件，而不是只给一个文档名称。

如果证据只能口头说明，按不通过处理。整改后再补证据并重新判定，不在原结论上直接改写。

基线确认之后计划又变了，清单还要再用一次吗？

基线确认后计划进入执行阶段，日常的偏差对比与纠偏按项目进度管理的流程处理，不需要每次都用这份清单。当发生范围、里程碑或关键资源调整并需要重新基线时，可针对受影响的部分重新核对：范围边界、里程碑定义、基线内容与审批记录。

重新基线同样要保留版本号和确认时间，便于与上一版对比追溯。

用ONES承载这份清单时，哪些检查项能直接在系统里核对？

范围与交付物可以对应到项目计划的工作分解结构，按目标、交付物或阶段逐层核对；活动依赖可在任务上设置前后置依赖，评审时直接查看关联；里程碑可在计划中标记，基线可设置项目计划和里程碑基线并通过版本对比追溯变更。

资源投入方面，工时日历可查看资源饱和度，成员工时报表与饱和度报表可用于分析资源利用情况。版本要求、套餐归属与部署方式需以实际产品信息为准。