如何建立项目集治理职责矩阵：五步方法与角色分工

建立项目集治理职责矩阵，核心是把“谁在什么事项上说了算”写成可查、可执行的一张表。做法是先梳理项目集运行中真正需要决策和批准的事项，再确定发起人、治理委员会、项目集经理、项目负责人等角色的参与方式，用统一的职责类型标注权限，经评审发布后纳入变更与年度复核。本文按五步展开，并给出职责类型定义表、一行完整示例和发布前检查清单。

要点总览（TL;DR）

• 先梳理项目集运行中需要治理层决策的事项，再确定发起人、治理委员会、项目集经理、项目负责人四类核心角色，形成事项清单与角色清单两张底表。
• 用决策、审批、会签、知会、执行、支持六类职责类型统一权限口径，每类配一句可操作定义，并区分最终决策权与建议权、执行责任。
• 填写矩阵以事项为行、角色为列，先定唯一决策人，再补审批、会签、知会与执行，同步处理多决策人、无人决策、执行缺位三类冲突。
• 矩阵经评审后纳入项目集治理章程发布，明确变更发起人与批准人，复核节奏与阶段评审同步，并引用到治理会议议程和决策记录模板。
• 发布前用检查清单核对：关键事项有唯一决策人、职责与岗位授权一致、决策时点明确、已纳入会议与记录流程、复核责任到人。

先定矩阵的骨架：治理事项与角色清单

矩阵的起点是两张底表：治理事项清单和角色清单。事项清单回答“哪些事需要治理层介入”，角色清单回答“谁有资格介入”。两张表没有对齐之前，直接画表格容易把日常任务混进治理范围，导致矩阵臃肿、评审时争议不断。

梳理事项时按项目集生命周期走一遍，通常能覆盖以下类别：

• 立项与范围变更：子项目纳入或退出项目集、项目集整体范围调整、重大需求变更的批准。
• 阶段关口与收益评审：子项目阶段关口放行、项目集阶段评审、收益实现情况的定期评估。
• 资源与预算调整：关键岗位人员调配、预算追加或削减、跨项目资源冲突的裁决。
• 重大风险与问题升级：超出项目负责人权限的风险接受、跨项目集影响的重大问题处置。
• 供应商与合同关键节点：重大采购决策、合同关键条款变更、供应商准入与退出。
• 项目集收尾：项目集整体关闭、成果移交、遗留问题处理方案的确认。

事项颗粒度以“可决策、可追责”为准。判断标准是：这件事是否需要某个人或某个集体拍板，拍板结果是否影响项目集的范围、进度、成本或收益。如果一件事只需要执行、不需要裁决，它属于项目负责人的日常管理，不应进入治理矩阵。颗粒度过细会让矩阵变成任务清单，治理委员会被拖入操作层；颗粒度过粗则会出现“项目集重大事项”这类无法追责的条目。

角色清单以四类核心角色为基本盘：发起人负责为项目集提供高层支持和资源保障；治理委员会承担集体决策职责；项目集经理负责整体协调、信息汇总和执行推动；项目负责人对子项目交付结果负责。在此基础上，按事项需要补充财务、架构、采购、法务等职能代表，补充原则是“该事项的决策需要其专业判断或授权”。

本步的输出是治理事项清单与角色清单两张底表，完成标志是：每个事项都能用一句话说清“要决定什么”，每个角色都能对应到具体岗位或岗位组合。

定义职责类型与决策权限口径

矩阵中常见的失败是同一个词在不同行含义不同：有的行“负责”指拍板，有的行“负责”指干活。解决办法是在填表之前先定义职责类型，并为每一类写一句可操作的定义，放在矩阵说明页。

职责类型	判定标准	可操作定义
决策	对事项结果有最终拍板权，其他人意见仅供参考	对该事项作出最终结论，结论生效后其他人执行
审批	在决策前进行把关，有权否决或要求补充	对提交的方案进行审核，同意后方可进入下一环节
会签	与其他人共同签署才生效，缺一不可	与其他会签人共同确认，任一方不同意则事项不通过
知会	不参与决策，但需在结论形成后获知	在决策完成后接收结论信息，无需回复意见
执行	按决策结果落实具体工作并对交付负责	承接决策结论，组织资源完成交付并反馈进展
支持	提供专业输入或资源配合，不承担决策责任	按要求提供分析、数据或人员支持，供决策参考

定义职责类型时，要特别区分最终决策权与建议权。建议权可以多人持有，最终决策权应尽量收敛到一个人或一个集体。单一决策人原则的作用是让每个事项都有明确的拍板者，避免出现“大家都同意才通过、有人反对就搁置”的僵局。例外情形需要写清楚，例如重大预算调整、项目集整体终止这类事项，可以由治理委员会集体决策或采用会签方式，但要在矩阵中注明触发条件，不能默认所有事项都走会签。

执行责任与决策权也要分开标注。一个事项可以由项目集经理决策、项目负责人执行，也可以由治理委员会决策、项目集经理执行。把决策和执行混在同一格，事后追责时容易出现“决策的人说执行不到位、执行的人说决策不清楚”的扯皮。

本步输出是职责类型定义表与权限口径说明，完成标志是：任取矩阵中的一格，参与方都能按定义说出这一格意味着什么、需要做什么动作。

把角色映射到事项：填写矩阵并处理冲突

填写矩阵时以事项为行、角色为列，按固定顺序推进：先为每个事项确定唯一决策人，再补审批和会签角色，然后标注知会对象，最后落实执行与支持角色。这个顺序能防止先填执行、后补决策造成的责任倒挂。

填写过程中通常会出现三类冲突，处理方式如下：

• 同一事项多个决策人：回到事项定义，确认这件事是否需要集体决策。若不需要，保留与事项授权最匹配的一个角色作为决策人，其余改为审批或会签；若确需集体决策，明确是治理委员会集体表决还是会签，并写清表决规则。
• 关键事项无人决策：常见于跨项目集的资源冲突或收益归属争议。这类事项要么上升为治理委员会议题，要么指定发起人裁决，不能留空。
• 执行角色缺位：有决策、有审批，但没有人承接落地。需要补充执行角色并确认其资源与权限，否则矩阵只是纸面分工。

每个事项还应补充决策时点或触发条件，例如“阶段关口评审在子项目提交关口材料后五个工作日内召开”“预算调整超过原预算一定比例时触发治理委员会审批”。决策时点写清楚，矩阵才能与治理会议议程对接。

本步输出是矩阵初稿与待裁决问题清单。初稿允许存在争议格，但每个争议格都要进入清单，标明争议点和建议处理方式，供评审会集中裁决。

评审发布与运行维护机制

矩阵初稿需要经过评审才能生效。评审参与方应覆盖矩阵中出现的所有角色，重点是发起人、治理委员会成员和项目集经理。评审要点有三项：权限是否与岗位授权匹配，即矩阵赋予的决策权是否在該角色的实际授权范围内；是否与现有制度冲突，包括财务审批制度、采购制度和人事授权；职责类型的使用是否一致，同一类事项在不同行是否采用了相同的标注逻辑。

评审通过后，矩阵以正式文件形式发布，纳入项目集治理章程或项目管理文件，明确生效范围和适用对象。发布不是终点，矩阵需要在三种情况下修订：组织调整导致角色或授权变化、项目集范围发生重大变化、治理运行中发现职责冲突。变更机制要指定修订发起人和批准人，避免人人可改、版本混乱。

复核节奏建议与项目集阶段评审同步，至少每年复核一次；出现重大组织调整或项目集重组时即时触发复核。复核内容包括事项清单是否仍覆盖当前治理需求、角色是否仍在岗、职责标注是否与实际运行一致。

落地方式决定矩阵能否真正用起来。把矩阵引用到治理会议议程中，每个议题标注对应的事项行和决策人；在决策记录模板中增加“依据矩阵第几行、决策人是谁”的字段。这样每次治理会议都在强化矩阵的权威性，而不是会后再补记录。

矩阵的载体同样影响执行。治理事项、决策记录和矩阵文档需要有稳定的存放位置和权限控制。ONES Plan 支持借助项目集管理总览多项目信息，并提供多项目进度管控和资源管理，可为治理会议提供进度与资源方面的决策输入；ONES Wiki 支持多人实时协同编辑、页面共享和页面模板，并以页面树组织页面，适合承载矩阵文档、职责类型定义和决策记录模板，其多维度权限管控可用于区分治理委员会成员与项目组成员的查看和编辑范围。工具承载的是记录与协同动作，矩阵的权限口径仍需由组织授权决定。

示例：一个阶段关口评审的职责行

以下以“项目集某子项目阶段关口评审”为例，演示矩阵中一行事项的完整填写。该示例为演示情景，实际授权需按组织制度调整。

事项	发起人	治理委员会	项目集经理	项目负责人	财务代表	决策时点
子项目阶段关口评审	知会	决策	执行	支持	会签（涉及预算释放时）	子项目提交关口材料后五个工作日内

逐角色说明理由：治理委员会对该关口是否放行作出最终结论，因为关口放行影响项目集整体进度和资源投入；项目集经理负责组织评审、汇总材料并推动结论落地，承担执行责任；项目负责人提供交付物和自评材料，属于支持角色，不参与放行决策；发起人接收结论信息即可，除非关口涉及项目集层面的重大调整；财务代表在关口涉及预算释放或追加时参与会签，其余情况不介入。

该行的输入材料包括阶段交付物清单、质量检查结果、风险与问题状态、预算使用情况；输出结论为“放行”“有条件放行”或“不放行”，并记录条件和后续动作。评审中可能被质疑的点是：治理委员会集体决策是否会导致放行拖延。处理方式是在矩阵说明页写明表决规则和默认时限，例如规定时限内未提出反对视为放行，或由治理委员会主任在紧急情况下代为决策并事后报备。

完成检查：矩阵是否可用

发布前用以下清单逐项核对，全部通过再进入正式运行：

• 关键决策事项是否都有唯一决策人，集体决策事项是否写明了表决规则。
• 每个角色的职责是否与其岗位授权一致，是否存在矩阵赋权超出实际授权的情况。
• 职责类型定义是否被参与方理解一致，抽查几行能否按定义说清动作。
• 每个事项是否标注了决策时点或触发条件，能否与治理会议议程对应。
• 矩阵是否已纳入治理会议议程和决策记录模板，决策记录能否回溯到矩阵行。
• 是否明确了复核周期、复核触发条件和变更责任人。
• 待裁决问题清单是否已全部关闭或有明确的处理计划。

这份清单同时可以作为矩阵运行一段时间后的自检工具。若发现某类事项反复出现决策拖延或责任争议，通常说明该行的事项定义或职责标注需要修订，应回到矩阵中调整，而不是在会议中临时指定负责人。

常见问题

矩阵里的事项应该拆到多细，才不会变成任务清单？

判断标准是这件事是否需要某个人或某个集体拍板，拍板结果是否影响项目集的范围、进度、成本或收益。只需要执行、不需要裁决的工作，属于项目负责人的日常管理，不进入治理矩阵。实际操作中，可以先按立项与范围变更、阶段关口与收益评审、资源与预算调整、重大风险升级、供应商与合同关键节点、项目集收尾六类归并，再逐类拆到“一句话能说清要决定什么”的程度。若某行在评审时无法说清决策内容，说明颗粒度还需调整。

发起人和治理委员会的决策权如何划分，避免同一事项两个人都能拍板？

划分依据是事项的影响范围和授权层级。影响单个子项目、在项目集经理授权内的事项，由项目集经理决策；影响项目集整体范围、预算或收益的事项，由治理委员会集体决策；涉及组织战略方向、跨项目集资源或超出治理委员会授权的事项，由发起人裁决。矩阵中每个事项只保留一个决策角色，其余角色改为审批、会签或知会。确需集体决策的，在矩阵说明页写明表决规则和默认时限，避免出现两个决策人互相等待。

组织调整或项目集范围变化后，矩阵应该多久修订一次？

修订由触发条件驱动，不必等到固定周期。常见触发条件包括：角色或岗位授权变化、项目集范围重大调整、治理运行中反复出现职责争议、复核发现事项清单不再覆盖当前治理需求。日常复核建议与项目集阶段评审同步，至少每年一次。变更机制中要指定修订发起人和批准人，修订后更新版本号并通知矩阵中出现的所有角色，避免出现多份并行版本。

矩阵发布后如何在治理会议上真正用起来，而不是挂在文档里？

关键是把矩阵嵌入会议和记录动作。治理会议议程中，每个议题标注对应的事项行和决策人；决策记录模板中增加“依据矩阵哪一行、决策人是谁、结论是什么”的字段。会议主持人在议题开始时确认决策人是否到场，结论形成后由记录人回填矩阵行号。运行一段时间后，若某类事项反复出现决策拖延，回到矩阵修订该行的事项定义或职责标注，而不是在会议中临时指定负责人。矩阵文档与决策记录需要有稳定的存放位置和权限控制，ONES Wiki 支持多人实时协同编辑、页面共享和页面模板，并以页面树组织页面，可用于承载矩阵文档与决策记录模板，其多维度权限管控可区分治理委员会成员与项目组成员的查看和编辑范围。

矩阵中财务、采购、法务等职能代表应该标什么职责类型？

按该职能在事项中的实际作用标注，常见有三种：需要其专业判断才能形成结论的，标为审批或会签；仅需提供数据和分析供决策参考的，标为支持；结论形成后需其知晓并配合执行的，标为知会。标注前要核对该职能在组织制度中的实际授权，例如财务审批制度规定的审批额度与环节。矩阵赋予的职责不能超出岗位授权，否则评审阶段就会被退回。职能代表的参与方式还需与现有制度衔接，矩阵只做归集和显性化，不替代原有审批制度。