项目立项书和项目章程容易写重：目标、范围、预算在两份文件里各写一遍，措辞稍有出入就形成冲突。更清晰的做法是让两份文件分工——立项书回答“要不要做、值不值得投入”，章程回答“批准后怎么做、谁负责、按什么规则做”。本文按这一分工给出字段承接表、编写步骤、角色责任和检查清单，帮助你把已批准的立项结论转写为可执行的章程。
要点总览（TL;DR）
- 立项书回答“要不要做、值不值得投入”，章程回答“批准后怎么做、谁负责、按什么规则做”；立项书获批是章程编写的前提。
- 重叠字段遵循“结论只写一次”：目标、范围、预算在立项书中论证定稿，章程直接引用结论，只补充里程碑、角色授权、变更规则等执行约定。
- 编写按四步推进：整理已批准结论形成承接清单、补齐章程执行字段、与发起人和项目经理核对授权、评审定稿并归档。
- 审批权与编写权分离：项目经理对章程内容负责，发起人批准授权与变更规则，PMO核对两份文件在目标、范围、预算上的一致性。
- 定稿前逐项核对目标、范围、预算一致，章程不重复论证，授权与变更规则可执行，版本与生效时点清晰；目标或范围冲突、审批缺失属阻断项。
两份文件的分工：先论证，再授权
立项书服务于投入决策，读者是发起人、决策层和资源审批方。它要说明项目要解决什么问题、目标是什么、范围到哪里、需要多少预算和人力、有哪些关键假设和风险，最终给出“建议立项”或“不建议立项”的结论。章程服务于执行授权，读者是项目经理、项目团队和职能负责人。它承接立项结论，明确交付物、里程碑、角色授权、沟通节奏、变更规则和验收关闭条件，作为项目启动后团队共同遵守的基准。
先后顺序上，立项书获批是章程编写的前提。立项书未通过，章程没有可承接的结论；立项书有条件通过（例如缩减范围、分期投入），章程应按批准后的条件编写，并在版本说明中记录调整依据。两份文件的重叠字段遵循“结论只写一次”的原则：目标、范围、预算等结论在立项书中论证并定稿，章程直接引用该结论，不再重复论证过程，只补充执行层面的细化。
| 对比项 | 项目立项书 | 项目章程 |
|---|---|---|
| 回答的问题 | 要不要做、值不值得投入 | 批准后怎么做、谁负责、按什么规则做 |
| 核心内容 | 问题背景、目标、范围、投入估算、关键假设与风险、可行性结论 | 目标与交付物、里程碑、角色与授权、沟通汇报、变更与验收规则 |
| 主要审批人 | 发起人与决策层（或立项评审会） | 发起人批准授权，项目经理对内容负责 |
| 生效时点 | 立项评审通过、批复下达时 | 章程评审通过、正式发布时 |
| 后续用途 | 作为投入决策依据归档，供审计追溯 | 作为执行基准，变更需走章程规定的变更流程 |
从立项书到章程的字段承接表
字段承接分三类处理：直接承接的字段照搬结论；需细化的字段在结论基础上补充执行约定；章程新增的字段在立项书中没有对应内容，需要单独编写。下表给出常见字段的处理方式和责任人，组织可按自身模板增删。
| 字段 | 承接方式 | 章程中的写法要求 | 责任人 |
|---|---|---|---|
| 项目目标 | 直接承接 | 引用立项书批准的目标表述，可补充衡量口径，不改动目标本身 | 项目经理 |
| 范围边界 | 直接承接 | 列明包含项与不包含项，与立项书保持一致 | 项目经理 |
| 关键交付物 | 直接承接并细化 | 将立项书中的成果描述拆为可验收的交付物清单 | 项目经理与职能负责人 |
| 预算与资源结论 | 直接承接 | 写明批准额度与资源来源，不重新估算 | 发起人确认 |
| 里程碑与阶段划分 | 需细化 | 把立项书中的总体周期拆为阶段节点、交付物和评审点 | 项目经理 |
| 角色与授权 | 需细化 | 明确项目经理授权范围、各角色职责与决策权限 | 发起人与项目经理 |
| 沟通与汇报节奏 | 需细化 | 约定例会频率、汇报对象、升级路径 | 项目经理 |
| 变更审批规则 | 章程新增 | 规定变更提出、评估、审批的层级与触发条件 | 发起人批准 |
| 决策机制 | 章程新增 | 写明关键决策由谁拍板、争议如何裁决 | 发起人 |
| 验收与关闭条件 | 章程新增 | 定义验收标准、验收人和项目关闭的判定条件 | 项目经理与业务方 |
立项书中的假设与风险需要移交而非照抄。做法是在章程中设“假设与风险承接”一节：逐条列出立项书中的关键假设，标注当前是否仍成立；对已识别风险写明责任人和应对动作。立项阶段的风险描述偏重“是否影响立项决策”，章程中的风险条目偏重“执行期如何监控”，同一风险在两处的表述角度不同，但编号和内容应可对应。
编写步骤：从立项结论到章程定稿
以下四步按顺序执行，每步都有明确的输入、动作、输出和完成标志，便于项目经理独立操作，也便于PMO抽查。
步骤一：整理立项书已批准结论，形成承接清单
输入是获批的立项书及批复意见（含条件批准时的附加要求）。动作是逐项摘出目标、范围、交付物、预算、资源、假设与风险，填入承接清单，并标注每项在章程中的处理方式（直接承接、细化或移交）。输出是一份承接清单。完成标志是清单覆盖立项书全部结论字段，且经发起人确认无遗漏。
步骤二：补齐章程执行约定字段，标注新增内容
输入是承接清单和组织的章程模板。动作是填写里程碑、角色授权、沟通节奏、变更规则、决策机制、验收关闭条件等字段，对章程新增内容单独标注，便于评审时区分“承接结论”与“新增约定”。输出是章程初稿。完成标志是模板中所有必填字段均有内容，新增字段有明确标注。
步骤三：与发起人、项目经理核对授权范围
输入是章程初稿。动作是组织一次核对会，重点确认项目经理的授权边界（如预算调整权限、范围变更审批权限）、职能负责人的资源承诺是否与立项书一致。输出是核对记录和修订后的章程稿。完成标志是发起人对授权条款书面确认，职能负责人对资源与交付承诺无异议。
步骤四：评审定稿并归档，明确生效时点
输入是修订后的章程稿。动作是提交章程评审，评审通过后发布定稿，与立项书一并归档，并在章程首页注明版本号、生效日期和与立项书的对应关系。输出是正式发布的章程和归档记录。完成标志是章程完成审批签署，生效时点已通知项目团队，立项书与章程在归档目录中可相互检索。
在文档流转环节，如果团队使用ONES Wiki，可以把立项书与章程放在同一项目页面组下，页面组关联项目后，需求与文档互相对应；使用模板库可一键创建立项书、章程等文档，减少格式统一的工作量；文档实时同步并记录页面版本，章程修订后可随时查看历史版本与回滚，便于追溯每次变更的依据。
角色分工与各阶段交付物
两份文件的编写涉及四类角色，各自的责任集中在不同阶段。下表按角色列出职责与交付物，避免出现“都参与、都不负责”的情况。
| 角色 | 主要职责 | 关键交付物 | 参与阶段 |
|---|---|---|---|
| 发起人 | 提出立项需求，批准立项结论，批准章程中的授权与变更规则 | 立项批复、章程授权条款确认 | 立项评审、章程核对与定稿 |
| 项目经理 | 承接立项结论，编写章程执行部分，组织核对与评审 | 承接清单、章程初稿与定稿 | 步骤一至步骤四全程 |
| 职能负责人 | 确认资源投入与交付承诺，参与里程碑可行性确认 | 资源与交付承诺确认记录 | 步骤三核对、章程评审 |
| PMO或管理角色 | 核对两份文件的一致性，检查归档与版本记录 | 一致性核对意见、归档记录 | 步骤四评审与归档 |
分工的关键是审批权与编写权分离：项目经理对章程内容的完整性和可执行性负责，发起人对授权范围和变更规则拥有批准权，PMO不代替业务判断，只核对两份文件在目标、范围、预算上是否一致。规模较小的项目可由发起人兼任部分核对工作，但审批签署环节仍应保留独立记录。
示例：一个系统上线项目的衔接写法
以下示例为演示情景，用于说明转写方法，不代表真实项目数据。
立项书中的写法示例：“为解决订单处理依赖人工录入的问题，建议建设订单系统并完成上线。目标：上线后订单录入环节由人工改为系统自动接收，覆盖华东区域三个业务单元。范围：订单接收、状态跟踪、异常提醒三个模块；不包含财务结算对接。投入：开发与实施合计约若干人月，预算经评审批准。关键假设：现有接口文档完整可用；业务单元在试点期配合完成数据核对。”
章程中对应的写法示例：“项目目标：按立项书批准结论，完成订单系统三个模块建设并在华东区域三个业务单元上线，实现订单自动接收。交付物：订单接收模块、状态跟踪模块、异常提醒模块及上线切换方案。里程碑：需求确认完成、开发完成、试点上线、全量上线四个节点，各节点设评审点。角色授权：项目经理负责计划执行与日常协调，范围与预算变更须提交发起人审批；业务单元负责人确认试点数据核对结果。变更规则：影响上线时间超过约定天数的变更须经发起人批准。验收条件：三个业务单元连续运行达到约定周期且异常处理闭环。”
两处表述的一致点在于目标、范围和交付物完全对应；差异点在于立项书侧重说明“为什么值得投入”和假设条件，章程侧重“谁在什么时间做什么、按什么规则变更”。可迁移的规律是：立项书的每个结论在章程中都能找到落点，章程的每条执行约定都能回溯到立项结论或明确标注为新增约定。
完成检查：衔接是否到位
章程定稿前，按以下清单逐项核对。每项给出通过标准，任一项不通过即视为阻断，需修订后重新核对。
- 目标一致性：章程中的目标表述与立项书批准结论一致，未擅自增加或删减目标。通过标准为逐字比对无实质差异。
- 范围一致性：包含项与不包含项均与立项书对应，章程未扩大范围。通过标准为范围条目可一一对应。
- 预算与资源一致性：章程引用的预算额度与资源来源与立项批复一致。通过标准为数字和来源可追溯至批复文件。
- 只承接不重复论证：章程未重复可行性分析、投入测算等论证内容。通过标准为章程中不出现论证性段落。
- 授权可执行：项目经理授权范围、变更审批层级、决策人明确到角色。通过标准为每条授权都能对应到具体审批动作。
- 变更规则可执行：变更触发条件、提出方式、审批路径完整。通过标准为模拟一次范围变更能走通流程。
- 版本与生效时点清晰：章程标注版本号、生效日期及与立项书的对应关系。通过标准为归档目录中两份文件可相互检索。
- 阻断项排查：目标或范围在两份文件中存在冲突、章程缺少发起人审批签署，均属阻断项，须解决后方可发布。
检查通过后，将立项书、章程及核对记录一并归档，章程生效时点通知到项目团队和相关职能负责人，后续变更按章程规定的规则执行并保留版本记录。
常见问题
立项书有条件通过时，章程应该按原方案写还是按调整后的条件写？
按批准后的条件写。有条件通过通常意味着范围缩减、分期投入或补充前置条件，章程承接的是最终获批的结论，原方案不再作为编写依据。建议在章程的版本说明中记录调整依据和批复文号，便于后续追溯；如果条件涉及目标或范围的实质变化，需在章程定稿前与发起人再次确认表述。
立项书里的风险条目，章程是照抄还是重写？
移交而非照抄。立项书的风险描述服务于投入决策，关注“是否影响立项”；章程的风险条目服务于执行监控，关注“谁负责、如何跟踪、触发什么动作”。可行做法是在章程中设“假设与风险承接”一节，逐条对应立项书的编号，标注假设当前是否仍成立，并为每条风险指定责任人和应对动作。
项目执行中范围发生变更，应该改立项书还是改章程？
按章程规定的变更规则处理，通常修订章程并保留版本记录，立项书作为历史决策依据归档、不随之改写。若变更幅度超出章程授权范围（例如突破批准预算或改变项目目标），需提交发起人重新审批，必要时补充立项层面的决策记录。关键是变更路径在章程中事先写明，执行时按规则走，避免两份文件各自改动形成冲突。
小项目能否把立项书和章程合并成一份文件？
可以合并，但两部分内容仍需分开表述。合并时建议在同一文件中划分“立项论证”与“执行授权”两个部分，前者保留目标、范围、投入与可行性结论，后者写明里程碑、角色授权、变更与验收规则，并分别设置审批签署。合并的代价是后续变更时论证部分与执行部分容易混改，因此版本记录要更清晰。
用文档工具管理立项书和章程，需要注意什么？
重点是把两份文件的对应关系和版本记录管住。以 ONES Wiki 为例，页面组可关联项目，需求与文档互相对应；模板库可一键创建文档，减少格式统一的工作量；文档实时同步并记录页面版本，支持查看历史版本与回滚。落地时建议把立项书与章程放在同一项目页面组下，章程首页注明与立项书的对应关系和生效日期，变更后保留版本记录以便追溯。
