项目集层面的变更决策，核心是按影响范围分层：影响单个项目内部、不改变项目集收益与里程碑的变更，由项目经理审批并报项目集经理备案；影响项目集里程碑、跨项目依赖、预算或收益实现的变更，由项目集经理组织评估、项目集治理委员会审批；涉及组织战略、投资额度或优先级重排的变更，上升到项目组合或组织级决策机构。本文给出分级判定表、角色职责矩阵、流转示例与落地检查清单，帮助建立可运行的分工。
要点总览（TL;DR）
- 项目集变更按影响范围分三级决策：项目级由项目经理审批并报项目集经理备案；项目集级由项目集经理组织评估、治理委员会审批；涉及战略、投资额度或优先级重排的变更上升到项目组合或组织级决策机构。
- 分级判断以五个字段为准：是否改变收益目标、是否影响里程碑基线、是否改变跨项目依赖、是否超出预算或资源池、是否改变范围基线，任一为“是”即超出项目级权限。
- 用RACI矩阵固定提议、评估、审批、知会、执行五类职责，并对应到变更单字段，避免同一类变更反复争论由谁拍板。
- 决策机制需配套治理委员会议事规则、项目集经理授权额度表、分歧与超期未决的升级路径，以及紧急变更的简化通道和事后补审时限。
- 变更单、评估报告与决策记录关联留痕，状态按待评估、待审批、已批准或已驳回、执行中、已关闭流转，便于审计与复盘。
变更分级：先定清楚哪类变更归哪一级决策
项目集变更决策最常见的争议，是同一类变更在不同时间由不同角色拍板。解决办法是把分级标准前置成一张判定表，让提议人在提交变更单时就完成初步定级，评估环节再确认或调整级别。分级以影响范围为第一判断字段，金额、工期等量化指标作为辅助条件。
判断一条变更归入哪一级，重点核对五个字段：是否改变项目集收益目标或收益实现路径；是否影响项目集里程碑基线；是否改变两个及以上子项目之间的依赖关系；是否超出已批准的项目集预算或资源池；是否改变项目集范围基线。任一字段为“是”，变更即超出项目级权限。
| 变更级别 | 判定条件 | 决策层级 | 典型示例 |
|---|---|---|---|
| 项目级 | 仅影响单个项目内部的任务、资源或交付节奏；不改变项目集收益、里程碑、跨项目依赖与预算 | 项目经理审批，报项目集经理备案 | 子项目内部调整测试排期、替换同岗位人员 |
| 项目集级 | 影响项目集里程碑、跨项目依赖、项目集预算或收益实现；在已批准的项目集范围与投资额度内 | 项目集经理组织评估，项目集治理委员会（或指导委员会）审批 | 两个子项目交付顺序调整、项目集内资源重新分配 |
| 组织/组合级 | 涉及组织战略方向、超出项目集投资授权额度、需要重排项目组合优先级或调整多个项目集之间的资源 | 项目组合管理委员会或组织级决策机构 | 因监管要求新增合规交付内容并追加投资 |
判定表需要写进项目集治理文件，并在启动阶段向所有子项目负责人宣贯。实际运行中，提议人填写变更单时先自评级别，项目集经理在受理环节复核；对定级有分歧的，按较高级别处理并提交对应决策机构，避免因降级审批造成后续返工。判定表应每季度结合实际发生的变更回看一次，把反复争论的案例补充为明确条目。
各角色的决策职责：谁提议、谁评估、谁审批、谁知会
分级标准解决“归哪一级”，角色职责解决“谁做什么”。建议用 RACI 矩阵把提议、评估、审批、知会、执行五类职责固定下来，并对应到变更单的字段上，使每个变更从提交起就有明确的责任人。
| 角色 | 提议 | 评估 | 审批 | 知会 | 执行 |
|---|---|---|---|---|---|
| 项目经理 | 提出项目级及项目集级变更申请 | 提供本项目影响分析 | 审批项目级变更 | 知会项目集经理 | 落实本项目内调整 |
| 项目集经理 | 提出项目集级变更申请 | 组织整体影响分析，汇总各项目意见 | 在授权额度内审批；超出授权提交委员会 | 知会PMO与财务 | 更新项目集计划与基线 |
| 项目集治理委员会/指导委员会 | — | 审议评估结论 | 审批项目集级变更 | — | — |
| 项目组合/组织级决策机构 | — | 审议战略与投资影响 | 审批组织级变更 | — | — |
| PMO | 可发起流程性变更建议 | 提供流程与数据支持 | — | 接收全部变更备案 | 维护变更台账与模板 |
| 财务与资源负责人 | — | 提供预算与资源影响意见 | — | 接收涉及预算的变更通知 | 调整预算与资源分配 |
| 受影响项目团队 | 可提出变更需求 | 提供技术可行性与工作量评估 | — | 接收变更结论 | 按更新后的计划执行 |
每个角色的输入、动作与输出需要写清楚。项目经理的输入是变更需求与项目现状数据，动作是填写变更单并完成本项目影响初判，输出是带初步定级的变更申请。项目集经理的输入是变更申请与各子项目反馈，动作是组织跨项目影响分析、协调评估会议，输出是影响评估报告与决策建议。治理委员会的输入是评估报告与决策建议，动作是审议并形成结论，输出是审批意见与决策记录。PMO 的输入是全部变更单，动作是登记台账、跟踪状态，输出是可查询的变更清单。
需要特别明确两类边界。其一，项目集经理的审批权仅限于治理委员会明确授权的额度与范围，超出部分必须提交委员会，不能以“先执行后补审”替代。其二，知会不等于审批，财务、资源负责人和受影响团队收到通知后提出意见，最终结论仍由对应审批角色作出，避免责任分散。
一次项目集变更的完整流转示例
以下为演示情景：某项目集在交付中期收到新的监管要求，需要调整两个子项目的交付范围，并可能影响项目集整体上线里程碑。通过这个场景可以看到各环节的负责人、输入材料、输出记录与完成标志。
- 提交变更单。负责人为受影响子项目的项目经理。输入是监管要求文件与初步影响判断，动作是填写变更单，标注变更级别为项目集级、影响范围为两个子项目及上线里程碑，输出是变更单。完成标志是变更单状态进入“待评估”。
- 影响评估。负责人为项目集经理。输入是变更单与两个子项目的评估意见，动作是组织技术、财务、资源角色分析工期、成本、依赖与收益影响，输出是影响评估报告与建议方案。完成标志是评估报告附在变更单上，相关方意见齐全。
- 治理委员会评审。负责人为治理委员会主席。输入是评估报告与决策建议，动作是召开评审会、审议方案并形成结论，输出是会议纪要与决策记录。完成标志是决策结论回写到变更单。
- 决策与批复。决策结论有三种可能：批准，按方案执行；有条件批准，附加资源补充或分期交付等前提，条件满足后生效；驳回，说明理由并关闭变更。负责人为项目集经理，输出是批复通知，完成标志是变更单状态更新为“已批准”或“已驳回”。
- 计划与基线更新。负责人为项目集经理与各项目经理。输入是批复结论，动作是更新项目集里程碑、甘特图、预算与依赖关系，输出是更新后的计划与基线版本。完成标志是新基线发布并通知相关团队。
- 执行跟踪。负责人为各项目经理。输入是更新后的计划，动作是按新范围组织交付并在例会上报告进展，输出是执行进展记录。完成标志是变更涉及的工作项全部完成。
- 关闭归档。负责人为PMO。输入是执行结果与全部过程记录，动作是核对完成情况、归档变更单与决策记录，输出是关闭的变更单。完成标志是状态更新为“已关闭”，台账可查。
有条件批准需要特别跟踪：条件未满足前，变更不进入执行；条件满足后由项目集经理确认并更新状态，避免“批了但没落地”的情况长期挂起。
决策机制设计：会议、授权与升级规则
角色职责要真正运行，需要配套议事规则与授权边界。治理委员会的组成应覆盖项目集经理、关键子项目负责人、财务与资源代表以及业务收益责任人，议事频率与项目集节奏匹配，例如每月一次例行评审加按需的临时评审。法定人数与表决方式在治理文件中写明，涉及收益目标调整的议题要求收益责任人到场。
授权额度用一张表固定：项目集经理可直接批准不影响里程碑与收益、且在预算浮动比例内的变更；超出比例或触及跨项目依赖的，提交委员会。额度按项目集规模设定，并在每个治理周期复核，避免授权长期不更新。
升级规则覆盖三类情形：评估意见存在实质分歧时，由项目集经理整理分歧点提交委员会裁决；变更提交后超过约定时限未决，自动升级到上一级决策机构；涉及多个项目集资源冲突时，提交项目组合层面协调。紧急变更可走简化通道，由项目集经理先行处置并同步知会委员会，事后在最近一次治理会议上补审并补齐记录，补审时限写入制度。
用工作项与文档承载变更决策过程
变更决策要可追溯，需要把变更单、评估材料和决策记录放在同一处关联。通用做法是以工作项承载变更单，字段包括变更级别、影响范围、涉及项目、评估结论、审批人、决策结果与决策日期；评估报告、会议纪要以文档形式关联到该工作项，形成从申请到关闭的完整链路。
状态按“待评估—待审批—已批准/已驳回—执行中—已关闭”流转，每次状态变更记录操作人与时间。治理会议结论在会后回写到工作项，便于审计与复盘时还原当时的判断依据。
在工具承载上，ONES Plan 支持借助项目集管理总览多项目信息，并通过里程碑与甘特图制定和查看项目计划进度，可用于变更批准后更新项目集计划与基线；其甘特图可监控及规划 ONES Project 中的相关项目和迭代，查看工作量和进度，适合跟踪变更执行对子项目的影响。ONES Performance 提供面向管理人员、项目经理等角色的场景化仪表盘模板，可用于治理例会上查看变更相关进展。变更单的具体字段与审批流配置，建议在选型或实施时结合组织流程与厂商确认。
完成检查：这套决策分工是否真的跑起来了
制度是否落地，用证据核对比用印象判断可靠。以下清单可按季度执行，每项注明证据来源与负责人。
| 检查项 | 证据 | 负责人 |
|---|---|---|
| 分级标准覆盖近期实际发生的变更，无越级审批 | 变更台账与定级记录对照 | PMO |
| 每个变更都有评估记录与审批记录 | 变更单关联的评估报告与决策记录 | 项目集经理 |
| 治理委员会按约定频率召开，超期未决事项已升级 | 会议纪要、升级记录 | 治理委员会主席 |
| 变更关闭后项目集计划与基线已更新 | 基线版本记录与通知 | 项目集经理 |
| 紧急变更已完成事后补审 | 补审记录与时限对照 | PMO |
| 授权额度表在最近一个治理周期内复核过 | 授权表版本与复核记录 | 治理委员会 |
检查中发现越级审批，应回溯该变更的影响范围，确认是否需要补充评估；发现评估记录缺失，应在下次治理会议前补齐并分析原因。连续两个周期检查通过，说明分级标准、角色分工与决策机制已形成稳定运行；若同类问题反复出现，优先修订判定表与授权表，再调整会议规则。
常见问题
项目集经理可以直接批准哪些变更，哪些必须提交治理委员会？
项目集经理的直接审批权来自治理委员会明确授权的额度与范围，通常覆盖不影响项目集里程碑与收益实现、且在预算浮动比例内的变更。判断时先看五个字段：收益目标、里程碑基线、跨项目依赖、预算或资源池、范围基线，任一被触及就超出项目级与项目集经理的常规授权，需要提交治理委员会。授权额度表应按项目集规模设定，并在每个治理周期复核，避免授权长期不更新导致实际运行中越权或反复请示。
治理委员会评审时意见分歧、无法当场形成结论，应该怎么处理？
分歧处理要在议事规则里预先写明。常见做法是由项目集经理整理分歧点、各方立场与评估依据，提交委员会裁决；涉及收益目标调整的议题，要求收益责任人到场参与。若变更提交后超过约定时限仍未决，自动升级到上一级决策机构，避免事项长期挂起。升级记录与最终结论一并回写到变更单，作为后续复盘和审计的依据。
紧急变更能否先执行再补审批，补审有什么要求？
可以设置简化通道，但需要限定条件并写入制度。通常由项目集经理先行处置并同步知会委员会，事后在最近一次治理会议上补审，补齐评估记录与决策记录，补审时限在制度中明确。补审时要核对变更的实际影响是否与当时判断一致，若影响范围超出简化通道的适用条件，应回溯评估并补充正式审批。紧急通道的使用频次也建议纳入季度检查，防止其成为绕过审批的常规路径。
子项目负责人认为变更只影响本项目，项目集经理认为影响跨项目依赖，定级分歧怎么解决？
定级分歧按较高级别处理，并提交对应决策机构确认，这是避免降级审批造成返工的基本规则。操作上，提议人在变更单中先自评级别，项目集经理在受理环节复核；双方意见不一致时，以影响范围字段的核对结果为准，重点看是否改变两个及以上子项目之间的依赖关系。反复争论的案例应在季度回看时补充进判定表，形成明确条目，减少下次同类争议。
变更批准后项目集计划与基线如何更新，由谁确认更新完成？
批准后由项目集经理牵头更新项目集里程碑、预算与依赖关系，各项目经理同步更新本项目计划，新基线发布并通知相关团队即为更新完成的标志。有条件批准的变更，条件未满足前不进入执行，条件满足后由项目集经理确认并更新状态。变更关闭后应核对基线版本记录与通知是否齐全，这项检查可纳入季度落地检查清单，由项目集经理负责。
