项目成功标准应在立项评审通过后、进入执行前确定并冻结，由项目发起人与业务负责人共同确认，涉及验收指标的还需客户或验收方确认。冻结后写入项目章程或立项基线，执行中出现新诉求时走变更评审，由原确认角色重新批准。本文给出时点判断、角色分工、冻结步骤、变更处理规则和完成检查清单。
要点总览（TL;DR）
- 成功标准应在立项评审通过后、执行启动前确定并冻结，写入项目章程或立项基线，带版本号发布。
- 由业务发起人提出草案，项目经理负责可度量化和口径统一，PMO审核一致性，发起人与业务负责人共同确认，验收类指标需客户或验收方确认。
- 冻结需满足签字齐全、基线入库、相关角色可见三项完成标志，冻结后阶段评审只做对照检查，不重新定义标准。
- 执行期新诉求先登记再分流：范围新增走范围变更，标准调整走变更评审并由原确认角色重新批准，合理诉求可转入后续阶段承接。
- 用检查清单核对可度量性、签字、版本追溯、变更记录和新诉求分流，发现缺失在进入下一阶段前补齐。
成功标准在哪个时点确定并冻结
成功标准的确定与冻结应落在立项评审通过之后、执行启动之前这个基线窗口内。立项评审解决的是“项目是否值得做”，成功标准解决的是“做到什么程度算成功”，两者前后衔接：评审通过意味着资源与方向获得认可，此时把成功标准写清楚并冻结，项目团队才能带着明确的目标进入执行。若在立项材料中已有成功标准草案，冻结动作就是对该草案的确认与定版；若立项时只写了业务目标，则需在进入执行前补齐可度量的成功标准条目。
冻结的载体是项目章程或立项基线中的成功标准条目。冻结意味着该版本成为后续范围、进度、成本和质量决策的参照基准，而不是一份可以随时改写的愿望清单。冻结时应记录版本号、确认角色、确认日期和适用阶段，使后续任何调整都能对照原版本说明差异。
| 时点 | 主要动作 | 成功标准状态 |
|---|---|---|
| 立项准备阶段 | 发起人提出业务目标与成功标准草案 | 草案，可讨论 |
| 立项评审 | 评审项目必要性、资源与目标合理性 | 草案随立项材料一并评审 |
| 立项通过后、执行启动前 | 可度量改写、口径审核、签字确认、基线入库 | 冻结版，带版本号 |
| 执行期阶段评审与里程碑 | 对照冻结标准检查进展，登记新诉求 | 保持冻结版，变更另行审批 |
| 变更评审通过后 | 形成新版本并重新批准 | 新版本冻结，旧版本留存 |
阶段评审和里程碑与成功标准的关系是“对照检查”而非“重新定义”。在每个里程碑，团队应回答的是当前进展相对冻结标准的完成情况，而不是借评审之机调整标准本身。执行中才确定成功标准，常见后果是标准随实际结果移动：做得好的指标被强调，没做到的指标被淡化，项目结束时难以判断是否真正达成目标。把确定与冻结放在执行之前，正是为了避免这种事后移动标准的情况。
由谁提出、谁确认、谁冻结
成功标准的形成涉及提出、可度量、审核、确认和冻结五类动作，角色分工清楚，签字链才完整。业务发起人最了解项目要解决的业务问题，由他提出成功标准草案；项目经理负责把草案转成可度量、可验证的表述，并统一各项指标的口径；PMO或承担治理职责的角色审核标准之间的一致性以及与组织目标的对齐；最终由发起人与业务负责人共同确认，验收类指标还需客户或验收方确认。冻结动作通常由PMO或项目经理按治理规则执行，记录在项目章程或立项基线中。
| 角色 | 主要职责 | 交付物或动作 |
|---|---|---|
| 业务发起人 | 提出成功标准草案，说明业务目标与价值预期 | 成功标准草案 |
| 项目经理 | 将标准改写为可度量表述，统一指标口径与统计方式 | 可度量版成功标准清单 |
| PMO或治理角色 | 审核标准口径、指标间一致性及与组织目标的衔接 | 审核意见 |
| 发起人与业务负责人 | 共同确认成功标准，承担标准达成的业务责任 | 确认签字 |
| 客户或验收方 | 确认验收类指标的定义与判定方式 | 验收指标确认 |
| PMO或项目经理 | 执行冻结，登记版本并纳入基线 | 冻结记录与版本号 |
需要说明的是，角色可以由同一人兼任，但职责不能省略。小团队中发起人可能同时是业务负责人，确认环节可由一人完成，但仍需留下书面确认记录；PMO职能可由项目管理负责人承担，审核动作仍需发生。治理成熟度较低的组织可以先从“发起人提出、项目经理可度量、发起人确认”这条最短链条做起，随着项目复杂度提升再引入PMO审核和客户确认环节。
成功标准冻结的操作步骤
冻结不是一次会议上的口头同意，而是一组有输入、有动作、有输出、有完成标志的操作。按以下步骤执行，可以保证冻结结果可追溯、可对照。
- 收集输入。汇集立项材料、业务目标说明、合同或验收要求、以往同类项目的指标参考。输入不完整时，先补齐业务目标和验收要求，再进入下一步。
- 起草标准。由发起人列出成功标准草案，覆盖业务结果、交付范围、质量要求和关键约束，每项写明期望达成的状态。
- 可度量改写。项目经理逐条把草案转成可度量表述，明确指标定义、统计口径、数据来源、目标值和判定时点。无法量化的条目改为可验证的定性判定条件，并写明判定人。
- 口径审核。PMO或治理角色检查指标之间是否冲突、口径是否与组织统计方式一致、目标值是否有依据，输出审核意见并推动修订。
- 签字确认。发起人与业务负责人共同确认定稿；涉及验收的指标提交客户或验收方确认。签字可采用电子审批或书面签署，关键是留下确认人和确认日期。
- 冻结入库。由PMO或项目经理将确认版写入项目章程或立项基线，赋予版本号，标注冻结日期和适用阶段，并在项目文档库中发布。
- 通知可见。将冻结版成功标准同步给项目团队、相关职能部门和验收方，确保执行角色在启动时即能看到同一版本。
完成标志有三项：签字齐全，即所有确认角色均已签署；基线入库，即冻结版已进入项目章程或立项基线并有版本号；相关角色可见，即团队成员和验收方能够获取同一版本。三项同时满足，冻结才算到位。输出物是冻结版成功标准清单，包含版本号、指标定义、目标值、确认角色和冻结日期。
在项目管理系统中承载这一过程时，可以把成功标准清单作为项目文档发布并保留版本记录，把确认签字作为审批节点留痕，把冻结状态与项目启动状态关联。ONES的项目文档与工作项状态可以承载这类文档发布、审批留痕和状态流转的管理动作，使冻结版本与后续变更记录在同一处可查。具体配置方式需结合组织现有的项目模板和审批规则确定。
执行中出现新诉求时如何避免事后移动标准
执行期出现新诉求是常态，关键在于先分流、再处理，避免新诉求直接改写已冻结的成功标准。分流的第一步是登记：任何新诉求都先进入需求或变更登记表，记录提出人、提出时间、诉求内容和期望影响。第二步是判断性质：属于范围新增的，走范围变更流程；属于对原成功标准定义或目标值的调整，才进入成功标准变更评审。两类诉求处理路径不同，混在一起处理最容易导致标准被悄悄移动。
| 诉求类型 | 判断依据 | 处理路径 |
|---|---|---|
| 范围新增 | 原成功标准不变，需要增加交付内容或功能 | 走范围变更，评估资源与进度影响，原标准保持不变 |
| 成功标准调整 | 需要改变指标定义、目标值或判定方式 | 走变更评审，评估对范围、进度、成本的影响，由原确认角色重新批准 |
| 后续阶段承接 | 诉求合理但不在当前阶段目标内 | 登记进入后续阶段或版本规划，不修改当前冻结标准 |
成功标准调整的评审应包含三项内容：调整理由，说明原标准为何不再适用；影响评估，说明调整对范围、进度、成本和质量的影响；替代方案，说明是否可以通过范围变更或后续阶段承接来满足诉求而不改标准。评审通过后，由原确认角色重新批准，形成新版本，旧版本和调整理由一并留存，保证任何时点都能回答“当时的标准是什么、为什么改”。
实践中有一条简单规则可以有效减少事后移动标准：新诉求默认走范围变更或后续阶段承接，只有证明原标准本身存在定义错误或外部条件发生实质性变化时，才启动标准调整。这条规则把举证责任放在调整方，而不是让标准在每次讨论中被重新解释。
示例：一次成功标准冻结与变更处理
以下为演示情景，用于说明冻结与变更处理的完整过程，不代表真实项目案例。
某企业启动一个客户服务系统升级项目，立项评审通过后进入执行前准备。业务发起人提出成功标准草案：客户咨询平均响应时间缩短、工单一次解决率提升、系统上线后三个月内客服团队完成切换。项目经理将草案改写为可度量条目：平均首次响应时间从当前基线缩短百分之三十，统计口径为工作日九点至十八点的在线咨询；工单一次解决率不低于百分之八十五，数据来源为工单系统月度报表；切换完成以客服团队全员在新系统处理工单满四周为判定条件。PMO审核后指出响应时间指标需明确是否包含非工作时间，项目经理补充口径说明。发起人与业务负责人共同签字确认，客户方对一次解决率的统计方式出具确认意见。PMO将定稿写入项目章程，赋予版本号并发布，冻结完成。
执行到第二个月，业务部门提出希望增加智能客服自动回复功能。项目经理登记诉求后判断：该功能属于交付范围新增，原成功标准中的响应时间和解决率指标不受影响。诉求转入范围变更流程，评估增加的工作量与进度影响后，由项目指导委员会批准在第二阶段实施，原冻结标准保持不变。
第三个月，客户方提出把一次解决率目标从百分之八十五调整为百分之八十，理由是业务量增长导致工单复杂度上升。项目经理启动成功标准变更评审，要求说明调整理由并提供数据支撑。评审确认外部条件确有变化，同时评估了目标下调对项目验收的影响，最终由原确认角色重新批准，形成第二版成功标准，第一版及调整理由完整留存。整个过程结束后，项目结束时对照的是第二版标准，而任何时点都能追溯第一版的内容和变更原因。
完成检查：冻结是否到位
冻结完成后，可用以下清单逐项核对。每项给出通过标准，全部通过才说明冻结机制真正落地。
| 检查项 | 通过标准 |
|---|---|
| 成功标准是否可度量、有口径 | 每项标准有指标定义、统计口径、数据来源、目标值和判定时点；定性条目有明确判定条件与判定人 |
| 确认角色是否签字齐全 | 发起人、业务负责人已确认；验收类指标有客户或验收方确认；签字记录含确认人和日期 |
| 冻结版本是否入库并可追溯 | 冻结版已写入项目章程或立项基线，有版本号和冻结日期，历史版本可查 |
| 变更是否有评审记录和重新批准 | 每次标准调整有调整理由、影响评估和原确认角色的重新批准记录 |
| 新诉求是否被正确分流 | 执行期新诉求均有登记记录，并明确归入范围变更、标准调整或后续阶段承接 |
| 相关角色是否可见同一版本 | 项目团队、职能部门和验收方能够获取当前冻结版本，版本信息一致 |
检查中发现签字缺失或版本不一致时，应在进入下一阶段前补齐，而不是等到项目收尾再补记录。冻结机制的价值在于让项目全程有一个稳定的成功参照，检查清单则是确认这个参照确实存在、确实被遵守的最直接方式。
常见问题
立项评审时已经写了成功标准，还需要在执行前再冻结一次吗？
需要。立项评审关注的是项目是否值得做，评审材料中的成功标准通常还是草案，指标口径、数据来源和判定时点未必写全。进入执行前应把草案补齐为可度量表述，完成口径审核和签字确认，再赋予版本号写入项目章程或立项基线。冻结动作让这份标准成为后续范围、进度、成本决策的参照基准，评审通过本身不产生这个效果。
小团队没有PMO，确认和冻结环节可以简化吗？
可以裁剪角色，但不能省略职责。小团队可采用最短链条：发起人提出草案，项目经理改写为可度量表述，发起人确认签字，项目经理登记版本并发布。审核动作可以由项目管理负责人承担，确认记录仍需书面留存。随着项目复杂度提升，再引入独立的PMO审核和客户验收确认环节。
客户在项目执行中途要求调整验收指标，属于范围变更还是标准调整？
看诉求改变的是什么。如果原成功标准不变、只是增加交付内容或功能，走范围变更；如果要改变指标定义、目标值或判定方式，属于成功标准调整，需走变更评审。评审应包含调整理由、对范围进度成本的影响评估和替代方案，通过后由原确认角色重新批准，形成新版本并留存旧版本。
冻结后的成功标准在里程碑评审中能不能顺手修订？
里程碑评审的作用是对照冻结标准检查进展，回答当前完成情况相对标准的差距，不承担重新定义标准的功能。评审中发现标准本身有问题，应登记为变更诉求，按变更评审流程处理，由原确认角色批准。把修订混入常规评审，容易让标准随实际结果移动，项目结束时难以判断目标是否真正达成。
成功标准冻结后，执行中出现的新诉求都只能拒绝或推迟吗？
不必。新诉求先登记，再按性质分流：属于范围新增的走范围变更，评估资源与进度影响后决定是否在当前阶段实施；合理但不在当前阶段目标内的，登记进入后续阶段或版本规划；只有证明原标准存在定义错误或外部条件发生实质性变化时，才启动标准调整。分流机制让新诉求有承接路径，同时保持原标准稳定。
