编写PMO职责说明，先确定PMO在本组织承担的角色边界，再按“定位与目标—职责清单—角色与权限—协作接口—流程与交付物—考核与修订”的顺序成文。每条职责写成“动作+对象+输出+完成标志”，标注负责人和协作方，让文档既能指导日常协作，也能作为考核和争议裁定的依据。下文给出可直接套用的结构、写法规则、填写示例和完成检查清单。
要点总览（TL;DR）
- 先确定PMO的角色类型（服务型、控制型或混合型）、适用组织范围和相邻职能边界，再展开职责清单，避免条目写到一半才发现边界不清。
- 职责条目按“动作+对象+输出+完成标志”四要素写，并标注负责人、协作方和权限类型，让每条职责都能被验收和考核。
- 跨部门事项要写清发起方、响应方、响应时限和升级路径，用接口表或RACI把PMO与项目经理、职能经理、决策层的交接物固定下来。
- 发布前经过决策层、项目经理和职能经理代表评审，发布后完成宣贯；设置修订触发条件并保留版本记录，让文档随组织变化持续可用。
- 用完成检查清单逐项核对职责完整性、权限对应、接口承接和表述可验收性，全部通过再进入评审发布。
先定PMO定位：职责说明的编写起点
职责说明写不清楚，多数问题出在动笔之前：PMO到底管什么、对谁负责、与哪些职能相邻，没有形成共识。编写前先把三项前提定下来，后面的职责清单才有边界可依。
第一项：确定PMO的角色类型
PMO常见的角色类型有三种，对职责写法的影响很直接。服务型PMO以提供方法、模板、工具和培训为主，职责条目多写“提供、维护、支持”，权限以建议权和知情权为主；控制型PMO承担计划审核、阶段 gate 评审、资源协调等把关动作，职责条目需要写清审核对象、审核标准和否决条件，权限包含审核权甚至决定权；混合型PMO在方法支持之外对关键项目保留评审与监督职责，写法上要按事项分别标注权限，避免整份文档笼统写“负责管控”。
角色类型由组织的治理成熟度、项目风险和决策层授权决定，没有统一答案。编写时可以先与决策层确认一句话定位，例如“为本年度重点项目提供方法支持与阶段评审”，再把它展开成职责条目。
第二项：明确适用组织范围与生效对象
职责说明要写明适用于哪些部门、哪类项目、哪些岗位。是按项目金额、项目等级还是按业务线划分适用范围，需要在文档中给出可判断的标准。生效对象包括PMO内部岗位、项目经理、职能经理和决策层，不同对象的义务要分别写清，例如项目经理有提交计划供评审的义务，职能经理有响应资源协调请求的义务。
第三项：划清与相邻治理职能的边界
PMO常与项目集运行、项目组合投资决策、质量管理、财务管理等职能相邻。边界划分的做法是列出相邻职能，逐项写明“由谁主导、PMO参与什么、PMO不承担什么”。例如投资决策由组合管理委员会决定，PMO负责提供项目状态与资源数据；项目集内的跨项目依赖协调由项目集经理主导，PMO提供协调机制和升级通道。把“明确不纳入的事项”写进文档，能显著减少后续争议。
| 定位确认项 | 填写内容 | 编写影响 |
|---|---|---|
| 角色类型 | 服务型／控制型／混合型，并注明按事项区分的例外 | 决定职责动词与权限等级 |
| 服务对象 | 决策层、项目经理、项目团队、职能部门 | 决定接口事项与交付物 |
| 职责边界 | 主导事项、参与事项、知情事项 | 决定职责条目的范围 |
| 明确不纳入的事项 | 如投资决策、职能绩效考核 | 减少跨部门执行争议 |
职责说明的标准结构与逐条写法
一份可执行的PMO职责说明，章节顺序建议固定为：目的与适用范围、PMO定位、职责清单、角色与权限、协作接口、工作流程与交付物、考核与修订。前两章回答“为什么写、管到哪里”，中间三章回答“做什么、谁来做、和谁衔接”，后两章回答“怎么运转、怎么更新”。
职责条目的四要素写法
每条职责按“动作+对象+输出+完成标志”展开，并标注负责人和协作方。动作使用可观察的动词，如编制、审核、组织、维护、提交、归档；对象是具体的项目、计划、模板、报告或会议；输出是可见的文档、记录或状态；完成标志是判断该职责已履行的客观条件，例如“评审纪要归档且问题项关闭率达到约定比例”。
| 要素 | 写法要求 | 示例 |
|---|---|---|
| 动作 | 可观察、可追溯的动词 | 组织、审核、维护、提交 |
| 对象 | 具体的工作对象 | 项目阶段计划、风险登记册、月度状态报告 |
| 输出 | 文档、记录或状态变化 | 评审纪要、风险跟踪表、状态报告发布记录 |
| 完成标志 | 可核验的客观条件 | 纪要发出且问题项有责任人与关闭时间 |
权限与职责一一对应
职责条目要同时标注权限类型：建议权（提出方案供决策）、审核权（对提交内容把关）、决定权（可直接裁定）、知情权（接收信息但不介入）。同一事项上，职责动词与权限等级要匹配，写“审核项目计划”就应具备审核权，写“参与资源协调”则对应建议权或知情权。权限缺失或越权，都会让职责说明在执行时失效。
空泛表述的改写
“统筹协调项目资源”“加强项目过程管理”“提升项目交付质量”这类表述无法验收，需要落到对象和输出上。改写时先问三个问题：对什么对象做、产出什么、什么状态算完成。例如“统筹协调项目资源”可改为“收集重点项目资源缺口，组织月度资源协调会，输出资源调配建议清单，会议后三个工作日内完成缺口响应确认”。
| 空泛表述 | 改写后 |
|---|---|
| 加强项目过程管理 | 按阶段组织项目计划评审，输出评审纪要并跟踪问题项关闭 |
| 提升项目交付质量 | 维护阶段交付物检查清单，在里程碑前完成检查并记录偏差 |
| 做好项目沟通 | 编制月度项目状态报告，经审核后发布给决策层与相关职能部门 |
角色分工与协作接口怎么落到文档里
职责说明只写PMO自己做什么还不够，跨部门事项必须写清谁发起、谁响应、多久响应、升级给谁。接口写不清，职责条目在跨部门执行时就会被反复拉扯。
PMO内部岗位分工
按职能把PMO内部岗位拆开，常见分工包括流程与方法、计划与进度、度量与报告、工具与数据支持。每个岗位对应到具体职责条目，避免一条职责挂多个岗位却无人真正负责。岗位数量按PMO实际规模设置，小规模PMO可由一人兼多个岗位，但职责条目仍要标明主责岗位。
与项目经理、职能经理、决策层的接口
接口事项用“输入—处理—输出—交接对象”描述。PMO与项目经理之间，典型接口是计划评审、状态报告和风险升级；与职能经理之间，典型接口是资源缺口响应和人员投入确认；与决策层之间，典型接口是阶段评审结论和重大风险上报。每个接口写明交接物和时限，接口才算落地。
发起、响应与升级路径
跨部门协作事项要写明发起方、响应方、响应时限和升级条件。例如资源缺口由项目经理发起，职能经理在约定工作日内响应，未响应或无法满足时升级至PMO负责人协调，仍无法解决则提交决策层。升级路径要写清每一级的触发条件和时限，避免所有问题都直接上抛。
RACI的使用方式
RACI适合在职责说明的附录或接口章节使用，按关键事项列出负责（R）、批准（A）、咨询（C）、知情（I）四类角色。使用时注意每个事项只有一个批准人，负责角色可以有多个；RACI表与职责条目要能互相对应，不能出现条目里没写、表里却有的职责。
| 接口事项 | 发起方 | PMO角色 | 响应／交接对象 | 交接物 |
|---|---|---|---|---|
| 阶段计划评审 | 项目经理 | 组织评审、记录结论 | 项目经理、决策层 | 评审纪要与问题清单 |
| 资源缺口协调 | 项目经理 | 汇总缺口、组织协调 | 职能经理 | 资源调配建议清单 |
| 重大风险上报 | PMO | 核实并上报 | 决策层 | 风险上报单与处置建议 |
| 月度状态报告 | PMO | 编制、审核、发布 | 决策层、职能部门 | 状态报告发布记录 |
编写示例：一份可套用的PMO职责说明片段
以下示例为演示情景，组织背景为一家设有研发中心、同时运行十余个研发项目的企业，PMO定位为混合型：提供方法与工具支持，并对重点项目保留阶段评审职责。示例中的时限和比例仅作写法示范，实际编写时按本组织约定替换。
定位段示例
“本PMO适用于研发中心全部立项项目，服务对象为决策层、项目经理与项目团队。PMO承担方法支持与重点项目阶段评审职责：维护项目管理流程、模板与工具，组织重点项目阶段评审，汇总项目状态与资源缺口供决策层参考。项目投资决策、职能人员绩效考核不纳入PMO职责范围。”
职责条目示例
| 职责条目 | 负责人 | 协作方 | 权限 | 完成标志 |
|---|---|---|---|---|
| 维护项目阶段计划模板与评审检查清单，每季度根据评审反馈更新一次，发布至项目管理文档库 | 流程与方法岗 | 项目经理代表 | 决定权（模板内容） | 新版模板发布且有更新记录 |
| 组织重点项目阶段评审，提前收集评审材料，输出评审纪要与问题清单，跟踪问题项至关闭 | 计划与进度岗 | 项目经理、技术负责人 | 审核权 | 纪要发出，问题项均有责任人与关闭时间 |
| 汇总各项目月度状态与资源缺口，编制月度状态报告，经PMO负责人审核后发布给决策层与相关职能部门 | 度量与报告岗 | 项目经理、职能经理 | 建议权（资源调配） | 报告按期发布并有接收确认 |
接口与升级路径示例
“项目经理在阶段评审前提交计划与风险清单；PMO在约定工作日内完成材料完整性检查并反馈。资源缺口由项目经理发起，职能经理在约定工作日内响应；未响应或无法满足的，由PMO负责人协调，仍无法解决的提交决策层裁定。评审中发现的重大风险，由PMO在两个工作日内形成风险上报单提交决策层。”
职责说明落地后，流程、交付物和评审状态需要有稳定的承载方式。ONES 支持将项目计划、评审记录和问题项作为工作项流转，ONES Performance 自动收录系统内日常流转的研发数据并形成分析指标，预置面向管理人员、项目经理等角色视角的仪表盘模板，可共享给其他用户。PMO可以把职责条目中的输出物对应到系统中的工作项与文档状态，让“完成标志”有可查的记录，减少靠人工汇总核对的工作量。
评审、发布与修订：让职责说明真正生效
职责说明写完不等于生效。发布前经过相关方评审，发布后完成宣贯，运行中按触发条件修订，文档才能持续指导协作。
评审参与方与关注点
评审至少覆盖决策层代表、项目经理代表、职能经理代表和PMO内部岗位。决策层关注授权范围与升级路径是否清晰，项目经理关注职责条目是否可执行、是否增加无效负担，职能经理关注接口事项的响应义务是否合理。评审输出问题清单，逐项确认修改或保留理由。
发布方式与宣贯动作
发布时明确版本号、生效日期和适用范围，通过项目管理文档库或内部知识库统一存放，并在项目启动会、PMO例会等场合做一次要点宣贯。宣贯重点讲清接口事项和升级路径，这两部分最容易在执行中产生分歧。
修订触发条件与版本管理
建议设置明确的修订触发条件：组织架构或PMO定位调整、相邻治理职能职责变化、连续出现同类职责争议、评审机制或工具发生较大变化。修订由PMO发起，按原评审范围确认后发布新版本，旧版本归档保留，文档中记录修订说明。
| 修订触发条件 | 发起方 | 确认范围 | 输出 |
|---|---|---|---|
| PMO定位或授权调整 | PMO负责人 | 决策层 | 新版本职责说明 |
| 相邻职能职责变化 | PMO | 相关部门负责人 | 边界条款修订记录 |
| 同类职责争议重复出现 | PMO | 争议相关方 | 条款澄清与宣贯记录 |
| 流程或工具较大调整 | PMO | 项目经理代表 | 流程与交付物章节更新 |
职责争议的裁定路径
文档中写明争议裁定顺序：先由争议双方对照职责说明协商，协商不成提交PMO负责人协调，仍无法解决的由决策层裁定。裁定结果如涉及条款不清，应同步触发修订，把裁定结论写回文档，避免同类争议反复出现。
完成检查：职责说明是否可用的判断标准
发布前用下面这份清单逐项核对，全部通过再进入评审发布环节。清单按可核验的条件设计，避免凭感觉判断。
| 检查项 | 判断标准 | 通过条件 |
|---|---|---|
| 职责条目完整性 | 每条职责是否具备动作、对象、输出与完成标志 | 抽查任意三条，四要素齐全 |
| 权限对应 | 职责动词与建议权、审核权、决定权、知情权是否匹配 | 无职责条目缺少权限标注 |
| 接口承接 | 每个跨部门接口事项是否都有承接方和交接物 | 接口表中无空白承接方 |
| 表述可验收 | 是否存在无法判断完成状态的空泛表述 | 全文检索“加强、提升、统筹”等词，均有具体对象与输出 |
| 范围与生效 | 是否写明适用组织范围、生效对象和生效日期 | 文档开头可查到 |
| 修订机制 | 是否写明修订触发条件、发起方和版本管理方式 | 修订章节可查到 |
| 争议裁定 | 是否写明职责争议的裁定路径 | 有明确的逐级裁定顺序 |
检查通过后，职责说明即可进入评审。运行一段时间后，结合评审记录和争议情况回看清单，把执行中暴露的问题转化为条款修订，文档才会随着组织协作方式的变化保持可用。
常见问题
PMO职责说明和项目集治理、项目组合决策的文件怎么区分，避免内容重叠？
三份文件回答的问题不同：职责说明回答“PMO这个组织单元做什么、有什么权限、和谁衔接”，项目集治理文件回答“多个关联项目如何协同运行与监控状态”，项目组合决策文件回答“哪些项目立项、优先级如何排、投资如何分配”。
编写时在职责说明的边界章节列出相邻职能，逐项写明由谁主导、PMO参与什么、PMO不承担什么。例如投资决策由组合管理委员会决定，PMO提供项目状态与资源数据；项目集内的跨项目依赖协调由项目集经理主导，PMO提供协调机制和升级通道。把“明确不纳入的事项”写进文档，三份文件就能各司其职。
组织里PMO只有一两个人，职责说明还要按岗位拆分吗？
需要保留岗位维度，但可以一人兼多岗。做法是职责条目仍标明主责岗位，例如流程与方法、计划与进度、度量与报告、工具与数据支持，再在文档中注明当前由谁兼任。
这样写的好处是：组织扩张时可以按岗位补人，职责条目不用重写；日常执行时每条职责都有明确的主责人，不会出现一条职责挂多个岗位却无人真正负责的情况。岗位数量按PMO实际规模设置，不必为了结构完整虚构不存在的岗位。
职责说明发布后，项目经理认为新增了额外负担、不愿配合，怎么处理？
先回到文档本身核对：该职责条目是否写清了输出和完成标志，是否标注了权限类型，是否与项目经理的现有动作重复。如果条目只写“配合PMO完成评审”这类没有对象和时限的表述，执行阻力往往来自写法不清，而非职责本身不合理。
处理路径可以分两步：一是把争议事项提交PMO负责人协调，对照职责说明确认双方义务；二是协调不成的由决策层裁定。裁定结果如果说明条款本身不清，应同步触发修订，把结论写回文档并做一次宣贯，避免同类争议反复出现。
职责说明里的“完成标志”设成比例或时限，有什么注意事项？
完成标志要可核验，比例和时限都要给出统计口径和起算点。例如写“问题项关闭率达到约定比例”，需要说明统计周期、分母是哪些问题项、由谁统计；写“三个工作日内完成响应确认”，需要说明从哪个事件起算、遇节假日如何处理。
示例中的比例和时限仅作写法示范，实际编写时按本组织约定替换，并在文档中写明数据来源。完成标志与系统中的记录对应起来，核验成本会明显降低。
PMO定位从服务型转向控制型，职责说明要整体重写吗？
不必整体重写，按事项逐条调整即可。定位段先更新角色描述和授权来源，然后逐条检查职责条目的动词和权限标注：原来写“提供模板、组织培训”的条目，转为控制型后可能改为“审核项目计划、组织阶段 gate 评审”，权限从建议权调整为审核权，完成标志也要相应改为可核验的评审结论。
相邻职能边界章节需要同步复核，确认新增的把关动作没有与质量管理、财务管理等职能重叠。修订按原评审范围确认后发布新版本，旧版本归档保留，并在修订说明中记录变化原因。
