范围基线核对清单用于在基线正式确认前，逐项判断范围内容是否完整、是否经过确认、后续变更是否有受控入口。它适合项目经理、范围负责人、业务代表和评审参与人在基线确认前或基线变更后重新确认前使用，按准备、内容核对、确认与归档三个阶段组织，每项写明通过标准、证据、负责人和是否阻断。
要点总览（TL;DR）
- 清单按准备、内容核对、确认与归档三个阶段组织，每项写明检查项、通过标准、证据、负责人和是否阻断。
- 内容核对是主体：范围说明书与WBS交付物一一对应、WBS编码连续无孤立节点、验收标准可判定、除外责任写明，这几项通常设为阻断项。
- 通过标准要写成可观察的结果或可查的文件，例如审批记录含审批人、日期和“通过”结论，避免“已确认”“已完成”这类无法判定的表述。
- 缺审批记录、WBS与范围说明书不一致、验收标准不可判定、除外责任缺失、变更入口未建立，任一未解除都不能确认基线。
- 核对结果建议沉淀到协作平台，把检查项建成工作项、证据与基线版本绑定，便于下一轮核对对照上一轮结论。
谁在什么时点使用这份核对清单
这份清单服务于一个明确动作：在范围基线被正式锁定之前，由相关角色逐项核对并给出通过或不通过的判断。使用对象和时点不同，关注点也不同，先对照下表确认自己处在哪个阶段。
| 使用角色 | 使用时点 | 主要关注 |
|---|---|---|
| 项目经理 | 基线确认前、变更后重新确认前 | 材料是否齐备、阻断项是否清零、审批与归档是否完成 |
| 范围负责人 | 内容核对阶段 | 范围说明书与WBS是否一致、验收标准是否可判定 |
| 需求或业务代表 | 内容核对与确认阶段 | 交付物是否覆盖业务需要、除外责任是否可接受 |
| 评审参与人 | 评审会前预读、评审会上确认 | 证据是否可查、结论是否有记录 |
进入核对前需要备齐四类前置输入：范围说明书、WBS及WBS词典、验收标准草案、审批流程约定。缺少任何一项，对应阶段的核对都无法给出有效结论，应先补齐再开始。基线变更后重新确认时，除上述材料外还需带上变更申请与变更影响说明，用于判断新版本是否完整承接了已批准的变更。
准备阶段：核对前需要备齐哪些材料
准备阶段只回答一个问题：材料是否存在、是否具备进入逐项核对的条件。这一阶段不评价内容质量，内容问题留到下一阶段处理。材料缺失时，由清单负责人记录缺件项、指定补齐责任人并约定补齐时点，缺件项未补齐前不进入内容核对。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 范围说明书存在且含项目目标、主要交付物、除外责任 | 三部分均有明确文字表述，可定位到具体章节 | 范围说明书文档及版本号 | 范围负责人 |
| WBS已分解到可估算、可分配的程度 | 最底层工作包能对应到责任角色和估算口径 | WBS文件或系统条目 | 项目经理 |
| WBS词典已配套 | 每个工作包均有对应的词典条目 | WBS词典文档 | 范围负责人 |
| 验收标准草案可判定 | 每条标准能对应到可观察的结果或可查的文件 | 验收标准草案 | 需求或业务代表 |
| 版本与审批流程已约定 | 版本编号规则、审批人、审批方式有书面约定 | 流程约定文档或会议记录 | 项目经理 |
材料缺失的处理方式应写入清单本身：缺件项标记为未就绪，记录补齐责任人和约定时点，并在下次核对时优先复查。这样处理可以避免核对会因个别材料缺失而整体中断，也避免在材料不全的情况下勉强给出通过结论。
内容核对阶段：范围基线本身要检查什么
内容核对是清单的主体，检查基线内容是否完整、一致、可判定。这一阶段的每一项都应能给出明确结论，无法判断的项按不通过处理并说明原因。
| 检查项 | 通过标准 | 证据 | 负责人 | 是否阻断 |
|---|---|---|---|---|
| 范围说明书与WBS交付物一一对应 | 范围说明书列出的每项交付物在WBS中均有对应工作包，WBS中无范围说明书之外的交付物 | 对照表或逐项核对记录 | 范围负责人 | 是 |
| WBS层级与编码连续、无重复、无孤立节点 | 编码规则统一，每个节点均有上级，无重复编号 | WBS文件 | 项目经理 | 是 |
| WBS词典说明每个工作包的产出与责任角色 | 每个工作包均有产出描述和明确责任角色 | WBS词典 | 范围负责人 | 否 |
| 验收标准具体到可判断通过或不通过 | 每条标准可对应到可观察结果或可查文件，无“基本满足”类表述 | 验收标准文档 | 需求或业务代表 | 是 |
| 假设条件与制约因素单独列出 | 假设与制约有独立章节或清单，逐条可读 | 范围说明书对应章节 | 范围负责人 | 否 |
| 除外责任写明 | 明确列出不纳入本次范围的事项，表述具体 | 范围说明书除外责任章节 | 需求或业务代表 | 是 |
| 范围与进度、成本的接口标注清楚 | 关键交付物与里程碑、成本估算口径有对应关系 | 范围说明书与计划文件的对照记录 | 项目经理 | 否 |
核对时建议按交付物逐条走查，而不是按文档章节通读。逐条走查更容易发现范围说明书与WBS之间的遗漏和多余项，也便于把每条结论直接记录到对应检查项下。发现不一致时，先记录差异位置和涉及的工作包，再判断属于文档修订还是范围调整，后者应转入变更流程处理。
确认与归档阶段：基线如何被正式锁定
内容核对通过后，还需要确认基线经过正式审批、版本唯一、变更入口可用。这一阶段核对的是锁定与可追溯性，不重复内容检查。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 审批记录完整 | 记录含审批人、审批时间、审批结论三项，结论明确为通过 | 审批单、会议纪要或系统审批记录 | 项目经理 |
| 基线版本号与生效日期唯一可查 | 版本号不与历史版本重复，生效日期明确 | 版本记录或系统条目 | 范围负责人 |
| 基线文档存放位置与访问权限明确 | 存放位置可定位，相关角色具备查看权限 | 文档库路径与权限设置记录 | 项目经理 |
| 变更控制入口已建立并告知相关角色 | 变更提交入口可用，相关角色知晓提交方式 | 变更流程说明与通知记录 | 项目经理 |
| 基线发布通知已发出 | 通知覆盖受影响角色，内容含版本号与生效日期 | 通知记录 | 项目经理 |
审批结论应明确写为通过或不通过，仅记录“已评审”无法支撑基线锁定。变更入口的核对重点在于入口是否存在、是否被相关角色知晓，变更如何批准属于变更管理流程的内容，不在本清单展开。
通过标准怎么写才可核验
通过标准的写法直接决定清单能否执行。可核验的标准描述可观察的结果或可查的文件，读者据此能独立判断通过与否；不可核验的标准停留在状态描述，不同人可能给出不同结论。
| 检查项 | 不可核验写法 | 可核验写法 |
|---|---|---|
| 除外责任 | 除外责任已确认 | 范围说明书除外责任章节列出不少于一项具体事项，且经业务代表书面确认 |
| 验收标准 | 验收标准清晰 | 每条验收标准均可对应到一份可查的验收记录或可观察的交付结果 |
| 审批记录 | 审批已完成 | 审批记录含审批人姓名、审批日期和“通过”结论 |
清单中应区分“必须满足”与“建议满足”。必须满足项对应阻断项，未满足即不能确认基线；建议满足项可以带条件通过，但需记录遗留事项和跟踪责任人。证据形式包括文档、记录、系统条目和签字页，写通过标准时同步写明证据形式，可以减少核对时的争议。
证据与负责人如何分配到每一项
每项检查指定一名负责人，负责提供证据并给出结论；证据写明来源与存放位置，便于复核人独立查验。负责人按职责分配：内容类检查由范围负责人承担，审批与归档类由项目经理承担，验收标准与除外责任由需求或业务代表承担。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 检查项编号 | 按阶段加序号，便于引用 | C-03 |
| 负责人 | 填写角色而非泛称，一人负责一项 | 范围负责人 |
| 证据来源 | 写明文档名称、系统条目或记录类型 | WBS词典第2版 |
| 证据位置 | 写明存放路径或系统位置 | 项目文档库/范围管理目录 |
| 复核人 | 与负责人不同人，负责抽查证据 | 评审参与人 |
| 核对结果 | 通过、不通过、带条件通过三选一，附说明 | 不通过：缺除外责任章节 |
交叉复核建议覆盖全部阻断项和至少部分非阻断项，复核人抽查证据是否与结论一致。核对结果统一记录在同一张表中，按检查项编号归档，便于基线变更后重新核对时对照上一轮结论。
阻断项与完成条件
阻断项是未解决即不能确认基线的问题。清单中应把阻断项单独列出，与建议项分开管理，避免在存在阻断项的情况下发出基线确认结论。
| 阻断项 | 解除条件 | 解除人 |
|---|---|---|
| 缺审批记录 | 补齐含审批人、时间、结论的审批记录 | 项目经理 |
| WBS与范围说明书不一致 | 差异项完成修订并重新对照通过 | 范围负责人 |
| 验收标准不可判定 | 每条标准改写为可观察结果或可查文件 | 需求或业务代表 |
| 除外责任缺失 | 范围说明书补充除外责任章节并经确认 | 需求或业务代表 |
| 变更入口未建立 | 变更提交入口可用并完成通知 | 项目经理 |
非阻断项可以带条件通过，但需记录遗留事项、责任人和计划完成时点，并在下一轮核对时复查。基线确认的最终完成条件是：全部阻断项解除、审批记录完整、版本号与生效日期已登记、发布通知已发出。四项同时满足，才可宣布基线锁定。
把核对结果落到协作工具里
核对结果如果只停留在个人表格中，基线变更后很难追溯上一轮结论和证据。把检查项、证据与审批状态沉淀到项目协作平台，可以让每次核对都留下可查记录。ONES 的项目计划支持创建工作分解结构（WBS），按目标、交付物或项目阶段等维度分解计划和工作，并可为任务设置前后置依赖、用里程碑标记重要时间点；项目计划和里程碑可设置基线，通过版本对比追溯变更细节。这些能力适合承载WBS核对结果与基线版本记录。
具体做法是：把清单中的每个检查项建成工作项或检查单条目，负责人和复核人作为处理人；证据文档关联到对应工作项，并与基线版本号绑定；审批结论记录在审批条目上，变更入口指向同一项目下的变更流程；复核与归档结果保留在系统中，供下一轮核对对照。ONES 围绕需求、基线、版本和变更建立统一管理对象，可支撑过程状态追踪和交付结果回溯。需要说明的是，现有资料描述的是项目计划和里程碑基线、需求基线，范围基线的独立设置方式需按实际配置确认；检查单模板也需按本文结构自行搭建。
常见问题
范围基线核对清单和范围管理计划是什么关系？
范围管理计划规定范围如何定义、确认和控制，核对清单是执行其中确认动作时使用的逐项检查工具。清单里的检查项来自范围管理计划的要求，例如验收标准如何判定、变更走哪个入口；清单本身不重新定义这些规则。如果团队还没有范围管理计划，可以先按本文清单跑一轮核对，把反复出现的判断口径补进计划，再固化为正式流程。
基线变更后重新确认，清单要全部重跑一遍吗？
不必全部重跑，但阻断项和受变更影响的部分必须重查。建议的做法是：先核对变更申请与变更影响说明是否完整，再针对受影响的工作包复查范围说明书与WBS的对应关系、验收标准和除外责任；审批记录、版本号、变更入口这类锁定类检查项每轮都要确认。未受影响的非阻断项可以引用上一轮结论，注明沿用依据和日期。
小项目也要做这么细的核对吗？
可以按项目规模裁剪检查项数量，但阻断项的逻辑建议保留。小项目可以把WBS词典与范围说明书合并成一份文档，把假设与制约写成简短列表，减少文档数量；范围说明书与WBS一致、验收标准可判定、审批记录完整、变更入口可用这几项仍然要查，因为它们决定基线能否被追溯。裁剪的是文档形式和工作量，不是判断基线是否成立的条件。
核对发现WBS里有范围说明书之外的交付物，应该怎么处理？
先记录差异位置和涉及的工作包，再判断性质：如果属于文档遗漏，补充范围说明书并重新对照；如果属于新增内容，应转入变更流程评估影响，批准后再纳入基线。两种情况都不要直接在核对表上勾选通过。差异记录本身要保留，作为下一轮核对的输入，也便于事后追溯基线为何调整。
核对结果放在文档里还是协作工具里更好？
取决于团队后续如何使用这些记录。如果只需要一次性留档，结构化文档即可；如果基线会多次变更、需要对照上一轮结论和证据，放在协作工具里更便于追溯。ONES 的项目计划支持创建工作分解结构（WBS），项目计划和里程碑可设置基线并通过版本对比追溯变更细节，可用来承载WBS核对结果与基线版本记录。范围基线的独立设置方式需按实际配置确认，检查单模板也需按本文结构自行搭建。
