项目章程模板通常分为五组栏目：项目基本信息、目标与成功标准、范围与交付物、角色与职责、约束与审批留痕。必填项集中在能决定“是否启动、由谁负责、以什么标准验收”的字段上，如项目名称、发起人、项目经理、项目目标、主要交付物、验收标准、里程碑、预算口径、审批人与审批日期。本文提供一份可直接复制的空白表格模板，并逐项说明填写口径、必填与选填的划分方法，以及审批留痕字段的设计和完整填写示例。
要点总览（TL;DR）
- 项目章程模板通常分五组栏目：项目基本信息、目标与成功标准、范围与交付物、角色与职责、约束与审批留痕。
- 必填项集中在决定“是否启动、由谁负责、以什么标准验收”的字段：项目名称、发起人、项目经理、项目目标、成功标准、项目范围、主要交付物、验收标准、关键里程碑、预算口径、审批人与审批日期。
- 审批留痕建议包含审批人、审批意见、审批日期、版本号和变更记录，有条件同意须写明附加条件，章程修订后追加变更记录并升版。
- 裁剪模板时只删减选填字段，必填项和审批留痕字段保持不变；周期短、投入小的内部项目可用轻量版，跨部门交付用标准版。
- 模板本身也应版本化管理，每半年结合立项评审记录复盘一次，字段增删在变更记录中说明原因。
可复制空白项目章程模板
下表为空白模板本体，可直接复制到文档或表格工具中填写。“填写提示”列用于提醒填表人该字段应写到什么程度，正式定稿时可删除该列。字段行按五组栏目排列，组内顺序即建议的填写顺序。
| 栏目组 | 字段 | 填写内容 | 填写提示 |
|---|---|---|---|
| 一、项目基本信息 | 项目名称 | 使用组织内可识别的正式名称，避免代号与简称混用 | |
| 项目编号 | 按组织编码规则填写，无规则可留空 | ||
| 发起人 | 填写对项目结果负责、有权批准启动的人 | ||
| 项目经理 | 填写实际负责推进的人，写明姓名与岗位 | ||
| 立项日期 | 填写章程获批或计划获批的日期 | ||
| 项目类型 | 如新产品、系统建设、流程优化、内部改进等 | ||
| 二、目标与成功标准 | 项目背景 | 用三到五句说明为什么现在要做这件事 | |
| 项目目标 | 写清目标对象、期望变化与衡量方式 | ||
| 成功标准 | 列出可核验的验收条件，逐条编号 | ||
| 关键里程碑 | 填写里程碑名称与计划完成时间 | ||
| 三、范围与交付物 | 项目范围 | 写明包含的工作内容与覆盖的业务对象 | |
| 范围外事项 | 写明本期明确不做的内容，防止后期争议 | ||
| 主要交付物 | 逐项列出交付物名称、形式与接收方 | ||
| 验收标准 | 与成功标准对应，写明验收方式与验收人 | ||
| 四、角色与职责 | 项目发起人职责 | 写明发起人在决策、资源与验收中的具体职责 | |
| 项目经理职责 | 写明计划、协调、汇报与变更管理的职责 | ||
| 核心成员及分工 | 按角色列出成员与承担的工作包 | ||
| 审批权限 | 写明哪些事项需谁批准，如范围变更、预算调整 | ||
| 关键相关方 | 列出受影响或需配合的部门与外部单位 | ||
| 五、约束与审批留痕 | 预算口径 | 写明预算金额、币种与包含的费用范围 | |
| 时间约束 | 写明硬性截止时间及其来源 | ||
| 资源与合规约束 | 写明人力、设备、资质或监管方面的限制 | ||
| 主要风险与假设 | 列出已识别的风险与成立前提，各写一句应对思路 | ||
| 审批人与审批意见 | 按审批顺序列出审批人，逐人记录意见 | ||
| 审批日期、版本号、变更记录 | 记录审批时间、章程版本及每次修改的内容与原因 |
复制使用时，建议保留“栏目组”列作为分组标识，便于后续按组裁剪；如果组织已有立项表单，可将本表字段映射到现有表单，避免同一信息重复填报。
各栏目字段说明与填写口径
模板能否发挥作用，取决于字段是否被填成可判断的信息。以下按五组栏目说明每个字段记录什么、写到什么颗粒度，重点是让审批人能据此判断项目是否值得启动。
基本信息：让项目可被识别和追溯
项目名称应使用组织内通用的正式名称，同一项目在章程、计划、汇报中保持同一叫法。项目编号按组织编码规则填写，用于后续与预算、合同、工作项对应。发起人填写对项目结果负责且有权批准启动的人，项目经理填写实际推进的人，两者可以是同一人，但职责描述要分开。立项日期填写章程获批日期，便于后续统计立项周期。
目标与成功标准：写到可衡量的程度
项目背景回答“为什么现在做”，用三到五句交代业务问题、触发事件和不做的后果。项目目标写成“对象＋变化＋衡量方式”的结构，例如“将订单审核平均时长从两个工作日缩短到一个工作日”，避免“提升效率”“优化体验”这类无法验收的表述。成功标准逐条编号，每条对应一个可核验的条件，并注明核验方式。关键里程碑填写名称与计划完成时间，数量控制在三到六个，覆盖启动、关键交付和验收节点。
范围与交付物：把边界写清楚
项目范围写明本期覆盖的业务对象、系统模块或工作内容；范围外事项单独列出，把容易产生争议的内容提前排除。主要交付物逐项写明名称、形式（文档、系统功能、实物等）和接收方。验收标准与成功标准对应，写明由谁验收、依据什么材料验收、验收不通过如何处理。范围与验收标准是后续变更管理的基准，填写时应具体到可对照检查。
角色与职责：写清授权关系
发起人职责写明其在资源协调、重大决策和最终验收中的具体动作；项目经理职责写明计划编制、进度跟踪、汇报频率和变更发起等职责。核心成员按角色列出，每人对应明确的工作包，避免只写部门名称。审批权限要写清哪些事项需要谁批准，例如范围变更、预算追加、里程碑调整，这是章程区别于普通项目介绍的关键字段。关键相关方列出受影响或需配合的部门与外部单位，并注明配合事项。
约束、假设与风险：记录判断前提
预算口径写明金额、币种和包含的费用范围，避免把人力成本、采购成本混在一个数字里。时间约束写明硬性截止时间及其来源，如监管要求、合同约定或市场窗口。资源与合规约束写明人力、设备、资质方面的限制。主要风险与假设各列三到五条，每条风险写一句应对思路，每条假设写明若不成立会影响什么。这部分内容随项目推进更新，章程阶段记录的是启动时的判断。
必填与选填的划分
必填项的判定原则是：缺少该字段，审批人无法判断项目是否应该启动，或项目启动后无法确定责任人和验收依据。按此原则，必填项集中在基本信息、目标、范围、角色和审批留痕五处，其余字段随项目复杂度补充。
| 类别 | 字段 | 判定理由 |
|---|---|---|
| 必填 | 项目名称、发起人、项目经理、立项日期 | 确定项目身份与责任人，缺失则无法启动 |
| 必填 | 项目目标、成功标准 | 决定项目是否值得做、做成什么样算完成 |
| 必填 | 项目范围、主要交付物、验收标准 | 界定交付边界与验收依据 |
| 必填 | 关键里程碑 | 提供进度基准，支撑后续跟踪 |
| 必填 | 预算口径、审批人、审批意见、审批日期 | 明确资源投入与审批结论，形成留痕 |
| 选填 | 项目编号、项目类型 | 组织有编码或分类规则时启用 |
| 选填 | 范围外事项 | 跨部门项目、易产生范围争议时建议填写 |
| 选填 | 核心成员及分工、关键相关方 | 成员较多或涉及外部单位时填写 |
| 选填 | 时间约束、资源与合规约束 | 存在硬性截止时间或监管要求时必填 |
| 选填 | 主要风险与假设、版本号、变更记录 | 复杂项目填写；章程发生修订时版本号与变更记录转为必填 |
裁剪时按项目规模调整：周期短、参与人少、投入有限的内部改进项目，可保留必填项加项目背景，选填项按需补充；跨部门、涉及外部交付或预算较大的项目，建议启用全部栏目，并补充范围外事项和风险假设。裁剪的判断依据是项目的不确定性和责任跨度，而非项目名称。无论怎样裁剪，审批人与审批日期都应保留，否则章程无法证明启动决定由谁做出。
审批留痕字段与完整填写示例
审批留痕解决两个问题：章程由谁批准、批准的是哪一版内容。建议设置以下字段，并与空白模板第五组栏目对应。
| 字段 | 记录内容 | 填写要求 |
|---|---|---|
| 审批人 | 姓名、岗位 | 按审批顺序逐行列出，发起人通常为最终审批人 |
| 审批意见 | 同意、有条件同意或不同意，附具体意见 | 有条件同意须写明附加条件 |
| 审批日期 | 每位审批人签署日期 | 与审批意见同行记录 |
| 版本号 | 如 V1.0、V1.1 | 首次获批为 V1.0，实质性修改后升版 |
| 变更记录 | 变更内容、原因、提出人、生效日期 | 每次修订追加一行，不覆盖历史记录 |
以下为一份已填示例，字段与空白模板逐项对应，演示情景中的项目与人员信息为虚构。
| 栏目组 | 字段 | 示例填写内容 |
|---|---|---|
| 一、项目基本信息 | 项目名称 | 客户订单审核流程优化项目 |
| 项目编号 | PRJ-2025-018 | |
| 发起人 | 运营中心总监 张明 | |
| 项目经理 | 运营管理部 李华 | |
| 立项日期 | 2025年3月10日 | |
| 项目类型 | 流程优化 | |
| 二、目标与成功标准 | 项目背景 | 订单量增长后，人工审核环节积压，客户投诉集中在发货延迟，需要在销售旺季前完成流程调整。 |
| 项目目标 | 将订单审核平均时长从两个工作日缩短到一个工作日以内，审核一次通过率提升到90%以上。 | |
| 成功标准 | 1. 连续四周审核平均时长不超过一个工作日；2. 一次通过率达到90%；3. 审核规则文档完成评审并发布。 | |
| 关键里程碑 | 规则梳理完成（4月15日）；系统配置上线（5月20日）；试运行评估（6月10日）；正式切换（6月30日） | |
| 三、范围与交付物 | 项目范围 | 覆盖零售订单的自动审核规则配置、人工复核环节调整及审核人员培训。 |
| 范围外事项 | 本期不调整退款审核流程，不改造订单系统底层架构。 | |
| 主要交付物 | 审核规则文档、系统配置方案、培训材料、试运行评估报告 | |
| 验收标准 | 由运营中心总监依据试运行四周数据验收，数据口径以系统报表为准。 | |
| 四、角色与职责 | 项目发起人职责 | 批准立项与预算，协调跨部门资源，主持最终验收。 |
| 项目经理职责 | 编制计划、跟踪里程碑、每周汇报进度、发起变更申请。 | |
| 核心成员及分工 | 系统配置：信息部王强；规则梳理：运营部赵敏；培训：运营部陈静 | |
| 审批权限 | 范围变更与超过原预算10%的追加由发起人批准；里程碑调整由项目经理提出、发起人确认。 | |
| 关键相关方 | 客服部（投诉数据支持）、财务部（费用结算配合） | |
| 五、约束与审批留痕 | 预算口径 | 人民币8万元，含系统配置服务费与培训费用，不含内部人力成本。 |
| 时间约束 | 须在6月30日前完成切换，与销售旺季备货计划衔接。 | |
| 资源与合规约束 | 信息部配置人力每周不超过两天；审核规则调整需符合公司内控要求。 | |
| 主要风险与假设 | 风险：规则配置延期影响试运行，应对为提前锁定配置窗口；假设：历史订单数据可用于规则验证。 | |
| 审批人与审批意见 | 信息部负责人 周涛：同意，配置人力按每周两天安排；运营中心总监 张明：同意，按计划推进 | |
| 审批日期、版本号、变更记录 | 审批日期：2025年3月10日；版本号：V1.0；变更记录：无 |
示例中每个字段都能在空白模板中找到对应行，审批意见与审批权限相互呼应。实际使用时，若章程在获批后发生范围或里程碑调整，应在变更记录中追加一行，写明变更内容、原因和生效日期，并同步升级版本号。
模板的调整与维护方法
模板需要随组织立项流程变化而调整，调整的依据是实际填写中反复出现的问题，而非一次性设计。以下规则可作为维护起点。
按项目类型裁剪栏目
先按项目类型建立两到三个版本：轻量版保留必填项与项目背景，适用于周期短、投入小的内部改进；标准版启用全部五组栏目，适用于跨部门交付；增强版在标准版基础上增加风险清单、相关方清单和合规检查项，适用于涉及外部合同或监管要求的项目。裁剪时只删减选填字段，必填项和审批留痕字段保持不变。
字段增删的判断依据
出现以下情况时考虑增加字段：同一信息在多个项目的评审中被反复追问；某类项目因缺少某项记录导致验收争议；组织流程新增了必须留痕的环节。出现以下情况时考虑合并或删除字段：连续多个项目该字段填写内容雷同且无人使用；字段与组织其他表单重复。每次增删只调整少量字段，并在变更记录中说明原因，避免模板频繁变动影响填写习惯。
版本号与变更记录维护
模板本身也应有版本号。字段增删、填写口径变化属于实质性修改，升主版本号；仅调整提示文字或排版，升次版本号。每次修改在模板末尾的变更记录表中追加一行，记录修改内容、原因、提出人和生效日期，历史版本保留可查，便于对照旧项目章程的填写口径。
| 版本号 | 修改内容 | 修改原因 | 提出人 | 生效日期 |
|---|---|---|---|---|
| V1.0 | 首次发布五组栏目模板 | 统一立项章程格式 | 项目管理办公室 | 2025年1月1日 |
| V1.1 | 增加“范围外事项”字段 | 跨部门项目范围争议较多 | 项目管理办公室 | 2025年4月1日 |
| V2.0 | 审批留痕增加版本号与变更记录 | 章程修订后无法追溯批准版本 | 项目管理办公室 | 2025年7月1日 |
模板评审与更新节奏
建议每半年结合立项评审记录做一次模板复盘，检查哪些字段长期空白、哪些字段在评审中被反复追问，据此提出调整。组织流程、审批权限或合规要求发生变化时，随时启动专项修订。修订后的模板先在小范围项目中试用，收集填写反馈后再正式发布，避免一次性改动过大。
章程定稿后的审批流转、版本留存和与项目工作的关联，可以在项目管理工具中承载。例如 ONES Wiki 提供页面模板库，可一键创建制式化文档，适合把定稿后的章程模板固化为统一格式；文档记录所有页面版本并支持查看与回滚，便于保留各版章程；页面组可关联项目，使章程文档与项目工作保持对应。具体模板配置与权限范围以组织实际开通的版本为准。
常见问题
项目章程模板里的“项目目标”和“成功标准”有什么区别，能不能只填一个？
两者记录的内容不同，建议都填。项目目标描述期望达成的变化和衡量方式，回答“这个项目要改变什么”；成功标准是逐条可核验的验收条件，回答“做到什么程度算完成”。只填目标，审批人难以判断项目结束时是否达成；只填成功标准，又缺少对项目意图的整体说明。填写时让成功标准与目标对应，例如目标写“将订单审核平均时长缩短到一个工作日以内”，成功标准就写成可核验的条目，并注明核验方式和数据来源。
小型内部项目也要填完整的五组栏目吗？
可以裁剪。判断依据是项目的不确定性和责任跨度，周期短、参与人少、投入有限的内部改进项目，保留必填项加项目背景即可，选填字段按需补充。跨部门、涉及外部交付或预算较大的项目，建议启用全部栏目，并补充范围外事项和风险假设。无论怎样裁剪，审批人与审批日期都应保留，否则章程无法证明启动决定由谁做出。
章程获批后范围发生调整，审批留痕应该怎么记？
在变更记录中追加一行，写明变更内容、原因、提出人和生效日期，不覆盖历史记录，同时升级版本号。实质性修改（如范围、里程碑、预算口径变化）升主版本号，仅调整文字表述或排版升次版本号。如果调整涉及审批权限内的事项，例如范围变更或预算追加，应按章程中写明的审批权限重新取得对应审批人的意见，并记录新的审批日期。
章程定稿后，审批流转和版本留存放在哪里管理比较合适？
章程定稿后通常需要在组织内流转审批并保留各版本记录。使用文档协作工具承载时，可以关注三点：是否支持用统一模板创建章程文档，避免每次从零排版；是否记录页面版本并支持查看与回滚，便于对照旧版章程；是否能与项目工作关联，让章程文档和项目进度对应。以 ONES Wiki 为例，其页面模板库可一键创建制式化文档，文档记录所有页面版本并支持查看与回滚，页面组可关联项目。具体模板配置与权限范围以组织实际开通的版本为准。
模板用了一段时间后，怎么判断该增加或删除字段？
依据实际填写中反复出现的问题来判断。同一信息在多个项目的评审中被反复追问、某类项目因缺少某项记录导致验收争议、组织流程新增了必须留痕的环节，这些情况可以考虑增加字段。连续多个项目某字段填写内容雷同且无人使用、字段与组织其他表单重复，可以考虑合并或删除。每次只调整少量字段，并在模板变更记录中说明原因，避免频繁变动影响填写习惯。
