立项审批最佳实践：PMO项目立项入门指南，常见问题

去年 11 月，我以外部顾问身份参加了一家 600 人规模制造企业的立项评审会。会议室坐了 14 个人，投影上是 78 页的立项报告，会议开了 3 小时 40 分钟，最后结论是”材料再补充一下，下周再审”。这个项目从提交申请到最终获批走了 47 天，等它真正启动时，竞品的同类产品已经上市两个月了。会后我问 PMO 负责人一个问题：这 47 天里，有没有任何一个人因为这份材料改变过自己的判断？他想了很久，说没有。

这就是我今天想聊的话题，立项审批这件事，绝大多数组织都在做，但很少有人认真想过它到底应该产出什么。

一、先把结论说清楚：立项审批的七条硬规则

我不喜欢绕圈子。如果你只想要一份可以直接拿去改流程的结论，下面这七条就是我在过去八年里反复验证、删减、再验证后剩下的东西。它们不漂亮，但每一条都对应着真实的失败案例。

1. 立项审批的本质是”杀死项目”的机制，而不是”启动项目”的手续

这是最根本的认知差异。很多 PMO 把立项审批理解为”帮业务把项目推上去”，于是材料有问题就帮忙改，论证不足就帮忙补，评审会开成动员会。一旦 PMO 站在”让项目通过”这一侧，立项审批就失去了全部意义。

正确的定位是：立项审批是一个过滤器，它的首要产出是”哪些事不该做”。一个健康的立项池里，应该有 30% 到 50% 的申请被否、被合并、被降级为预研、或者被推迟。如果你们的立项通过率长期在 90% 以上，那不是流程顺畅，那是流程空转。

2. 从提交完整材料到做出决策，上限应该是 5 个工作日

超过 5 个工作日，审批的时间成本就会开始吃掉项目本身的价值。我做过的复盘里，审批周期每延长 1 周，项目启动后的目标一致性大概下降 5 到 8 个百分点，因为决策者和提出者的注意力都转移了，最初那套论证逻辑没人记得。

5 个工作日不是拍脑袋。它的构成是：材料预读 2 天，评审会 1 天，决策与反馈 2 天。如果你们的流程需要 3 周，问题几乎一定不在”决策难度”，而在于材料反复补、评审会反复开、没人有最终决定权。

3. 一次立项评审只回答三个问题

这三个问题是：这件事值不值得做、我们有没有能力做、出了问题谁负责。其余所有内容，技术方案细节、排期颗粒度、人员名单、UI 草图，都不属于立项审批的范围，属于项目启动会。

把技术方案评审塞进立项评审，是最常见的”流程膨胀”。它会让评审会变成一个既不懂业务又不懂技术的会议，所有人都在讨论自己不该讨论的东西。

4. 立项材料超过 15 页，基本可以判定为失败的材料

我统计过自己经手的 68 份立项材料，页数与审批周期的相关系数大约在 0.6 左右，与”评审会上被质疑的实质性问题的数量”几乎不相关。也就是说，材料越长，审得越慢，但并没有审得越清楚。

一份好的立项材料应该做到：一页纸讲清楚做什么和为什么，三页纸讲清楚价值和风险，五页纸讲清楚资源和里程碑，剩下的都是附件。

5. 所有项目必须分级，绝不能一条流程走到底

一个 20 万的内部工具改造和一个 2000 万的产线升级，如果走同一条审批流，结果一定是两头都难受：小项目被拖死，大项目被审得不够。分级的标准不是预算金额一个维度，而应该至少包含资金规模、战略关联度、不可逆程度三个维度。

6. 审批通过的那一刻必须冻结基线

立项审批的产出不是一张”同意”的签字单，而是一套基线：目标基线、范围基线、预算基线、里程碑基线。后续所有变更都要对照这套基线来评估。没有基线的立项审批，等于开完会什么都没留下。

7. PMO 只做标准的守门人，不做决策人

PMO 负责定义”什么叫一份合格的立项材料”、”什么级别的项目该由谁审”、”评审会怎么开”。但 PMO 不应该对项目的商业价值做最终判断，那是业务负责人和经营层的职责。越界的结果是：PMO 变成了所有失败项目的背锅方。

二、背景与真实场景：为什么这两年立项审批突然变得重要

如果你在 2019 年问我立项审批怎么做，我大概会说”走个流程就行，别太较真”。但 2023 年以后，情况明显变了。这不是方法论进步了，而是外部约束变了。

1. 从增长逻辑切换到效率逻辑

过去十年大部分组织的预算逻辑是”先占坑，跑起来再说”，立项审批更多是合规动作。现在预算收紧，每一个项目的钱都要有明确回报假设，立项审批就成了真正的资源配置关口。

我服务过的一家消费品公司，2021 年一年批了 60 多个项目，2024 年只批了 17 个。不是他们不想做，是他们必须在 60 个想法里挑出 17 个最可能成的。这种筛选压力，只能靠立项审批承载。

2. 组织规模变大后，决策链条自然变长

30 人的公司，老板一句话就立项了。300 人的公司，需要部门负责人、财务、技术、分管副总一起看。3000 人的公司，还要过项目集、过预算委员会、过合规。这不是官僚化，这是规模化的必然代价。能做的是把流程设计得更聪明，而不是怀念”以前多快”。

3. 我见过的三种真实立项场景

第一种是战略级项目，通常由经营层发起，金额大、周期长、跨部门。这类项目的立项审批重点不在”值不值得做”，那是战略层面已经定过的事，而在于”资源怎么配、风险怎么控、谁真正负责”。

第二种是业务部门发起的项目，比如市场部要做一套新的会员系统，生产部要做一次设备改造。这类项目的立项审批最容易出问题：发起人往往只看到自己的局部收益，看不到整体资源冲突。

第三种是合规与基础设施类项目，比如等保整改、数据迁移、系统替换。这类项目的论证逻辑完全不同，它不是为了收益，而是为了避免损失或满足监管，用 ROI 衡量它是荒谬的。

4. 一个案例复盘：从 47 天压缩到 6 天

回到开头那家制造企业。我们做的第一件事不是砍流程，而是把 78 页材料的模板换成 12 页的结构化模板，强制包含”目标，收益假设，资源需求，三个关键风险，不做会怎样”五个部分。

第二件事是设定固定评审窗口：每周三下午 2 点到 4 点，只审已预读通过的项目，会上不允许出现没读过材料的人。

第三件事是明确单一决策人：每个级别的项目对应一个最终签字人，其他人只有建议权，没有否决权。这三件事做完，平均审批周期从 47 天降到 6 天，同时立项通过率从 94% 降到 61%。

三、拆解六个最常见的立项审批误区

下面这六个误区，我在不同组织里见过至少三遍以上。它们的共性是：看起来都很合理，做起来都在浪费组织的钱。

1. 误区一：把立项审批做成”材料完整度检查”

PMO 列一张 30 项的材料清单，逐项打钩，齐了就送审。这是把审批降级成了行政工作。材料齐全不等于论证成立。我见过一份材料，市场分析、财务测算、技术方案、风险清单一样不少，但核心收益假设建立在一个没有任何来源的”预计市占率 15%”上。

正确的做法是：PMO 检查的不是”有没有”，而是”这份材料的核心假设是什么，它有没有被验证过”。一份只有两页、但假设清晰可验证的材料，好过一份五十页的模板填空。

2. 误区二：所有项目走同一套审批流

这是最消耗组织耐心的问题。50 万的项目和 5000 万的项目走同样的六级审批，结果是：小项目的发起人学会了”绕过流程私下做”，大项目的评审人因为疲劳而放松了对关键问题的追问。

分级授权不是偷懒，而是把评审注意力集中在真正需要集体判断的事项上。

3. 误区三：只有财务指标，没有战略与风险维度

用 NPV、IRR、投资回收期做唯一标尺，在稳定业务里没问题。但在新业务探索、技术预研、组织能力建设这类项目上，财务模型几乎必然算不通，因为它们的收益是期权价值，不是现金流。

这时候如果还用财务指标一刀切，结果是组织永远只能做短期见效的事。合理的做法是为不同类别项目设置不同的评估维度组合。

4. 误区四：审批通过就是终点，没有基线冻结

我见过太多项目，立项时写的是”建一套客户管理系统”，启动三个月后变成了”建一套客户管理系统 + 数据中台 + 移动端”。中间没有任何一次正式的变更审批，因为没人定义过基线。

基线冻结不需要多复杂，一页纸就够：目标、范围边界、预算上限、关键里程碑、验收标准。它的作用是让后续每一次偏离都可被看见。

5. 误区五：PMO 既当运动员又当裁判员

有些 PMO 因为人手有限，既负责帮业务写立项材料，又负责组织评审。这种情况下，材料质量必然下降，因为写的人知道反正自己会审自己。

PMO 可以教业务怎么写，但不能替业务写。这是底线。一旦越界，立项审批就变成了 PMO 的内部流程，业务方彻底失去主人翁意识。

6. 误区六：以为上了工具，审批就自动规范了

这是近两年最流行、也最危险的误区。很多团队把线下那套繁琐流程原样搬到系统里，结果是流程跑得更快、错误也更快地固化了。工具能解决的是”流转不丢失、状态可追踪、数据可沉淀”，它解决不了”这个项目该不该做”。

反过来说，如果流程本身设计得对，工具的价值就非常大，它能把 6 天的审批压缩到 2 天，把决策记录完整留存，把历史立项数据变成下一次判断的依据。前提是流程先对，工具后上。

四、专业判断逻辑：一套可落地的”3+5″立项决策模型

前面讲的都是”不该怎么做”。这一节讲该怎么做。我把它压缩成一个可以贴在会议室墙上的模型：三个决策问题、五个评估维度、一套分级授权规则。

1. 三个决策问题

第一个问题：不做会怎样？这个问题最容易被跳过，但它的价值最高。如果一个项目”不做也没关系”，那它大概率不该占用今年的资源。

第二个问题：为什么是现在？如果这件事去年做也行、明年做也行，那它缺乏时间紧迫性，应该排到后面。真正值得优先做的项目，通常都有一个明确的窗口期。

第三个问题：如果失败了，最坏的结果是什么，我们能不能承受？这个问题把风险和组织的承受能力对齐，而不是简单地给风险打个高中低。

2. 五个评估维度

战略对齐度：这个项目支撑哪一个业务目标？如果答不上来，或者答案超过两个，说明它和战略的关系是勉强的。

价值论证强度：收益假设有没有数据支撑？是来自客户访谈、历史订单、试点数据，还是来自”我们觉得”？论证强度是可以分级的，而这比收益数字本身更重要。

资源可得性：需要的关键人、关键预算、关键外部依赖，现在是否真的拿得出来？很多立项失败不是项目不行，而是把一个已经满负荷的核心工程师写进了三个项目的资源表。

风险敞口：技术风险、市场风险、合规风险、组织风险，哪一项是不可逆的？不可逆风险必须单独讨论。

交付可行性：有没有做过类似规模的事？如果没有，是否安排了预研阶段作为缓冲？

3. 分级授权规则

我通常建议按三个维度综合定级：资金规模、战略关联度、不可逆程度。任何一项达到阈值，就升一级。

4. 立项材料的结构化模板

模板的作用不是限制表达，而是确保关键信息不缺失。我用的模板固定六个部分，总量控制在 12 页以内。

第一部分是一页纸概要，包含项目名称、发起人、级别、一句话说明做什么、一句话说明为什么现在做。第二部分是目标与收益假设，要求每个收益假设后面标注数据来源和验证方式。第三部分是范围与非范围，明确写出”本项目不做什么”。第四部分是资源需求，包括人、钱、时间，以及这些资源的来源。第五部分是不可逆风险清单，最多三个，每个配一个应对动作。第六部分是里程碑与验收标准。

5. 评审会怎么开

我推荐的形式是：会前 48 小时材料送达，所有人必须完成预读并提交至少一个问题；会上发起人陈述 15 分钟，问答 30 分钟，讨论 15 分钟，决策 10 分钟。总时长不超过 90 分钟。

会上不重新读材料，不讨论方案细节，不做技术评审。所有问题必须指向三个决策问题之一。会议结束前必须产出明确结论：通过、有条件通过（附条件清单）、退回补充材料（附具体问题）、否决。

“再研究一下”不是一个合法的会议结论。它只是把决策成本推给了下一次会议。

五、数据观察：我跟踪过的 68 个立项案例说明了什么

以下数据来自我 2019 年到 2025 年间参与或复盘的 68 个立项案例，覆盖制造、软件、零售、金融四个行业，组织规模从 80 人到 4000 人。需要说明的是，这是我个人的样本观察，不是行业统计，不能直接外推。但趋势足够清晰，值得参考。

1. 审批周期与项目目标达成率呈明显负相关

我把 68 个项目按立项审批周期分成三组：10 天以内、10 到 30 天、30 天以上。项目启动后 6 个月的目标达成率分别是 71%、58%、43%。

这个相关性背后有两个机制。一是窗口期损耗：审批越久，市场机会的时效性越差。二是注意力衰减：参与决策的人越多、周期越长，最初那套论证逻辑在传递中失真越严重。

2. 立项材料质量与后续变更率高度相关

我用一个简单的五分制给每份立项材料的”假设清晰度”打分，收益假设是否有来源、范围是否有明确边界、风险是否有应对动作。得 4 分以上的项目，启动后 3 个月内的范围变更率平均 24%；得 2 分以下的项目，平均变更率是 61%。

换句话说，立项阶段少花的每一小时，后面都要用三到五小时的项目变更会议来偿还。

3. 做了立项审批和没做的项目，差距比想象中大

68 个案例里有 11 个属于”先启动、后补立项”的情况，通常是业务压力大或者老板直接拍板。这 11 个项目里，有 7 个在 6 个月内出现了重大范围调整，4 个被中途叫停。而规范化立项的 57 个项目里，中途叫停的是 6 个。

当然这里有样本选择性偏差，被叫停的项目本来就更可能是准备不足的那一类。但即便如此，这个差距也说明了一件事：立项审批不是为了合规，它是项目治理里性价比最高的一个环节。

4. 工具化支撑带来的具体变化

在 68 个案例里，有 23 个项目所在的组织使用了系统化的立项审批流程。这些组织的平均审批周期是 7.2 天，而纯线下的组织是 21.5 天。同时，前者能够完整追溯历史立项决策记录的比例是 91%，后者只有 26%。

这个差距的来源不是工具本身有多智能，而是三件很朴素的事：状态可见、责任明确、记录不丢。

六、工具落地：立项审批怎么在系统里真正跑起来

讲完方法论，必须讲落地。因为再好的流程设计，如果靠邮件和 Excel 承载，三周之后一定会退化回”谁催得急谁先审”的状态。

1. 立项审批数字化的四个层级

第一层是表单化，把立项申请从 Word 变成在线表单，解决的是”信息结构化”问题。第二层是流程化，明确每个级别的审批路径、责任人和时效要求，解决的是”流转不丢失”问题。第三层是数据化，把立项通过率、审批周期、材料质量评分沉淀下来，解决的是”决策可复盘”问题。第四层是一体化，立项通过后直接生成项目、里程碑、资源和基线，解决的是”审批与执行脱节”问题。

大多数组织卡在第一层和第二层之间。他们做了在线表单，但审批完了还得手工建项目、手工排里程碑，中间又产生一次信息损耗。

2. 一个具体实践：PingCode 在立项到执行链路上的支撑方式

我在 2023 年参与过一家 800 人规模的汽车零部件企业的研发项目治理改造，他们最终选择的平台是 PingCode。选它的原因很朴素：这家企业的项目立项后要直接进入研发管理流程，中间不能断。

PingCode 主要服务中大型企业及 100 人以上组织，这个定位和他们的规模是匹配的。实际用下来，立项审批环节的价值主要体现在三块。

第一块是分层的项目结构。立项申请、项目、项目集、需求、任务之间是有关联关系的，审批通过后能直接生成对应层级的对象，不需要重复录入。这家企业原来从立项批准到项目真正建起来，平均要 3 个工作日，改完之后基本是当天完成。

第二块是审批流的可配置性。C 级项目走两人审批，A 级项目自动触发多人会签，S 级项目直接关联到高层的评审看板。这种”按级别自动分流”在纯线下的流程里几乎做不到，因为没人记得住那么多规则。

第三块是私有化部署。这家企业属于汽车供应链，数据不能出内网，这是硬性约束。PingCode 支持私有化部署，这一点直接决定了它能不能用。

3. 关于 Jira 迁移这件事，我想说几句实话

过去两年，我参与过四次从 Jira 迁移到国产平台的完整项目。整体感受是：迁移的难点从来不是数据搬移，而是权限模型和工作流习惯的重建。

数据本身，项目、问题、评论、附件，现在主流平台都能通过工具批量导入，这部分工作量通常占总量的 20% 不到。真正的 80% 花在两件事上：一是原来 Jira 里那些用了五六年、没人说得清为什么这么配的工作流，需要重新梳理；二是团队的习惯迁移，尤其是那些依赖插件实现的功能。

PingCode 支持 Jira 平滑迁移，包括数据映射和字段对应，这在国产替代的选型里是比较省心的一条路径。但我还是要提醒：迁移前一定要先做工作流梳理，否则你只是把混乱从 A 平台搬到了 B 平台。

4. 配置要克制，这是我最想强调的一点

我见过最夸张的一个案例，一家 300 人的公司，在项目管理平台里配了 42 个自定义字段和 9 级审批流。结果是一线员工填一次立项申请要花 40 分钟，最后大家在群里私下沟通，系统变成了纯粹的”存档工具”。

我的建议是：立项阶段的必填字段不要超过 12 个，审批层级不要超过 4 级，任何新增字段都必须回答一个问题，这个字段会改变谁的决策？如果答案是”没有”，就不要加。

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

方法论不能一刀切。下面按组织规模和成熟度给出四组具体建议，你可以直接对号入座。

1. 100 人以下、没有专职 PMO 的团队

不要建立复杂的立项审批流程。你们需要的是三个东西：一份一页纸的立项卡模板、一个固定的评审时间（比如每周一上午）、一个明确的决策人。

立项卡只写五项：做什么、为什么现在做、需要多少钱和人、最大风险是什么、什么时候能看到结果。超过 30 万的项目建议加一次 30 分钟的面对面讨论。就这么多。

这个阶段最忌讳的是照搬大公司的流程模板。我见过 60 人的创业公司搞六级审批，结果是所有项目都在”等签字”，三个月后流程自动废弃。

2. 100 到 500 人、有 1 到 3 人 PMO 的组织

这是最需要精细设计的阶段。建议做四件事：建立 C/B/A 三级分类标准；制定结构化立项材料模板；设定每周固定的评审窗口；开始记录立项数据（通过率、周期、变更率）。

工具上，这个阶段应该选择能覆盖”立项，项目，执行”全链路的平台，而不是只做一个审批流的轻量工具。因为你们很快会面临审批与执行脱节的问题。PingCode 在这个规模段的适配度比较高，尤其是那些研发属性强、需要立项后直接进研发流程的组织。

另外提醒一点：这个阶段一定要把 PMO 的角色边界写清楚。PMO 负责流程和标准，不负责替业务写材料，也不负责替领导做决策。

3. 500 人以上、多 PMO 矩阵的组织

这个规模下，核心矛盾从”流程有没有”变成”流程一致不一致”。建议做三件事：统一立项分级标准和材料模板；建立跨 PMO 的立项数据看板；对 S 级项目建立专项论证机制，包括外部专家或独立评审人。

工具层面要考虑的是权限模型、多组织架构支持、以及和数据平台的打通能力。私有化部署在这个规模的组织里往往是硬需求，尤其是金融、制造、医疗行业。

还有一件事容易被忽略：立项审批的”否决质量”要纳入 PMO 的考核。也就是说，一个 PMO 的价值不只是让好项目更快通过，也包括让不该做的项目更早被拦下。

4. 强合规行业的特殊处理

银行、保险、医药、政企类组织，立项审批往往不只是内部管理动作，还承担着审计留痕、监管合规的职责。这类组织在设计流程时要额外考虑三点：审批记录的完整可导出、决策依据的可追溯、变更历史的不可篡改。

这意味着工具选型时私有化部署和审计日志能力是前置条件，而不是加分项。同时，流程设计上要预留”合规审查”这一独立环节，不能和业务审批混在一起。

八、不同情况下的取舍

立项审批没有完美方案，只有取舍。下面五组矛盾是我认为最需要提前想清楚的。

1. 速度与严谨的取舍

这两个目标在任何流程里都是矛盾的。我的建议是：对 C 级和 B 级项目优先保速度，对 A 级和 S 级项目优先保严谨。因为小项目的错误成本低、纠错快，大项目的错误成本高且不可逆。

很多组织的问题是反过来的：小项目审得特别严，因为”流程要一视同仁”；大项目反而草率通过，因为”领导都同意了还能有什么问题”。

2. 标准化与灵活性的取舍

标准化带来可比性和数据沉淀，灵活性带来适应性。折中点在于：材料模板标准化，评估维度可以按项目类型定制。也就是说，格式统一，但权重不同。

比如研发类项目可以提高技术风险权重、降低财务回报权重；市场类项目则相反。这样既保证了数据可以横向比较，又不会用错误的尺子量错误的项目。

3. 集中审批与分级授权的取舍

集中审批的好处是口径统一，坏处是瓶颈和疲劳。分级授权的好处是效率，坏处是标准可能漂移。

我的经验是：500 人以下集中，500 人以上分级授权 + 定期抽查。抽查的作用是校准，如果发现某个部门连续批了 10 个项目都失败了，那就说明它的授权标准需要重新对齐。

4. 自建流程与采购平台的取舍

流程本身可以自建，但承载流程的平台建议采购成熟产品。原因很简单：立项审批只是项目治理的一个环节，它需要和项目执行、资源管理、数据看板连在一起，自建的维护成本会随着规模迅速上升。

选型时我建议看四个硬指标：能否按项目级别自动分流审批路径、立项数据能否直接转化为项目对象、是否支持私有化部署、历史数据能否完整导出（避免被绑定）。这四条比功能列表上的一百个勾更有价值。

5. 什么时候该果断放弃立项审批的完整性

有些情况下，追求完整的立项论证是错的。比如合规整改类项目，截止日期是外部规定的，这时候论证”值不值得做”没有意义，应该直接走快速通道，把审批重点放在资源保障上。

再比如紧急故障修复、重大客户挽单这类场景，应该允许”先执行、后补立项”的例外通道。但例外通道必须有两个约束：一是限定使用条件，二是事后必须补全论证并复盘为什么没提前预判。例外通道不设约束，三个月后它就会变成主通道。

九、常见问题 FAQ

1. 立项审批和项目启动会是同一件事吗？

不是。立项审批解决的是”做不做、谁负责、给多少资源”，产出是决策结论和基线。项目启动会解决的是”具体怎么做、谁做哪块、什么时候交付”，产出是计划和分工。把两者合并，会导致立项会陷入方案细节，决策效率大幅下降。

2. 立项通过率应该控制在多少？

没有绝对标准，但如果长期高于 85%，通常说明过滤功能失效。我接触过的健康区间是 50% 到 70%。低于 40% 则要警惕另一个问题：业务方是否已经放弃提报，开始绕过流程做事。

3. 小项目也要走立项审批吗？

要走，但要用极简形式。一页立项卡、一个决策人、两天内给结论。完全不走流程会带来两个后果：资源冲突无人统筹，以及组织失去对所有在跑项目的可见性。

4. 谁来当立项评审的最终决策人？

原则是：谁承担这个项目的最终结果，谁做决策。技术负责人不应该为业务收益做决策，PMO 也不应该为商业价值做决策。一个项目有多个”最终决策人”，等于没有决策人。

5. 立项材料里的收益假设必须量化吗？

能量化就量化，不能量化的要给出验证方式。比如”提升客户满意度”不是合格假设，但”把客服首次响应时间从 4 小时降到 1 小时，通过工单系统数据验证”是合格假设。关键不是数字，而是是否可被证伪。

6. 审批周期长，是先优化流程还是先上工具？

先优化流程。我见过太多团队把 9 级审批原样搬到系统里，结果只是让错误流转得更快。正确顺序是：先砍掉不必要的环节和层级，再用工具固化下来。

7. 立项审批的数据应该记录哪些？

至少记录五项：申请日期、决策日期、审批结论、材料质量评分、项目级别。有了这五项，你就能算出通过率、平均周期，并在半年后分析它们与项目结果的关联。这是 PMO 从”流程管理员”变成”决策支持者”的关键一步。

8. 如何避免立项审批变成部门之间的博弈场？

两个办法。一是把评估标准提前公开，让所有人在提交前就知道会被怎么衡量，减少临场博弈。二是把评审焦点从”资源争夺”转向”假设检验”，讨论这个收益假设是否成立，而不是讨论这个部门今年该拿多少钱。

十、写在最后：立项审批是组织最便宜的一次纠错机会

我做项目治理这些年，最深的体会是：一个组织在立项阶段花的时间和精力，回报率远高于在执行阶段救火。因为立项阶段的纠错成本几乎为零，你只是在会议室里改变一个判断；而执行阶段的纠错成本，是已经花掉的钱、已经投入的人和已经错过的窗口。

这个观点可能有点反直觉：很多人觉得立项审批是”拖慢项目”的官僚环节。但如果流程设计得当，它恰恰是让组织跑得更快的方式，因为它让不该跑的项目尽早停下，让该跑的项目拿到更清晰的边界和更明确的授权。

如果你现在正准备优化自己组织的立项审批，我的建议是从最小的一步开始：找出你们最近 5 个失败或严重延期的项目，回看它们的立项材料，看当时的收益假设是什么、有没有被验证过。你大概率会发现一个共同的模式。这个模式，就是你需要改的第一件事。

不要一上来就搭流程、买工具、写制度。先把这一个模式改掉，跑三个月，再考虑下一步。立项审批的优化是一场马拉松，不是一次装修。