项目集治理职责矩阵要解决的是“哪类决策由谁拍板、谁提供输入、谁需要知会”。编制时先把项目集运行中的真实决策场景列成事项清单，再固定发起人、治理委员会、项目集经理、项目负责人四类角色，用提议、评审、决策、知会、执行五种职责类型逐项填写，经评审发布后约定维护触发条件。矩阵落地后，可借助ONES Plan的项目集总览与多项目进度信息，为治理会议提供决策输入。
要点总览（TL;DR）
- 编制路径分四步：从项目集运行场景列出治理决策事项、固定四类治理角色、用职责类型逐项映射、评审发布并约定维护触发条件。
- 决策事项要写成可判断的问题，如“阶段关口是否放行”“预算追加是否批准”，来源覆盖阶段关口、资源与预算、范围与收益、风险与升级、变更与例外五类。
- 映射的核心规则是每个决策事项只设一个决策角色，其余角色按提议、评审、知会、执行填写；决策权限需补充决策依据、所需输入、时限与升级路径。
- 发起人批准矩阵发布并对超权限事项作最终决策，治理委员会评审事项完整性与权限合理性，项目集经理组织编制与维护，项目负责人提供输入并按矩阵提议或评审。
- 矩阵发布前逐项自查决策唯一性、输入材料与时限、升级路径和维护责任人，运行初期在每次治理会议后核对决策记录与矩阵是否一致。
先定矩阵骨架：决策事项清单与角色清单
矩阵的编制起点是两张初始表：治理决策事项清单和治理角色清单。事项清单决定矩阵覆盖哪些决策，角色清单决定每行由谁参与。两张表都完成后再进入映射，可以避免边填边改、遗漏关键决策。
从项目集运行场景提取决策事项
决策事项应来自项目集实际运行中需要拍板的节点，常见来源有五类：阶段关口、资源与预算、范围与收益、风险与升级、变更与例外。提取时可以回顾最近一个季度的治理会议纪要、升级记录和审批记录，把反复讨论或悬而未决的问题整理出来，再按上述五类归并。
事项描述要写成可判断的决策问题，让参与者一眼看出需要决定什么。例如“阶段关口是否放行”“预算追加是否批准”“重大风险是否升级至治理委员会”“范围重大变更是否接受”。写成“阶段管理”“预算管理”这类职能名称，矩阵填完后仍然无法判断谁在什么情况下拍板。
固定四类治理角色
角色清单建议固定为发起人、治理委员会、项目集经理、项目负责人四类，覆盖项目集治理的主要决策链条。角色清单不能只写岗位名称，还要写清当前承担者与替补人。项目集周期较长，人员变动和休假都会影响决策时效，替补安排应在矩阵发布前确定。
| 清单 | 包含字段 | 完成标志 |
|---|---|---|
| 治理决策事项清单 | 事项编号、所属类别、决策问题描述、触发时点、所需输入材料 | 每个事项都能用“是/否”或明确选项回答 |
| 治理角色清单 | 角色名称、承担者、替补人、所属组织、联系方式 | 四类角色均有明确承担者与替补 |
映射方法：用职责类型把决策事项落到角色
映射的核心规则是：每个决策事项只设一个决策角色，其余角色根据实际参与方式填写提议、评审、知会或执行。这条规则让每类决策都有唯一拍板人，出现争议时也能找到责任主体。
五种职责类型的含义与边界
| 职责类型 | 含义 | 边界说明 |
|---|---|---|
| 提议 | 发起决策请求，提交背景、方案与建议 | 提议不等于决定，提议人不能替代决策角色拍板 |
| 评审 | 对提议内容给出专业意见或合规判断 | 评审意见是决策输入，评审人承担意见质量责任 |
| 决策 | 对事项作出最终决定并承担结果责任 | 同一事项只设一个决策角色 |
| 知会 | 接收决策结果，按需在职责范围内配合 | 知会不构成审批环节，不阻塞决策 |
| 执行 | 按决策结果落实具体动作 | 执行角色对落地进度和结果反馈负责 |
填写规则与权限补充说明
填写时按行推进：先确定该事项的决策角色，再判断谁提议、谁评审、谁需要知会、谁负责执行。同一角色在同一事项上不重复承担评审与决策，避免出现“自己评审自己拍板”的情况。若某角色既是提议人又是执行人，可以在同一单元格内并列标注，但决策栏仍只保留一个角色。
决策权限不能只写角色名称，还要补充四项信息：决策依据（制度、授权额度或治理章程条款）、所需输入（评审意见、数据报告、风险清单等）、决策时限（例如关口评审会后三个工作日内）、升级路径（决策角色无法在时限内决定时向谁升级）。这四项与职责类型填在同一行，矩阵才具备可执行性。
常见映射冲突及处理
- 多头决策：同一事项出现两个决策角色。处理方式是回到授权来源，确认哪一方拥有最终权限，另一方改为评审或知会。
- 角色缺位：某事项无人提议或无人执行。补充承担者，或判断该事项是否应纳入矩阵。
- 职责与职权不匹配：要求某角色评审其无权获取的信息。调整输入材料范围，或将评审职责移到具备信息条件的角色。
角色分工与交付物：谁在什么时点交出什么
矩阵编制不是项目集经理一个人的工作。四类角色在编制阶段和运行阶段各有动作与交付物，明确到人后矩阵才能从文档变成运行机制。
| 角色 | 编制阶段动作与交付物 | 运行阶段动作与交付物 |
|---|---|---|
| 发起人 | 确定治理边界与授权范围，批准矩阵发布 | 对超出治理委员会权限的事项作出最终决策 |
| 治理委员会 | 评审决策事项完整性与决策权限合理性，给出评审意见 | 按矩阵对授权范围内事项作出决策，形成决策记录 |
| 项目集经理 | 组织编制矩阵，汇总事项清单与角色清单，维护矩阵版本 | 推动事项按矩阵流转，跟踪决策时限，记录争议与升级 |
| 项目负责人 | 提供所负责项目的决策事项输入，确认本项目的评审与执行职责 | 按矩阵提交提议或评审意见，执行决策结果并反馈进展 |
编制阶段的交付物集中在矩阵本身及配套的职责类型定义表；运行阶段的交付物是决策记录、评审意见和执行反馈。两类交付物应分开存放，避免把编制过程中的讨论稿与正式决策记录混在一起。
示例：一个项目集治理职责矩阵片段
以下片段选取四个典型决策事项，示范职责类型的填写方式。示例为演示情景，实际填写时需结合组织授权额度与治理章程调整。
| 决策事项 | 发起人 | 治理委员会 | 项目集经理 | 项目负责人 | 决策依据与输入 |
|---|---|---|---|---|---|
| 阶段关口是否放行 | 知会 | 决策 | 评审 | 提议 | 关口评审报告、交付物完成情况、遗留问题清单 |
| 预算追加是否批准 | 决策（超授权额度时） | 决策（授权额度内） | 评审 | 提议 | 预算追加申请、成本偏差分析、收益影响说明 |
| 重大风险是否升级 | 知会 | 决策 | 提议 | 评审 | 风险登记册、影响评估、应对方案 |
| 范围重大变更是否接受 | 知会 | 决策 | 评审 | 提议 | 变更申请、范围影响分析、进度与资源影响 |
示例体现了两个设计要点。第一，预算追加按授权额度拆分决策角色：额度内由治理委员会决策，超额度由发起人决策，同一事项在矩阵中仍保持单一决策路径。第二，重大风险升级由项目集经理提议、项目负责人评审、治理委员会决策，升级路径清晰：项目集经理在风险超出项目集可控范围时提交，治理委员会在约定时限内决定是否升级至发起人。
矩阵落地后，决策事项的流转需要承载载体。ONES Plan 支持借助项目集管理总览多项目信息，并提供多项目进度管控和资源管理，可为关口评审、预算与资源类决策提供进度和资源输入；决策记录、评审意见与执行反馈则可依托工作项状态和文档流转留痕，使矩阵中的每个事项都能追溯到提议、评审与决策结果。
评审、发布与维护：让矩阵持续可用
矩阵初稿完成后不能直接使用，需要经过评审、发布和约定维护机制，才能成为项目集运行的正式规则。
评审参与方与评审要点
评审由项目集经理组织，发起人、治理委员会成员和项目负责人代表参加。评审重点看三项：事项覆盖度，即五类决策来源是否都有对应事项；决策唯一性，即每个事项是否只有一个决策角色；权限匹配，即决策角色的授权是否足以支撑该决策，所需输入是否在其可获取范围内。评审意见逐条记录，修改后形成定稿。
发布方式与知会范围
定稿矩阵由发起人批准后发布，知会范围至少覆盖四类角色的承担者与替补人，以及与决策执行相关的职能接口人。发布时同步说明矩阵的生效日期、适用项目集范围和查询位置，避免出现多份版本并行使用。
维护触发条件与版本管理
矩阵在以下情况需要更新：组织调整导致角色承担者变化、项目集进入新阶段导致决策事项增减、出现矩阵未覆盖的决策争议。维护由项目集经理发起，变更内容经治理委员会评审、发起人批准后发布新版本。版本记录建议保留变更日期、变更内容、批准人和生效范围，历史版本归档备查，便于回溯某次决策当时适用的规则。
完成检查：矩阵可用的判断标准
发布前逐项核对以下清单，全部通过即可认为矩阵达到可运行状态。
- 每个决策事项都有且仅有一个决策角色，决策栏没有空白或多填。
- 每个角色清楚自己在各事项上的提议、评审、知会或执行义务，替补人已确认。
- 每个事项的决策依据、所需输入材料和决策时限已写明。
- 升级路径明确：决策角色无法在时限内决定时，指向具体的升级对象和触发条件。
- 例外处理有明确指向，例如超授权额度、跨项目集资源冲突由谁裁定。
- 矩阵已经过治理委员会评审、发起人批准并正式发布，知会范围覆盖全部承担者。
- 已指定矩阵维护责任人，并约定组织调整、阶段变化、决策争议三类更新触发条件。
清单核对完成后，矩阵即可投入运行。运行初期建议在每次治理会议后检查决策记录是否与矩阵一致，发现偏差及时修正，使矩阵逐步贴合项目集的实际决策节奏。
常见问题
项目集刚启动、决策事项还看不清时，矩阵要不要一次编全？
不必一次编全。可以先覆盖阶段关口、预算追加、重大风险升级、范围重大变更这几类高频事项，形成可运行的初版矩阵，再按维护触发条件补充。项目集进入新阶段时决策事项会增减，矩阵本身就需要随阶段更新，初版留出扩展空间比追求完整更实际。
需要守住的是初版中每个已列事项的决策角色唯一、输入材料和时限写明，否则矩阵发布后仍无法执行。
同一事项在不同金额或影响程度下由不同角色决策，是否违反“单一决策角色”规则？
不违反，前提是拆分后每个分支仍只有一个决策角色，并且拆分条件写清楚。例如预算追加按授权额度拆分：额度内由治理委员会决策，超额度由发起人决策，矩阵中标注额度阈值即可。读者需要能根据条件判断走哪条路径，避免出现两个角色同时拥有决策权、谁也说不清最终拍板人的情况。
发起人和治理委员会的决策边界怎么划，容易在哪里出问题？
常见做法是把治理委员会限定在授权范围内决策，超出授权额度、跨项目集资源冲突、影响项目集整体收益目标的事项由发起人决策。边界出问题多在两处：一是授权额度只写在制度里、没有写进矩阵，运行中反复确认；二是升级路径只写“报发起人”，没有写触发条件和时限。把额度阈值、升级触发条件与决策时限填进对应行，边界才可操作。
矩阵发布后，项目负责人不按矩阵提交提议怎么办？
先检查矩阵本身是否可执行：提议所需的输入材料是否明确、提交时点是否与项目节奏匹配、提交载体是否方便。若矩阵没有问题，则由项目集经理在治理会议上指出偏差，并把“按矩阵提交提议与评审意见”纳入项目负责人的运行阶段职责。运行初期建议每次治理会议后核对决策记录与矩阵是否一致，偏差及时纠正，比事后追责更有效。
矩阵落地后，决策流转和记录用什么承载比较合适？
关键是让每个事项能追溯到提议、评审与决策结果。ONES Plan 支持借助项目集管理总览多项目信息，并提供多项目进度管控和资源管理，可为关口评审、预算与资源类决策提供进度和资源输入；决策记录、评审意见与执行反馈可依托工作项状态和文档流转留痕。具体功能范围以官网产品页当前描述和实际版本为准。
