项目集章程是项目集启动前的授权与共识文件，由项目集发起人和项目集经理共同确认，把“为什么把这些关联工作放在一起管理、期望获得什么共同收益、谁负责、边界在哪、按什么规则治理”写成可评审、可追踪的约定。编写时先明确共同收益与项目集边界，再依次写清目标与收益指标、组成与结构、角色与决策权、治理与变更规则、资源与阶段安排、风险与成功标准，最后组织评审签署，作为后续阶段评审和变更控制的基准。涉及多角色共同起草、版本反复和评审留痕时，可以借助 ONES 的工作项与文档协作承载编写过程。
要点总览（TL;DR）
- 项目集章程是启动前的授权与共识文件，核心是把共同收益、边界、角色决策权、治理规则写成可评审、可追踪的约定。
- 编写顺序建议先收益与边界，再结构与角色，最后治理与资源；收益和边界未谈拢时，后续条款容易反复返工。
- 判断是否构成项目集，关键看各项工作是否存在必须统一协调才能实现的共同收益，而非项目数量多少。
- 发起人负责收益期望、边界确认、资源承诺与签署；项目集经理组织编写与版本维护；组件负责人提供范围与依赖输入。
- 章程评审覆盖启动前、阶段关口和重大变更三个时点，检查项全部满足并由发起人、项目集经理和治理机构代表签署后，方可作为管理基准。
项目集章程先写清哪几件事
章程要回答的是授权问题，而非执行细节。它需要让发起人、项目集经理、组件负责人和治理机构在同一份文件上达成共识：这批关联工作值得作为一个项目集管理，收益可以衡量，责任有人承担，变更有人审批。项目计划描述“怎么做、什么时候做完”，项目组合管理决定“投不投、先投谁”，章程处在两者之间，负责把一个已获方向认可的项目集正式立起来。
一份可用的章程通常由六部分组成，每部分对应一个必须回答的问题：
| 组成部分 | 要回答的问题 | 主要输入来源 | 确认人 |
|---|---|---|---|
| 共同收益与目标 | 为什么把这些工作放在一起管理，期望获得什么共同结果 | 业务需求、收益期望、组件初步方案 | 项目集发起人 |
| 项目集边界与组成 | 哪些工作纳入本周期管理，哪些暂不纳入 | 组件清单、依赖关系、范围说明 | 发起人与组件负责人 |
| 角色与决策权 | 谁负责、谁拍板、谁提供输入 | 组织架构、授权约定 | 发起人、治理机构 |
| 治理与变更规则 | 按什么节奏评审，变更走什么路径 | 组织治理要求、阶段划分 | 治理机构 |
| 资源与阶段安排 | 需要什么资源，分几个阶段推进 | 资源承诺、组件排期 | 发起人、PMO |
| 风险与成功标准 | 主要风险是什么，怎样算成功 | 风险登记、收益指标 | 项目集经理、治理机构 |
编写顺序建议按“先收益与边界，再结构与角色，最后治理与资源”推进。收益和边界决定了项目集的范围，如果这两项没有谈拢，后面的角色和治理条款会反复返工；角色与决策权确定后，治理规则才有承载对象；资源与阶段安排放在最后，是因为它依赖前面几项结论。每部分写完后由对应确认人签字或书面确认，避免章程在评审会上才第一次暴露分歧。
从共同收益到章程条款的编写步骤
把框架落成条款，需要按固定顺序推进，每一步都有明确的输入、动作、输出和完成标志。下面六步适合项目集经理牵头组织，PMO 提供模板和过程支持。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 识别关联工作与共同收益 | 业务需求、候选工作清单、依赖关系 | 梳理各项工作之间的依赖与共享收益，判断是否构成项目集 | 关联工作清单与共同收益说明 | 发起人认可这些工作需要作为一个整体管理 |
| 2. 定义目标与收益指标 | 共同收益说明、业务基线数据 | 把收益转成可衡量的指标，写明口径与时间点 | 目标与收益指标表 | 每项收益都有指标、基线和目标值 |
| 3. 划定边界与组成 | 候选工作清单、组件初步范围 | 列出纳入和暂不纳入的工作，说明理由 | 项目集组成清单与边界说明 | 纳入项与排除项均有明确表述 |
| 4. 确定角色与决策权 | 组织授权约定、人员安排 | 明确发起人、项目集经理、组件负责人和治理机构的职责与决策权限 | 角色职责与决策权表 | 每类决策都有唯一拍板人 |
| 5. 写治理与变更规则 | 阶段划分、组织治理要求 | 规定阶段评审节点、变更审批层级和升级路径 | 治理与变更条款 | 变更规则可直接执行，无需再解释 |
| 6. 资源、阶段与风险，形成初稿并评审 | 资源承诺、风险登记、前五步输出 | 补齐资源与阶段安排、主要风险与成功标准，整合成初稿并组织评审 | 章程初稿与评审记录 | 关键干系人评审通过并签署 |
第一步最容易走偏。判断是否构成项目集，关键看各项工作是否存在必须统一协调才能实现的共同收益，例如共享一套客户数据标准、共用一条交付窗口或共同满足一项监管要求。如果只是若干项目在时间上并行、彼此没有依赖和共享收益，按多项目清单分别管理更合适，强行套用项目集结构会增加治理成本。
第二步的收益指标要落到口径上。比如“提升客户满意度”需要写明用哪项调查、统计周期和目标分值；“缩短交付周期”需要写明从哪个节点算到哪个节点。指标口径与时间点写在章程里，后续阶段评审才有对照依据。
第六步形成初稿后，建议先在小范围核对事实，再提交正式评审。初稿阶段可以借助 ONES 文档建立章程页面，把收益指标、组成清单和角色表作为同一文档的章节维护，评审意见以评论或工作项形式记录，修改后保留版本，便于追溯每轮调整的原因。
角色分工与各角色交付物
章程编写涉及多个角色，职责不清时容易出现“人人提意见、无人做决定”的情况。下面按角色列出职责和交付物，便于在启动会上直接对照分工。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 项目集发起人 | 提出收益期望，确认项目集边界与资源承诺，签署章程 | 收益期望说明、边界确认、资源承诺、签署意见 |
| 项目集经理 | 组织编写，整合各组件信息，维护章程版本 | 章程初稿、修订稿、版本记录 |
| 组件（子项目）负责人 | 提供范围、依赖与资源需求输入，确认纳入边界 | 组件范围说明、依赖清单、资源需求 |
| 治理机构或指导委员会 | 评审收益目标与决策规则，确认治理安排 | 评审意见、治理规则确认 |
| PMO 或章程归口部门 | 提供模板，组织评审，归档与变更记录 | 章程模板、评审组织记录、归档版本 |
分工中有两个容易空转的环节需要特别注意。一是发起人的资源承诺，如果章程只写“资源由相关部门支持”而没有具体确认人，后续阶段就缺少兑现依据；二是组件负责人的依赖输入，如果组件范围在章程中只写名称不写依赖，项目集层面的协调就失去抓手。建议在章程定稿前，由项目集经理逐项核对这两类输入是否到位。
当项目集涉及多个组件、章程需要多轮评审时，可以把“章程编写”本身作为一个工作项管理：在 ONES 中建立章程编写任务，拆分为收益梳理、边界确认、角色确认、治理规则、评审签署等子项，指定负责人和截止时间，评审意见与最终版本关联在同一工作项下，形成从起草到签署的完整记录。
一份章程示例：从收益到治理条款
以下示例为演示情景，用于说明条款写法，读者可按自身项目集替换具体内容。
背景：某企业计划在一年内统一三个业务线的客户数据口径，涉及数据标准制定、系统改造和报表迁移等若干关联工作，这些工作共享同一套数据标准，需要统一协调才能实现“同一客户在不同系统中口径一致”的收益。
收益与目标条款示例：“本项目的共同收益是客户主数据在三个业务线实现统一口径。衡量指标为：核心客户字段一致率在项目集结束时达到约定目标值；跨业务线客户报表差异投诉数量较基线下降。指标口径由数据管理团队提供，统计周期为每季度一次，基线数据以启动前最近一次统计为准。”
边界与组成条款示例：“纳入本周期管理的工作包括：客户数据标准制定、三个业务线的系统字段改造、核心报表迁移。暂不纳入的工作包括：供应商主数据治理、历史数据全量清洗，后者另行立项。纳入项如需调整，按变更规则审批。”
角色与决策权条款示例：“项目集发起人由分管数据的负责人担任，负责收益目标确认与资源承诺。项目集经理负责整体计划与协调。各业务线组件负责人负责本线改造范围与依赖输入。数据标准变更由数据治理委员会审批，项目集经理无权单方面调整标准口径。”
治理、变更与阶段评审条款示例：“项目集按季度设置阶段评审点，评审收益指标进展与风险状态。范围新增、收益指标调整和阶段延期超过约定阈值时，提交治理机构审批。组件之间的依赖冲突先由项目集经理协调，协调不成升级至发起人裁决。”
示例中的关键做法是：每条条款都指向具体对象、具体责任人和可判断的条件，避免出现“加强协调”“确保一致”这类无法验收的表述。
章程评审与完成检查
章程写完后需要经过评审才能作为管理基准。评审时点包括三类：启动前评审，确认章程可以作为项目集授权依据；阶段关口复核，检查收益指标和边界是否仍然成立；重大变更时更新，范围、收益或治理规则发生实质变化时修订章程并重新确认。
评审时可按以下清单逐项判断：
- 共同收益是否可衡量：每项收益都有指标、口径、基线和目标值。
- 边界是否明确：纳入项和暂不纳入项都有表述，排除项写明理由。
- 角色决策权是否无歧义：每类决策有唯一拍板人，审批层级清晰。
- 变更规则是否可执行：变更类型、审批人和升级路径可以直接照做。
- 资源承诺是否有确认人：资源需求对应到具体确认人，而非笼统的部门支持。
- 风险与成功标准是否具体：主要风险有应对方向，成功标准与收益指标对应。
通过标准建议设为：上述检查项全部满足，发起人、项目集经理和治理机构代表签署确认。签署后的章程进入版本管理，每次修订记录变更内容、原因、审批人和生效时间，旧版本保留备查。借助 ONES 文档的版本记录与评审评论，可以把每轮修改和确认意见留在同一处，阶段复核时直接对照历史版本判断变化。
评审中常见的退回原因有三类：收益写成口号，缺少指标和口径；边界含糊，纳入与排除混在一起；角色重叠，同一决策出现两个拍板人。遇到这些情况，退回补充对应条款即可，不必重写整份章程。
常见问题
项目集章程和项目组合管理是什么关系？
项目组合管理解决的是投资选择与优先级排序，决定哪些项目集或项目值得投入资源；项目集章程处理的是方向已获认可之后，如何把一个项目集正式立起来，写清共同收益、边界、角色与治理规则。章程不承担投资决策职责，也不替代项目组合层面的排序结论。编写章程时，收益目标和资源承诺需要与项目组合层面的决策保持一致，避免章程承诺的资源与已批准的投资安排脱节。
几项工作并行推进，是否就应该写成项目集章程？
判断标准是共同收益，而非工作数量或时间重叠。如果各项工作之间存在必须统一协调才能实现的共同结果，例如共享一套数据标准、共用一条交付窗口或共同满足一项监管要求，按项目集管理并编写章程是合适的。如果各项工作彼此独立、各自有独立的收益和交付节奏，按多项目清单分别管理更合适，强行套用项目集结构会增加治理成本。编写第一步时，建议把依赖关系和共享收益逐项写出来，由发起人确认后再进入后续条款。
章程评审时收益指标还没法定稿，可以先签署吗？
不建议在收益指标缺少口径的情况下签署。收益指标是后续阶段评审的对照依据，如果只写方向性表述，阶段关口复核时就无法判断进展。可行的做法是：先明确指标名称、统计口径、基线和目标值，基线数据暂时无法取得的，写明取数来源和补齐时间，并在章程中标注该指标的确认状态。评审时由发起人确认指标口径，治理机构确认评审节奏，待基线数据补齐后按变更规则更新章程版本。
章程签署后，范围和收益目标发生调整怎么处理？
按章程中约定的变更规则处理。范围新增、收益指标调整和阶段延期超过约定阈值时，提交治理机构审批，审批通过后修订章程并重新确认，保留旧版本备查。变更记录应写明变更内容、原因、审批人和生效时间。如果调整涉及项目集是否继续成立，例如共同收益已不存在或关键组件被移出，需要回到发起人层面重新确认，而非仅在项目集经理层面修改条款。
多角色共同起草章程时，如何避免版本混乱？
建议指定项目集经理为章程唯一维护人，其他角色以输入和评审意见的方式参与，不各自维护副本。起草阶段把收益指标、组成清单和角色表放在同一份文档中分章节维护，评审意见集中记录并关联到对应条款，修改后保留版本。定稿前由项目集经理逐项核对发起人的资源承诺和组件负责人的依赖输入是否到位，确认后再提交正式评审。这样每轮调整的原因和确认人都可追溯，阶段复核时可以直接对照历史版本判断变化。
