项目立项如何做好项目背景？项目经理制度设计与操作步骤

我把过去五年经手评审的立项材料做过一次回收复盘：从 137 份立项文档里，按”业务动因是否具体、现状是否有证据、差距是否量化、约束是否写明、不作为后果是否可推演”五个维度打分（满分 10 分），能拿到 7 分以上的只有 29 份，占比 21%。这 29 个项目里，按期交付的有 24 个；而背景得分低于 4 分的 58 个项目里，按期交付的只有 16 个。样本不大，也不构成严格因果，但它足够说明一件事：项目背景不是立项文档的开篇套话，它是整个项目治理链条上最早、也最便宜的一次风险拦截点。

这篇文章我会把”项目背景怎么写”和”项目经理制度怎么设计”放在一起讲，因为在我实际参与的组织里，这两件事从来是同一件事，背景写不好，往往不是因为写的人不会写，而是因为制度里没人对”写得好不好”负责。

一、先给结论：项目背景不是开篇套话，而是一份可被反驳的决策论证

很多人把项目背景理解成”交代一下为什么要做这个项目”，于是写出来的东西长这样：随着公司业务快速发展，现有系统已无法满足需求，为提升管理效率、支撑战略落地，特启动本项目。这段话的问题不是错，而是它无法被反驳，因此也无法被验证。一份不能被反驳的背景，等于没有为决策提供任何信息增量。

1. 背景的本质是”立项理由的可验证表达”

我习惯把项目背景定义为一句话：它要回答”如果不做这个项目，组织会在什么时间、以什么方式、付出什么代价”。注意这里的主语是组织，不是某个部门，也不是某位领导。主语一旦错位，后面的目标、范围、验收标准都会跟着歪。

这个定义有个好处：它天然要求你给出时间、方式和代价三个要素。凡是不含这三个要素的背景描述，都可以先判定为”不合格初稿”，不需要再讨论文笔和排版。

2. 三个硬标准：可证伪、可量化、可追溯

我在内部评审时用三个标准快速筛背景质量，任何一个不达标，立项材料直接退回，不进入评审会议程。

• 可证伪：背景中的关键论断，必须存在一个能让它被推翻的证据形式。比如”现有流程平均审批耗时 4.2 个工作日”，这是可证伪的；”流程效率低下”，不可证伪。
• 可量化：痛点必须带基线值。没有基线的痛点，后续无法验收，也无法证明项目真的解决了问题。
• 可追溯：每个数字都要能指回一个来源，系统报表、访谈记录、工单抽样、财务口径，写清采集时间和样本量。

这三条听起来像常识，但真正落到文档里，我在评审中看到的达标率不到三成。原因很简单：写背景的人通常是项目经理或业务对接人，他们没有采集数据的权限和预算，于是只能用形容词填空。

3. 项目经理制度必须先于背景文档设计，而不是反过来

这是一个我坚持了很多年的反常识判断：先设计制度，再设计文档模板。绝大多数组织的顺序是反的，先搞一套漂亮的立项模板，然后要求大家填，填了两年发现还是写不好。

因为模板只能约束”格式”，制度才约束”责任”。如果制度里没有规定”谁必须提供现状数据””谁必须对背景中的数字签字确认””背景失真后谁承担后果”，那么模板上的那几行空，最终一定会被最省事的写法填满。

二、真实场景：我评审过的立项背景都长什么样

下面两个场景是我实际参与过的，细节做了脱敏处理，但结构和数字保留了原貌。它们几乎代表了中大型组织里最常见的两类立项。

1. 场景 A：120 人研发团队要替换用了 6 年的研发管理平台

背景初稿的核心论点是：”现有某项目管理平台功能老旧、体验差、无法支撑敏捷转型。”我第一次看到这份材料时提了一个问题：你说的”无法支撑”，能不能用三个具体场景描述出来？对方答不上来。

后来我们花了 9 天做了一次现状采样，得出的东西完全不一样：跨项目需求复用率只有 11%，因为需求条目散在 40 多个项目里没有统一字段；版本发布前的缺陷回归平均要占用 3.5 人日/迭代，因为缺陷与代码提交没有自动关联；管理层要看跨团队进度，需要 2 名 PMO 每周手工汇总约 6 小时。这三条一写进去，背景的说服力立刻不一样了，而且每一条都可以在替换后复测。

这个项目最终选择了支持私有化部署、能与代码仓库和 CI 深度打通的研发管理平台，并且在立项文档里直接写明了”替换后需求复用率目标 ≥35%、缺陷回归人工耗时目标 ≤1.5 人日/迭代”作为验收前提。

2. 场景 B：集团层面要建”统一项目管理平台”

这份背景初稿写得比场景 A 还漂亮，通篇是”打通数据孤岛、实现集团一体化管控、提升战略执行力”。但我在评审会上只问了三个问题：现在有几个孤岛、每个孤岛的数据量多大、不打通的具体损失是什么？全场沉默了大约 20 秒。

这类立项最危险的地方在于：它的背景描述越大，越容易通过；越容易通过，越容易在实施半年后变成无人认领的烂尾工程。这个项目后来被拆成了三个子立项，第一个子立项只做”集团项目主数据统一”，背景里明确写了 7 个业务系统的项目编码规则差异和由此产生的每月约 120 条重复录入。

3. 我的样本观察：背景质量与交付结果的相关性

回到开头的 137 份样本。我又做了一次拆分，把”背景得分”和”交付阶段的重大变更次数（指影响里程碑或预算的变更）”做了交叉，结果如下表。需要说明的是，这是我自己经手项目的样本观察，样本量有限，只能作为经验参考，不是行业基准。

这张表里最值得注意的不是按期交付率的差距，而是返工轮次。背景写得差的团队，往往在立项阶段就要来回改三四轮，而这些返工消耗的是最贵的一批人的时间，业务负责人、技术负责人、财务和 PMO。换句话说，背景写不好，成本在项目启动之前就已经开始产生了。

三、拆解七个高频误区

误区这一节我按”出现频次 × 破坏力”排序，前三个几乎每个组织都中招，后四个是进阶问题。

1. 误区一：把”领导要求”当成项目背景

这是最普遍也最致命的一个。“领导要求”是立项的触发条件，不是立项的背景。触发条件回答”为什么现在提”，背景回答”为什么值得做”。

我在评审时会把这两者明确分开写：触发事件（如管理层会议决议、监管新规发布、竞品上线）单独一行表明；业务动因单独一段展开。这样做还有一个隐性好处，当提出要求的领导调岗后，项目不会因为”人走了”而自动停摆，因为它有独立的业务理由支撑。

2. 误区二：把痛点清单当成背景

很多人写背景时列了七八条痛点，看起来很充分。但痛点清单只回答了”哪里不舒服”，没有回答”这些不舒服值多少钱、优先级怎么排”。

我通常要求把痛点清单转成一张”痛点，影响，量化，优先级”四列表。没有量化列，痛点就无法排序；无法排序，资源分配就只能靠嗓门大小决定。

3. 误区三：背景、目标、范围三段混写

这三者的边界其实很清楚：背景是”为什么”，目标是”做到什么程度”，范围是”做哪些、不做哪些”。混写的直接后果是验收时扯皮，因为目标里的量化指标被写进了背景段落，验收时对方可以说”那只是背景描述，不是承诺”。

我的做法是在文档结构上强制分离，甚至用不同的字体和分隔线把它们隔开。结构上的物理隔离，比口头强调有效得多。

4. 误区四：只写”我们缺什么”，不写”不做会怎样”

这是我认为最被低估的一条。多数背景通篇在讲”我们要什么”，但决策者真正在做的是资源取舍，在十个项目里选三个。不写”不作为后果”的背景，在资源竞争中天然处于劣势。

不作为后果要尽量具体：合规项目写处罚金额和整改期限；业务系统写每月损失的人天和错失的窗口期；技术债项目写故障概率和单次故障的平均恢复时长。

5. 误区五：背景写完就冻结，不做版本迭代

背景应该是活的。我在一些团队推行”背景半年复检”机制：如果项目周期超过 6 个月，必须在里程碑评审时复核背景中的关键假设是否仍然成立，变了就更新版本并记录变更原因。

这条在执行时经常被质疑”太麻烦”。但现实是，一个跑了两年的项目，如果背景还停留在两年前的假设上，那么后续所有决策都在漂移。

6. 误区六：没有作者署名和确认人

我要求背景部分必须有明确的撰写人和至少两位确认人（通常是业务负责人和技术负责人），且确认动作在系统里留痕。没有署名的背景，本质上是”组织的集体幻觉”，出问题时无人可追。

7. 误区七：用形容词代替证据

这一条是前六条的表征。”显著提升””大幅降低””有效支撑””全面提升”，这些词在立项文档里出现超过 3 次，我就基本可以判断这份背景没有做过数据采集。

我的经验是：一份合格的背景里，形容词与数字的比例最好不要超过 1:5。写完之后可以用查找功能统计一下，这个自检动作只要 30 秒。

四、专业判断逻辑：项目背景的五层结构

讲了这么多误区，得给一个可落地的东西。我把项目背景归纳成五层结构，按顺序写，写完就是一个完整论证。

1. 第一层：业务动因（为什么是现在）

这一层要回答两个问题：业务上发生了什么变化，以及这个变化为什么在此刻构成行动压力。写法上建议采用”外部变化 + 内部响应缺口”的对照结构。

比如：外部变化是客户验收周期从季度缩短到月度；内部响应缺口是当前质检流程的排期粒度仍以周为单位，导致每月约有 3-5 批次交付延期风险。两句话，动因就立住了。

2. 第二层：现状证据（现在到底是什么样）

这是最需要下功夫的一层。我要求所有现状描述都必须回答”数据从哪来、什么时候采的、样本多大”。常见的证据来源有四类：系统操作日志与报表、工单抽样、结构化访谈记录、财务与人力口径数据。

经验上，一次 5-9 天的现状采样，通常能把背景的说服力提升一个量级。这笔投入相对项目总预算几乎可以忽略，但收益极高。

3. 第三层：差距量化（差多少，值不值得补）

差距量化要把现状和目标之间的鸿沟折算成可比较的量纲。我常用三类量纲：时间（人天、小时）、金钱（成本、损失、机会成本）、风险（故障率、合规概率、违约敞口）。

关键在于量纲要统一，否则无法和别的项目比较。如果 A 项目说”能省 2000 人天”，B 项目说”能降低 40% 风险”，决策者根本无法取舍。

4. 第四层：约束条件（哪些边界不能碰）

约束条件经常被漏写，但它是后续方案设计的天花板。至少应覆盖：预算上限、人力可用量、时间窗口、合规与数据安全要求、必须兼容的存量系统。

我见过不少项目在方案阶段被推倒重来，原因就是背景里没写”数据不能出境”或”必须在 Q3 前上线”，导致技术选型做了两个月才发现方向不可行。

5. 第五层：不作为的后果（不做会怎样）

这一层是优先级论证的核心。写法上建议给出”短期后果 + 中期后果 + 长期后果”三段，并且尽量带上时间节点。

比如：3 个月内会因质检延期导致约 2 家客户进入观察名单；12 个月内质量问题导致的返工成本预计上升 15%-20%；24 个月内可能失去某类业务的市场准入资格。

五、项目经理制度设计：谁写、谁审、谁批、谁背

结构讲清楚了，接下来是制度。我常说一句话：背景质量不是写作能力问题，是责任分配问题。下面这套设计我前后在四个组织里做过变体和验证，核心逻辑是一致的。

1. 三个不可合并的角色

我坚持把立项环节的角色拆成三个，并且不允许由同一人兼任其中任意两个。

• 动因提出人：通常是业务负责人，负责说清”为什么现在要做”和”不做会怎样”。这个角色必须由能对业务结果负责的人担任。
• 背景撰写人：通常是项目经理或 PMO，负责把动因转成结构化的五层背景，并采集现状证据。这个角色对”文档质量”负责。
• 证据确认人：通常是数据归属部门负责人或技术负责人，负责确认背景中引用的数据口径和真实性。这个角色对”数据可信度”负责。

三者合并会怎样？我在一家公司见过 PMO 一个人把三个角色全包了，结果背景里的数据是”合理估算”的，立项通过后三个月被发现现状数据高估了约 40%，整个项目的收益测算全部失效。这不是能力问题，是制度设计问题。

2. 立项评审委员会的构成与议事规则

评审委员会不用搞得很庞大，我推荐 5-7 人的常设规模，且必须包含一个”唱反调”的固定席位，通常是财务或风控代表，职责就是质疑背景中的数据假设。

议事规则上，我建议明确三条：一是背景部分单独评审并单独表决，不通过不进入方案讨论；二是评审意见必须落到”退回修改条款”，不能只说”再完善一下”；三是评审记录留档，后续若背景假设被证伪，可回溯当时的判断依据。

3. 项目经理的职权边界：能调什么、不能调什么

制度设计最容易忽略的是项目经理在立项阶段的权限。我给的建议是明确列出”三调三不调”。

• 可调：背景文档的结构表述、现状数据的采集方式、差距量化的算法口径。
• 不可调：业务动因的实质内容、量化目标的最终数值、约束条件中的预算与合规红线。

这条边界看似苛刻，但它解决了一个很现实的问题：项目经理不能为了让立项通过而放松目标或模糊约束，因为那样做的代价会在交付阶段由他自己承担。

4. 配套的激励与问责设计

没有激励与问责的制度是空转的。我在实践中用过两条比较有效的措施。

第一条是”背景准确度回溯”：项目结项时，用当初背景中的量化基线做一次复测，偏差在 ±15% 以内的撰写人和确认人计入正向记录；偏差超过 40% 的，要求在复盘会上说明原因。注意这里不是惩罚，而是把”背景写得准”变成一件被看见的事。

第二条是”立项质量与项目考核解耦”：不把”立项通过率”作为 PMO 的考核指标。这个指标一旦存在，PMO 的最优策略就是让所有项目都通过，背景质量必然下降。

六、操作步骤：写出一份能过评审的项目背景（8 步 SOP）

下面这套 SOP 我用了很多次，从 20 人团队到上千人组织都做过删减版使用。完整版是 8 步，实际耗时取决于现状采样的深度，一般在 5-15 个工作日。

1. 步骤 1-3：动因澄清与范围预判

1. 写触发事件一句话：用不超过 40 个字写清”是什么事件让这件事被提上日程”，标注日期和来源。
2. 做一次 60 分钟动因访谈：访谈对象是业务负责人，只问三个问题，你觉得现在最痛的三件事是什么？如果不做会怎样？你愿意为此投入什么？全程录音，事后逐句整理。
3. 划定初步边界：用”本立项包含/不包含”两栏写清范围预判。这一步不需要精确，但要防止背景写到最后变成了一个大杂烩。

2. 步骤 4-5：现状采样与差距量化

1. 设计现状采样方案：明确采样指标、数据来源、时间窗口、样本量。我通常要求至少 3 类不同来源的数据，避免单一来源的偏差。
2. 做差距量化并统一量纲：把所有差距折算成人天、金额、风险概率三类中的一种。这一步最好和技术负责人一起做，因为很多技术上不可行的量化会让后面的方案设计崩塌。

3. 步骤 6-8：约束梳理、后果论证与评审准备

1. 逐项梳理约束条件：按预算、人力、时间、合规、存量兼容五类逐项确认，每项都要有明确的数字或规则，不允许写”尽量””原则上”。
2. 写不作为后果的三段论证：短期（3 个月内）、中期（12 个月内）、长期（24 个月内），每段都带时间节点和量级。
3. 准备一页纸摘要：把五层结构压缩成一页，用于评审会预读。这一页纸的质量直接决定评审会是在讨论实质问题还是在补基础信息。

下面是我在实际项目中使用的一个背景文档骨架。它不是模板，而是一个字段清单，你可以把它直接改造成系统里的立项表单。

项目背景（五层结构骨架）
[第一层·业务动因]

触发事件： 事件描述 + 日期 + 来源

外部变化： 市场/客户/监管/技术的变化

内部响应缺口： 当前组织响应不了的具体环节

动因确认人： 姓名 + 角色 + 确认日期

[第二层·现状证据]

证据 1：指标名 | 当前值 | 数据来源 | 采样窗口 | 样本量

证据 2：……

证据 3：……

证据确认人： 姓名 + 角色 + 确认日期

[第三层·差距量化]

目标值： 与证据一一对应

折算量纲： 人天 / 金额 / 风险概率

年化收益或止损： 数值 + 计算口径

量化口径确认人： 姓名 + 角色

[第四层·约束条件]

预算上限： X 万元（含人力折算口径）

可用人力： X 人 × Y 月，来源部门

时间窗口： … 之前必须上线，原因

合规与安全： 数据等级 / 部署要求 / 审计要求

存量兼容： 必须兼容的系统与版本

[第五层·不作为后果]

短期（3 个月内）： 事件 + 量级

中期（12 个月内）： 事件 + 量级

长期（24 个月内）： 事件 + 量级

[元信息]

背景版本： v1.0

撰写人 / 确认人 / 批准人

下次复检时间： 建议不超过 6 个月

七、工具落地：把背景结构固化进研发管理平台

制度和 SOP 都齐了，还有一个现实问题：靠 Word 模板和邮件流转，这套东西通常撑不过半年。原因不难理解，模板不会提醒你”现状证据还没确认”，邮件不会阻止你在数据未确认时进入评审。

1. 为什么”文档模板”救不了背景质量

模板是静态的，而立项是一个有状态、有角色、有门禁的过程。凡是需要”人记得去做”的环节，在组织规模超过 50 人之后，失效率都会快速上升。我在一家 400 人的公司做过统计：使用 Word 模板时，五层结构中”证据确认人签字”这一项的完整率只有 52%；迁移到系统字段强制填写后，完整率升到 94%。

差别不在人的意识，而在约束方式。模板只能靠自觉，系统可以靠流程。

2. 用字段和门禁把五层结构变成流程约束

我的具体做法是把五层结构拆成系统中的结构化字段，而不是一个大文本框。比如”现状证据”做成可增删的子表单，每一行强制包含指标名、当前值、数据来源、采样窗口、样本量、确认人六个字段，任一项为空则无法提交。

再配合两个门禁：一是”证据确认人未签署则无法流转到评审会”；二是”背景版本变更超过阈值（如目标值变动超过 20%）必须重新触发评审”。这两条一旦写进流程，背景就从一个文档变成了一个受控对象。

3. PingCode 在中大型组织里的实际用法

我参与过的一次平台替换，客户是一家 600 人规模的制造企业研发中心，最终选择的是 PingCode。选择理由和背景文档里写的三条现状证据直接对应：跨项目需求复用率低、缺陷与代码提交脱节、跨团队进度依赖手工汇总。

PingCode 主要服务中大型企业及 100 人以上组织，这点在他们身上的体现是：需求、迭代、测试、缺陷、代码仓库可以放在同一条数据链上，背景里写的”需求复用率 ≥35%”这类指标，后续可以直接用平台内的字段统计复测，不需要再手工拉数。

另外两个实际影响到立项决策的点：一是支持私有化部署，这家企业的研发数据有明确的本地化要求，这一点在背景的”约束条件”层里是硬性红线；二是支持从 Jira 平滑迁移，他们原有的 Jira 上有约 3 年的历史数据，迁移方案的可信度直接决定了立项能否通过，因为背景里有一句”历史缺陷数据必须可追溯至 2021 年”。在国内研发管理平台里，PingCode 是国产替代场景下被提及频率较高的选项之一。

需要说清楚的是，工具不会自动让背景变好，它只是让”背景质量”这件事变得可观测、可门禁、可复测。如果制度层面没有明确谁写、谁审、谁背，再好的平台也只能存一堆结构化垃圾。

4. 从通用工具迁移时的注意点

如果你们现在用的是通用协作工具（在线表格 + 即时通讯 + 文档），迁移到专业研发管理平台时，有三件事必须在立项背景里提前写清楚，否则迁移本身会成为新的风险源。

• 历史数据口径：旧工具里的状态字段和字段含义往往没有统一定义，迁移前必须先做一次字段映射表，写清哪些字段废弃、哪些合并、哪些需要人工清洗。
• 迁移期间的双轨成本：迁移期通常会有一段双轨运行，这部分人力成本要计入背景的约束条件，否则会挤占原有交付资源。
• 复测基线：迁移前必须采集一次现状指标作为基线，否则迁移完成后无法证明是否达成了背景中承诺的改进目标。

八、不同情况下的行动建议

制度和技术都要匹配组织规模，下面按四种典型情况给出建议。这些建议是我在实操中反复调整后的版本，不是理论推演。

1. 20 人以下团队：把五层压成一张卡片

这个规模不需要完整制度和评审委员会，但”可证伪、可量化、可追溯”三条不能丢。我的建议是把五层结构压缩成一张不超过 300 字的立项卡片，粘贴在项目看板顶部，任何人随时可以看一眼。

重点保留两样：一是现状证据（哪怕只有 2 条），二是不作为后果（哪怕只有一句话）。这两样是防止团队做无用功的最低成本手段。

2. 20-100 人团队：建立简版三权分立

这个规模开始出现跨部门协作，需要明确角色。建议设立动因提出人和背景撰写人两个角色（证据确认可由撰写人兼任但需技术负责人签字），评审采用 3 人小组，每月固定一次评审窗口。

背景文档控制在 2-4 页，五层结构齐全即可，不追求细节完备。这个阶段最关键的是把”背景质量回溯”机制建立起来，让写得好的人被看见。

3. 100 人以上或多业务线组织：制度 + 平台双轨

到这个规模，靠人盯已经不可能。必须同时做三件事：完整的三角色制度、分级的评审授权（比如预算 50 万以下由部门评，以上由集团评）、以及把五层结构固化到专业研发管理平台里做结构化字段。

如果你所在组织正在做国产化替换，或者正在从 Jira 迁移，我会建议把”立项背景的结构化承载能力”作为选型评估项之一。以 PingCode 为例，它面向 100 人以上组织中大型企业的定位、私有化部署能力和 Jira 平滑迁移支持，恰好对应了这个阶段最常出现的三类约束。但请记住，平台是放大器，制度才是信号源。

4. 强监管行业：把合规证据前置到背景层

金融、医疗、汽车电子这类行业，立项背景里必须提前写清监管条款编号、审计要求、数据处理等级和留存期限。这些内容不是方案阶段才考虑的，它们本身就是背景的一部分，甚至是决定项目是否成立的前提。

我的经验是，强监管行业的背景文档中，”约束条件层”的篇幅通常应占到全文的 25%-35%，远高于一般行业的 10%-15%。

九、不同情况下的取舍

制度设计到最后，都是取舍。下面四组取舍我经常被问到，也都有自己的答案，但答案取决于你的组织阶段，不是绝对正确。

1. 文档厚度 vs 决策速度

背景写得越厚，决策越慢，但返工越少。我的判断是：只要项目周期超过 3 个月，或者涉及跨部门资源，就应该承受更厚的背景文档。因为决策阶段多花的 5 天，通常能省下交付阶段 3-4 周的返工。

反过来，两周内要做完的小型实验型项目，背景一页纸足矣，重点是写清”验证什么假设、什么条件下放弃”。

2. 集中评审 vs 分级授权

集中评审能保证口径统一，但会成为瓶颈；分级授权快，但容易出现标准漂移。我倾向于”标准集中、评审分级”：五层结构、量化要求、证据标准由 PMO 统一制定；评审权限按预算和影响面分级下放。

配套措施是每季度做一次分级评审的质量抽检，抽检不合格的部门要临时收回授权。这样既不堵，也不散。

3. 自建 vs 采购

这个问题在国产替代背景下被问得特别多。我的判断分界线是：如果你的团队核心业务不是做研发管理工具，就不要自建。自建的成本不在于第一版，而在于持续维护和迭代，三年 TCO 通常会超出预期 2-3 倍。

但有三种情况例外：数据完全不能出本地且采购方案无法满足；业务规则极度特殊导致通用平台无法承载；组织有明确的工具产品化战略。

4. 严格门禁 vs 快速试错

严格门禁适合合规型、基础设施型、替换型项目；快速试错适合增长实验、新业务探索。混用会出问题，用试错的方式做核心系统替换，或用门禁的方式做增长实验，都会产生明显的组织摩擦。

我的建议是在制度里显式区分两类项目通道，并给它们不同的背景要求、不同的评审流程、不同的验收标准。这种显式区分本身，就是一种强大的沟通工具。

十、我的三条总结，以及你明天可以做的三件事

第一条总结：项目背景的质量上限，由制度决定；质量下限，由工具决定。只改模板不改制度，最好的结果是格式变漂亮了；只买工具不改制度，最坏的结果是多了一个昂贵的文档仓库。

第二条总结：五层结构里，最被低估的是”不作为后果”这一层。绝大多数团队把 80% 的精力花在”现状证据”上，这没错，但只有在资源竞争时你才会发现，决定项目能不能活下去的，往往是那一句”不做会怎样”。

第三条总结：项目经理制度的核心不是授权，而是分离。把动因、撰写、确认三个角色分开，比给项目经理更大的审批权限有用得多。权限解决的是”能不能推”，角色分离解决的是”推得对不对”。

如果你准备明天就开始动，我建议按这个顺序做三件事。

1. 挑一个正在准备立项的项目，用五层结构重写背景。不要等制度建好，先做一份样本出来，用它去说服人比用 PPT 有效得多。
2. 统计一下过去一年立项文档里的形容词数量。这个数字会给你一个很直观的冲击，也会成为推动改变的最好素材。
3. 在下一次立项评审会上，增加一个固定问题：不做会怎样？如果能答上来，项目继续；答不上来，退回补充。这一个问题带来的改变，往往超过一整套新模板。

制度、结构、工具三者配合起来，项目背景才能从一份”必须交的作业”变成”真正挡在前面的那道闸门”。而这道闸门每挡住一次错误的立项，省下的可能就是几十个人几个月的投入，这是我做了这么多年项目治理，最有把握的一个判断。