集团PMO在推进研发治理时，常遇到一个尴尬局面：既牵头制定评审规则和度量口径，又被拉进具体项目做发布判断，结果标准制定与执行责任混在一起。本文给出一套划分口径和落地工具，帮助集团PMO把两类责任拆开，用责任矩阵、发布与例外流程、检查清单让机制真正运转起来。
要点总览（TL;DR）
- 用“产出物是规则还是交付结果”判断责任归属：定义方法、模板、评审规则和度量口径归集团PMO，按标准完成计划、交付与自检归项目团队和业务线。
- PMO保留标准解释权、例外审批权和审计权，同时不代替项目负责人做发布、延期、资源调配等日常执行决策。
- 用责任矩阵把每项活动落到标准制定方、执行方、评审方、例外审批方和交付物，集团与业务线两级PMO分别填写并指定维护责任人。
- 标准发布要明确评审角色、发布形式、生效日期和版本号；例外审批要明确申请条件、审批层级、时限和记录方式，口头批准不计为有效例外。
- 定期用检查清单核对矩阵覆盖、标准版本、例外留痕和审计执行，出现职责空白或版本混乱时先整改再进入常规审计。
先划清两类责任的边界
区分标准制定与项目执行责任，核心是回答一个问题：这项工作的产出物是“规则”，还是“按规则交付的结果”。产出规则的工作归标准制定责任，产出交付结果的工作归项目执行责任。集团PMO承担前者，项目团队和业务线承担后者。
标准制定责任的范围包括方法、模板、评审规则和度量口径的定义、发布与维护。具体表现为：定义需求评审要检查哪些项、发布准入需要满足哪些条件、质量门禁设在哪些环节、度量报表按什么口径统计。承担方是集团PMO，对标准的一致性、适用性和版本有效性负责。
项目执行责任的范围包括按已发布标准完成计划、交付、自检与问题上报。项目团队依据标准编制计划、组织评审、留存证据、执行自检，发现问题及时上报。承担方是项目负责人及其团队，对结果和进度负责，业务线对执行质量负管理责任。
PMO在两类责任之外保留三项权力：标准解释权，即执行方对标准理解有分歧时由PMO裁定；例外审批权，即执行方无法满足标准时按流程申请豁免；审计权，即定期检查标准执行情况。同时明确一条边界：PMO不代替项目负责人做日常执行决策，包括是否发布、是否延期、资源如何调配。
实际工作中可以用四个问题快速归类一项活动：谁定义这项规则、谁按规则执行、谁评审执行结果、谁批准例外。四个答案指向同一角色时，说明职责过度集中，需要拆分。
| 判断问题 | 答案指向标准制定 | 答案指向项目执行 |
|---|---|---|
| 谁定义 | 集团PMO牵头起草并发布规则 | 项目团队提出执行中的问题反馈 |
| 谁执行 | 不适用，标准本身不产生交付物 | 项目团队按标准完成计划与交付 |
| 谁评审 | PMO组织标准评审，确认适用性 | 评审角色按标准检查执行结果 |
| 谁批例外 | PMO设定例外条件和审批层级 | 项目负责人提出申请，按层级审批 |
建立责任矩阵：把活动落到角色
边界口径确定后，需要一张可填写的责任矩阵，把每项活动落到具体角色和交付物。矩阵以活动为行，以标准制定方、执行方、评审方、例外审批方、交付物为列，集团与业务线两级PMO分别填写各自负责的部分。
| 活动 | 标准制定方 | 执行方 | 评审方 | 例外审批方 | 交付物 |
|---|---|---|---|---|---|
| 需求评审规则 | 集团PMO | 项目团队 | 业务线PMO | 集团PMO标准负责人 | 评审规则文档、评审记录 |
| 发布准入标准 | 集团PMO | 项目团队 | 质量角色 | 集团PMO负责人 | 准入标准、发布检查单 |
| 质量门禁设置 | 集团PMO与质量角色联合 | 项目团队 | 业务线PMO | 集团PMO负责人 | 门禁配置说明、门禁通过记录 |
| 度量报表口径 | 集团PMO | 项目团队填报 | 业务线PMO核对 | 集团PMO标准负责人 | 口径说明、报表模板 |
集团与业务线两级PMO的分工建议这样写：集团PMO负责跨业务线通用的方法、模板和度量口径，保证标准一致；业务线PMO负责在本业务线内解释标准、组织执行检查、汇总例外申请，并将执行中的共性问题反馈给集团PMO作为标准修订输入。两级PMO都不进入项目日常执行决策。
矩阵需要指定维护责任人，通常由集团PMO标准负责人担任，负责矩阵版本和字段完整性。更新触发条件包括：新标准发布、标准重大修订、组织架构调整导致角色变化、审计发现职责空白或重叠。每次更新记录版本号和变更说明，避免矩阵与实际运行脱节。
标准发布与例外审批的操作流程
标准从起草到发布、执行方从遇到障碍到获得例外，需要一条清晰的流程。每一步都明确输入、动作、输出和完成标志，避免标准停留在讨论阶段或例外靠口头批准。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 标准起草 | 执行中的共性问题、适用范围说明 | 集团PMO编写草案，向业务线PMO和项目代表征求意见 | 标准评审稿 | 评审稿完成意见征集并形成处理记录 |
| 标准评审 | 标准评审稿 | 集团PMO组织评审，业务线PMO和质量角色确认可执行性 | 评审结论 | 评审意见闭环，关键分歧有裁定结论 |
| 标准发布 | 评审通过的标准文本 | 确定发布形式、生效日期和版本号，向执行方通知 | 已发布标准 | 标准可被执行方查阅，版本号和生效日期明确 |
| 例外申请 | 执行方无法满足标准的说明和影响评估 | 项目负责人提交申请，按层级审批，记录审批意见 | 例外审批记录 | 审批结论留痕，例外范围和有效期明确 |
| 标准变更 | 执行反馈、审计发现、业务变化 | 评估影响范围，修订标准并重新发布 | 新版本标准 | 变更通知送达执行方，旧版本标注失效 |
例外申请需要设定条件：执行方已按标准尝试但客观条件不满足，或标准本身在特定场景下不适用。审批层级按影响范围确定，影响单个项目的例外由业务线PMO审批，影响跨业务线一致性的例外由集团PMO审批。审批时限在机制文件中约定，超时未批视为不通过，避免例外无限期悬置。所有例外必须记录申请理由、审批人、有效期和补救措施，口头批准不计为有效例外。
标准变更的触发条件包括：审计发现标准与业务实际脱节、多个项目重复申请同类例外、组织或流程发生结构性调整。变更时先做影响评估，明确受影响的业务线和项目范围，再修订发布并通知执行方。标准文档的版本记录、例外审批流转和执行证据留存，可以在协作平台中承载，例如用文档版本管理标准文本、用审批流程记录例外结论，让审计时有据可查。
角色与交付物清单
责任矩阵按活动组织，角色清单按岗位组织，两者互补。每个角色明确职责、所需输入和应交付的产物，便于岗位落地和交接。
| 角色 | 职责 | 输入 | 输出交付物 |
|---|---|---|---|
| 集团PMO标准负责人 | 牵头标准起草、评审组织、发布与版本维护，解释标准 | 执行反馈、审计发现、业务变化信息 | 标准文本、版本记录、解释裁定记录 |
| 业务线PMO | 在本业务线解释标准、组织执行检查、汇总例外申请 | 集团标准、项目执行情况 | 执行检查记录、例外申请汇总、标准修订建议 |
| 项目负责人 | 按标准编制计划、组织交付、执行自检、上报问题 | 已发布标准、项目计划 | 执行计划、自检记录、问题上报单 |
| 质量/评审角色 | 按标准评审执行结果，确认证据完整性 | 标准、执行方提交的证据 | 评审结论、问题清单 |
角色冲突时的升级路径需要事先约定。常见冲突有两类：执行方认为标准不适用，评审方认为执行证据不足。前者由业务线PMO判断，无法裁定时升级至集团PMO标准负责人行使解释权；后者由评审角色出具问题清单，项目负责人限期补充证据，仍无法达成一致时提交业务线PMO协调，涉及标准本身缺陷的转入标准变更流程。升级路径的每一级都要有响应时限，避免问题在角色之间反复流转。
示例：一次发布准入标准的分工落地
以下为演示情景，用于说明责任划分如何运转。集团PMO发现各业务线发布准入检查项不一致，决定制定统一的发布准入标准。
标准制定侧，集团PMO标准负责人收集近几个版本的发布问题和各业务线现有检查项，起草统一标准，明确准入检查项、证据要求和评审角色。草案向业务线PMO和质量角色征求意见，对分歧项组织评审并形成裁定结论。标准发布时标注版本号和生效日期，通过正式渠道通知所有执行方。此阶段PMO的产出是标准文本和评审记录，不对任何具体项目是否发布表态。
执行侧，某业务线项目在版本发布前按标准逐项自检，留存测试报告、评审记录和问题关闭证据。项目负责人对自检结果签字确认，发现两项检查项因技术方案特殊无法满足，按流程提交例外申请，说明原因、影响范围和补救措施。业务线PMO审核后提交集团PMO审批，审批结论和有效期记录在案。项目按批准后的例外范围完成发布，发布决策由项目负责人做出。
这个示例体现了边界：集团PMO负责标准是否合理、例外是否批准，项目负责人负责发布是否执行、证据是否充分。审计时，集团PMO检查标准版本是否最新、例外是否留痕、执行证据是否完整，据此判断机制运行情况，而不是替项目做发布判断。标准文档的版本管理、例外审批流转和自检证据留存，可以在协作平台中统一承载，让标准、审批和执行记录形成可追溯的链条。
完成检查：责任划分是否真正落地
机制建立后需要定期验证。以下检查项可逐项核对，每项给出通过标准和证据来源，帮助集团PMO判断责任划分是否真正运行。
| 检查项 | 通过标准 | 证据来源 |
|---|---|---|
| 责任矩阵覆盖关键活动 | 需求评审、发布准入、质量门禁、度量口径等活动均有明确制定方、执行方、评审方和例外审批方 | 责任矩阵文档及版本记录 |
| 标准有版本与生效日期 | 每份在用标准标注版本号、生效日期和适用范围，旧版本明确失效 | 标准文档库、发布通知记录 |
| 例外审批留痕 | 每笔例外有申请理由、审批人、审批结论和有效期，无口头批准 | 例外审批记录 |
| 审计按期执行 | 按约定频率完成执行检查，发现问题有整改跟踪 | 审计报告、整改记录 |
常见失效信号值得警惕：标准发布后长期无人维护，版本停留在初版；例外以口头或即时消息批准，审计时无法追溯；执行方不知道标准存在或不清楚适用版本；责任矩阵与实际组织不符，出现无人负责的活动。出现这些信号时，先定位是标准制定侧的问题还是执行侧的问题，再决定修订标准还是加强执行检查。
阻断项指必须整改后才能继续推进的情况，例如关键活动在矩阵中无责任方、例外审批无记录、标准版本混乱导致执行方无法判断依据。整改条件包括：补齐矩阵责任方并重新发布、建立例外审批留痕机制、完成标准版本清理并通知执行方。整改完成后重新执行上述检查项，确认通过后再进入常规审计周期。
常见问题
集团PMO和业务线PMO在标准制定上如何分工，避免两级重复出标准？
建议按适用范围划分：集团PMO负责跨业务线通用的方法、模板和度量口径，保证各业务线执行同一套规则；业务线PMO负责在本业务线内解释标准、组织执行检查、汇总例外申请，并把执行中的共性问题反馈给集团PMO作为修订输入。
两级PMO都承担标准解释和执行检查的职责，但标准文本的发布权和版本维护权集中在集团PMO，避免同一活动出现两个版本的标准。业务线确有特殊场景需要差异化规则时，走例外审批或标准变更流程，不另行发布平行标准。
项目团队认为标准不适用时，应该走例外审批还是直接申请修改标准？
先判断问题是个案还是共性。如果只是单个项目因技术方案、外部约束等客观条件无法满足标准，走例外审批，由项目负责人提交申请，说明原因、影响范围和补救措施，按影响范围确定审批层级并记录有效期。
如果多个项目重复申请同类例外，或审计发现标准与业务实际脱节，说明标准本身需要修订，转入标准变更流程，做影响评估后修订发布并通知执行方。例外解决个案，变更解决规则问题，两者不宜混用。
例外审批的时限和层级怎么设定才不至于悬而不决？
审批层级按影响范围确定：影响单个项目的例外由业务线PMO审批，影响跨业务线一致性的例外由集团PMO审批。审批时限在机制文件中事先约定，超时未批视为不通过，执行方需按标准执行或重新提交申请。
每笔例外都要记录申请理由、审批人、审批结论、有效期和补救措施，口头或即时消息批准不计为有效例外。例外到期后需要重新评估，确需延续的重新申请，避免例外变成长期默认状态。
责任矩阵建好后由谁维护，什么情况下需要更新？
维护责任人通常由集团PMO标准负责人担任，负责矩阵版本和字段完整性。更新触发条件包括：新标准发布、标准重大修订、组织架构调整导致角色变化、审计发现职责空白或重叠。
每次更新记录版本号和变更说明，并通知两级PMO和相关角色。矩阵长期不更新会与实际组织脱节，出现无人负责的活动，因此建议把矩阵更新纳入标准发布和审计整改的固定动作。
审计发现执行方不知道标准存在，应该先整改哪一侧？
先定位问题出在标准制定侧还是执行侧。如果是标准发布后未有效通知、版本记录混乱导致执行方无法判断依据，属于标准制定侧问题，需要补齐发布通知和版本清理；如果是标准已发布但业务线未组织传达和检查，属于执行侧问题，需要加强执行检查和培训。
两类问题可能同时存在，整改时分别明确责任方和完成时限，整改完成后重新执行检查项，确认通过后再进入常规审计周期。
