项目集治理职责矩阵是一张把项目集治理中的关键决策与监督事项，按“治理事项—决策/建议/知会角色—时点与触发条件—输出物”逐行对应起来的职责分工表。它回答的是“哪类事项由谁定、谁参与、何时定、定完留下什么”。本文说明它的定义与边界、五类核心要素、运转流程，并厘清它与治理委员会、项目集经理职责清单的层次关系。
要点总览（TL;DR）
- 项目集治理职责矩阵是一张把治理事项与决策、建议、知会、执行角色逐行对应的分工表，回答“哪类事项由谁定、何时定、定完留下什么”。
- 核心要素有五类：治理事项清单、角色与权限类型、决策时点与触发条件、输出物与记录、升级与例外路径。
- 矩阵在运行中按“事项触发—会前输入—决策记录—下发跟踪复核”闭环使用，触发方式分固定节点与事件两类。
- 治理委员会是组织与会议载体，矩阵是其议事规则的一部分，项目集经理职责清单是岗位职责；三者关系为委员会定规则、矩阵定分工、经理清单定执行。
- 矩阵需要定期复核，避免照搬RACI、当成签到表或一次性制度文件。
项目集治理职责矩阵的定义与适用边界
项目集治理职责矩阵的核心，是把治理层面需要拍板或监督的事项逐条列出，并为每条事项指定参与角色、权限类型、发生时点和产出记录。它约束的对象是治理决策与监督动作，例如阶段关口是否放行、重大变更是否批准、跨项目资源冲突如何裁决、高风险如何升级。日常执行任务的分派、个人工作安排、团队内部的任务拆解，属于项目集经理和团队负责人的管理范围，不进入这张矩阵。
理解这个定义，要抓住三个限定。第一，矩阵以“事项”为行，不以“人”为行；它先问有哪些治理事项，再问每件事由谁以什么身份参与。第二，矩阵规定的是权限类型，即某角色对某事项是决策、建议、知会还是执行，而不规定具体某个人每天做什么。第三，矩阵服务于项目集层面的治理节奏，与单个项目的执行计划、任务看板属于不同层次。
本文的讨论范围限于项目集治理职责矩阵本身的概念、构成与使用方式。组织层面的PMO制度建设、研发治理机制设计，以及独立项目的选择与项目组合层面的投资决策，属于相邻但不同的主题，本文不展开。这样界定，是为了让矩阵的边界清晰：它是一份治理议事分工表，向上承接治理委员会的议事规则，向下衔接项目集经理的岗位职责。
矩阵包含哪些核心要素
一张可用的项目集治理职责矩阵，通常由五类要素构成。它们共同保证矩阵既能覆盖治理事项，又能在实际运行中被执行和追溯。
| 核心要素 | 作用 | 填写要点 |
|---|---|---|
| 治理事项清单 | 界定矩阵覆盖哪些决策与监督事项 | 按事项类型分组，如关口评审、变更审批、风险升级、资源裁决、收益复核 |
| 角色与权限类型 | 明确每个事项上各角色的参与方式 | 区分决策、建议、知会、执行四类权限，避免所有角色都写成“参与” |
| 决策时点与触发条件 | 规定事项何时进入治理议程 | 写明固定节点（如阶段末）与事件触发（如变更超阈值、风险等级上升） |
| 输出物与记录 | 保证决策可追溯、可复核 | 明确决议、评审意见、变更单、风险处置记录等产出形式 |
| 升级与例外路径 | 处理权限不足、意见分歧和紧急情况 | 写明升级到哪一层、例外由谁批准、事后如何补记 |
治理事项清单是矩阵的骨架。事项划分过粗，矩阵无法指导具体决策；划分过细，又会退化成任务清单。实践中可按决策影响面归类：影响项目集范围、预算、关键里程碑、跨项目资源的事项优先纳入。角色与权限类型是矩阵的核心信息，决策角色对结果负责，建议角色提供专业输入，知会角色接收结果，执行角色落实决议。四类权限分开写，能避免“集体负责等于无人负责”的常见问题。
决策时点与触发条件决定矩阵能否被及时使用。固定节点适合纳入年度或阶段性的治理日历，事件触发则要求矩阵写明阈值和判断人。输出物与记录让每次治理动作留下痕迹，便于后续复核和交接。升级与例外路径是矩阵的兜底设计，它承认治理中会出现权限不够、意见不一致或时间紧迫的情形，并提前约定处理方式。
矩阵如何运转：从事项触发到决策留痕
矩阵的价值在运行中体现。一条典型的使用流程，可以拆成四个环节。
第一步是事项触发。事项可能来自固定治理节点，例如阶段关口到期；也可能来自事件，例如变更申请超出预设阈值、风险等级上升、跨项目资源出现冲突。触发后，由约定角色判断该事项是否进入治理议程，并按矩阵找到对应行。
第二步是会前材料与建议角色输入。进入议程的事项，由执行角色准备背景材料，建议角色在会前给出专业意见。矩阵在这里的作用是明确谁必须提供输入、谁可以只接收信息，避免会前准备遗漏关键角色，也避免无关角色被拉入所有讨论。
第三步是决策形成与记录。决策角色在约定会议上或授权范围内作出决定，记录人按矩阵要求的输出物形式留下决议，包括决定内容、依据、生效条件和责任人。记录不是形式动作，它决定了后续跟踪和复核是否有据可查。
第四步是决议下发、跟踪与复核。决议下发到执行角色后，按约定节奏跟踪落实情况；到期或达到复核条件时，由治理角色复核结果是否达到预期。若执行中发现新情况超出原决议范围，则回到矩阵的升级与例外路径，重新触发相应事项。
这四个环节形成闭环：触发—输入—决策—跟踪。矩阵在每一环都提供“找谁、按什么权限、留下什么”的答案。矩阵落地时需要有承载治理事项流转、评审记录与决议跟踪的载体。ONES Plan 支持借助项目集管理总览多项目信息，查看多项目数据集合、多维度掌控项目进度，并提供多种资源报表实时反馈项目投入情况，这些视图可作为治理例会的进度与资源输入；决议和跟踪记录的具体承载方式，则需结合团队现有的文档与工作项管理方式确定。
与治理委员会、项目集经理职责清单的区别与衔接
项目集治理职责矩阵常与两个相邻概念混用：项目集治理委员会和项目集经理职责清单。三者处于同一治理体系的不同层次，职责不同，不能互相替代。
| 概念 | 回答的问题 | 主要形态 | 在体系中的位置 |
|---|---|---|---|
| 项目集治理委员会 | 谁来治理、以什么会议和机制治理 | 组织与会议载体，含成员构成、议事规则、会议节奏 | 治理的组织层 |
| 项目集治理职责矩阵 | 哪类事项由谁定、何时定、留下什么 | 事项与角色的对应表 | 治理的规则层，是委员会议事规则的组成部分 |
| 项目集经理职责清单 | 项目集经理这个岗位负责什么 | 岗位职责说明 | 治理的执行层 |
治理委员会是组织与会议载体，矩阵是它议事规则的一部分。委员会确定治理的层级、成员和会议节奏，矩阵则把这些规则落到具体事项上：哪些事项上委员会、哪些授权给项目集经理、哪些只需知会。没有矩阵，委员会的议事容易停留在原则层面；只有矩阵而没有委员会，决策缺少合法的组织载体。
项目集经理职责清单描述岗位的全面职责，矩阵则规定项目集经理在各类治理事项中的权限类型。同一位项目集经理，在预算调整事项上可能是建议角色，在跨项目资源调配事项上可能是决策角色，在重大风险事项上可能是执行角色并需向上升级。职责清单回答“这个岗位管什么”，矩阵回答“在这件事上他是什么身份”。
三者的衔接可以概括为：委员会定规则，矩阵定分工，经理清单定执行。实际使用时，先由委员会确认治理层级和议事规则，再用矩阵把规则细化到事项与角色，最后由项目集经理职责清单承接矩阵中分配给该岗位的执行与建议动作。三者对齐，治理决策才能既有人负责，又有据可依。
一个具体例子与常见误解
下面是一段示意矩阵，仅用于说明填写方式，不代表任何真实企业的治理安排。
| 治理事项 | 决策 | 建议 | 知会 | 时点/触发 | 输出物 |
|---|---|---|---|---|---|
| 阶段关口评审 | 治理委员会 | 项目集经理、技术负责人 | 相关项目经理 | 阶段末固定节点 | 关口评审决议、放行条件 |
| 重大变更审批 | 治理委员会（超阈值）／项目集经理（阈值内） | 项目集经理、财务代表 | 受影响项目经理 | 变更申请提交时 | 变更决议、影响评估记录 |
| 高风险升级 | 治理委员会指定的风险责任人 | 项目集经理 | 委员会成员 | 风险等级达到预设阈值 | 风险处置决议、跟踪记录 |
从这段片段可以看到，同一类角色在不同事项上的权限类型并不相同，这正是矩阵区别于岗位职责清单的地方。阶段关口评审由委员会决策，重大变更按阈值分层决策，高风险升级则指定专门责任人，三者都写明了触发条件和输出物。
常见误解有三个。其一，把矩阵当成RACI的全量复制。RACI适合描述具体任务或交付物的责任分配，项目集治理矩阵聚焦治理决策与监督事项，范围更窄、权限语义更明确，直接照搬RACI容易把执行任务混入治理议程。其二，把矩阵当成会议签到表。签到表记录谁到场，矩阵记录谁对什么事项拥有什么权限，二者不能互相替代。其三，把矩阵当成一次性的制度文件。治理事项、角色和阈值会随项目集阶段和组织调整而变化，矩阵需要定期复核，并在出现例外时通过升级路径反馈修订。
矩阵的维护责任通常落在治理委员会或由其指定的治理支持角色，复核节奏可与阶段关口或年度治理评估对齐。把矩阵与治理委员会的议事规则、项目集经理职责清单放在同一套文档体系中管理，能减少版本不一致带来的执行偏差。
常见问题
项目集治理职责矩阵和RACI矩阵可以互相替代吗？
两者适用范围不同，通常不能互相替代。RACI适合描述具体任务或交付物上的责任分配，颗粒度细、覆盖面广；项目集治理职责矩阵聚焦治理层面的决策与监督事项，范围更窄，权限语义也更明确，区分决策、建议、知会和执行四类角色。
如果直接把RACI全量复制成治理矩阵，容易把日常执行任务混入治理议程，导致委员会被大量事务性事项占满。可行的做法是先梳理治理事项清单，再针对每类事项单独填写权限角色，必要时在具体交付物层面另用RACI管理。
治理事项的触发条件应该由谁设定，阈值调整走什么流程？
触发条件通常由治理委员会在议事规则中确定，例如变更金额或范围超过某一阈值、风险等级达到某一级别、阶段关口到期等。矩阵负责把这些条件写到对应事项行上，并注明判断人。
阈值需要随项目集阶段和组织授权变化调整。调整时一般由治理支持角色提出，经委员会确认后更新矩阵版本，并同步知会受影响的角色。若执行中出现矩阵未覆盖的紧急情况，按升级与例外路径先行处理，事后补记并反馈修订，避免矩阵与实际运行脱节。
项目集经理在矩阵中同时是建议角色和执行角色，会不会造成职责冲突？
这种安排在实践中很常见，本身不构成冲突，关键在于权限类型按事项分别界定。项目集经理在预算调整等事项上提供专业输入，属于建议角色；在跨项目资源调配等授权范围内的事项上可以决策；在重大风险事项上负责落实决议并向上报告。
需要避免的是同一事项上既当决策者又当执行者而缺少监督。矩阵填写时应确保每类治理事项都有独立的决策角色，项目集经理的执行动作接受委员会复核，这样建议、决策与执行之间形成制衡。
矩阵落地时，治理事项的流转和决议记录用什么承载比较合适？
承载方式取决于团队现有的工具与文档体系，常见做法是把治理事项作为独立工作项管理，评审材料、决议和跟踪记录关联在同一事项下，便于按事项追溯。
ONES Plan 支持借助项目集管理总览多项目信息，查看多项目数据集合、多维度掌控项目进度，并提供多种资源报表实时反馈项目投入情况，这些视图可作为治理例会的进度与资源输入。决议和跟踪记录的具体承载方式，需结合团队现有的文档与工作项管理方式确定。
矩阵多久复核一次比较合理？
复核节奏可与项目集的治理节奏对齐，常见做法是跟随阶段关口评审做一次检查，或在年度治理评估时整体复核。触发式复核同样重要：当组织授权调整、治理委员会成员变化、出现多次例外审批或升级事件时，应提前复核相关事项行。
复核内容至少包括治理事项是否仍适用、角色权限是否与实际授权一致、阈值是否合理、输出物是否被实际使用。复核结果形成版本记录，并与治理委员会议事规则、项目集经理职责清单同步更新。
