首次建立项目集治理职责矩阵的步骤

首次建立项目集治理职责矩阵，关键是把“谁在什么事项上做什么决定”先定清楚，再落成表格并投入运行。可按五步推进：盘点治理决策事项、把角色映射到事项、用统一职责类型界定权限、组织评审发布、设定维护与复核机制。本文面向首次建立或重构矩阵的PMO与项目集经理，给出每步的输入、动作和可交付产物。

要点总览（TL;DR）

• 矩阵的行来自治理决策事项：先盘点阶段关口、预算调整、范围变更、重大风险升级、资源冲突裁决、收益目标调整等决策点，为每条事项写明编号、触发条件和决策时限。
• 矩阵的列来自角色映射：把项目集发起人、治理委员会、项目集经理、项目负责人逐事项对应到提议、决策、执行、知会四类动作，确保同一事项的最终决策人唯一。
• 每格权限用统一职责类型表达：定义决策、审批、会签、知会、执行、支持的含义，并为决策类职责补充金额阈值、影响程度与否决权等边界。
• 评审发布要落到实际场景：关键角色共同确认决策权归属，形成带生效日期的正式版本，并接入例会、阶段关口评审和变更审批。
• 维护机制决定矩阵能否长期有效：明确阶段转换、角色更换、委员会调整、重大治理争议等更新触发条件，指定维护责任人与复核周期。

先定矩阵覆盖哪些治理决策事项

职责矩阵的行由治理事项构成，事项清单没定清楚就画表，容易把角色争论变成表格格式争论。第一步的输入是项目集当前运行中的关键决策点，输出是一份带编号、触发条件和决策时限的治理事项清单。

收集事项时，从项目集实际发生的决策场景入手，逐类梳理：

• 阶段关口：阶段交付是否达到放行标准，能否进入下一阶段。
• 预算调整：追加、削减或跨项目调剂预算的申请与批准。
• 范围变更：项目集范围或关键项目目标发生实质性变化时的变更裁决。
• 重大风险升级：超出项目集经理权限的风险处置方案与资源投入。
• 资源冲突裁决：多个项目争用同一关键资源时的优先级判定。
• 收益目标调整：收益指标、衡量口径或达成时点的变更。

事项收集完成后按类型和发生频率归类。阶段关口、例行变更审批属于高频例行事项，适合固化流程；重大风险升级、收益目标调整属于低频例外事项，需要明确升级路径和决策时限。归类的作用是让后续角色映射有轻重之分，避免所有事项都堆到治理委员会。

事项清单要划清边界：只收项目集运行治理范围内的事项，组织PMO制度建设、项目组合层面的项目选择与投资决策不纳入本矩阵，这些内容有各自的治理载体。边界写进清单说明，可以防止矩阵越做越厚、职责越写越模糊。

清单的完成标志是每条事项都有编号、触发条件、决策时限三项信息。触发条件写清“什么情况下启动”，决策时限写清“多长时间内必须给出结论”，这两项直接决定矩阵能否在实际运行中被触发使用。

把发起人、治理委员会、项目集经理、项目负责人映射到事项上

第二步解决矩阵的列：谁参与、谁拍板。输入是上一步的事项清单，输出是以事项为行、角色为列的矩阵初稿。

先列出参与角色。项目集发起人、治理委员会、项目集经理、项目负责人是基本角色；涉及资金、技术架构、质量门槛的事项，可补充财务、架构、质量等职能代表作为列。角色列不宜过多，每一列都应对应实际存在的任命，而不是为求完整虚构岗位。

然后逐事项判断四件事：谁提议、谁决策、谁执行、谁知会。判断时把握一条原则——同一事项的最终决策人唯一。多个角色都可以表达意见，但最终签字或拍板的只能是一个人，否则出现争议时无人能定。执行人可以是项目负责人或项目集经理，知会对象则是需要知情但不参与决策的角色。

角色重叠是常见情形。发起人同时担任治理委员会成员时，需要写明表决与回避规则：涉及发起人本人提出的议题，是否回避表决、由谁主持，应在矩阵附注中写清楚。类似地，项目集经理兼任某项目负责人时，该项目的事项决策是否需要上级复核，也要提前约定。

映射完成后形成矩阵初稿。初稿允许有争议格，但每个事项至少应有一个决策人和一个执行人，空白格留待下一步用职责类型补齐并检查。

用统一的职责类型界定每格权限

第三步解决每格写什么。输入是矩阵初稿，输出是职责类型定义表和填好的职责矩阵。

先定义职责类型集合，并写明每种类型的含义。常用类型如下：

职责类型	含义	典型动作
决策	对事项作出最终结论，承担结果责任	批准放行、否决、裁定优先级
审批	在既定规则内审核并放行	按阈值审批预算或变更
会签	参与联合签署，意见需被记录	多职能联合确认方案
知会	接收信息，不参与决策	接收决策结果与依据
执行	落实决策要求并交付结果	提交材料、完成整改
支持	提供专业输入或资源协助	提供评估意见、调配人员

决策类职责要补充权限边界，否则“决策”二字无法执行。边界通常包括金额阈值、范围影响程度、是否具有否决权。例如预算调整在某一金额以内由项目集经理审批，超过阈值提交治理委员会决策；范围变更影响项目集收益目标时，发起人具有否决权。阈值和否决规则按组织授权实际情况填写。

会签与知会必须区分清楚：会签意味着意见进入决策依据、缺签则流程不完整；知会只要求信息送达，不影响决策成立。把两者混用，会导致流程要么被无谓拖长，要么关键意见被漏掉。

填完后做一轮完整性检查：是否存在空白格、同一事项是否出现多个最终决策人、执行项是否有人负责。发现空白格，要么补角色，要么明确该格为“不参与”，不留模糊。

评审、发布并让矩阵进入实际运行

第四步把矩阵从文档变成运行规则。输入是填好的矩阵，输出是经评审发布的正式版本和宣贯记录。

组织评审时，发起人、治理委员会、项目集经理和项目负责人应共同参加，评审重点放在决策权归属和冲突点上，而不是逐格校对措辞。评审中暴露的分歧，往往说明某项授权在组织内尚未真正达成一致，此时应现场确认或带回上级裁定，不宜以“先发布再调整”带过。

评审意见和修订结果要记录，形成发布版本并标注生效日期。版本号、生效日期、修订摘要三项信息齐全，后续追溯才有依据。

发布之后，把矩阵接入实际治理场景：项目集例会上按矩阵确认待决事项的决策人，阶段关口评审按矩阵规定的提议、决策、执行路径走，变更审批以矩阵中的权限边界作为受理依据。矩阵只有被这些场景引用，才会真正约束行为。

向相关角色宣贯时，讲清各自在矩阵中的职责和触发时点，比通读整张表更有效。例如告诉项目负责人“阶段交付证据由你提交，提交后治理委员会在约定时限内决策”，角色就知道自己在什么时候做什么。

矩阵发布后需要在协作工具中承载事项流转与审批协作时，可考虑ONES：ONES Plan 提供项目集管理能力，支持多项目总览、里程碑与甘特图，便于把治理事项与项目进度放在同一视图下跟踪；ONES Wiki 支持多人协同编辑、页面模板和细颗粒度权限管控，适合存放矩阵正式版本、职责类型定义和修订记录，并与项目数据关联，让角色看到的是同一份最新版本。具体审批流配置方式需结合实际版本向厂商核验。

设定维护触发条件与定期复核

第五步保证矩阵长期有效。输入是已发布的矩阵，输出是维护规则与版本变更记录。

明确触发更新的情形，出现即启动修订：项目集阶段转换、关键角色更换、治理委员会组成调整、发生重大治理争议。这些情形都会改变原有授权关系，矩阵若不随之更新，就会出现“表上有人、实际无人”的情况。

指定维护责任人。常见做法是由项目集经理提出修订建议，治理委员会审定，避免矩阵被单方面修改。复核周期可按季度或按阶段设置，与项目集节奏匹配。

保留版本记录与变更说明，写清每次调整的原因，例如“因发起人变更，阶段关口重大偏差的知会对象调整”。变更说明让后来者理解职责为何这样划分，减少反复讨论。

把矩阵复核纳入项目集例行治理议程，作为固定议题而非临时事项。这样矩阵的更新有固定时点，不依赖个人记忆。

一个简化示例：阶段关口决策的职责落位

以下示例为演示情景，用于说明一行矩阵如何写完整，实际角色与时限需按组织任命调整。

事项：项目集某阶段关口是否放行。触发条件：阶段交付物提交完毕且自评达标。决策时限：材料齐备后五个工作日内给出结论。

角色	职责类型	具体动作与权限边界
项目负责人	执行	提交本阶段交付证据与自评结论
项目集经理	提议	汇总材料、给出放行建议并提交治理委员会
治理委员会	决策	决定放行或限期整改，决定唯一且需记录理由
项目集发起人	知会	接收决策结果；出现重大偏差时具有要求复议的权限

这一行的写法可以迁移到其他事项：先写触发条件和时限，再按“执行—提议—决策—知会”的顺序落位角色，最后为决策角色补上权限边界。预算调整事项把决策角色换成按金额阈值区分的审批人或治理委员会，重大风险升级事项把执行角色换成风险责任人和处置团队，规律一致。

发布前的完成检查

矩阵达到可发布状态前，逐项核对以下检查项，并记录核对结论：

• 事项清单是否覆盖项目集运行中的主要决策点，阶段关口、预算调整、范围变更、风险升级、资源冲突、收益调整是否都有对应条目；清单边界是否写明不包含PMO制度与项目组合决策。
• 每个事项是否有唯一的最终决策人；职责类型是否都有明确定义；决策类职责是否写明金额阈值、影响程度与否决权。
• 角色映射是否与实际组织任命一致；发起人兼任治理委员会成员等重叠情形，表决与回避规则是否写明。
• 是否完成关键角色评审，评审意见与修订结果是否留有记录，发布版本是否标注生效日期。
• 维护责任人、复核周期和更新触发条件是否已确定，版本记录机制是否建立。

以上各项均有明确结论，矩阵即可发布并进入运行；存在未决项的，先解决再发布，避免带着模糊授权进入实际治理场景。

常见问题

项目集治理职责矩阵和RACI表是什么关系，可以直接套用RACI吗？

RACI用负责、批准、咨询、知情四类角色描述职责，可以作为职责类型设计的起点。项目集治理职责矩阵在此之上还需要补充两点：一是决策类职责的权限边界，例如金额阈值、影响程度与否决权；二是事项的触发条件和决策时限。只套用RACI字母，容易出现“谁批准”写清了但“多大金额内可以批”“多久必须批完”没写清的情况。实际做法是保留RACI的简洁性，再为关键事项增加权限与时限两列。

发起人同时是治理委员会成员时，矩阵里怎么处理？

在矩阵附注中写明表决与回避规则即可，不必为此拆出额外角色。常见处理是：涉及发起人本人提出或与其直接利益相关的议题，发起人回避表决，由治理委员会其他成员决策或提交上级裁定；日常事项仍按正常程序参与。项目集经理兼任某项目负责人时同理，需约定该项目的事项是否由上级复核。规则写清楚，矩阵在实际运行中才不会因角色重叠而卡住。

矩阵发布后，项目集进入下一阶段，需要整表重做吗？

通常不需要整表重做。阶段转换触发的是复核而非重建：检查本阶段新增了哪些决策事项、原有事项的决策人是否变化、权限边界是否仍适用，只修订受影响的行和格。整表重做成本高，也容易让已形成的职责共识被打断。建议把阶段转换列为固定复核触发条件，由项目集经理提出修订、治理委员会审定，并在版本记录中写明本次调整的原因。

矩阵里的决策时限设多长比较合适？

时限取决于事项的影响范围和所需材料，没有统一标准。阶段关口放行通常按材料齐备后的工作日计算，预算调整和重大风险升级可按紧急程度分档设置。设置时把握两点：时限从触发条件满足、材料齐备之日起算，避免因材料不全无限期挂起；超时未决策时要有升级路径，例如自动提交上一级治理角色。时限写进事项清单，与矩阵同步发布。

矩阵正式版本和修订记录放在哪里，才能让相关角色看到同一份最新版本？

关键是让矩阵有唯一存放位置，并与项目集的实际协作场景关联。可以使用支持多人协同编辑、页面模板和细颗粒度权限管控的知识库承载正式版本与修订记录，例如ONES Wiki支持多人实时协同编辑、页面共享与页面模板，并以页面树组织页面，从所有页面到单个页面提供不同颗粒度的权限管控；同时可将业务信息、项目数据与文档关联，便于角色查看同一份最新内容。矩阵涉及的事项与进度跟踪，可在ONES Plan的多项目总览、里程碑与甘特图视图中同步呈现。具体配置方式与版本差异建议向厂商核验。