项目启动授权评审要回答一个具体问题：这个项目现在能否投入资源正式启动。需要确认的事项集中在五类：启动依据与目标是否成立、范围与交付物是否清晰、资源与预算是否有承诺、角色与决策权是否到位、风险与退出条件是否明确。本文给出一份分阶段检查清单，每项都写明通过标准、所需证据和负责人；任一阻断项未通过，就不应签发启动授权。
要点总览（TL;DR）
- 项目启动授权评审只判断单个项目现在能否投入资源启动，多个项目之间的优先级排序属于提案准入环节。
- 需要确认的五类事项是：启动依据与目标、范围与交付物、资源与预算、角色与决策权、风险与退出条件。
- 每项检查都要写明可观察的通过标准、可当场查看的证据和单一责任人，评审会才能逐项打勾。
- 目标不可衡量、范围边界不清、无验收人、无预算承诺、核心角色未确认、无退出条件属于阻断项，任一未通过不应签发授权。
- 非阻断项可以带条件放行，但要在授权记录中写明整改责任人和完成时限，并在约定检查点复核。
谁在什么时点使用这份授权检查清单
这份清单服务于单个项目的启动授权评审，不用于多个项目之间的优先级排序，也不覆盖项目执行中的进度与质量管理。它解决的是“立项材料已经齐备，是否批准正式启动并投入资源”这一道关口。使用对象和时点对应如下。
| 使用角色 | 在评审中的职责 | 主要关注的检查阶段 |
|---|---|---|
| 项目发起人 | 说明立项理由与目标，确认资源承诺，签署授权 | 启动依据与目标、资源与授权 |
| 项目经理 | 准备检查材料，逐项自检，记录整改事项 | 全部阶段，重点是范围与风险 |
| 业务负责人 | 确认业务问题真实、目标与业务优先级一致 | 启动依据与目标、验收口径 |
| 财务审批人 | 核对预算来源与审批记录 | 资源、预算与角色授权 |
| 资源审批人 | 确认人力投入与关键成员可用性 | 资源、预算与角色授权 |
使用时点应放在立项材料齐备之后、正式启动会与资源实际投入之前。此时项目尚未大规模动用人力与预算，评审结论可以直接决定是否放行。需要区分两个关口：项目提案准入判断的是“这个方向值不值得做”，可能同时比较多个候选；启动授权判断的是“这一个项目现在能不能启动”。本文只处理后者，提案阶段的比较与排序不在清单范围内。
启动依据与目标确认：立项理由是否站得住
第一阶段判断项目是否具备启动的业务依据。这一阶段的检查项缺失时，后续范围与资源讨论都缺少参照，因此多数条目应设为阻断项。
| 检查项 | 通过标准 | 证据 | 负责人 | 阻断 |
|---|---|---|---|---|
| 业务问题与立项理由 | 有书面说明，写清当前问题、影响对象和发生场景 | 立项说明文档 | 项目发起人 | 是 |
| 项目目标 | 目标可衡量，写明完成时间和衡量口径 | 目标说明或立项文档中的目标章节 | 项目发起人 | 是 |
| 预期收益与不做的后果 | 收益有描述和估算依据；不启动的影响写明 | 收益测算说明、业务方确认记录 | 业务负责人 | 否 |
| 与组织优先级的一致性 | 能对应到当前阶段重点任务或上级目标 | 优先级对照说明、评审纪要 | 业务负责人 | 否 |
目标条目最容易写成“提升效率”“优化体验”这类无法判断完成与否的表述。通过标准要求目标包含对象、变化方向和衡量方式，例如“将某类订单的人工复核比例从当前水平降至约定比例，并在某时间点前完成”。收益估算允许有假设，但假设要写明，便于评审人判断其合理性。
范围、交付物与验收口径确认
第二阶段确认“做什么、交付什么、谁来验收”。范围不清的项目在启动后最容易出现反复追加和验收争议，因此范围边界与验收人应作为阻断项。
| 检查项 | 通过标准 | 证据 | 负责人 | 阻断 |
|---|---|---|---|---|
| 范围内事项 | 逐项列出本阶段要完成的工作与产出 | 范围说明文档 | 项目经理 | 是 |
| 范围外事项 | 明确列出本次不做的内容，避免默认包含 | 范围说明文档中的排除项 | 项目经理 | 是 |
| 主要交付物清单 | 每项交付物有名称、形式、责任人和计划完成时间 | 交付物清单 | 项目经理 | 是 |
| 验收标准与验收人 | 每项主要交付物有可判断的验收条件，并指定验收人 | 验收标准文档、验收人确认记录 | 业务负责人 | 是 |
| 关键里程碑与时间基线 | 形成初版里程碑，标注关键节点日期 | 里程碑计划 | 项目经理 | 否 |
验收标准要写到可以判断“通过或不通过”的程度。以文档类交付物为例，“完成需求说明书”不是验收标准，“说明书覆盖约定的业务场景，经业务负责人评审并记录评审结论”才具备可判断性。里程碑初版允许在启动后细化，但关键节点日期应在授权时可见，便于资源审批人判断投入节奏。
资源、预算与角色授权确认
第三阶段检查人、钱、权是否落实。项目启动授权本质上是一次资源承诺，缺少预算记录或决策权安排时，项目经理在启动后将无法处理变更和冲突。
| 检查项 | 通过标准 | 证据 | 负责人 | 阻断 |
|---|---|---|---|---|
| 核心角色指定 | 发起人、项目经理、关键成员均已指定并确认参与 | 角色名单、成员确认记录 | 项目发起人 | 是 |
| 人力投入承诺 | 关键角色投入比例或工时已由所在团队确认 | 资源确认邮件或审批记录 | 资源审批人 | 是 |
| 预算与审批记录 | 预算金额、来源和审批状态有记录 | 预算审批单 | 财务审批人 | 是 |
| 项目经理决策权限 | 写明可自主决定的事项范围与需上报的事项 | 授权说明或项目章程 | 项目发起人 | 是 |
| 升级路径 | 明确冲突与超权限事项向谁升级、多久内响应 | 授权说明中的升级条款 | 项目发起人 | 否 |
| 外部依赖与供应商条件 | 关键外部依赖已有对接人或合同条件说明 | 供应商沟通记录、合同或意向文件 | 项目经理 | 否 |
决策权限的写法要具体到事项类型，例如“预算内一定额度以下的采购可由项目经理决定，超出部分报发起人审批”“范围变更影响里程碑的，提交变更评审”。只写“项目经理负责项目日常管理”无法在争议发生时提供依据。外部依赖未完全落地的，可以作为非阻断项记录，但需写明对接状态和预计确认时间。
风险、假设与退出条件确认
第四阶段补齐不确定性与中止条件。启动授权不仅批准项目开始，也应说明在什么情况下暂停或终止，否则项目一旦启动就缺少止损依据。
| 检查项 | 通过标准 | 证据 | 负责人 | 阻断 |
|---|---|---|---|---|
| 主要风险登记 | 列出主要风险、影响判断、应对措施和责任人 | 风险登记表 | 项目经理 | 是 |
| 关键假设 | 写明项目成立所依赖的假设及其验证方式 | 假设清单 | 项目经理 | 否 |
| 暂停与终止条件 | 写明触发暂停或终止的具体条件与判断人 | 授权说明中的退出条款 | 项目发起人 | 是 |
| 合规、安全、数据前置审批 | 涉及相关事项的审批已完成或已列入启动前置条件 | 审批记录 | 对应审批负责人 | 是 |
| 沟通与汇报节奏 | 确定例会频率、汇报对象和报告形式 | 沟通计划 | 项目经理 | 否 |
退出条件要写成可观察的事件，例如“关键假设在约定验证节点未得到验证”“预算执行超过批准额度且未获追加审批”“合规审批未在约定日期前完成”。同时指定由谁判断条件是否触发，避免条件写在文档里却无人执行。合规、安全、数据类审批是否构成阻断，取决于项目是否涉及相应事项；涉及而未完成的，应作为阻断项处理。
通过标准、证据与负责人如何填写
清单能否用于评审会逐项打勾，取决于每一行的填写质量。以下规范适用于全部阶段。
- 通过标准：写成可观察、可判断完成与否的表述。避免“合理”“充分”“尽快”等无法判定的词；能用数量、日期、名单或评审结论描述的，优先使用具体口径。
- 证据：填写评审时可当场查看的材料类型，包括文档、审批记录、会议纪要、确认邮件和签署页。证据应指向具体文件或记录，而非“已沟通”。
- 负责人：每项只填一个责任人，填角色加姓名，不填部门。部门无法承担整改责任，也无法在评审会上回答追问。
- 检查时点与复核人：项目经理在评审前完成自检并标注状态；评审会上由复核人逐项确认，复核人一般为发起人或其指定的评审主持者。
示例行：“验收标准与验收人｜每项主要交付物有可判断的验收条件并指定验收人｜验收标准文档、验收人确认记录｜业务负责人（姓名）｜阻断｜评审前自检、评审会复核”。按此格式填写，评审时只需确认证据是否存在、标准是否满足，减少现场解释。
当检查项较多、评审参与人分散时，可以把清单转为可跟踪的工作项：每项检查对应一个工作项，附上证据附件、负责人和截止时间，评审结论与审批记录留在同一处。ONES 支持以工作项承载检查任务、以文档沉淀立项材料与评审纪要，并把审批结果与后续里程碑关联，便于在授权签发后继续跟踪非阻断项的整改。是否采用工具承载取决于团队已有的评审习惯，清单本身的填写规范不因工具而变化。
阻断项与授权完成条件
阻断项是授权放行的硬条件。以下任一事项未通过，不应签发启动授权。
| 阻断项 | 不通过的典型情形 | 处理方式 |
|---|---|---|
| 目标缺失或不可衡量 | 只有方向性描述，无完成时间与衡量口径 | 补充目标后重新评审 |
| 范围边界不清 | 未列范围外事项，交付物无责任人 | 补齐范围说明 |
| 无验收人或验收标准 | 交付物无法判断是否通过 | 指定验收人并确认标准 |
| 无预算承诺 | 预算金额或审批记录缺失 | 完成预算审批 |
| 核心角色未确认 | 项目经理或关键成员未落实 | 完成资源确认 |
| 无退出条件 | 未写明暂停或终止的触发条件 | 补充退出条款 |
| 必要前置审批未完成 | 涉及合规、安全、数据事项但审批缺失 | 完成审批或调整启动范围 |
非阻断项不阻止签发，但要在授权记录中写明整改责任人和完成时限，并在约定的检查点复核。例如外部依赖对接、沟通计划细化、里程碑初版完善，可列为启动后限期完成的事项。
授权签发的完成条件包括：全部阻断项通过并有证据可查；非阻断项已登记整改责任人与时限；评审结论、签署人和签署日期记录在案。签署人一般为项目发起人，涉及预算的授权需财务审批人共同确认。未通过时的处理路径有三条：材料可短期补齐的，补件后重新提交评审；范围过大导致资源无法匹配的，缩减范围后按新范围评审；业务依据本身不成立的，暂缓启动并将结论反馈给提案环节。三条路径都应在评审纪要中留下记录，便于后续追溯。
常见问题
启动授权评审时，发起人和项目经理的分工怎么划？
发起人负责说明立项理由与目标、确认资源承诺并签署授权，对目标缺失、预算未落实这类阻断项承担补件推动责任。项目经理负责准备检查材料、评审前逐项自检、记录整改事项，并在授权签发后跟踪非阻断项的整改。评审会上由复核人逐项确认证据，复核人一般为发起人或其指定的评审主持者。
项目已经开了启动会，还能补做这份授权检查吗？
可以补做，但结论的效力要如实说明。启动会已经召开、资源已经投入时，补做的检查更适合作为基线确认：把目标、范围、验收人和预算记录补齐，对缺失的阻断项设定整改时限，并在下一次阶段评审时复核。若补做中发现业务依据本身不成立，应把结论反馈到提案环节，而不是用一份形式上的授权记录掩盖问题。
非阻断项一直没整改，授权还有效吗？
授权记录中应为每个非阻断项写明责任人和完成时限，并约定复核检查点。到期未完成的，由复核人判断是否升级为阻断项处理：影响范围、验收或预算执行的，应暂停相关工作的推进，补齐后再恢复；仅涉及文档细化的，可延长时限但需重新登记。把非阻断项长期挂起不作处理，会让授权记录失去约束力。
涉及合规、安全、数据审批的项目，授权时点怎么安排？
这类审批是否构成阻断，取决于项目是否实际涉及相应事项。涉及的，应在签发启动授权前完成审批，或把审批完成明确列为启动前置条件并指定负责人；未完成的按阻断项处理。不涉及的，在清单中注明判断依据即可，不必为凑齐条目而虚构审批流程。
检查项较多、评审人分散在不同地点时，怎么组织评审？
可以把清单转为可跟踪的工作项：每项检查对应一个工作项，附证据附件、负责人和截止时间，评审前由项目经理完成自检并标注状态，评审会上由复核人逐项确认结论。ONES 支持以工作项承载检查任务、以文档沉淀立项材料与评审纪要，并把审批结果与后续里程碑关联，便于授权签发后继续跟踪整改。是否用工具承载取决于团队已有的评审习惯，清单的填写规范不因工具而改变。
