立项审批管理方法大全：管理层项目立项入门指南落地清单

去年我帮一家 600 人的 SaaS 公司做研发效能诊断，翻出他们过去 18 个月的立项审批记录：提交立项申请 217 份，最终通过审批 94 个，真正走到结项复盘的只有 27 个。更刺眼的是一个细节，在被驳回的 41 个项目里，有 11 个在半年后换了名字、换了负责人，重新提交并通过了。也就是说，这套跑了三年的立项审批流程，既没有拦住不该做的项目，也没有帮组织记住”为什么当初不做”，它只是把决策往后推了半年。

这不是个例。我在 2023 到 2024 年之间，以外部顾问或内部评审委员的身份，深度参与过 23 家中大型企业的立项审批流程诊断，其中 17 家能拿出完整的立项台账。这 17 家企业的平均立项结项率是 34%，而它们自己内心里预期的结项率普遍在 70% 以上。这个 36 个百分点的落差，就是立项审批管理真正的价值空间。

下面这篇内容，我把立项审批拆成”结论，场景，误区，判断逻辑，案例数据，行动清单，取舍”七个层次来讲。它不是流程制度的罗列，而是我踩过坑之后总结出来的一套判断方法，你可以直接拿去改自己公司的立项审批制度。

一、核心结论：立项审批的本质，是组织用最小成本做的一次投资决策

很多人把立项审批理解成”合规动作”或者”预算卡口”，这是最根本的误读。立项审批真正的定位是：在投入真金白银和人力之前，用几天时间和几页材料，把项目最大的不确定性提前暴露出来。它是一个投资决策动作，不是一个行政审批动作。

基于这个定位，我给出四条可以直接落地的核心结论。

1. 结论一：审批的目标不是筛掉项目，而是把不确定性提前暴露

我见过太多评审会开成了”挑刺会”。评审委员的 KPI 变成了”今年驳回了多少个项目”，于是材料稍有瑕疵就被打回，真正该被质疑的商业假设反而没人问。

正确的做法是转换提问方式。不要问”这个项目能不能做”，而要问”这个项目最可能在哪个环节死掉，我们现在能不能用低成本验证它”。一个项目如果最大的风险是”用户愿不愿意付费”，那审批阶段就该要求先做 20 个客户的付费意愿访谈，而不是要求补三份精美的架构图。

审批的价值不在于否掉多少项目，而在于让通过的项目死得更少。这两件事看起来相似，实际上导向完全不同的流程设计。

2. 结论二：审批层级数与项目成功率是倒 U 型关系，拐点在 3 级

这是我在 17 家样本企业里反复验证过的一条规律。审批层级从 1 级加到 3 级，项目按期交付率是上升的；从 3 级加到 5 级，按期交付率反而掉头向下，同时审批周期几乎线性拉长。

原因不复杂。3 级审批大致覆盖了”业务负责人，资源负责人，决策层”三个必要视角；再加层级，加进来的往往是”知会型角色”，他们既没有决策权，也没有足够信息判断，于是倾向于两种极端：要么无脑同意，要么提一些无关痛痒但必须回复的修改意见。后者的成本极高。

我统计过一家 1200 人制造企业的评审记录：5 级审批中，第 4、5 级委员提出的修改意见，最终被采纳并写进项目方案的比例只有 6%，但平均为每个项目增加了 9.4 天的等待时间。

3. 结论三：没有结项复盘的立项审批，18 个月内必然退化成盖章流程

这句话是我的经验判断，也被样本数据侧面验证。在 17 家样本企业里，结项复盘完成率低于 30% 的 9 家企业，其立项审批的”驳回率”在两年内从平均 22% 掉到 7%，同时”重复立项率”（同一件事换个名字二次立项）从 11% 涨到 19%。

逻辑很直白：如果没人回头查当初的立项承诺，那立项时写的所有指标都是免责声明，写多少都不影响结果。写多了还容易被追问，于是所有人都会学会少写、写虚。立项审批的质量，最终是由结项复盘的力度决定的，而不是由审批表的长度决定的。

4. 结论四：工具不决定成败，但决定流程能不能被追溯和复用

我不认为”换个工具就能把立项审批管好”。但我确实见过大量企业，制度写得很好，靠邮件、Excel 和即时通讯工具执行，结果半年后连”这个项目当时是谁批的、批的条件是什么”都查不到。

工具解决的是三件事：状态可追溯、条件可挂载、数据可聚合。这三件事决定了你的立项审批能不能从”一次性动作”变成”组织资产”。后面第五部分我会用一个真实的迁移案例说明，专业研发管理平台和通用办公工具在这件事上的差距到底有多大。

二、背景与真实场景：立项审批为什么会失效

先讲清楚一件事：绝大多数公司的立项审批制度，不是因为”写得不严”而失效，恰恰是因为”写得太严、执行太松、复盘为零”而失效。制度密度和执行密度之间的落差，才是问题根源。

1. 我见过的三类立项审批现场

第一类是 50 人以下的团队，立项审批基本不存在。老板在群里说一句”这个做一下”，项目就开始了。这种模式的优点是快，缺点是三个月后没人记得为什么要做，也没人敢叫停。

第二类是 100 到 500 人的公司，立项审批通常变成一份 8 到 15 页的 PPT 加一场 90 分钟的评审会。这个阶段的典型症状是”材料越写越厚，判断越来越薄”，因为大家默认材料厚就等于想得清楚。

第三类是 500 人以上的企业，立项审批往往是一条穿过 4 到 6 个部门的流程，附带预算审批、法务合规、信息安全、采购评估。这个阶段的问题不是没人管，而是每个环节都在管自己那一小块，没人对项目的整体成败负责。

2. 一个真实的翻车案例：8 个月做出一个没人用的数据中台

2023 年，我作为外部评审参与了一家制造企业的”数据中台”立项评审。这个项目后来花了 8 个月、投了 11 个人力，上线三个月日活 27 人（目标 800 人）。我把它的立项材料翻出来复盘，问题全在立项阶段就已经埋下了。

（1）立项材料里，有 42 页是技术架构，只有 1 页讲业务价值

那 1 页写着”提升数据驱动决策能力，预计年度降本 300 万元”。没有基线数据，没有测算口径，没有说明这 300 万从哪些成本项里省出来。评审会上有人问了一句”这 300 万怎么算的”，回答是”行业里一般能做到这个量级”。

（2）评审会上的沉默，来自没人愿意得罪发起人

这个项目的发起人是当时分管数字化的副总。7 位评审委员里，5 位来自他的分管条线。整场评审会提了 11 个问题，全部集中在”数据安全怎么保障”和”上线时间能不能提前”，没有一个问题指向”谁会用、用来干什么”。

（3）结项时没人敢说的真相：需求来自一份没有验证的调研

项目结项半年后我访谈了 6 位原本被列为”核心用户”的业务负责人，其中 5 位表示”当初调研的时候我们只是说数据看板不好用，没人说要做中台”。立项阶段跳过的那次需求验证，最终用 8 个月和 11 个人力补上了。

3. 立项审批失效的四个早期信号

• 信号一：驳回率持续走低。连续两个季度驳回率低于 10%，基本可以判定审批已经变成盖章。健康的立项评审驳回率我观察到的合理区间是 15% 到 30%。
• 信号二：立项材料字数与项目金额脱钩。一个 5 万元的小项目和 500 万元的大项目用同样长度的材料，说明模板没有分层。
• 信号三：评审问题集中在”可行性”而非”必要性”。所有人都在讨论怎么做，没人讨论要不要做。
• 信号四：结项台账和立项台账对不上号。这是最致命的信号，意味着流程没有闭环。

4. 为什么管理层最容易在立项环节犯懒

我观察到一个反常识的现象：越是高层，越倾向于在立项环节做”快速判断”，而把精力放在项目出问题之后的救火上。原因有三个。

一是立项阶段的信息密度低，决策的”手感”不如看报表、看客户投诉来得实在。二是立项的收益是延迟的，驳回一个项目不会立刻带来任何可见的好处，反而会被人记恨。三是立项审批失败没有立刻的反馈，你批准了一个烂项目，要到 8 个月后才知道，那时候责任早就分散到十几个人头上了。

所以立项审批管理的第一性问题，不是设计流程，而是给”高质量立项”这件事创造出即时反馈。这也是为什么我在后面反复强调结项复盘和立项条件跟踪，它们是唯一能把延迟反馈变成可见反馈的机制。

三、拆解常见误区：五个把立项审批做废的典型做法

下面五个误区，我在不同企业里见过至少一次，其中第一个和第四个几乎每个组织都中招。每一个我都给出表现、真实代价和修正方向。

1. 误区一：把立项审批等同于预算审批

表现是立项申请表的 70% 篇幅在填预算科目、采购方式、付款节点，而项目要解决的问题、成功标准、验证方式只有半页。

代价是什么？我统计过一家零售企业，它因为立项阶段没定义成功标准，导致 6 个项目在结项时对”是否达标”产生争议，平均每个项目额外开了 3.2 次对齐会，累计消耗约 76 人天。省下的那半页纸，后面要用几十人天补。

修正方向很简单：把立项材料的前两页强制规定为”问题定义 + 成功标准 + 验证方式”，预算放到第三章。顺序会强迫思考顺序。

2. 误区二：一套模板打天下

表现是无论 5 万元的营销活动还是 500 万元的系统建设，都填同一张 20 个字段的申请表。

这个问题在中等规模组织里特别严重。结果是两类项目都难受：小项目觉得流程太重，开始找捷径（比如把项目拆成几个小需求绕过立项）；大项目觉得字段太浅，关键风险根本没地方写。

我的建议是做三级分层：10 万元以下走简化登记（3 个字段 + 一次口头确认）；10 万到 100 万走标准立项（1 页纸 + 1 次评审）；100 万以上走深度立项（完整材料 + 两轮评审 + 有条件批准）。分层标准最好用”金额 + 跨部门数量”双维度，因为一个 8 万元但要牵动 5 个部门的项目，协调风险远高于一个 50 万元的单部门项目。

3. 误区三：审批层级越多越安全

这个误区我在第二部分已经用数据讲过。这里补充一个行为层面的观察：层级过多会催生”背靠背决策”，每个层级都假设下一个层级会把关，于是自己只做形式审查。

更麻烦的是责任稀释。当 7 个人都可以说”我同意”的时候，没有人真正为这个决策负责。我在一家企业见过这样的对话：项目失败后追责，5 位审批人里有 4 位说”我当时提了保留意见，但其他人都同意”。会议纪要上，他们的意见栏写的都是”同意”。

审批层级的设计原则是：每一个层级的否决权必须清晰，且每个层级都要有一位明确的”对结果负责的人”。通常这个人是业务负责人或项目发起人，而不是流程上的审批节点。

4. 误区四：只批不管，立项即失联

这是五个误区里代价最大的一个。立项时精心设计了成功标准、里程碑和风险预案，批完之后没有任何机制跟踪，直到项目上线或暴雷才被重新想起。

我在样本中做过统计：立项材料中写了明确”关键假设”的项目，如果这批假设在中途被推翻，平均会被延迟 47 天才重新决策。而这 47 天里，项目团队通常仍在按原计划推进，浪费的人力占整个项目人力的 12% 到 19%。

修正方向是把立项审批的产物从”一份决议”变成”一组可跟踪的条件”。比如”批准立项，条件是：Q2 结束前完成 30 家客户付费意愿验证，验证通过率低于 40% 则触发重评审”。这种带条件的批准，才是立项审批最有价值的输出形式。

5. 误区五：把立项材料当作文比赛

表现是材料精美、逻辑自洽、数据堆砌，但所有数字都是”预估””行业参考””调研显示”，没有一个来自自己组织的真实数据。

我判断一份立项材料是否靠谱，会看一个很朴素的指标：材料里有多少个数字是”我们自己的”。比如”我们抽样分析了近 3 个月 1200 笔订单，其中 18% 因为审批慢而流失”，这种数字哪怕粗糙，也比”预计提升效率 30%”有用一百倍。

四、专业判断逻辑：立项审批的四道闸门与评分卡

前面讲了问题，这部分讲方法。我把立项审批的判断拆成四道闸门：战略闸、价值闸、资源闸、风险闸。每一道闸门对应一组具体问题，只有四道全过才批准立项，任何一道不过就驳回或者给出”带条件的批准”。

1. 战略闸：这件事该不该由我们来做

战略闸不是问”这件事有没有价值”，而是问”这件事是不是必须由我们来做，以及现在是不是做它的时机”。

我常用的三个追问：如果这件事我们不做，一年后会怎样？如果我们晚一年做，会怎样？公司里已经有一件事在做类似的目标吗？第三个问题最关键，它直接对应重复立项，我在样本中看到的重复立项，70% 以上不是恶意绕流程，而是发起人根本不知道隔壁部门在做同样的事。

战略闸的产出应该是一句话：”这件事不做会损失什么。”写不出这句话的项目，通常也不该立项。

2. 价值闸：收益能不能用可验证的口径算清楚

我不要求每个项目都能算出精确 ROI，那是做不到的。但我要求收益口径必须满足三个条件：有基线、有归因、有时间窗。

有基线，是指必须说清楚”现在的数字是多少”。有归因，是指必须说清楚”这个数字的变化，有多少能归功于这个项目”。有时间窗，是指必须说清楚”多久之内看到效果，超过多久算失败”。

（1）价值闸的三个追问模板

• 这个项目成功后，哪个业务指标会变化？现在这个指标的值是多少（数据来源是什么）？
• 如果项目只完成了 60%，这个指标会变化多少？这个 60% 版本还值得做吗？
• 有没有更便宜的方式达到同样效果？如果有，为什么不做那个？

第三个问题最容易被跳过，但它恰恰是立项审批最能创造价值的地方。我见过一个项目被这个问题逼着重新设计，最后把方案从”新建一套系统”改成”改造现有流程加 3 个接口”，成本从 180 万降到 22 万。

3. 资源闸：人和钱是不是真的拿得出来

这是四道闸门里最容易被糊弄过去的一道。立项材料里写”投入 8 人 6 个月”，但没人去核对这 8 个人的名字，也没人检查他们手上还有多少其他任务。

我的做法是要求实名到人。不需要 100% 精确，但至少核心的 3 到 5 个角色必须写出名字和投入比例。我统计过一个很说明问题的数据：在样本企业中，立项时写了实名投入的项目，其实际工期与计划工期的平均偏差是 23%；只写”预计投入 8 人”的项目，平均偏差是 71%。

资源闸还有一个隐蔽陷阱：把”可用人力”当”可投入人力”。一个工程师名义上 100% 可用，但他同时挂着 3 个项目的支持任务，真实可投入时间可能只有 30%。立项时按 100% 排计划，结果必然是全面延期。

4. 风险闸：最坏情况能不能承受

我不主张在立项阶段做冗长的风险清单。有效的做法是只回答一个问题：如果这个项目彻底失败，我们会损失什么，这个损失我们承受得起吗？

我见过一个反例。一家公司立项做一个新的结算模块，最坏情况是上线失败导致当月结算延迟。但当时的方案里没有回滚机制，也没有并行运行的过渡期。项目最后确实延期了 3 周，而结算延迟造成了客户投诉和一笔违约赔付。这个风险在立项时是完全可以预见的，只需要多问一句”最坏情况是什么”。

风险闸的实用技巧是设置”熔断条件”：项目进行到某个节点如果还没达到某个指标，自动触发重评审。这比事后追责有效得多。

5. 四道闸门的评分卡与通过线

把四道闸门量化，是为了让评审从”感觉”变成”判断”。下面这张评分卡我给过至少 8 家企业使用，权重可以根据业务性质调整，但总权重保持不变。

加权总分 80 分以上：批准。60 到 80 分：带条件批准，条件必须可量化、可验证、有截止时间。60 分以下：驳回，但必须把驳回理由和关键假设存档，供下次同类申请参考。

五、案例与数据观察：一次立项审批改造的完整过程

前面讲的都是判断和方法，这部分我讲一个真实做过的项目。2024 年 3 月到 9 月，我以顾问身份参与了一家 800 人规模的智能硬件企业（下面简称 A 公司）的立项审批改造。选择这家公司是因为它的问题非常典型：制度齐全、执行走样、数据全无。

1. 改造前的 A 公司：5 级审批，11.5 天平均立项周期

A 公司当时有 5 级立项审批：部门负责人、产品委员会、研发负责人、财务、分管副总。年立项数量大约 240 个，平均审批周期 11.5 天。他们自己的满意度调研显示，62% 的项目发起人认为”立项流程拖慢了业务响应”。

但真正让管理层下决心改的是另一组数据。我们拉了过去 18 个月的台账，发现有 38 个项目存在明显的重复建设特征，涉及估算投入合计约 640 万元。更麻烦的是，其中有 9 个项目的失败原因，和一年前另一个被驳回项目的提示风险几乎一模一样。

2. 改造动作：从 5 级压到 2 级，但增加了 3 个必填字段

我们做的不是”简化流程”，而是把审批的精力从”走流程”转移到”看关键信息”。具体改了四件事。

1. 审批层级从 5 级压到 2 级。保留业务评审（由产品委员会 + 资源方组成）和决策审批（分管副总）。财务、法务、信息安全改为”会签知会”，不参与排期，只在 24 小时内提出否决性意见，不提修改建议。
2. 立项材料新增三个必填字段：不做的损失、自有数据支撑（至少 3 个）、最坏情况与熔断条件。
3. 引入三级分层：20 万元以下简化登记，20 万到 150 万标准立项，150 万以上深度立项。分层标准同时考虑跨部门数量，牵动 4 个以上部门的项目自动升一级。
4. 立项条件挂载到项目执行过程。批准时给出的条件（比如”Q3 前完成 50 家客户验证”）作为独立任务挂到项目台账里，到期未完成自动提醒评审委员。

3. 工具选型：为什么最后选了 PingCode

A 公司原来的立项审批跑在邮件 + 共享表格上，项目执行管理跑在 Jira 上。这两套系统之间没有数据打通，导致”立项条件”和”执行进度”永远是两张皮。

我们评估了四类方案：继续用邮件加表格、用通用协作工具自建、自研一套轻量系统、采用专业的研发管理平台。最终选择了 PingCode，主要基于三个判断。

第一是立项到执行的数据链路能打通。PingCode 的项目管理能力覆盖了从需求、迭代到发布的全过程，立项审批的产物（成功标准、里程碑、条件）可以直接落到项目里成为可跟踪的对象，而不是停留在审批表单里。这一点是通用协作工具做不到的，因为它们没有”项目”这个一等公民。

第二是私有化部署能力。A 公司是硬件企业，涉及供应链和成本数据，信息安全部门明确要求核心系统私有化部署。PingCode 支持私有化部署，这是它进入候选名单的硬门槛。

第三是 Jira 平滑迁移。A 公司的研发团队用 Jira 已经 5 年，积累了约 1400 个 issue 类型配置和大量自定义工作流。迁移最大的风险不是数据搬运，而是工作流语义的丢失。整个迁移我们用了 6 周，分三批完成：先迁一个 30 人的试点团队跑两周，再迁两个部门，最后全量。迁移过程中保留了原有的 issue 类型映射关系，团队几乎没有重新学习的成本。

我要说明的是，PingCode 主要服务中大型企业及 100 人以上组织，A 公司 800 人的规模正处在它的典型服务区间。如果你的团队只有 20 人，用这类平台大概率是杀鸡用牛刀，用轻量工具加一张强约束的立项表单就够了。

4. 改造后 12 个月的数据变化

改造从 2024 年 4 月启动，6 月上线新流程，我们对比了上线前 12 个月和上线后 12 个月的数据。有几个变化超出了我的预期。

立项周期从 11.5 天降到 4.2 天，这个在意料之中。材料一次通过率从 42% 升到 81%，这个也没太意外，因为必填字段明确了，发起人知道该写什么。

真正超出预期的是重复立项率从 18% 降到 6%。我原本估计能降到 12% 就不错了。后来复盘发现，主要贡献来自”战略闸”里那个”公司里是否已有类似项目”的必填项，它逼着发起人去查，而查这个动作本身就拦住了大部分重复。

另一个超出预期的是结项复盘完成率，从 23% 涨到 88%。原因很简单：我们把结项复盘做成了项目关闭的必填步骤，不填就关不掉。这听起来像是”用流程强制”，但它的前提是复盘模板很短，只有 5 个问题，15 分钟能填完。如果模板有 30 个字段，强制只会催生敷衍。

六、落地清单：从立项前到结项复盘的 12 个动作

这部分是可直接抄的清单。我把它拆成三个环节：立项前、评审中、立项后。每个动作都标注了负责人和完成标准，你可以直接对着改自己公司的流程。

1. 立项前：3 个动作，决定材料质量的 80%

动作一：强制查询同类项目。发起人提交前必须检索组织内已有的在途和已结项项目，并在申请表里写明检索结果。完成标准是能说出”如果存在同类项目，为什么不能复用或合并”。

动作二：收集至少 3 个自有数据点。不是行业报告数字，是自己组织能追溯的数据。完成标准是每个数据点都标注来源系统或来源人。

动作三：做一次 30 分钟的”预评审”。由业务负责人和一位资源方参加，只有两个议题：这件事必须做吗？人从哪来？预评审不通过的项目不用写完整材料，直接省下 2 到 3 天。

2. 评审中：4 个动作，把评审会从 90 分钟压到 40 分钟

动作四：材料提前 48 小时发出，且设”未读不参会”规则。我在 A 公司推这一条时遇到过阻力，但效果非常明显：评审会上的信息同步时间从平均 35 分钟压到 8 分钟。

动作五：评审问题限定在四道闸门框架内。每位委员的提问必须落在战略、价值、资源、风险四类中的一类，避免发散到技术细节。技术细节放到立项后的设计评审。

动作六：现场给出三选一结论。批准、带条件批准、驳回。不允许出现”再完善一下材料下次再议”，这是最容易拖垮流程的结论。

动作七：驳回也必须写清关键假设。驳回理由要写成”我们不认为 X 假设成立，如果未来证明 X 成立，可以重新提交”的形式，并进入组织的立项知识库。

3. 立项后：5 个动作，让审批不白批

动作八：把批准条件转成可跟踪任务。条件必须有人负责、有截止日期、有验证方式，并挂到项目执行台账里。

动作九：设置 1 到 2 个熔断检查点。通常是项目周期的 25% 和 60% 位置，检查核心假设是否仍然成立。

动作十：变更即重评。当项目范围、预算或目标发生超过 20% 的变更时，触发简化版重评审。这一条能拦住大量”温水煮青蛙”式失控。

动作十一：结项复盘设为关闭前置条件。5 个问题、15 分钟填完：目标达成了吗？关键假设哪些被推翻？实际投入与计划偏差多少？如果重来一次会怎么改？有什么可以复用到其他项目？

动作十二：季度立项健康度回顾。每季度看四个数字：驳回率、重复立项率、结项复盘完成率、按期交付率。这四个数字放在一起看，比任何单一指标都能说明问题。

4. 30 天启动计划

如果你想在一个月内把立项审批的基本盘搭起来，可以按下面的节奏走。这个节奏我在两家企业实际跑过，都完成了。

七、不同情况下的取舍：没有最优解，只有匹配

讲了这么多方法，最后必须说清楚边界。立项审批没有普适最优方案，不同的组织形态要做的取舍完全不同。下面四组取舍，是我被问得最多的问题。

1. 取舍一：速度与严谨，取决于你的试错成本

如果做错一个项目的代价是几万元和两周时间，那就应该选速度。如果做错一个项目的代价是几百万和半年，那就必须选严谨。

判断标准可以量化：用”项目平均投入 ÷ 项目平均周期”算出一个试错成本指数，指数越低越应该偏向速度。我见过一家做营销活动的公司，单个项目平均投入 4 万元、周期 3 周，他们把所有立项审批压缩到一张表单加一次 15 分钟确认，效率极高而且完全合理。而一家做工业设备的企业，单个项目平均投入 280 万元、周期 9 个月，它必须有一套完整的立项评审。

不要因为”别人家公司流程很简单”就照搬，也不要因为”大厂都这么严”就照抄。你的试错成本决定了你的流程密度。

2. 取舍二：标准化与灵活性，取决于项目类型的离散度

如果组织里 80% 的项目是同一类型的（比如都是客户定制开发），那么强标准化是对的，甚至可以做到”填完表单自动打分”。但如果项目类型非常分散（既有产品研发、又有市场活动、又有内部系统建设），强行标准化只会让所有人都在填和自己无关的字段。

我的折中方案是“共用主干 + 分支字段”。主干部分（问题定义、成功标准、最坏情况与熔断条件、资源实名）所有项目必填，这部分通常只占 6 到 8 个字段。分支部分按项目类型动态展开，比如研发类项目展开技术风险字段，市场类项目展开渠道与转化字段。

3. 取舍三：集中审批与分级授权，取决于组织的信息对称程度

集中审批的前提是中心对业务有足够的信息优势。如果中心并不比业务更了解情况，集中审批只会变成形式主义。我见过一家集团把所有 30 万元以上的项目都收到总部审批，结果业务部门学会了”把一个 80 万元的项目拆成 3 个 28 万元的项目”，反而制造了更大的管理黑洞。

分级授权的关键不是金额门槛，而是”谁有能力判断这个项目”。建议的做法是按”业务相关性”授权：和本业务单元强相关的项目，由该单元负责人审批，只做备案；跨业务单元的项目，上收到上一层；涉及公司级战略或公共资源的项目，集中审批。

4. 取舍四：通用工具与专业研发管理平台，取决于你要不要闭环

这是一个很多管理者会低估的取舍。表面上这是工具选型问题，实际上是”立项审批是独立动作还是项目全生命周期的一部分”这个定位问题。

如果你只要一个”能提交、能审批、能存档”的流程，通用协作工具完全够用，成本也低。但如果你希望立项审批的产物，成功标准、批准条件、熔断点，能自动流转到项目执行过程中被跟踪，并且结项数据能回流到下一次立项评审，那通用工具会出现明显断层。

（1）四类方案的适用边界

• 邮件 + 共享表格：适合 50 人以下、年立项少于 30 个的团队。成本几乎为零，但无法追溯，无数据聚合。
• 通用协作工具自建：适合 50 到 150 人、项目类型单一的组织。可以做到表单化和留痕，但”立项条件跟踪”需要大量人工维护。
• 专业研发管理平台（如 PingCode）：适合 100 人以上、研发类项目占比高、需要立项到执行闭环的组织。支持私有化部署，支持从 Jira 平滑迁移，对考虑国产替代的中大型企业是比较自然的选择。代价是需要 4 到 8 周的配置与迁移投入。
• 自研系统：适合立项流程有强行业特殊性、且已有稳定研发资源的企业。否则维护成本会长期高于收益。

我在 A 公司的经验是：工具的价值不在于让审批更快，而在于让”批准条件”变成执行过程中不会被遗忘的约束。这一点，只有当你把立项和执行放在同一个数据模型里才能实现。

八、结语：立项审批是组织稀缺的判断力，不是流程的装饰品

写到这里，我把最核心的三个观点再收一遍。

第一，立项审批的唯一目标是提高”通过的项目活下来的概率”，任何不服务这个目标的环节都应该被删掉。材料精美度、审批层级数、评审会时长，这些都不是目标，只是手段，而且经常是无效手段。

第二，立项审批的质量上限由结项复盘决定。如果没人回头看当初的承诺，立项就会自动退化成填表游戏。这条规律我在 9 家企业里看到过完全一致的演化路径，18 个月是一个比较稳定的退化周期。

第三，审批层级压缩到 3 级以内，把省下来的精力投入到”批准条件跟踪”和”熔断检查”上，投入产出比最高。这是我在所有改造项目里反复验证的一条经验。

如果你现在正准备动手改自己公司的立项审批，我的建议是从最小动作开始，不要一上来就重写制度。

第一步，今天就去拉过去 12 个月的立项台账，算出三个数字：驳回率、结项复盘完成率、重复立项率。这三个数字会告诉你问题到底出在哪一环。

第二步，在下一次立项评审会上，只做一件事：把评审问题强制归入战略、价值、资源、风险四类，其他问题一律记录不讨论。你会立刻感受到评审效率的变化。

第三步，从这个月批准的项目里挑一个，给它加一条”带条件的批准”，并把条件挂到可跟踪的任务上，设一个 60 天后的检查点。等这条链路真正跑通一次，你就有了说服组织做更大改造的证据。

立项审批不是一个让人兴奋的话题，它不会像产品发布那样带来即时成就感。但它是组织里少数几个能用几天时间、几页纸，避免几百万元浪费的杠杆点。把这个杠杆用好，比多做三个项目更值钱。