项目集章程要回答的是一个立项判断：为什么把这些项目放在一起管理、共同收益是什么、谁对结果负责、边界和治理规则怎么定。本文提供一份可直接复制填写的空白章程表格，逐项说明字段含义与必填选填，并附一份完整填写示例和后续维护方法，适合项目集发起人、项目集经理和PMO在立项评审前使用。
要点总览（TL;DR）
- 空白章程模板按六个区块组织：基本信息、项目集定位、目标与收益、治理、风险与依赖、授权，可直接复制到文档或表格工具中逐格填写。
- 共同收益、范围边界、目标与收益指标、发起人与项目集经理、治理机制、关键依赖与主要风险、预算口径与变更条件属于必填内容，空缺会直接影响立项评审与后续跟踪。
- 填写时把目标写成结果状态、把收益指标写成可量化的值与统计口径，依赖与风险分开记录，分别对应协调动作与应对准备。
- 章程批准后按版本与变更记录维护，范围、收益目标、治理结构或预算授权发生变化时按原审批路径修订，并与项目集计划、状态报告和关闭评估衔接。
可复制空白项目集章程模板
下表按六个区块组织，可直接复制到文档或表格工具中，逐格填写。每个区块对应章程要解决的一类问题，填写时保持区块顺序，便于评审人按同一路径阅读。
| 区块 | 字段 | 填写内容 |
|---|---|---|
| 一、基本信息 | 项目集名称 | |
| 章程编号 | ||
| 版本号 | ||
| 编制人 / 编制日期 | ||
| 审批人 / 审批日期 | ||
| 文档状态（草稿 / 待审批 / 已批准 / 已归档） | ||
| 二、项目集定位 | 背景与驱动因素 | |
| 共同收益（为什么放在一起） | ||
| 范围边界（包含什么、不包含什么） | ||
| 包含项目清单（项目名称、负责人、预计起止） | ||
| 与其他项目集 / 单项目的关系 | ||
| 三、目标与收益 | 项目集目标（结果性描述） | |
| 收益指标与衡量口径 | ||
| 关键时间节点（里程碑） | ||
| 收益责任人与验收方式 | ||
| 四、治理 | 发起人（Sponsor） | |
| 项目集经理 | ||
| 治理机构（名称、成员、职责） | ||
| 决策与评审机制（会议、频率、决策权限） | ||
| 五、风险与依赖 | 关键依赖（跨项目、外部供应商、其他部门） | |
| 主要风险（描述、影响、应对方向） | ||
| 假设 | ||
| 约束（时间、法规、技术、人力） | ||
| 六、授权 | 资源授权（人力、设备、外部服务） | |
| 预算口径（总额、来源、审批权限） | ||
| 变更条件（何种变更需重新审批） | ||
| 关闭条件（何时、依据什么关闭项目集） |
表格中的“包含项目清单”建议单独用子表展开，列明项目名称、项目负责人、预计起止时间和该项目对共同收益的贡献，避免只写项目名称导致评审时无法判断组合逻辑。
字段说明：每个格子该填什么
字段说明解决的是“填得对不对”的问题。以下按区块给出填写口径与判断标准，重点区分容易混淆的几组字段。
| 字段 | 填写内容 | 判断标准 |
|---|---|---|
| 共同收益 | 描述这些项目合在一起才能获得的收益，例如共享一套数据标准、统一上线一个客户流程 | 删掉其中任一项目，收益是否明显减弱；若各项目收益互不相关，说明这只是项目清单 |
| 范围边界 | 分别写“包含”和“不包含”，不包含部分写明归属 | 评审人能据此判断哪些需求应拒收、哪些应转其他项目集 |
| 项目集目标 | 项目集整体要达成的结果状态，通常一到三条 | 描述结果而非活动，能对应到收益指标 |
| 收益指标与衡量口径 | 指标名称、基线值、目标值、统计周期、数据来源 | 指标可量化或有明确验收方式，口径写清由谁统计 |
| 发起人 | 对项目集结果最终负责、能调动资源的高层角色 | 具备预算与跨部门协调权限，能在治理机构中拍板 |
| 项目集经理 | 负责日常协调、依赖管理、状态汇总的执行负责人 | 对项目集整体进度与收益跟踪负责，不等同于单个项目经理 |
| 治理机构 | 名称、成员构成、议事范围 | 成员覆盖关键项目与关键职能部门，职责写明决策还是建议 |
| 关键依赖 | 依赖对象、依赖内容、需要的时间点、责任方 | 每条依赖可追踪到具体项目或外部方，有承诺时间 |
| 主要风险 | 风险描述、可能影响、应对方向、责任人 | 与依赖分开记录，风险是可能发生的不利事件，依赖是必须兑现的前提 |
| 预算口径 | 总额、分年度或分阶段金额、资金来源、超支审批权限 | 写明是上限授权还是估算参考，避免执行阶段口径争议 |
目标与收益指标的区别值得单独说明：目标是方向性的结果描述，例如“客户订单处理周期缩短”，收益指标则是可衡量的具体值，例如“订单平均处理时长从48小时降至24小时，按季度统计”。目标给评审人判断价值，指标给后续跟踪提供依据，两者应成对出现。
依赖与风险分开记录的原因在于管理动作不同。依赖需要提前协调、锁定承诺时间并跟踪兑现；风险需要评估概率与影响、准备应对措施。混在一起记录，容易导致依赖无人跟进、风险被当作既定事实。
必填与选填：哪些字段不能空
章程的必填字段决定立项评审能否进行。以下清单按“空缺后果”区分，组织可据此设定审批门槛。
| 类别 | 字段 | 空缺后果 / 适用情形 |
|---|---|---|
| 必填 | 项目集名称、编号、版本、编制人与日期 | 无法追溯文档来源与审批状态 |
| 必填 | 背景与驱动因素 | 评审人无法判断立项必要性 |
| 必填 | 共同收益 | 无法证明项目组合的合理性，章程退化为项目清单 |
| 必填 | 范围边界 | 执行阶段范围蔓延，需求归属争议频发 |
| 必填 | 包含项目清单 | 无法界定管理对象与责任分工 |
| 必填 | 项目集目标与收益指标 | 后续无法评估项目集是否成功 |
| 必填 | 发起人与项目集经理 | 决策与执行责任缺位 |
| 必填 | 治理机构与决策机制 | 跨项目冲突无裁决路径 |
| 必填 | 关键依赖与主要风险 | 执行阶段被动应对，缺少提前协调依据 |
| 必填 | 预算口径与变更条件 | 资源授权不清，变更失控 |
| 选填 | 与其他项目集 / 单项目的关系 | 项目集数量少、边界清晰时可简化 |
| 选填 | 假设 | 不确定性低的小型项目集可合并进风险区 |
| 选填 | 收益责任人与验收方式 | 收益由项目集经理统一跟踪时可暂不单列 |
| 选填 | 关闭条件 | 长期运营型项目集可改为阶段性评估条件 |
裁剪字段的原则是按规模与复杂度取舍：项目数量多、跨部门依赖强、预算规模大的项目集，应保留全部字段并细化治理机制；项目数量少、边界清晰、周期短的项目集，可简化“与其他项目集关系”“假设”等辅助字段，但共同收益、范围边界、目标与收益指标、责任人四类内容不建议省略，它们直接决定章程是否成立。
章程与相邻文档的边界也需要写清。项目组合管理关注在多个项目集之间做投资选择与优先级排序，章程不承担选择决策；单项目立项报告关注单个项目的可行性与交付内容，章程关注项目之间的协调关系与共同收益。章程中引用组合层面的优先级结论即可，不重复论证。
填写示例：一份完整的项目集章程
以下示例为演示情景，用于说明字段之间如何相互呼应，不对应真实客户案例。
背景：某零售企业计划在一年内完成订单系统升级、仓储流程调整和客服工单改造三个项目。三者单独推进时各自可行，但订单数据标准不统一会导致仓储与客服反复返工，因此作为一个项目集统一协调。
| 区块 | 字段 | 示例内容 |
|---|---|---|
| 基本信息 | 项目集名称 / 编号 / 版本 | 订单履约能力提升项目集 / PG-2025-03 / V1.0 |
| 基本信息 | 编制人 / 审批人 / 日期 | PMO 张明 / 运营副总裁 / 2025-03-10 |
| 定位 | 背景与驱动因素 | 订单量年增长约30%，现有系统与流程在高峰期出现履约延迟，客户投诉集中在订单状态不透明 |
| 定位 | 共同收益 | 三个项目共用一套订单状态与数据标准，实现订单从下单到交付的全流程可视，减少跨系统重复录入 |
| 定位 | 范围边界 | 包含：订单系统升级、仓储作业流程调整、客服工单与订单数据打通。不包含：财务结算系统改造（归财务数字化项目集）、门店POS替换 |
| 定位 | 包含项目清单 | 订单系统升级（负责人李华，4—9月）；仓储流程调整（负责人王强，5—10月）；客服工单改造（负责人陈静，6—11月） |
| 目标与收益 | 项目集目标 | 订单履约全流程可视、高峰期履约稳定、客户订单咨询一次解决 |
| 目标与收益 | 收益指标与衡量口径 | 订单平均履约时长由36小时降至24小时（按月度统计，数据来自订单系统）；订单状态类客服工单占比由25%降至10%（按季度统计，数据来自工单系统） |
| 目标与收益 | 关键时间节点 | 数据标准确定（5月底）、订单系统上线（9月底）、三项目联调完成（11月底） |
| 治理 | 发起人 / 项目集经理 | 发起人：运营副总裁；项目集经理：PMO 张明 |
| 治理 | 治理机构 | 项目集指导委员会：运营副总裁、IT总监、客服总监、仓储总监，负责范围变更与跨部门资源裁决 |
| 治理 | 决策与评审机制 | 每两周项目集例会，每月指导委员会评审；范围与预算变更由指导委员会审批 |
| 风险与依赖 | 关键依赖 | 订单数据标准需在5月底前由IT与业务共同确认；仓储流程调整依赖订单系统接口文档，需8月前提供 |
| 风险与依赖 | 主要风险 | 高峰期切换影响履约（应对：分批切换并保留回退方案）；客服人员培训不足导致工单分类不准（应对：上线前完成两轮培训） |
| 风险与依赖 | 假设 / 约束 | 假设：现有订单系统可支持接口改造。约束：切换窗口避开大促期 |
| 授权 | 资源与预算口径 | 预算总额按三个项目分列，项目集层面预留10%应急额度；跨项目人力调配由项目集经理提出、发起人审批 |
| 授权 | 变更与关闭条件 | 范围增减或预算变动超过10%需重新审批；三个项目全部上线且收益指标连续两个月达标后进入关闭评估 |
示例中目标、指标与治理机制形成对应关系：履约时长指标由订单系统项目主要贡献，工单占比指标由客服工单项目主要贡献，数据标准这一依赖则由治理机构在5月底节点上裁决。范围边界中明确排除财务结算系统，使评审人能直接判断后续需求归属。
调整与维护：章程如何随项目集演进更新
章程在批准后进入维护状态，作为项目集范围、收益和治理的基准文档。维护的核心是让变更留痕、让评审有据。
版本与变更记录建议在章程末尾附一张变更记录表，字段包括：版本号、变更日期、变更内容、变更原因、提出人、审批人。每次修订递增版本号，旧版本保留可查，避免执行阶段对“当初怎么定的”产生争议。
触发章程修订的典型情形包括：包含项目增减或项目负责人变更；共同收益或收益指标调整；范围边界扩大或收缩；发起人、项目集经理或治理机构成员变化；预算授权额度调整。出现上述情形时，由项目集经理提出修订，按原审批路径确认。
评审节奏可与治理机制对齐：项目集例会跟踪依赖与风险变化，指导委员会月度或季度评审时确认章程是否需要修订。审批人确认方式建议采用书面确认并记录在变更记录表中，口头同意不作为生效依据。
章程与后续文档的衔接体现在三处：项目集计划以章程的目标和范围为依据展开；状态报告对照章程中的收益指标汇报进展；关闭评估以章程的关闭条件为准。章程本身不承担详细进度计划的功能，执行层面的排期放在项目集计划中。
在文档工具中维护章程时，可以把章程作为项目集的主文档，关联各项目的工作项与进度数据，使范围、依赖和收益指标的更新有据可查。ONES Wiki 支持使用模板库创建文档、记录页面版本并支持查看与回滚，页面组可关联项目，文档中可嵌入任务进度和报表；ONES Plan 支持项目集层面的多项目信息总览、自定义项目属性以及资源报表与工时管理。将章程放在这类环境中维护，修订记录与项目数据可以放在同一处对照，减少版本分散带来的核对成本。具体模板是否预置、功能范围如何，以实际使用的版本和模板库内容为准。
常见问题
项目集章程和单项目立项报告可以合并成一份文档吗？
可以放在同一文档体系中管理，但两者的回答对象不同。单项目立项报告论证一个项目自身的可行性与交付内容；项目集章程论证多个项目放在一起协调的理由，即共同收益、范围边界和跨项目治理。若合并成一份文档，建议在结构上分区，章程部分保留共同收益、包含项目清单、依赖与治理机制，避免评审人只看到单个项目的可行性而看不到组合逻辑。
项目数量少、周期短的项目集，章程可以简化到什么程度？
可简化“与其他项目集关系”“假设”等辅助字段，把假设合并进风险区记录。共同收益、范围边界、目标与收益指标、责任人四类内容建议保留，它们决定章程是否成立。治理机制可以简化为例会加发起人确认的形式，但决策权限和变更审批路径仍需写明，否则执行阶段出现范围争议时缺少裁决依据。
章程批准后，项目增减是否需要重新走审批？
取决于章程中变更条件字段的约定。常见做法是把包含项目增减、项目负责人变更、范围边界调整、收益指标修改、预算授权额度变化列为需重新审批的情形，由项目集经理提出修订，按原审批路径确认。若章程未约定，建议在首次修订时补上这一条，并在变更记录表中登记版本号、变更内容、原因和审批人。
收益指标在章程阶段难以量化，应该怎么填？
可以先写清指标名称、统计周期和数据来源，基线值与目标值标注为待测量，并写明由谁在什么时间点完成基线测量。这样章程仍能提供后续跟踪依据，避免用“提升效率”“改善体验”这类无法验收的表述占位。基线测量完成后，按变更流程补充数值并递增版本号。
章程在文档工具中维护时，如何让修订记录和项目数据对得上？
可以把章程作为项目集的主文档，在末尾附变更记录表，同时让文档与项目工作项、进度数据保持关联。ONES Wiki 支持使用模板库创建文档、记录页面版本并支持查看与回滚，页面组可关联项目，文档中可嵌入任务进度和报表；ONES Plan 支持项目集层面的多项目信息总览、自定义项目属性以及资源报表与工时管理。这样修订记录与项目数据可以放在同一处对照。模板库是否预置项目集章程模板、功能范围如何，以实际使用的版本和模板库内容为准。
