项目集章程要回答的核心问题是：这组相互关联的项目为什么放在一起管理、共同收益是什么、由谁决策、边界在哪里。本文给出一份虚构但完整的项目集章程示例，覆盖愿景、收益、范围、治理、依赖、里程碑、预算、风险和变更规则，并逐项说明填写依据，便于替换成自己组织的信息。
要点总览（TL;DR）
- 一份可用的项目集章程要写清愿景与可衡量收益、范围与排除项、治理角色与决策权限、组成项目与依赖、里程碑与关口、预算口径、风险与变更规则、汇报与关闭条件。
- 示例采用虚构的“区域订单履约协同项目集”情景，收益指标落到平均履约时长、调拨占比、异常订单占比等可统计口径，并注明数据来源与验证时点。
- 填写时让收益、范围、依赖三者相互支撑：每个收益有对应项目支撑，每个依赖能解释项目为何要放在一起管理。
- 迁移到自己的场景时保持结构骨架不变，替换业务对象与指标口径；治理层级可增减，但决策权限、变更阈值和关闭条件不能省。
- 章程是活文档，随关口评审更新版本；落地后可与协作工具中的工作项和文档状态衔接，便于执行与追溯。
这份示例要解决什么问题
这份示例的目标，是把“多个相关项目如何协同取得共同收益”写成一份可评审、可签署、可执行的文档。读者可以把它当作填写模板：先对照字段确认自己的项目集是否想清楚了，再按示例的写法组织语言，最后提交指导委员会评审。
示例设定一个虚构情景：某零售企业设立“区域订单履约协同项目集”，希望通过仓储、配送、订单系统三方面的关联项目，缩短订单从支付到送达的时间，并降低跨区域调拨的履约成本。文中出现的组织名称、数字目标、人员角色均为示例设定，用于演示写法，不代表任何真实客户或实际成效。
本文覆盖章程本身的写法与字段解释，不涉及项目组合层面的投资选择与优先级排序，也不展开单个项目的详细进度计划与任务分解。这两部分分别属于项目组合管理和项目级计划，章程只需引用其结论，不必替代它们。
完整示例：某区域订单履约协同项目集章程
以下为示例章程正文，字段齐全、前后自洽，可直接参照填写。
基本信息
| 字段 | 示例取值 |
|---|---|
| 项目集名称 | 区域订单履约协同项目集 |
| 发起人 | 运营副总裁（示例角色） |
| 章程版本 | V1.0 |
| 生效日期 | 2025年3月1日（示例日期） |
| 项目集经理 | 履约运营部负责人（示例角色） |
愿景与预期收益
愿景：让区域内订单在承诺时效内稳定送达，跨仓调拨按统一规则执行。预期收益写成可观察的业务结果，并注明衡量口径与验证时点：
- 订单支付到签收的平均时长，在项目集结束时较基线下降，按区域月度报表统计；
- 跨区域调拨单占比按季度下降，以仓储系统调拨记录为准；
- 履约异常订单（超时、拆单失败）占比下降，以订单系统异常标记统计。
收益实现责任人为履约运营部负责人，财务口径由财务BP确认，收益验证安排在阶段关口进行。
范围边界
纳入本项目的组成项目：
- 项目A：区域仓配网络调整；
- 项目B：订单路由规则统一；
- 项目C：配送时效监控看板建设。
明确排除：全国仓网规划、供应商合同谈判、门店端系统改造。排除项由发起人确认，如需纳入须走变更流程。
治理结构与决策权限
| 角色 | 职责 | 决策权限 |
|---|---|---|
| 项目集指导委员会 | 审定章程、收益目标与阶段关口结论 | 范围重大变更、预算调整超阈值、关口放行 |
| 项目集经理 | 协调跨项目依赖、汇总状态、管理风险与变更 | 阈值内的资源调配、依赖冲突裁决建议 |
| 各项目经理 | 执行本项目计划、上报依赖与风险 | 本项目内任务安排与执行决策 |
组成项目与依赖关系
项目B的订单路由规则依赖项目A完成仓配网络调整后的仓库清单；项目C的监控看板依赖项目B输出的路由规则口径。依赖以“提供方—接收方—交付物—需要时点”的方式登记，由项目集经理在月度协调会上跟踪。
阶段划分、里程碑与关口
- 阶段一（3—5月）：仓配网络调整方案确定，关口评审确认仓库清单；
- 阶段二（6—8月）：路由规则上线试运行，关口评审核对时效与异常率基线变化；
- 阶段三（9—11月）：监控看板上线，关口评审验证收益指标并决定关闭或延期。
资源与预算口径
预算按项目分列，项目集层面保留一定比例的预备费用于跨项目协调与依赖处理。预算口径以财务批复为准，超支需按变更规则上报。收益实现责任人为履约运营部负责人。
主要风险、假设与约束
- 风险：仓配调整期间出现履约中断，应对为分批切换并保留回退方案；
- 假设：区域订单量在项目期内保持稳定；
- 约束：系统改造须在业务低峰期上线。
变更控制与例外上报
范围增减、预算调整超过批复比例、关口延期超过两周，须提交指导委员会决策；阈值内的调整由项目集经理审批并记录。例外事项在月度报告中单列。
汇报节奏、状态口径与关闭条件
各项目每周提交状态，项目集每月向指导委员会汇报，状态统一使用“正常、关注、风险”三档口径。关闭条件为：三个组成项目完成验收、收益指标完成验证、遗留事项移交明确责任人。
逐项解释：每个字段为什么这样填
收益描述从“提升效率”落到可观察结果，关键是写清指标、口径、数据来源和验证时点。示例中把“缩短履约时长”拆成平均时长、调拨占比、异常占比三个可统计的指标，并指定统计系统和责任人，评审时才能判断收益是否实现。
范围边界写排除项，是为了避免把任意多项目清单当成项目集。项目集成立的前提是项目之间存在共同收益和实质依赖；写明不纳入的内容，可以防止执行中范围蔓延，也让评审者看清边界是否合理。
治理角色与决策权限要对应到具体决策类型。示例把范围重大变更、预算调整、关口放行分别落到指导委员会，把阈值内调配落到项目集经理，避免出现“都负责、都不拍板”的情况。填写时可先列出本组织常见的决策类型，再逐一指定决策人和阈值。
依赖关系用“提供方—接收方—交付物—需要时点”表达，便于后续跟踪。只写“项目A与项目B相关”无法判断影响，写清交付物和时点后，依赖延误才能被及时发现并升级。
里程碑与关口与收益验证挂钩：每个关口不仅检查交付物，还核对收益指标的变化。这样章程从立项文件变成阶段性验证依据，避免项目做完才发现收益无法衡量。
风险与变更规则设定上报阈值，是为了让例外管理有明确触发条件。阈值可以是预算比例、延期天数或影响范围，具体数值按组织授权体系确定，章程中写清即可。
可迁移规律：换成自己的场景怎么改
结构骨架保持不变，内容随业务对象替换。无论行业是制造、零售还是公共服务，章程都要回答愿景与收益、范围、治理、依赖、里程碑、预算、风险、变更、汇报这几类问题，替换的是具体项目名称、指标口径和角色名称。
收益、范围、依赖三者要保持一致：收益指标应能由纳入的项目共同支撑，依赖关系应能解释项目为何必须放在一起管理。如果某个收益没有任何组成项目支撑，或某两个项目之间没有实质依赖，就需要重新审视项目集边界。
治理层级可按项目集规模增减。小型项目集可以只设项目集经理和发起人两级，大型项目集可增加指导委员会和专项协调组，但决策权限必须写清，不能因层级简化而留下决策空白。
章程是活文档，随关口评审更新版本。每次关口评审后记录版本变化、变更原因和批准人，使章程与执行状态保持一致。
可以简写的字段包括背景描述、组织介绍等说明性内容；不能省的是收益指标与口径、范围排除项、决策权限、依赖登记方式、变更阈值和关闭条件，这些直接决定章程能否用于评审和执行。
适用边界与使用提醒
本文示例为虚构情景，其中的组织、角色、日期和指标均为演示写法，不代表任何真实组织或实际成效。读者套用时须替换为自己组织经确认的信息，指标基线应以实际统计数据为准。
章程不能替代项目组合层面的投资决策。是否启动项目集、资源在多个项目集之间如何分配，属于项目组合管理的职责；章程处理的是项目集获批后的协同与治理安排。
项目集与大型单项目、项目组合的区分在于：大型单项目以单一交付物为目标，项目组合以投资选择和整体平衡为目标，项目集则以关联项目的协调和共同收益为目标。判断标准是是否存在需要协同管理的多个项目和共同收益，而非项目数量多少。
评审章程时重点核对一致性：收益指标是否有对应项目和责任人，范围排除项是否与治理权限匹配，依赖登记是否覆盖关键交付物，里程碑关口是否包含收益验证，变更阈值是否可执行。
章程落地后需要与协作工具中的工作项、文档状态衔接，便于执行与追溯。例如在ONES中可将组成项目、依赖事项和关口评审建为工作项，把章程文档与阶段状态关联，使版本更新、评审结论和执行进度在同一处可查，减少章程与执行脱节的情况。
常见问题
项目集章程和单个项目的项目章程有什么不同？
项目章程围绕单一交付物，说明目标、范围、主要干系人和成功标准；项目集章程围绕一组关联项目的协同，重点是共同收益、跨项目依赖、治理层级和收益验证方式。判断依据是是否存在需要协调管理的多个项目以及共同收益，项目数量多少本身不构成判断标准。
章程里的收益指标还没有基线数据，可以先写目标值吗？
可以写目标方向，但要注明基线待补及其确认时点。示例中的做法是写清指标、统计系统、责任人和验证关口，基线数值在阶段一关口前由责任部门确认后补入。这样章程仍可用于评审，同时避免用未经验证的数字充当承诺。
小型项目集是否必须设指导委员会？
不必须。治理层级可以按规模简化，小型项目集可只设发起人和项目集经理两级，由发起人承担关口放行和重大变更决策。需要保留的是决策权限的明确归属：范围变更、预算调整、关口放行分别由谁拍板、阈值多少，这些内容在简化层级下同样要写清。
章程批准后，执行中发现依赖关系漏登记怎么办？
按变更规则处理：先由项目集经理评估影响，补充登记依赖的提供方、接收方、交付物和需要时点，涉及关口或预算的提交指导委员会确认，并在下一版章程中记录变更原因和批准人。依赖登记本身应作为月度协调会的固定议题，减少事后补录。
章程写好后，怎么避免它和实际执行脱节？
把章程中的关键约定转成可跟踪的对象：组成项目和依赖事项建为工作项，关口评审结论与章程版本关联，状态按统一口径定期更新。在ONES中可以用工作项承载项目与依赖、用文档承载章程版本，使评审结论和执行进度在同一处可查，章程更新时同步调整对应工作项。
