项目章程是项目的启动授权文件:说明为什么要做、做到什么程度、由谁负责,以及项目经理能调动哪些资源。它不靠篇幅说服人,而要让发起人和关键相关方对目标、边界、预算与成功标准作出明确决定。没有公司模板时,也可以先用一页结构把这些问题说明白。
把信息放到Boardmix协作白板上,可以在一次立项讨论中并列查看目标、时间线和职责,发现相互冲突的约定。下面沿用8个编写步骤,以“客服工单分流试点”为例填写章程;金额、周期和数量用于说明写法,应按实际估算替换。

1. 什么是项目章程
项目章程由项目发起人或发起组织正式批准,授权项目存在,并赋予项目经理在约定范围内使用组织资源的权限。项目经理可以组织起草,但不能用自己的签名代替发起人的授权。PMI关于项目发起人职责的说明也强调,发起人参与初始范围与章程,并承接超出项目经理权限的决策。
| 文件 | 主要回答 | 不要混写的内容 |
|---|---|---|
| 项目章程 | 为什么批准项目、谁负责、资源与权限边界是什么 | 不必穷尽每个开发任务和每天的排期 |
| 项目范围说明 | 具体交付什么、不交付什么、如何验收 | 不能只写“做好系统”而没有交付边界 |
| 项目管理计划 | 如何组织执行、跟踪、处理风险与变更 | 不能把未经授权的详细排期当成项目已获批准 |
章程提供高层约定,是后续规划的输入,不等于已经批准的全部范围、进度和成本基线。若立项时还有关键不确定性,写明假设、调查责任人和决策日期,比写一个无法解释的精确数字更有用。
2. 如何编写项目章程
可以按下列8步起草。每一步都要产生一个能被讨论和批准的结果,最后由发起人确认授权。下图先展示各部分的关系,具体填写方式在后面的段落中展开。
(1)选择项目名称
项目章程的命名要尽可能明确项目内容。比如“人力资源计划”或“软件更新”这样的项目名称就太过宽泛,即不能描述为什么要实施该项目,也不容易与其他项目章程区分开来,需要把内容具体一些才更容易理解,比如“新公司健康计划”或“软件更新以改善移动支付用户体验”这样的命名会更加合适。
客服工单案例可命名为“华东客服组工单分流试点”,比“客服系统升级”更清楚:本次只在一个客服组验证分流规则,不代表全公司客服体系都要改造。标题直接体现试点范围,能减少立项会上的误解。
(2)确定目标和项目规范
目标要说明项目希望改变什么,以及用什么证据判断是否达到。可以用SMART原则检查目标是否具体、可衡量、可实现、相关且有时限,但遵循SMART并不保证目标一定实现。把业务问题、成功标准和验收负责人一起写,避免只留下“提升客服效率”一句话。
例如:计划在第8周完成华东客服组试点,上线“售前咨询、订单售后、账户问题”三类工单的分流规则;客服负责人按事先确认的验收集核对分流和兜底路径。至于是否减少实际错派,应比较试点前后同口径的业务记录,不能把测试集通过率当作真实业务改善幅度。
(3)制定项目预算
项目的初期需要做出各项成本预算和资金来源,还需要列出执行计划所需的其他资源。
| 费用或资源 | 估算 | 审批与使用说明 |
|---|---|---|
| 规则配置与开发 | 36,000元 | 根据工作量估算,注明内部工时是否计入 |
| 测试及试点支持 | 10,000元 | 包含测试数据准备与试点问题排查 |
| 培训及操作材料 | 6,000元 | 按本次一个客服组的范围估算 |
| 风险预留 | 8,000元 | 启用前由发起人批准,不是默认可花完的经费 |
| 合计上限 | 60,000元 | 36,000+10,000+6,000+8,000;超出上限重新决策 |
如果开发由内部团队承担,还要列出可投入的人员和时间,例如一名后端工程师每周可投入几天。预算有钱但关键人员未承诺工时,项目仍可能无法启动。
(4)定义可交付成果
明确完成项目后将交付什么产品、服务或结果。由于项目章程非常灵活,我们可以在可交付成果中说明可以证明该项目中取得成功的重要信息,以此来确定是否完成目标以及在接下来的工作中将考核哪些指标。
| 交付物 | 验收标准 | 确认人 |
|---|---|---|
| 工单分类及分流规则 | 三类工单规则可配置;未匹配工单进入人工处理队列 | 客服负责人 |
| 权限与日志 | 只有授权人员能修改规则;修改记录包含操作者、时间和内容 | 系统负责人 |
| 验收记录 | 覆盖三类正常路径、未匹配路径和规则失效后的人工接管 | 测试负责人 |
| 培训与交接材料 | 值班人员能按材料处理未匹配工单和上报规则异常 | 客服主管 |
“系统上线”是一个状态,“工单走错队列时谁能接管”才是具体的交付责任。成功标准要包含正常情况和异常兜底。
(5)评估范围和风险
从启动时明确范围和主要风险,而不是一味缩小范围。试点内包括三类工单分流、人工兜底和日志;试点外包括全公司推广、历史工单迁移和智能质检。若后来有人要求把智能质检一并上线,就能据此评估变更,而不是默认为“顺手补一下”。
最关键的假设是现有工单接口能够提供所需分类信息。把“接口字段缺失”列为风险,系统负责人在第1周结束前完成字段核对;若不满足,则提交简化规则或延期两个选项给发起人决定。风险条目要有触发条件和应对责任人,不能只写“加强沟通”。
(6)时间表或里程碑
时间表和里程碑需表示何时完成项目,以及每个阶段需要完成多少任务。最重要的信息是开始日期和结束日期,还有其他更多的信息都可以在项目时间表明确。Boardmix的项目时间线(里程碑)模板可以帮助绘制时间线,突出工作的关键节点。
| 节点 | 完成条件 | 未达到时的决定 |
|---|---|---|
| 第1周:范围确认 | 工单字段可用,三类规则和试点人员确认 | 决定缩小范围、补字段或推迟启动 |
| 第3周:方案评审 | 客服与技术共同确认分流、人工兜底和日志 | 不通过则修正方案,不直接进入部署 |
| 第6周:测试完成 | 验收集执行完毕,阻断问题关闭 | 若仍有错派且无法接管,不进入试点 |
| 第8周:试点验收 | 试点记录、培训、交接和遗留问题清单齐备 | 发起人决定结束、延长试点或另行批准推广 |
里程碑写成果和批准条件;具体任务依赖可以在后续项目排期甘特图中展开。章程不需要把每天的工作都塞进时间线。
(7)列出项目相关人员名单
虽然项目章程是内部文件,但可能会与外部有合作,还需要向外部相关方进行报告,例如客户以及公司的其他项目经理或团队。完成项目相关人员分析并在项目章程中列出这些主要相关人,能更好地对受项目影响的人负责。
本案例中,客户服务负责人是发起人,试点客服人员是使用者,系统负责人提供接口与运维支持,信息安全负责人确认访问范围。对每个人写清“需要他提供什么、何时确认”,而不只列一个通讯录。若工单数据受访问权限限制,应在准备测试材料时就落实授权与脱敏要求。
(8)明确团队角色和职责
列出参与此项目的人员及其角色。许多项目章程示例只是列出了个人的头衔或所在团队,但如果这些信息不能充分定义他们的职责,就需要参考一份更具体的文档,其中包含职责分解等更详细的内容。Boardmix的团队成员职责模板可以帮助明确分工,提高工作效率。
| 角色 | 可以决定什么 | 必须升级的情形 |
|---|---|---|
| 发起人/客服负责人 | 批准章程、预算、试点验收及重大变更 | 涉及其他部门资源时协调对应负责人 |
| 项目经理 | 在已批范围和资源内组织任务、跟踪风险和汇总变更 | 增加交付物、超过预算或影响关键日期时提交决策 |
| 系统负责人 | 确认接口方案、部署条件和故障接管安排 | 现有平台无法满足分流或权限要求 |
| 测试与客服代表 | 按标准执行验收,记录问题与使用反馈 | 阻断缺陷未解决、人工兜底无法执行 |
签核区至少包含章程版本、批准日期、发起人和项目经理。内部评审通过不等于正式批准;只有获得约定的授权,才把章程状态标为已批准。
3.制定项目章程技巧
知道了项目章程的定义和组成部分,还要记住一些小技巧,以避免不必要的麻烦,并增强项目章程说服力。
(1)使项目章程可视化
把章程分成目标、边界、预算、里程碑、职责几个清楚区域。Boardmix画布可以用不同区域放置这些内容;讨论时先检查各部分是否一致。例如目标写“全公司覆盖”,预算与人员却只够一个客服组,说明范围还没有对齐,排版再漂亮也不能通过。
项目计划表
(2)及时与相关人员共享
在完成项目章程并开始项目后,需要与所有相关人员共享项目章程,有时可能需要打印出章程,以便展示。
分享章程前先确认访问对象和权限,让相关方能找到同一份已批准版本。讨论意见与已批准的约定要分开;后续提出新增需求时,记录变更内容、原因、影响和批准结果,不直接覆盖原来的授权边界。
章程写完后,让发起人回答四个问题:为何现在值得投入?什么情况下算完成?项目经理能决定哪些事?出现超出权限的冲突由谁拍板?如果答案仍不一致,先解决分歧再启动。需要整理材料时,可进入Boardmix工作台,把这份试点章程的目标、预算和时间线排在同一画布上共同讨论。






