建立项目集治理职责矩阵，核心是把项目集运行中需要拍板的事项逐条列出，为每项指定唯一的决策主责，再用统一的职责类型标明其他角色的参与方式。本文按“定骨架—填内容—评审发布—明确角色交付—示例参照—发布前检查”的顺序展开，适合首次建立或正在重构矩阵的项目集经理与PMO人员使用。
要点总览（TL;DR）
- 矩阵由治理事项、治理角色、职责类型三类要素构成，交叉格只填一种主责类型，同一事项只设一个决策角色。
- 建立顺序为五步：从章程与授权文件中提取治理事项、逐事项映射角色、标注决策权限阈值、治理委员会评审发布、指定责任人持续维护。
- 发起人掌握关键授权与超限决策，治理委员会集体决策并裁决争议，项目集经理起草与维护，项目负责人确认本层边界并履行输入义务。
- 发布前逐项核对决策主责唯一性、权限与授权一致、知会范围合理、与章程无冲突、维护规则已明确。
- 矩阵发布后的事项流转与版本记录需要载体，可在协作工具中按事项类别汇总状态、控制文档权限并留存版本。
先定矩阵骨架：治理事项、角色与职责类型
职责矩阵由三类要素构成：纵向是治理事项，横向是治理角色，交叉格填写职责类型。骨架定得清楚，后续填写才不会出现同一格塞进多个动作、同一事项多人拍板的情况。
治理事项的分类
把项目集运行中需要治理介入的事项按类别归并，便于查漏。常见类别包括：
- 决策类：项目集立项确认、阶段关口放行、项目集终止或重大方向调整。
- 监控类：整体进度与收益状态评审、里程碑达成确认、治理例会结论确认。
- 变更类：范围变更、预算追加或调减、关键里程碑日期调整。
- 资源类：关键人员调配、跨项目资源冲突裁决、外部供应商引入。
- 风险类：重大风险升级、风险应对方案批准、问题升级裁决。
- 收尾类：项目集收尾验收、经验总结确认、资源释放确认。
四类核心角色
矩阵至少覆盖四类角色：发起人（对项目集整体成败负责、掌握关键授权）、治理委员会（集体决策与争议裁决机构）、项目集经理（日常运行的组织者与执行者）、项目负责人（单个项目的责任人与输入提供方）。组织若设有PMO或治理支持角色，可作为第五列加入，承担模板与记录工作。
职责类型的填写口径
每个交叉格只填一种主责类型，含义如下：
| 职责类型 | 含义 | 填写要点 |
|---|---|---|
| 决策 | 对该事项作出最终决定 | 同一事项只能有一个决策角色 |
| 审批 | 对已形成的方案或申请行使同意权 | 与决策区分：审批针对提交物，决策针对事项本身 |
| 会签 | 共同签署，缺少则流程不完整 | 仅用于确需多方共同担责的事项 |
| 知会 | 事后或事前获得信息，不参与决定 | 范围控制在确需知情者 |
| 执行 | 具体承办该事项 | 通常为项目集经理或项目负责人 |
| 支持 | 提供输入、分析或资源协助 | 写明提供什么输入，避免笼统 |
空白表头可设计为：治理事项｜事项类别｜决策权限说明｜发起人｜治理委员会｜项目集经理｜项目负责人｜（PMO）。权限说明列用于标注阈值和等级，与职责类型分开填写，避免格内信息过载。
第一步到第三步：识别事项、映射角色、定义权限
第一步：从现有文件中提取治理事项
输入是项目集章程、阶段关口定义、近期的变更记录与风险登记册。做法是逐份翻阅，把其中出现“需批准”“需上报”“由……决定”的条款摘出来，转写成动宾结构的事项名称，例如“批准预算追加超过10%的申请”。输出是一张事项清单，按前述六类归并，并标注来源文件，便于回溯。完成标志是清单覆盖了章程中全部授权条款，且没有两个事项描述同一决策。
第二步：逐事项映射角色
对每个事项依次回答三个问题：谁拍板（决策）、谁提供输入或方案（支持、执行）、谁必须知情（知会）。映射时以章程中的授权表述为准，章程未写明的，先按现有实际做法填写并标记待确认，提交治理委员会裁定。输出是矩阵初稿的主体内容。
第三步：标注决策权限层级
同一类事项往往因金额或影响程度不同而由不同层级决策。做法是在权限说明列写明阈值，例如预算追加：在项目集已批预算内由项目集经理审批，超出一定比例由治理委员会决策，超过项目集授权上限报发起人决策。范围变更按等级区分：影响单个项目交付内容的由项目负责人提出、项目集经理审批；影响项目集收益目标的提交治理委员会决策。阈值口径应与组织授权文件一致，不自行设定。
多角色重叠时的归并规则
填写中常见两种重叠：一是同一事项出现两个“决策”，二是多个角色都填“会签”。处理规则是：决策只保留授权文件中明确的最高责任角色，其余改为审批、会签或支持；会签仅保留在确需共同担责的事项上，能改为知会的降为知会。归并后逐条复核，确保每个事项有且仅有一个决策格。
第四步到第五步：评审发布与持续维护
第四步：治理委员会评审
评审会前将初稿与章程、授权文件一并发出。会上重点核对三件事：每个事项的决策主责是否唯一；标注的权限阈值是否落在该角色的实际授权范围内；知会范围是否与信息保密要求相容。争议事项当场裁决并记录理由，形成评审记录。评审通过后由治理委员会正式发布，明确生效日期与适用范围（覆盖哪些项目、哪一层级人员），并同步至项目集章程的关联文件清单。
第五步：建立维护规则
矩阵发布后需要指定维护责任人，通常为项目集经理，PMO可承担版本归档。触发更新的情形包括：组织调整导致角色更换、授权额度变化、项目集范围重大变更、治理委员会组成变化。每次更新保留版本号、修改内容、修改人和生效日期，旧版本归档不删除，便于追溯历史决策依据。建议在每次阶段关口评审时顺带核对矩阵是否仍然有效，把维护动作挂到已有的治理节奏上，而不是另设一套检查。
矩阵发布后的事项流转需要载体：变更申请、风险升级、关口放行等事项按矩阵规定的角色提交与审批，知会对象同步收到信息，版本更新留痕。ONES Project 的项目集管理提供多项目进度管控和资源管理，并支持自定义项目属性、查看多项目数据集合，便于按矩阵中的事项类别汇总状态；ONES Wiki 以页面树组织文档，适合存放矩阵正文与各版本记录，其页面级权限管控可用于控制知会范围。具体审批流与通知配置需结合实际版本确认。
角色分工与各角色的交付物
矩阵的建立与运行涉及五类角色，各自的动作与交付物如下：
| 角色 | 在建立与运行中的职责 | 交付物 |
|---|---|---|
| 发起人 | 批准治理框架与关键授权，对超出治理委员会权限的事项作最终决策 | 治理框架批准意见、授权额度确认 |
| 治理委员会 | 评审并发布矩阵，裁决角色重叠与权限争议，定期确认矩阵有效性 | 评审记录、发布决议、争议裁决结论 |
| 项目集经理 | 起草矩阵，组织评审，按规则维护版本，按矩阵推动事项流转 | 矩阵初稿、评审材料、版本更新记录 |
| 项目负责人 | 确认本层职责边界，按矩阵提交变更、风险与资源申请，履行输入义务 | 职责边界确认、事项申请与输入材料 |
| PMO或治理支持角色（如设有） | 提供模板，汇总评审与变更记录，归档各版本 | 矩阵模板、记录台账、版本档案 |
分工的关键是起草与批准分离：项目集经理负责把内容填完整，治理委员会负责确认权限是否成立。项目负责人的确认环节不能省略，否则矩阵中涉及单项目的职责边界在执行时容易产生分歧。
示例：一个项目集治理职责矩阵片段
以下为演示情景，不对应任何真实组织。假设某项目集章程规定：预算追加在已批预算10%以内由项目集经理审批，10%至20%由治理委员会决策，超过20%报发起人决策；阶段关口放行由治理委员会决策；重大风险（影响项目集收益目标）升级由治理委员会决策，一般风险由项目集经理处理。
| 治理事项 | 权限说明 | 发起人 | 治理委员会 | 项目集经理 | 项目负责人 |
|---|---|---|---|---|---|
| 预算追加 | ≤10%项目集经理审批；10%–20%治理委员会决策；>20%发起人决策 | 决策（>20%） | 决策（10%–20%） | 审批（≤10%）、执行 | 支持（提交申请与测算） |
| 阶段关口放行 | 按关口定义逐项核对交付物后放行 | 知会 | 决策 | 执行（组织评审、提交材料） | 支持（提交阶段成果） |
| 重大风险升级 | 影响项目集收益目标的风险 | 知会 | 决策 | 执行（升级上报、落实应对） | 支持（识别与上报风险） |
填写时容易出错的地方有三处：一是把预算追加的决策格同时填给治理委员会和发起人，正确做法是按阈值拆分，同一金额区间只对应一个决策角色；二是把项目负责人填成关口放行的“会签”，实际其职责是提交成果并接受评审，应填支持；三是知会列填得过宽，把全体项目成员都列入，导致知会失去筛选意义。阈值必须写在权限说明列，不能只写在格内，否则调整阈值时要改动多处。
完成检查：矩阵可用的判断标准
发布前逐项核对以下清单，全部通过再提交治理委员会发布：
- 每个治理事项有且仅有一个决策主责，逐行检查决策格数量。
- 职责类型与角色授权一致：审批、决策权限均能在章程或授权文件中找到对应表述。
- 权限阈值已显式标注，且与组织现行授权额度一致。
- 知会范围经过筛选，每个知会对象都能说明知情理由。
- 矩阵内容与项目集章程、授权文件无冲突，冲突处已修订或注明以何者为准。
- 事项清单覆盖章程中的全部授权条款，无遗漏类别。
- 维护责任人、更新触发情形、版本记录方式已写入矩阵附注。
- 项目负责人已确认涉及本项目的职责边界。
清单通过后，矩阵即可作为项目集运行期间的决策依据使用；后续每次组织或授权变化时，按维护规则更新并重新发布版本。
常见问题
矩阵初稿中同一事项出现两个决策角色，应该怎么处理？
先回到授权文件确认该事项的最终责任归属，只保留授权中明确的最高责任角色作为决策，其余角色改为审批、会签或支持。若授权文件本身表述模糊，把该事项标记为待确认，提交治理委员会裁定并记录理由，不要在两个角色之间折中填写。
项目集章程没有写明的治理事项，是否要纳入矩阵？
建议纳入，但标注来源为“实际做法待确认”。做法是先按当前运行中的实际决策方式填写，再在评审会上由治理委员会确认或修正，确认后同步补充到章程的授权条款中。这样矩阵与章程逐步对齐，避免出现矩阵有规定、章程无依据的空白地带。
预算、范围这类带阈值的事项，阈值应该写在哪里？
写在矩阵的权限说明列，与职责类型分开。格内只填职责类型和适用的金额或等级区间，例如“决策（10%–20%）”。阈值集中在一列便于统一调整，也避免同一阈值散落在多个格子里导致更新时遗漏。
矩阵发布后，什么情况下必须重新评审而不是直接改版本？
角色更换、授权额度调整、项目集范围重大变更、治理委员会组成变化，这四类情形会改变决策主责或权限边界，应重新提交治理委员会评审后发布新版本。仅涉及表述修订、错别字或不改变职责归属的调整，可由维护责任人直接更新并记录版本。
矩阵发布后，事项流转和版本记录放在哪里比较合适？
矩阵正文与各版本记录适合放在支持页面树组织和页面级权限管控的知识库中，便于按角色控制知会范围；变更申请、风险升级、关口放行等事项则在项目管理工具中按矩阵规定的角色提交与审批。ONES Project 的项目集管理提供多项目进度管控和资源管理，支持自定义项目属性并查看多项目数据集合，可用于按事项类别汇总状态；ONES Wiki 以页面树组织文档，提供多颗粒度权限管控，适合存放矩阵与版本记录。具体审批流与通知配置需结合实际版本确认。
