PMO与项目经理的职责交叉，往往源于职责说明按“动作”罗列：计划、汇报、风险、评审，两边都写了一遍，执行时自然互相等待或重复介入。本文给出一套按业务对象与决策权划分的编写方法，包含五列职责说明表、典型交叉场景的归属示例与发布后的检查清单，并说明如何借助ONES的工作项与文档状态让主责、协同和升级路径可执行。
要点总览（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承担版本维护，负责收集运行中的争议、组织定期复核并发布更新，项目经理作为主要使用方提出修订建议。复核周期建议与组织架构调整、项目类型变化挂钩，至少每年一次，避免职责说明与实际运行脱节。
在工具层面，职责说明的落地可以把主责、协同和升级路径写进工作项字段与文档状态。ONES 效能管理预置了面向管理人员、项目经理等不同角色视角的仪表盘模板，可直接使用；同时支持为不同角色配置读写权限，并可将仪表盘共享给其他用户，减少重复配置。当状态口径和角色视角在系统中被固定下来，职责说明中的“谁填报、谁校验、谁查看”就有了对应的承载位置。ONES Assistant 可围绕项目进展、工时投入、缺陷分布和资源配置生成进展分析与资源合理性建议，供项目经理和PMO在监控节点参考，分析结论仍需由管理者确认后采用。具体字段与权限配置应结合组织实际流程确定。
落地与完成检查
职责说明发布不等于生效。发布前需要经过评审，发布后需要设置校验和争议处理机制，才能保证它在实际运行中被遵守。
评审与发布流程建议如下：由PMO起草或汇总修订稿，组织项目经理代表逐条评审，重点检查每条是否只有一个主责人、交付物是否可检查、升级路径是否有触发条件；评审通过后由项目管理委员会或对应管理层批准发布，明确生效日期和适用项目范围；发布时同步更新相关模板和系统字段，避免文本与操作脱节。
争议处理需要事先约定。职责说明中应写明：日常执行分歧先由当事双方按条目文字协商，协商不成提交PMO负责人裁决；涉及跨项目资源或优先级的分歧提交项目管理委员会；裁决结论应记录在案，作为下次修订的依据。裁决时限也应写明，避免争议长期悬置影响项目推进。
完成检查可按以下清单逐项核验：
- 每条职责只有一个主责人，协同人的参与方式具体可查。
- 每条职责的业务对象可唯一识别，动作动词明确。
- 每条职责都有对应交付物，且交付物有明确接收方和确认方式。
- 升级路径写明触发条件、升级对象和时限，且包含双向通道。
- 同一业务对象上不存在两条主责冲突的条目。
- 职责说明已明确维护责任人和复核周期。
- 文本中的角色、节点和交付物名称与系统字段、模板保持一致。
全部条目通过上述检查，且争议裁决人与升级路径已获相关方确认，即可判定职责说明具备执行条件。此后每次发生职责争议，都应回到条目文字判断归属；若条目无法支撑判断，说明该条需要修订，而不是在个案中临时协商，这样职责说明才能随组织运行持续校准。
常见问题
组织规模较小、PMO为兼职形态时，这套划分方法还能用吗？
可以使用，但需要调整角色承载方式。项目数量少、PMO由其他岗位兼任时，可将部分PMO职责合并到项目管理委员会或由指定负责人承担，例如评审组织与状态口径维护由同一人负责。需要保留的是两条底线：每条职责只设一个主责人；升级路径写明触发条件、升级对象和时限。角色可以合并，主责唯一的原则不变，否则合并后又会回到“共同负责”的状态。
职责说明写完后，实际运行中仍出现双方都认为不归自己的情况，怎么处理？
先回到条目文字判断：该条的业务对象是否可唯一识别、主责人是否只有一个、交付物是否有明确接收方。多数空档来自条目本身写得模糊，例如只写“负责风险管理”而未区分项目内风险处置与跨项目风险跟踪。若条目确实无法支撑判断，应按修订流程补充条目，而不是在个案中临时协商。临时协商的结论应记录在案，作为下一轮修订的输入，避免同类争议反复出现。
PMO既维护状态口径又汇总跨项目视图，会不会与项目经理的状态汇报职责冲突？
按对象拆分即可避免冲突。项目经理对本周项目状态数据的真实性负责，按既定口径填报；PMO维护口径定义本身，并负责跨项目汇总视图。两者作用的对象不同：一个是单项目数据，一个是跨项目可比性。出现数据口径争议时由PMO裁定，出现数据失实由项目经理更正并说明原因。把这两类问题的处理方式分别写进职责说明，执行时就不需要每次重新讨论归属。
职责说明中的裁决时限和升级层级，应该照示例设置吗？
示例中的时限与裁决层级属于示范设置，组织应结合自身决策节奏确定。设置时把握两点：时限要短到能支撑项目推进，例如风险升级后两个工作日内未获响应即自动上升；层级要与实际授权一致，跨项目资源或优先级分歧提交到有分配权的层级，而非固定提交给某一会议。时限和层级一旦写入职责说明，就应在争议处理中实际执行，否则条目会失去约束力。
职责说明如何与系统中的角色和字段保持一致，避免文本与操作脱节？
发布职责说明时同步更新相关模板与系统字段，把主责、协同和升级路径对应到工作项字段与文档状态，使“谁填报、谁校验、谁查看”有承载位置。ONES 效能管理预置了面向管理人员、项目经理等不同角色视角的仪表盘模板，可直接使用，并支持为不同角色配置读写权限、将仪表盘共享给其他用户，减少重复配置。ONES Assistant 可围绕项目进展、工时投入、缺陷分布和资源配置生成进展分析与资源合理性建议，供监控节点参考，结论仍需管理者确认后采用。具体字段与权限配置应结合组织实际流程确定。
