项目章程写起来最难的往往不是格式，而是每一栏到底该填到什么程度。本文给出一份已填好的完整范例，用虚构的“客户门户改版”项目演示项目名称、目标与成功标准、范围边界、交付物与里程碑、角色授权、预算资源、风险假设和审批签署各栏怎么写，并逐项说明取舍理由和改写方法。示例中的数值、周期与角色均为演示，不代表任何真实客户或实测结果。
要点总览（TL;DR）
- 一份可套用的项目章程应覆盖项目名称与背景、目标与成功标准、范围包含与排除、交付物与里程碑、角色与授权、预算资源、风险假设、审批签署八类字段。
- 示例用虚构的“客户门户改版”项目演示：目标写成可验证结果，成功标准对应功能验收、业务效果与使用落地三类动作，范围同时写明排除项与变更路径。
- 授权层级按金额与影响面分层，风险与假设写到可挂责任人跟踪的颗粒度，章程控制在单页可读长度。
- 改写到自己的项目时按项目类型调整详略，用“给动作加对象、给结果加判断依据、给条件加责任人”把模糊表述改成可核对表述。
- 示例的数值、周期与签署安排均为演示，组织治理流程差异、多项目准入评估和章程的持续维护需按实际情况处理。
这份示例要解决什么问题
这份示例面向需要起草项目章程、又缺少可对照样本的读者：项目经理、业务发起人、参与立项评审的部门负责人。它提供一份填满的章程骨架，读者可以逐栏对照，把自己项目的信息替换进去，再按组织流程送审。
示例设定如下前提：一家虚构的中型企业，已有官网和客服系统，客户查询订单、提交售后申请需要电话或邮件往返；公司决定启动“客户门户改版”项目，由信息技术部牵头，客服与市场部门参与。项目周期、预算、人员数量均为演示数值，用于展示写法，不作为估算参考。
读者可以从示例中获得三样东西：一份字段齐全、前后自洽的章程成品；每个字段的填写思路与颗粒度说明；一套把示例改写成自己项目版本的规律。示例不涉及多个项目之间的准入比较与优先级排序，那属于项目组合管理的另一层工作。
完整示例：客户门户改版项目章程
以下为填写完成的章程正文，按常见单页章程的字段顺序排列。示例中的组织名称、人名、金额与日期均为虚构。
| 字段 | 示例填写内容 |
|---|---|
| 项目名称 | 客户门户改版项目（Customer Portal Revamp，简称 CPR） |
| 发起人 | 分管客户服务的副总经理 李某 |
| 项目经理 | 信息技术部 王某 |
| 章程版本与日期 | V1.0，2025 年 3 月 10 日 |
| 项目背景与立项理由 | 现有客户查询订单、提交售后申请依赖电话与邮件，客服每月处理重复咨询约 1200 次（演示数据）。客户希望自助查询进度，公司希望降低重复咨询量并沉淀服务记录。经管理层会议决定立项。 |
| 项目目标 | 上线一个客户可自助登录的门户，支持订单查询、售后申请提交与进度跟踪三类核心操作，并在上线后三个月内承接原电话与邮件渠道中重复咨询的主要部分。 |
| 成功标准 | 1）三类核心操作全部可用，通过验收测试；2）上线后首个完整季度，重复咨询工单量较基线下降，具体降幅在立项后由发起人与客服部门确认并写入基线文档；3）客服与市场部门关键用户完成培训并签署使用确认。 |
| 范围：包含 | 客户登录与身份校验、订单查询页、售后申请表单与工单流转、进度查询页、客服后台的工单查看、上线培训与操作手册。 |
| 范围：排除 | 不改造现有客服系统核心工单引擎；不包含移动端原生应用；不包含在线支付与退款功能；不包含多语言版本。以上如需变更，走变更审批。 |
| 主要交付物 | 需求说明与原型、门户前端与接口、客服后台查看页、验收测试报告、培训材料与操作手册、上线切换方案。 |
| 里程碑 | 需求与原型确认（4 月中旬）；开发完成并进入测试（6 月中旬）；验收测试通过（7 月中旬）；上线与培训完成（7 月底）；上线后首季度复盘（10 月底）。 |
| 角色与职责 | 发起人：批准目标、预算与范围变更；项目经理：统筹计划、进度与风险，组织评审；客服部门代表：提供业务规则、参与验收；市场部门代表：提供客户侧文案与培训支持；开发负责人：技术方案与交付质量。 |
| 授权层级 | 预算内、范围不变的事项由项目经理决定；涉及范围增减、里程碑整体后移超过两周、预算调整的，由发起人审批；跨部门资源冲突由发起人协调。 |
| 预算与资源 | 项目预算 60 万元（演示数值），含开发人力、测试与培训；投入人力为开发 3 人、测试 1 人、业务代表各 1 人（兼职）。 |
| 主要风险 | 1）客服业务规则未及时确认，影响需求冻结；2）与现有客服系统接口联调延期；3）客户对新入口接受度低于预期，影响使用量目标。 |
| 假设与依赖 | 假设现有客服系统提供可用的查询接口；依赖客服部门在 4 月上旬前完成业务规则确认；依赖运维团队在上线前完成环境准备。 |
| 审批与签署 | 发起人签署批准目标与预算；项目经理签署确认计划可行性；客服与市场部门代表签署确认业务规则与培训安排。三方签署后章程生效，变更按授权层级处理。 |
这份章程控制在单页可读的长度，字段之间相互对应：目标里的三类核心操作，在范围包含项、交付物和成功标准中都能找到落点；排除项写明了变更路径，避免后续争议无处可依。
逐项解释：每个字段为什么这样写
目标写成可验证的结果
示例中的目标没有写“提升客户体验”这类口号，而是落到“三类核心操作可用”和“承接重复咨询的主要部分”两个可核对的方向。目标回答的是项目完成后业务上会发生什么变化，颗粒度到能被验收和复盘引用即可，不必写成完整的需求清单。
成功标准与验收口径对应
成功标准的三条分别对应三类验收动作：功能验收看测试报告，业务效果看季度工单量对比，使用落地看培训确认。示例中降幅没有写死具体百分比，而是注明在立项后由发起人与客服部门确认基线，这是演示写法的一种取舍——当基线数据尚未统计清楚时，把确认责任人和确认时点写进章程，比编一个数字更可靠。
范围同时写包含与排除
只写“做什么”的章程，评审时最容易被追问“那这个算不算”。示例把移动端原生应用、在线支付、多语言明确列入排除项，并注明变更走审批。排除项的价值在于把边界争议提前到立项阶段解决，而不是在开发中途反复确认。
授权层级对应审批与变更决定
授权层级要回答“谁能在什么条件下拍板”。示例按金额与影响面分了两层：预算内、范围不变由项目经理决定；范围、里程碑、预算变化由发起人审批。层级写得越具体，变更发生时越不需要临时找人。
风险与假设写到可跟踪
示例中的每条风险都指向一个具体环节——业务规则确认、接口联调、客户接受度，后续可以直接挂责任人定期跟踪。假设与依赖单独列出，是因为它们一旦不成立，目标和计划都要调整，需要在评审时被看见。
从示例到自己的章程：可迁移的写法
示例的结构可以整体借用，但各栏详略要按项目类型调整。内部系统改造类项目，范围与接口依赖写细；面向外部客户的产品项目，成功标准与客户接受度写细；合规驱动类项目，审批与验收依据写细。字段一个不少，篇幅向风险最高的地方倾斜。
把模糊表述改写为可核对表述，可以用三个动作：给动作加对象，给结果加判断依据，给条件加责任人。例如“加强客户沟通”改为“客服部门在需求确认阶段每周向关键客户同步一次进展”；“尽快上线”改为“7 月底完成上线与培训”。改写后每一句都能在评审时被追问、被验证。
章程定稿后要与后续文档衔接：目标与成功标准进入项目计划作为验收依据，范围包含项拆解为需求清单，里程碑成为进度基线，风险与假设进入风险登记。章程本身也需要维护，范围或目标发生批准过的变更时，同步更新章程版本并记录变更原因。
评审与签署环节建议按“先分发、再评审、后签署”组织：章程草案提前发给发起人与相关部门代表，评审会上集中处理范围与授权分歧，会后按审批层级完成签署。章程定稿后的评审记录、签署确认和后续变更，可以在项目协作工具中承载，例如在 ONES 中把章程作为项目文档归档，将评审意见、签署状态和变更申请关联到同一项目下，便于后续追溯。具体功能以组织实际使用的版本为准。
适用边界：示例不能直接照搬的地方
不同组织的治理与审批流程差异很大。有的组织要求章程经项目管理办公室统一评审，有的把预算审批放在财务系统单独走流程，有的对跨部门项目设有专门的立项委员会。示例中的签署安排只是演示一种常见做法，读者应按本组织的制度调整审批人与签署顺序。
示例针对单个项目的章程。大型组织在启动多个项目时，通常先有项目提案与准入评估，再为通过评估的项目编写章程；组合层面的优先级排序、资源分配不在单项目章程的范围内，需要另行处理。
示例中的预算金额、周期、人力数量和咨询次数均为演示数值，用于展示写法与颗粒度，不能作为同类项目的估算依据。真实估算应结合本组织的成本口径、历史数据和资源情况。
章程也不是一次定稿就束之高阁的文件。目标调整、范围增减、里程碑整体移动、预算变化，都应通过授权层级审批后更新章程版本。把章程当作活文档维护，它才能在项目推进中持续发挥作用；只在立项时写一次、之后不再回看的章程，很快会与项目实际脱节。
常见问题
章程里的成功标准还没法量化，可以先空着吗？
不建议空着，也不建议编一个数字。示例的做法是把确认责任人和确认时点写进章程：功能类标准直接对应验收测试，业务效果类标准注明“在立项后由发起人与客服部门确认基线并写入基线文档”。这样章程在签署时就是完整的，量化口径在基线确定后补齐，后续复盘也有据可依。
项目进行中范围要增加，章程需要重写吗？
不需要重写，但需要按章程里约定的授权层级走变更审批，然后更新章程版本并记录变更原因。示例把范围增减、里程碑整体后移超过两周、预算调整划归发起人审批，就是为了让这类变更发生时知道找谁拍板。更新后的章程版本与变更记录一并归档，后续验收和复盘都以最新版本为准。
小项目也要写这么全的章程吗？
字段可以保留，篇幅可以压缩。判断依据是风险集中在哪里：内部系统改造类项目把范围与接口依赖写细，面向外部客户的项目把成功标准与客户接受度写细，合规驱动类项目把审批与验收依据写细。即便只有一页，目标、范围包含与排除、授权层级这几栏也建议保留，它们是后续争议最常出现的地方。
章程评审会上最常见的分歧是什么，怎么提前处理？
常见分歧集中在范围边界和授权层级两处：某功能算不算在项目内，某类决定由谁拍板。示例的处理方式是在章程草案中同时写包含项与排除项，并注明排除项如需变更走审批；授权层级按金额与影响面写明分层。评审前把草案提前发给发起人与相关部门代表，会上集中处理这两类分歧，比逐条过字段更有效率。
章程签署之后放在哪里，怎么保证后续还能查到？
签署后的章程应与评审记录、签署确认、后续变更申请放在同一处归档，避免散落在邮件和个人目录里。可以在项目协作工具中把章程作为项目文档归档，将评审意见、签署状态和变更申请关联到同一项目下，便于追溯。具体承载方式以组织实际使用的工具与版本为准。
