项目进度延期、资源被临时抽调、状态口径不一致，是PMO与项目经理职责最容易交叉的场景。界定边界的可行做法，是按“决策权、交付责任、过程标准、信息汇总”四类事项逐项归属，再用职责清单、RACI表和一份职责边界说明固化。ONES可承载职责清单、评审记录与状态汇总，本文围绕这套机制说明如何制定、如何验证。
要点总览（TL;DR）
- 按“决策权、交付责任、过程标准、信息汇总”四类事项逐项归属，比按角色笼统分工更能划清PMO与项目经理的边界。
- 交叉事项按固定顺序判定：先看交付责任落在谁身上，再看过程标准由谁制定维护，最后确认信息汇总与上报口径。
- 界定工作分五步推进：收集职责清单输入、逐项标注主责配合与升级路径、形成RACI表与职责边界说明、在启动会与阶段评审中确认、定期复核更新。
- 同一事项只设一个主责角色，升级路径写到触发条件、提交人、接收人、时限和闭环方式，避免停留在口头沟通。
- 边界是否生效按职责清单覆盖度、RACI唯一主责、升级路径实际使用、争议闭环、数据口径一致、文档版本受控逐项核对。
先按四类事项划清归属
职责边界模糊，通常源于按角色笼统分工，例如“PMO负责项目管理，项目经理负责项目执行”。这种表述在具体事项上无法判断谁拍板、谁交付、谁维护标准。更可操作的方式是把日常事项归入四类，再为每类确定默认归属。
| 事项类别 | 包含内容 | 默认归属 | 判断要点 |
|---|---|---|---|
| 决策权 | 项目目标调整、范围变更审批、关键资源调配、重大风险处置 | 项目经理提出方案，治理层或项目发起人裁决；PMO组织评审并记录结论 | 谁承担决策后果，谁就应拥有对应决策权 |
| 交付责任 | 单个项目的范围、进度、成本、质量与最终交付结果 | 项目经理 | 交付结果的第一责任人只有项目经理一个 |
| 过程标准 | 流程规范、模板工具、评审规则、度量口径 | PMO制定与维护，项目经理在项目内执行并反馈适用性问题 | 标准面向多个项目复用时归PMO；单个项目的执行安排归项目经理 |
| 信息汇总 | 跨项目状态汇总、风险台账、治理议题上报、效能数据 | PMO汇总与上报，项目经理提供本项目准确输入 | 汇总口径由PMO统一，数据真实性由项目经理负责 |
遇到交叉事项时，按固定顺序判定：先看交付责任落在谁身上，再看过程标准由谁制定和维护，最后确认信息汇总与上报口径。举例来说，某项目进度延期，交付责任在项目经理，由其制定追赶计划并协调资源；PMO负责按统一口径收集延期信息、组织评审、把需要治理层决策的资源冲突列入议题。这样同一事项只有一个主责角色，另一个角色承担配合职责。
需要说明的是，四类归属是默认原则，不是固定模板。组织规模较小、PMO仅承担支持职能时，过程标准的制定可能由项目经理群体共同维护，PMO负责归集和发布；组织设有独立质量或流程部门时，过程标准的所有权也可能在该部门。归属结果应写入职责边界说明，避免口头约定。
职责边界界定的操作步骤
界定边界是一项有产出的工作，建议按五步推进，每步明确输入、动作、输出和完成标志。
第一步：收集职责清单的输入来源
输入包括现有项目管理制度、PMO岗位说明、项目经理岗位说明、近半年评审纪要与升级议题记录、项目状态报告模板，以及项目经理和PMO人员的访谈记录。动作是把这些材料中出现的事项逐条摘出，合并同义项，形成一份原始职责清单。输出是覆盖高频事项的清单初稿，完成标志是清单中的事项能对应到具体工作场景，而非抽象职责描述。
第二步：逐项标注主责、配合与升级路径
对清单中每一项，标注主责角色、配合角色，以及出现分歧时的升级对象和升级时限。主责角色只能有一个；配合角色可以多个，但需写明配合的具体动作，例如“提供资源占用数据”而非“协助”。升级路径写到岗位或会议名称，例如“资源冲突超过三个工作日未解决，升级至项目发起人”。输出是带归属标注的职责清单，完成标志是每项都有主责、配合和升级路径三栏内容。
第三步：形成RACI表与职责边界说明文档
把标注结果整理为RACI表，逐项检查是否每行只有一个R（主责），A（批准）是否落在有决策权的角色上，C（咨询）和I（知会）是否必要。随后编写职责边界说明，内容包括适用范围、四类事项归属原则、RACI表、升级路径和争议处理方式。输出是可发布的文档，完成标志是文档经PMO负责人与项目经理代表共同确认。
第四步：在启动会与阶段评审中确认
新项目启动会上，由项目经理与PMO共同确认本项目适用的职责边界，重点核对是否有项目特有事项需要补充归属。阶段评审中检查边界执行情况，把出现的争议记录为议题并明确处理结论。输出是启动会确认记录和评审议题记录，完成标志是每个在跑项目都有一次边界确认，争议事项有明确结论。
第五步：定期复核与更新
组织调整、项目类型变化或连续出现同类争议时，触发职责边界说明的复核。输出是更新后的文档版本，完成标志是变更内容已通知相关角色并在下一次评审中验证。
角色分工与各自交付物
边界机制要运转，需要三类角色各自清楚产出什么。下表按角色列出主要职责与交付物，便于在职责边界说明中直接引用。
| 角色 | 在边界机制中的职责 | 主要交付物 |
|---|---|---|
| PMO | 制定和维护过程标准与模板；组织跨项目评审；汇总状态与风险；把超出项目经理权限的议题上报治理层；维护职责边界说明文档 | 流程规范与模板、RACI表、跨项目状态报告、治理议题清单、评审纪要、职责边界说明版本记录 |
| 项目经理 | 对单项目交付结果负责；在项目内执行过程标准；提供准确的项目数据；在权限范围内处理问题，超出范围时按升级路径上报 | 项目计划、进度与风险报告、变更申请、资源需求说明、升级申请 |
| 治理层/项目发起人 | 对升级事项作出裁决；确认重大变更与资源调配；对边界争议给出最终结论 | 决策记录、变更批复、争议裁决结论 |
职责边界说明文档的维护责任建议放在PMO，由其负责版本管理、变更通知和归档；项目经理负责提出修订建议并提供执行反馈。文档维护责任本身也应写入说明，避免出现多人修改、版本不一致的情况。
在工具承载上，职责清单、RACI表可以作为文档或工作项属性维护，评审纪要与升级议题可作为记录留痕。ONES提供业务、产品经理与研发团队多视角的统一需求池、工单与任务看板，便于跨角色同步状态与追溯问题；效能管理支持为不同角色配置读写权限，并可将仪表盘共享给其他用户，减少重复配置。这些能力适合承载状态汇总与角色视图，具体配置需按实际部署确认。
职责边界说明示例
以下示例以“进度延期与资源冲突”为场景，展示同一事项如何在PMO与项目经理之间分工，以及升级路径如何书写。示例为演示情景，组织可直接替换为自身项目名称与岗位。
事项描述与分工写法
事项：项目A关键里程碑预计延期两周，同时核心开发人员被另一项目抽调，项目经理判断现有资源无法完成追赶计划。
- 交付责任：项目经理负责评估延期影响、制定追赶方案、提出资源需求，并对最终交付结果负责。
- 过程标准：PMO负责提供延期上报模板与风险分级规则，项目经理按模板提交延期说明。
- 信息汇总：PMO负责将该项目延期纳入跨项目状态报告，标注影响范围，并在周度评审中通报。
- 决策权：资源抽调涉及两个项目的优先级，超出项目经理权限，由项目发起人裁决；PMO负责组织评审并记录结论。
升级路径写法
升级路径写成可执行的条件与对象，例如：“资源冲突在项目经理提出需求后三个工作日内未解决，由项目经理向项目发起人提交升级申请，抄送PMO；PMO在两个工作日内安排专项评审，评审结论记入议题台账，未闭环事项在下次治理会议复核。”这样的写法明确了触发条件、提交人、接收人、时限和闭环方式，避免升级停留在口头沟通。
RACI填写示例
| 事项 | 项目经理 | PMO | 项目发起人 |
|---|---|---|---|
| 制定追赶计划 | R | C | I |
| 提供延期上报模板 | I | R | — |
| 跨项目状态汇总 | C | R | I |
| 资源优先级裁决 | C | C | A/R |
表中“资源优先级裁决”一行由项目发起人同时承担批准与主责，是因为该事项的决策后果由发起人承担；PMO在此承担咨询与组织评审的配合职责。填写时应逐行核对，确保没有一行出现两个R。
边界落地后的完成检查
文档发布不等于机制生效。建议在边界说明运行一个季度后，按以下清单逐项核对，判断职责边界是否真正落地。
- 职责清单覆盖度：抽查近一个季度的评审纪要与升级记录，高频交叉事项是否都能在清单中找到对应条目；找不到的条目应补充归属。
- RACI唯一主责：逐行检查RACI表，每项是否只有一个R；出现两个R的行，说明边界仍未划清，需要重新判定交付责任归属。
- 升级路径实际使用：统计升级申请数量与处理时长，确认升级路径被真实触发过；长期零升级可能意味着问题被压在项目层，也可能意味着升级门槛过高，需要结合争议记录判断。
- 争议闭环：检查评审中提出的边界争议是否都有结论、责任人和完成时间；未闭环事项是否进入治理会议跟踪。
- 数据口径一致：对比PMO汇总报告与项目经理提交的项目数据，确认统计口径一致；口径差异应回到过程标准环节修正。
- 文档版本受控：确认职责边界说明有明确版本号、变更记录和通知范围，相关角色使用的是同一版本。
检查结果可作为下一轮修订的输入。若某类事项反复出现争议，说明该类事项的默认归属原则需要调整，或需要在职责边界说明中增加更细的分场景规则。ONES效能管理提供交付效率、交付质量、资源效率、完成情况四个维度的度量实践体系，并预置面向管理人员、项目经理等角色视角的仪表盘模板，可作为核对状态口径与角色视图的参考；具体指标口径仍需按组织实际配置。
常见问题
PMO和项目经理对同一件事都认为自己该管，怎么快速判定主责？
先回到交付责任：这件事的最终结果由谁承担，主责就先归谁。以进度延期为例，交付结果由项目经理承担，追赶计划的制定与执行归项目经理；PMO承担的是按统一口径汇总延期信息、组织评审、把超出项目经理权限的资源冲突列入治理议题。
如果交付责任确实落在项目经理身上，但过程标准由PMO制定，那么项目经理按标准执行、反馈适用性问题，标准本身的修订权仍在PMO。判定完成后把结论写入职责边界说明，下次遇到同类事项直接引用，减少重复争论。
组织规模较小、PMO只承担支持职能时，职责边界还要不要写得这么细？
仍然建议写，但可以简化归属层级。小组织中过程标准的制定可能由项目经理群体共同维护、PMO负责归集和发布，这时四类事项的默认归属需要按实际情况调整，调整结果写进职责边界说明即可。
需要保留的核心是两点：每项高频交叉事项有明确主责，出现分歧时有写明的升级对象。文档篇幅可以短，但这两项不能省，否则边界仍停留在口头约定。
升级路径写好了，但实际很少被触发，说明机制有问题吗？
不能直接下结论，需要结合争议记录判断。长期零升级有两种可能：一是问题在项目层就被消化，机制运转正常；二是升级门槛过高或角色不愿升级，问题被压在项目层。
核对方法是抽查近一个季度的评审纪要与争议记录，看是否存在应当升级却未升级的事项。若存在，检查升级条件是否写得太模糊，例如只写“重大冲突”而未给出时限和判定标准，应改为可执行的条件与对象。
职责边界说明发布后，什么情况下需要修订？
常见触发条件有三类：组织调整导致角色或汇报关系变化；项目类型变化带来新的事项类别；连续出现同类争议，说明原有归属原则覆盖不到。
修订责任建议放在PMO，由其负责版本管理、变更通知和归档，项目经理提出修订建议并提供执行反馈。修订后在下一次阶段评审中验证执行情况，确认相关角色使用的是同一版本。
职责清单、RACI表和评审记录放在工具里维护，有什么实际好处？
放在工具里维护，主要解决版本一致和状态同步两个问题：职责清单与RACI表作为文档或工作项属性维护，评审纪要与升级议题作为记录留痕，相关角色看到的是同一份内容。
ONES提供业务、产品经理与研发团队多视角的统一需求池、工单与任务看板，便于跨角色同步状态与追溯问题；效能管理支持为不同角色配置读写权限，并可将仪表盘共享给其他用户，减少重复配置。这些能力适合承载状态汇总与角色视图，具体配置需按实际部署确认。
