PMO职责说明用于界定PMO的定位、职责边界、协作接口与考核口径，是PMO开展工作的组织依据。本文提供一份可直接复制填写的空白模板，按定位与授权、职责清单、接口与边界、运作机制、考核指标、版本维护六块组织，并配套字段说明、必填选填规则与一份完整填写示例，便于按组织实际裁剪后发布。
要点总览（TL;DR）
- 模板按“定位与授权—职责清单—接口与边界—运作机制—考核指标—版本维护”六块组织，复制后替换方括号内容即可使用。
- 职责描述写清动作、对象与结果，输出物填名词性成果，责任角色填岗位而非人名，是模板可用的关键。
- 文档信息、定位授权、职责编号与描述、接口对象与交接内容、运作机制、版本记录为必填；协作方、触发时点、考核指标可按组织情况裁剪。
- 示例以约300人软件企业为假设背景，演示五项职责、五类接口与四项指标如何填写，读者需替换为本组织实际内容。
- 发布后每半年复核一次，实质性变更升主版本号，措辞修正升次版本号，并同步检查与项目管理制度、考核办法的引用关系。
可复制空白模板：PMO职责说明文档
以下模板可直接复制到文档工具中填写。方括号内为填写提示，正式发布时替换为实际内容。表格部分保留表头即可扩展行数。
一、文档基本信息
| 项目 | 填写内容 |
|---|---|
| 文档名称 | [组织名称]PMO职责说明 |
| 文档编号 | [如 PMO-GOV-001] |
| 版本号 | [V1.0] |
| 生效日期 | [YYYY-MM-DD] |
| 编制人 | [姓名/角色] |
| 审批人 | [姓名/角色] |
| 适用范围 | [适用的部门、项目类型或项目集范围] |
二、PMO定位与授权
| 项目 | 填写内容 |
|---|---|
| 使命 | [PMO存在的目的，一句话说明为谁解决什么问题] |
| 汇报关系 | [向谁汇报，如分管研发的副总裁] |
| 组织形态 | [支持型/控制型/指令型，或按组织自定义描述] |
| 授权范围 | [可决定的审批事项、可调用的资源、可发起的检查] |
| 不授权事项 | [明确不由PMO决定的事项，如项目立项终审权归属] |
三、职责清单
| 职责编号 | 职责名称 | 职责描述 | 责任角色 | 输出物 | 协作方 |
|---|---|---|---|---|---|
| R-01 | [职责名称] | [动作＋对象＋结果] | [PMO内承担角色] | [可交付成果] | [配合部门或角色] |
| R-02 | |||||
| R-03 |
四、接口与边界
| 接口对象 | 交接内容 | 触发时点 | 边界说明 |
|---|---|---|---|
| 项目管理 | [交接的输入与输出] | [何时发生交接] | [PMO做到哪一步为止] |
| 项目集管理 | |||
| 项目组合管理 | |||
| 质量管理 | |||
| 财务 |
五、运作机制
| 机制名称 | 频率 | 参与角色 | 产出 |
|---|---|---|---|
| 项目例会 | [每周/双周] | [参会角色] | [会议纪要、问题清单] |
| 阶段评审 | [按里程碑] | [评审结论] | |
| 状态报告 | [每月] | [项目状态报告] |
六、考核指标
| 指标名称 | 口径 | 目标值 | 数据来源 | 统计周期 |
|---|---|---|---|---|
| [指标名称] | [计算公式与统计范围] | [目标值] | [系统或台账] | [月度/季度] |
七、版本与维护记录
| 版本号 | 变更日期 | 变更内容 | 变更人 | 审批人 |
|---|---|---|---|---|
| V1.0 | [YYYY-MM-DD] | 首次发布 | [姓名] | [姓名] |
字段说明：每个填写项的含义与写法
模板能否被正确使用，取决于填写人对每个字段口径的理解是否一致。下表逐项说明含义与写法，其中“示例写法”仅示意格式，不代表真实组织分工。
| 字段名 | 含义 | 填写口径 | 示例写法 |
|---|---|---|---|
| 职责编号 | 职责条目的唯一标识 | 采用“R-两位序号”，新增职责顺延编号，删除的编号不复用，便于历史追溯 | R-03 |
| 职责名称 | 职责的简短概括 | 使用动宾短语，控制在12字以内，同一文档内不出现重名 | 项目进度跟踪与预警 |
| 职责描述 | 职责的具体内容 | 写清动作、对象与结果三要素，避免只写“负责项目管理”这类无法考核的表述 | 按周收集各项目进度数据，识别偏差超过阈值的项目并发出预警 |
| 责任角色 | PMO内部承担该职责的岗位 | 填写岗位或角色名称，不填具体人名，人员变动时无需改文档 | 项目管理专员 |
| 协作方 | 配合完成该职责的其他部门或角色 | 与责任角色区分：责任角色对结果负责，协作方提供输入或配合动作 | 各项目经理、研发部门负责人 |
| 输出物 | 该职责产生的可交付成果 | 填写名词性成果，如报告、清单、模板、决议，不填“跟踪”“检查”等动作 | 项目周报、进度偏差清单 |
| 接口对象 | 与PMO发生工作交接的组织单元 | 按管理层次和职能列出，交接内容写清输入与输出两个方向 | 项目集管理 |
| 触发时点 | 接口交接发生的时机 | 写明具体节点，如“项目立项通过后3个工作日内”，避免“及时”“适时” | 每月5日前 |
| 指标口径 | 指标的计算方式与统计范围 | 写明分子分母、统计对象与排除条件，确保不同人计算结果一致 | 按期交付项目数÷在管项目总数，不含已终止项目 |
| 数据来源 | 指标取数的系统或台账 | 写明具体系统名称或台账名称，注明由谁维护 | 项目管理系统状态字段 |
职责描述是最容易写空的字段。一个可操作的判断方法是：把描述读给未参与编写的人听，对方能说出“谁在什么时候做什么、做完得到什么”，这条描述就算合格。若只能听出态度或方向，需要补充动作和结果。
必填与选填：哪些字段不能空
模板字段并非全部同等重要。必填字段缺失会导致文档无法作为职责依据使用；选填字段则可根据组织规模和管理成熟度裁剪。
| 字段 | 必填/选填 | 理由或适用条件 |
|---|---|---|
| 文档名称、版本号、生效日期、编制人、审批人 | 必填 | 缺少审批信息，文档不具备发布效力 |
| 使命、汇报关系、授权范围 | 必填 | 定位与授权是职责清单的前提，缺失会导致职责无法落地 |
| 不授权事项 | 建议必填 | 组织内存在职责争议时必填，用于划清与其他部门的界限 |
| 职责编号、职责名称、职责描述、责任角色、输出物 | 必填 | 构成一条可考核职责的最小信息集 |
| 协作方 | 选填 | 职责由PMO独立完成时可空；涉及跨部门配合时填写 |
| 接口对象、交接内容 | 必填 | 接口不清是PMO与其他部门冲突的主要来源 |
| 触发时点 | 选填 | 交接为常态化流转时可写频率代替具体时点 |
| 运作机制中的例会与报告 | 必填 | 运作节奏是职责履行的载体 |
| 考核指标 | 建议必填 | PMO处于支持型定位、暂不纳入考核时可先留空，但需在版本记录中注明原因 |
| 版本与维护记录 | 必填 | 首次发布即产生第一条记录 |
裁剪需结合组织实际。三五人的小团队中，PMO往往由项目经理兼任，接口与运作机制可合并为一节，重点写清与研发负责人的交接即可；多项目并行的组织中，项目集与项目组合两个接口应分开描述，因为前者关注跨项目依赖协调，后者关注投资取舍，混写会让职责边界模糊。
裁剪后要检查关联字段是否同步。例如删去“协作方”列，职责描述中就不应再出现“协同XX部门完成”的表述；合并接口章节后，职责清单中的输出物仍需能对应到某个接口对象，否则该输出物无人接收，职责实际落空。
填写示例：一份完整的PMO职责说明
以下示例为演示用途，背景设定为一家约300人规模的软件企业，同时管理十余个研发项目，PMO由4人组成。示例中的职责分工、指标目标值均为假设，不代表任何真实组织，读者应替换为本组织实际内容。
基本信息与定位授权
| 项目 | 填写内容 |
|---|---|
| 文档名称 | 研发中心PMO职责说明 |
| 文档编号 | PMO-GOV-001 |
| 版本号 | V1.0 |
| 生效日期 | 2025-03-01 |
| 编制人 | PMO负责人 |
| 审批人 | 研发副总裁 |
| 适用范围 | 研发中心全部在建项目及项目集 |
| 使命 | 为研发中心提供项目过程可视性与方法支持，使项目状态可被及时掌握、风险可被提前处理 |
| 汇报关系 | 向研发副总裁汇报 |
| 组织形态 | 支持型，对项目过程提供方法、模板与数据支持，不直接指挥项目团队 |
| 授权范围 | 可发起项目过程检查、可要求项目经理按期提交状态数据、可发布过程改进建议 |
| 不授权事项 | 项目立项终审、项目预算调整审批、人员调配决定 |
职责清单
| 职责编号 | 职责名称 | 职责描述 | 责任角色 | 输出物 | 协作方 |
|---|---|---|---|---|---|
| R-01 | 项目过程模板维护 | 维护项目立项、计划、周报、结项四类模板，每季度收集使用反馈并更新一次 | PMO专员 | 过程模板包、模板更新记录 | 各项目经理 |
| R-02 | 项目进度跟踪与预警 | 每周汇总各项目进度数据，识别偏差超过一周的项目并向项目经理发出预警 | PMO专员 | 项目周报、进度偏差清单 | 项目经理 |
| R-03 | 阶段评审组织 | 按项目里程碑组织阶段评审，提前三个工作日发出材料要求，会后两个工作日内发布评审结论 | PMO负责人 | 评审通知、评审结论 | 技术负责人、质量部门 |
| R-04 | 跨项目依赖协调 | 收集项目间资源与交付依赖，每月组织一次依赖协调会并跟踪未决事项闭环 | PMO负责人 | 依赖清单、协调会纪要 | 项目集负责人 |
| R-05 | 过程改进建议 | 基于项目数据识别重复出现的问题，每季度形成改进建议并提交研发管理层 | PMO负责人 | 季度改进建议报告 | 研发管理层 |
接口与边界
| 接口对象 | 交接内容 | 触发时点 | 边界说明 |
|---|---|---|---|
| 项目管理 | PMO输出模板与预警信息；项目经理输入进度数据与风险说明 | 每周五前提交数据，次周一发布周报 | PMO负责发现与提示偏差，纠偏措施由项目经理制定 |
| 项目集管理 | PMO输出跨项目依赖清单；项目集负责人输入资源冲突信息 | 每月依赖协调会前 | PMO负责组织协调与记录，资源调配决定由项目集负责人做出 |
| 项目组合管理 | PMO输出项目状态汇总；组合管理方输入立项与终止决策 | 每季度组合评审前 | PMO提供数据支持，不参与投资取舍决策 |
| 质量管理 | PMO输出阶段评审结论；质量部门输入质量检查结果 | 每次阶段评审后 | 质量判定标准由质量部门制定，PMO负责组织评审流程 |
| 财务 | PMO输出项目进度与资源投入数据；财务输入成本核算口径 | 每月成本核算前 | PMO不承担成本核算与预算审批 |
运作机制与考核指标
| 机制名称 | 频率 | 参与角色 | 产出 |
|---|---|---|---|
| 项目周例会 | 每周一 | PMO、项目经理 | 周报、问题清单 |
| 阶段评审 | 按里程碑 | PMO、技术负责人、质量部门 | 评审结论 |
| 依赖协调会 | 每月一次 | PMO、项目集负责人、项目经理 | 依赖清单、会议纪要 |
| 季度改进回顾 | 每季度 | PMO、研发管理层 | 改进建议报告 |
| 指标名称 | 口径 | 目标值 | 数据来源 | 统计周期 |
|---|---|---|---|---|
| 状态数据按时提交率 | 按期提交周报的项目数÷在管项目总数，不含已终止项目 | ≥95% | 项目管理系统状态字段 | 月度 |
| 进度预警响应率 | 收到预警后三个工作日内给出纠偏说明的项目数÷预警总数 | ≥90% | 预警台账 | 月度 |
| 评审结论按时发布率 | 会后两个工作日内发布结论的评审场次÷评审总场次 | 100% | 评审记录 | 季度 |
| 改进建议采纳数 | 经研发管理层确认采纳的改进建议条数 | 每季度≥2条 | 改进建议报告及批复记录 | 季度 |
版本记录
| 版本号 | 变更日期 | 变更内容 | 变更人 | 审批人 |
|---|---|---|---|---|
| V1.0 | 2025-03-01 | 首次发布，确立五项核心职责与四类运作机制 | PMO负责人 | 研发副总裁 |
示例中考核指标的口径均写明了分子分母与排除条件，这是避免同一指标在不同部门算出不同结果的关键。指标数据若分散在多个系统或手工台账中，统计成本会显著上升，建议在发布前确认每个指标都能稳定取数。
调整与维护：模板发布后的更新方法
职责说明发布后若长期不更新，会逐渐与实际工作脱节，最终失去约束力。维护工作应围绕评审、变更触发、版本规则和定期复核四件事形成固定动作。
首次发布的评审与审批
初稿完成后，先由PMO内部核对职责清单与接口章节是否一一对应，再提交给主要接口部门负责人会签，重点确认边界描述是否被对方认可。会签通过后由分管领导审批发布，并在发布通知中说明生效日期与旧版本的处理方式。会签环节不可省略，接口边界只有在对方确认后才具备执行基础。
职责变更的触发条件
出现以下情况时应启动修订：组织架构调整导致汇报关系或接口对象变化；新增项目类型使原有职责覆盖不到；连续两个考核周期某项指标无法取数或目标值明显失真；接口部门提出书面异议且经沟通确认需要调整边界。日常小范围措辞修正可随定期复核一并处理，不必单独发起修订。
版本号与变更记录规则
建议采用两级版本号：职责条目增删、授权范围调整、接口对象变化等实质性变更升主版本号，如V1.0升至V2.0；措辞修正、示例更新、格式调整升次版本号，如V1.0升至V1.1。每次变更在版本记录表中写明变更内容、变更人和审批人，旧版本归档保留，便于追溯某项职责是何时加入或取消的。
定期复核与责任人
建议每半年复核一次，由PMO负责人发起，核对职责清单与实际工作是否一致、指标是否仍可稳定取数、接口部门是否有新的交接需求。复核结论无论是否修订都应有记录，未修订的注明“本次复核无变更”。组织发生重大调整时不受半年周期限制，应及时启动专项复核。
与相关制度文档的联动
PMO职责说明通常与项目管理制度、考核管理办法、评审规范等文档相互引用。修订本文件时，应检查引用关系：职责清单中引用的模板名称是否与模板文件一致，考核指标是否与考核办法中的定义冲突，接口描述是否与项目管理制度中的流程节点对应。联动更新可在版本记录的变更内容中注明同步修订的其他文档编号，避免出现两份文件对同一事项规定不一致的情况。
当职责分派、评审记录和版本变更需要在系统中留痕时，可将职责清单拆解为可分配的工作项，把评审结论与版本记录沉淀为文档，使每次修订都有对应的审批记录和数据来源。ONES 提供工作项与文档管理能力，ONES Performance 则列出 PMO 多项目管理等场景，并支持对系统内产生的研发数据进行多维度分析，可用于承接考核指标中状态提交率、预警响应率这类过程数据的统计；具体指标口径仍需按本文模板中的定义在组织内确认。
常见问题
PMO职责说明和项目管理制度、考核办法是什么关系，需要重复写吗？
三者分工不同，内容应相互引用而非重复。职责说明回答“PMO负责什么、做到哪一步、与谁交接”；项目管理制度规定项目从立项到结项的整体流程与节点；考核办法规定指标定义与评分规则。填写时，职责清单中的输出物应能对应到制度中的流程节点，考核指标的名称与口径应与考核办法保持一致。修订任一份文件时，检查另外两份的引用处是否需要同步更新，并在版本记录中注明联动修订的文档编号。
组织规模很小，PMO由项目经理兼任，模板可以精简到什么程度？
可以保留四块核心内容：文档基本信息、定位与授权、职责清单、版本记录。接口与边界可合并为一节，只写与研发负责人、财务的交接；运作机制可并入职责描述，用“每周汇总进度并发布周报”这类表述代替单独表格；考核指标若暂不纳入考核可留空，但需在版本记录中注明原因。精简后要检查职责清单的输出物是否仍有明确接收方，避免出现无人接收的成果。
职责描述写到什么颗粒度算合格，写得太细会不会限制执行？
判断标准是可验证：未参与编写的人读完能说出谁在什么时点做什么、做完得到什么。达到这个程度即可，不必写到具体操作步骤。颗粒度过细会把方法固化为制度，流程调整时文档频繁失效；颗粒度过粗则无法考核。建议一条职责对应一个可交付成果，跨多个部门、多个阶段的职责拆成多条，用职责编号区分。
考核指标的数据取不到，还能写进职责说明吗？
不建议写入无法稳定取数的指标。发布前应逐项确认数据来源：系统字段是否有人维护、台账是否按期更新、统计口径能否被相关方复算。若某项指标暂时取数困难，可先不列入，待数据基础具备后随版本修订补充。已列入的指标若连续两个考核周期无法取数或目标值明显失真，应启动修订，而不是在文档中保留一个无法执行的指标。
职责说明发布后，接口部门不认可边界描述怎么办？
边界描述只有在对方确认后才具备执行基础，因此会签环节应放在审批发布之前。若发布后出现异议，先由PMO与接口部门就具体交接事项逐条核对，明确输入、输出与触发时点，形成书面修订意见后按变更流程处理。涉及授权范围调整的，需重新走审批；仅措辞澄清的，可随定期复核一并修订，并在版本记录中写明变更原因与双方确认情况。
