项目章程模板通常需要覆盖九类字段：项目基本信息、目标与成功标准、范围边界、交付物、里程碑、角色与授权、预算与资源、主要风险与假设、审批签署。填写时建议先确定发起人与项目经理，再写可验证的目标和验收口径，最后补齐范围、里程碑和审批。本文提供一张可直接复制的空白表格、逐字段填写说明、必填与选填规则，并用一份完整示例演示各字段之间的对应关系。
要点总览（TL;DR）
- 项目章程模板覆盖九类字段：基本信息、目标与成功标准、范围、交付物与里程碑、角色与授权、预算与资源、风险与假设、审批签署，可直接复制空白表使用。
- 填写顺序建议先定发起人与项目经理，再写可验证的目标和验收口径，最后补齐范围、里程碑和审批，避免把章程写成任务清单。
- 启动评审前必须齐备的字段是项目名称、发起人、项目经理、目标、成功标准、范围边界、主要里程碑和审批人；预算明细、资源清单、风险登记、假设与依赖可按项目规模裁剪。
- 字段暂时无法确定时标注“待定”并写明补齐责任人和时间，便于评审区分尚未确定与被遗漏。
- 模板需按项目类型调整字段深度并维护版本号与变更记录，章程批准后与立项评审、项目计划、风险登记册衔接，避免批准后被搁置。
可复制空白项目章程模板
下表为空白项目章程模板，可直接复制到 Word、在线文档或表格工具中填写。字段编号用于后文说明与示例引用，复制后建议保留编号列，便于评审时逐项核对。
| 编号 | 字段 | 填写内容 |
|---|---|---|
| 一、基本信息 | ||
| 1.1 | 项目名称 | |
| 1.2 | 项目编号 | |
| 1.3 | 发起人 | |
| 1.4 | 项目经理 | |
| 1.5 | 文档版本 | |
| 1.6 | 编制日期 | |
| 二、目标与成功标准 | ||
| 2.1 | 项目背景与问题 | |
| 2.2 | 项目目标 | |
| 2.3 | 成功标准 | |
| 2.4 | 验收口径 | |
| 三、范围 | ||
| 3.1 | 范围包含项 | |
| 3.2 | 范围不包含项 | |
| 四、交付物与里程碑 | ||
| 4.1 | 主要交付物 | |
| 4.2 | 里程碑 | |
| 五、角色与授权 | ||
| 5.1 | 关键角色与职责 | |
| 5.2 | 决策权限 | |
| 5.3 | 审批人 | |
| 六、预算与资源 | ||
| 6.1 | 预算量级与来源 | |
| 6.2 | 资源需求 | |
| 七、风险与假设 | ||
| 7.1 | 主要风险 | |
| 7.2 | 假设与依赖 | |
| 八、审批签署 | ||
| 8.1 | 发起人签署 | |
| 8.2 | 项目经理签署 | |
| 8.3 | 审批日期 | |
复制时注意两点：一是表格只承载章程层面的决策信息，任务分解、排期明细应放到项目计划中；二是每个空白格都要填写，暂时无法确定的写“待定”并注明责任人和补齐时间，留空容易被评审误认为遗漏。
字段说明：每个字段填什么、依据什么
字段说明与上表编号一一对应。填写口径的核心原则是：章程回答“为什么做、做到什么程度、谁来决定”，依据来自业务需求、发起人授权和可获得的资源信息，而非个人推测。
| 编号 | 填写口径 | 常见写法与注意事项 |
|---|---|---|
| 1.1 项目名称 | 用业务对象加动作命名，能与其他项目区分 | 如“客户门户改版项目”；避免“XX优化”这类无法识别对象的名称 |
| 1.2 项目编号 | 沿用组织现有编码规则 | 无统一规则时可留待定，由项目管理办公室分配 |
| 1.3 发起人 | 填写为项目提供资源和决策支持的人 | 写姓名与职务，发起人通常也是审批人之一 |
| 1.4 项目经理 | 填写对交付结果负责的执行负责人 | 写姓名与所属部门，便于跨部门对接 |
| 1.5 文档版本 | 从 V0.1 起草版开始，批准后升为 V1.0 | 每次实质性修改递增版本号 |
| 1.6 编制日期 | 填写当前版本定稿日期 | 与版本号配套，便于追溯 |
| 2.1 项目背景与问题 | 说明触发项目的业务问题或机会 | 两三句话讲清现状与差距，不展开解决方案 |
| 2.2 项目目标 | 写成可验证的结果，包含对象、变化和衡量方式 | 如“将订单处理时长从2天缩短至4小时”；避免“提升效率”这类无法验证的表述 |
| 2.3 成功标准 | 列出项目结束时判断成功的条件 | 与目标对应，可包含业务指标、交付质量和上线范围 |
| 2.4 验收口径 | 写明由谁、依据什么材料、在什么节点确认 | 如“由业务负责人在上线后两周依据验收清单确认” |
| 3.1 范围包含项 | 列出本项目要交付的业务能力或工作内容 | 按模块或对象列举，控制在可读范围内 |
| 3.2 范围不包含项 | 明确本期不做的内容，防止范围蔓延 | 把容易混淆的相邻需求写进来，如“本期不含移动端适配” |
| 4.1 主要交付物 | 列出可移交的成果物 | 如系统功能、文档、培训材料；写清形态而非过程 |
| 4.2 里程碑 | 写日期加可交付成果 | 如“6月30日完成核心流程上线”；不写“开发阶段”这类活动清单 |
| 5.1 关键角色与职责 | 列出业务负责人、技术负责人等关键角色 | 每个角色写一句职责，避免只写头衔 |
| 5.2 决策权限 | 写明哪些事项由谁拍板 | 如范围变更、预算追加分别由谁审批 |
| 5.3 审批人 | 填写章程的批准人 | 通常为发起人或其授权人，可多人会签 |
| 6.1 预算量级与来源 | 写预算区间和资金来源 | 如“人力投入约X人月，费用由年度IT预算列支”；精确金额未定时写量级 |
| 6.2 资源需求 | 列出关键人力、系统或外部服务需求 | 写清来源部门或供应商类型，不写具体人员排期 |
| 7.1 主要风险 | 列出影响目标达成的关键风险 | 每条风险附一句应对方向，详细登记可放风险清单 |
| 7.2 假设与依赖 | 写明项目成立所依赖的前提 | 如“依赖上游系统接口按期开放” |
| 8.1—8.3 审批签署 | 填写签署人、签署日期 | 电子审批可记录审批人与时间，纸质签署留签字栏 |
填写顺序建议按“1.3发起人→1.4项目经理→2.2目标→2.3成功标准→3范围→4里程碑→8审批”推进。先定人再定目标，能避免目标写成项目经理单方面的愿望；先定范围再定里程碑，能减少后期返工。
必填与选填：哪些字段不能空
启动评审时，以下字段必须齐备，缺失会直接影响评审能否通过：项目名称、发起人、项目经理、项目目标、成功标准、范围包含与不包含项、主要里程碑、审批人。这些字段共同回答“做什么、做到什么程度、谁负责、谁批准”，是章程成立的最低条件。
可按项目情况裁剪的字段包括：预算明细、资源清单、风险登记、假设与依赖。小项目可以把预算写成量级、把风险合并为一段说明；大项目或跨部门项目则建议拆细预算科目、逐条登记风险并明确责任人。
| 字段类别 | 字段 | 裁剪原则 |
|---|---|---|
| 必填 | 项目名称、发起人、项目经理、目标、成功标准、范围边界、主要里程碑、审批人 | 任何项目启动评审前必须填写完整 |
| 选填 | 预算明细、资源清单、风险登记、假设与依赖 | 小项目可写量级或合并说明；大项目需拆细并明确责任人 |
| 可合并 | 交付物与里程碑 | 小项目可将交付物直接写入里程碑行，减少重复 |
字段暂时无法确定时，处理方式是标注“待定”，同时写明补齐责任人和补齐时间，例如“预算明细待定，由财务接口人于评审后一周内补充”。这样评审时能区分“尚未确定”和“被遗漏”，也便于后续跟踪。
填写示例：一个完整项目章程样例
以下为演示情景，用于说明字段之间的对应关系，不代表真实客户案例。
| 编号 | 字段 | 示例内容 |
|---|---|---|
| 1.1 | 项目名称 | 客户自助服务门户建设项目 |
| 1.2 | 项目编号 | PRJ-2025-018 |
| 1.3 | 发起人 | 张明，客户服务部总监 |
| 1.4 | 项目经理 | 李华，信息技术部 |
| 1.5 | 文档版本 | V1.0 |
| 1.6 | 编制日期 | 2025年3月10日 |
| 2.1 | 项目背景与问题 | 客户咨询中约六成是订单状态、发票下载等重复问题，人工客服占用大量工时，响应时长偏长 |
| 2.2 | 项目目标 | 上线自助服务门户，覆盖订单查询、发票下载、工单提交三类高频场景，使重复咨询量在门户上线三个月后下降40% |
| 2.3 | 成功标准 | 三类场景全部上线并通过验收；重复咨询量下降达到目标；客服团队完成操作培训 |
| 2.4 | 验收口径 | 由客户服务部依据验收清单在上线后第四周确认，数据以客服系统统计为准 |
| 3.1 | 范围包含项 | 订单查询、发票下载、工单提交三个功能模块；与现有客服系统的数据对接；客服人员培训 |
| 3.2 | 范围不包含项 | 本期不含移动端App、不含智能客服机器人、不含海外站点 |
| 4.1 | 主要交付物 | 门户系统（三个模块）、接口对接文档、验收清单、培训材料 |
| 4.2 | 里程碑 | 5月15日完成需求确认与原型评审；7月31日完成三个模块开发与联调；9月15日完成上线与培训 |
| 5.1 | 关键角色与职责 | 发起人负责资源协调与最终验收；项目经理负责计划与交付；客服部业务代表负责需求确认；技术负责人负责架构与接口 |
| 5.2 | 决策权限 | 范围变更由发起人审批；预算追加由发起人与财务共同审批；技术方案由技术负责人确认 |
| 5.3 | 审批人 | 张明（发起人）、信息技术部负责人 |
| 6.1 | 预算量级与来源 | 人力投入约12人月，费用由年度数字化预算列支，明细待财务确认 |
| 6.2 | 资源需求 | 开发3人、测试1人由信息技术部调配；客服业务代表2人由客户服务部指派 |
| 7.1 | 主要风险 | 客服系统接口开放延迟，影响联调进度，应对方式为提前两周启动接口对接；业务代表投入不足，应对方式为在章程中明确投入比例 |
| 7.2 | 假设与依赖 | 假设现有客服系统可在6月前提供数据接口；依赖信息安全团队完成上线前安全评估 |
| 8.1 | 发起人签署 | 张明，2025年3月12日 |
| 8.2 | 项目经理签署 | 李华，2025年3月12日 |
| 8.3 | 审批日期 | 2025年3月14日 |
从示例可以看出字段之间的对应关系：2.2目标中的“三类高频场景”对应3.1范围包含项；2.3成功标准中的“重复咨询量下降40%”对应2.4验收口径中的数据来源；4.2里程碑的每个日期都挂着一个可交付成果，而非“开发阶段”这类活动描述；7.1风险中的接口延迟与7.2假设中的接口开放时间相互呼应。填写时保持这种对应关系，评审时就能快速判断章程是否自洽。
模板的调整与维护方法
模板需要按项目类型调整字段深度，而不是每次重写。判断依据主要有三条：项目是否跨部门、是否涉及外部供应商、预算与合规要求是否严格。跨部门或涉及外部供应商的项目，应保留并细化角色授权、风险与依赖字段；研发内部小项目可以合并交付物与里程碑，把风险压缩为一段说明；受合规约束的项目则需在审批签署区增加合规或安全审批人。
模板本身要有版本管理。建议在模板页眉标注模板版本号（如“项目章程模板 V2.1”）和生效日期，并维护一份变更记录，写明改了什么字段、为什么改、从哪个项目开始适用。章程文档批准后，触发变更的常见条件包括：范围增减、里程碑整体推迟超过约定阈值、预算超出批准量级、发起人或项目经理更换。出现这些情况时，按章程5.2中约定的决策权限走变更审批，批准后更新章程版本号，而不是在原文档上直接覆盖。
章程批准后要与后续文档衔接：立项评审记录引用章程版本号作为评审依据；项目计划中的阶段划分与章程里程碑对齐；风险登记册承接章程7.1中的风险条目并持续更新。这样章程不会在批准后被搁置，而是成为后续计划的基准。
在协作工具中管理章程时，可以把章程作为项目文档存放，并与项目工作项建立关联，使文档版本与项目进展保持同步。以 ONES 为例，ONES Wiki 支持页面组关联项目、需求与文档互相对应，文档实时同步并记录所有页面版本，支持随时查看与回滚；同时提供页面模板库，可一键创建制式化文档模板，并支持为不同角色配置读写权限。把章程模板放入模板库、把每个项目的章程作为关联项目的页面维护，能让字段编号、版本记录和审批信息集中在一处，减少多份副本各自修改的情况。具体模板配置方式和版本能力以组织实际使用的产品版本为准。
常见问题
项目章程和项目计划有什么区别，哪些内容不该写进章程？
章程回答“为什么做、做到什么程度、谁来决定”，是项目启动阶段的授权文件；项目计划回答“怎么做、谁在什么时候做什么”，是执行阶段的安排。任务分解、详细排期、人员逐日投入这类内容应放到项目计划中，章程只保留里程碑日期加可交付成果。把活动清单写进章程，会让评审难以判断项目边界，也会让后续计划失去调整空间。
小项目也要填满整张章程模板吗？
不必逐格填满，但必填字段不能空。项目名称、发起人、项目经理、目标、成功标准、范围边界、主要里程碑和审批人是启动评审的最低条件。小项目可以把预算写成量级、把风险合并为一段说明、把交付物直接写入里程碑行；跨部门或涉及外部供应商的项目则建议拆细角色授权、预算科目和风险条目。裁剪的是字段深度，不是决策信息本身。
章程批准后范围发生变化，应该改章程还是改计划？
先看变更是否触及章程中的决策信息。范围增减、里程碑整体推迟超过约定阈值、预算超出批准量级、发起人或项目经理更换，都属于章程变更的触发条件，应按章程中约定的决策权限走审批，批准后更新章程版本号。若只是执行层面的任务调整，在项目计划中处理即可。判断标准是这次变化是否需要重新获得授权。
章程里的目标和成功标准怎么写才不算空话？
目标写成包含对象、变化和衡量方式的结果，例如“将订单处理时长从2天缩短至4小时”，而不是“提升处理效率”。成功标准与目标逐条对应，可以包含业务指标、交付质量和上线范围。验收口径再进一步写明由谁、依据什么材料、在什么节点确认，例如“由业务负责人在上线后两周依据验收清单确认，数据以客服系统统计为准”。三层写清楚，评审时才能判断目标是否可验证。
在协作工具里管理章程模板，需要注意什么？
重点是把模板、单个项目的章程和审批记录放在同一处，避免多份副本各自修改。以 ONES 为例，ONES Wiki 提供页面模板库，可一键创建制式化文档模板；页面组可关联项目，需求与文档互相对应；文档实时同步并记录所有页面版本，支持随时查看与回滚；还支持为不同角色配置读写权限。把章程模板放入模板库、把每个项目的章程作为关联项目的页面维护，字段编号和版本记录就能集中管理。具体模板配置方式和版本能力以组织实际使用的产品版本为准。
