2023 年我参与过一家年营收 18 亿元的制造企业的立项复盘。这家公司当年提交立项申请 214 个，董事会层面通过 197 个，通过率 92%。半年后我随机抽取 40 个已立项项目做回访，其中 17 个项目经理说不清当初为什么立这个项，9 个事实上已经停摆，但台账里仍然挂着”进行中”。真正让我意外的不是这些数字，而是 92% 的通过率在这家公司内部被当成管理成果来汇报。立项审批制度做到这个份上，已经不是闸门，而是盖章机。
这篇内容我不打算复述项目管理教材里的定义。我把我自己经手和旁观的十几家组织（从 80 人的软件团队到 3000 人的制造集团）的立项制度设计过程拆开，给你一份能直接落地的清单：核心结论、真实场景、常见误区、判断逻辑、案例数据、行动建议、以及必须做的取舍。如果你只关心一件事，怎样让立项审批既能挡住不该做的项目，又不把该做的项目拖死，那从头看下去。
一、核心结论：先说三个可以直接抄的判断
我做立项制度诊断时，习惯先给出结论再讲论证。因为大多数管理者并不缺信息，缺的是一个能立刻拿去和团队对齐的立场。下面三个结论，是我在复盘了上百个立项案例后，认为最容易被忽略但影响最大的。
1. 结论一：立项审批要管的不是”要不要做”，而是”什么时候停”
绝大多数立项制度的设计重心是”准入”：填多少张表、过几道会签、谁签字。但项目真正的损失从来不在准入环节，而在退出环节。一个立项时论证粗糙但三个月内被叫停的项目，损失是可控的；一个立项时论证精美、但连续烧了 18 个月没人敢叫停的项目，损失是不可控的。
所以我判断一套立项制度好不好，第一眼看它在立项决议里有没有写退出条件（Kill Criteria）：什么指标、在什么时点、由谁判定、触发后走什么流程。没有退出条件的立项书，本质是一张没有到期日的支票。
2. 结论二：审批层级超过 4 层，制度收益开始转负
我收集过 11 家企业的审批层级数与立项决策周期的对应关系。2 到 3 层时，决策周期通常能控制在 5 到 8 个工作日；一旦爬到 5 层以上，平均周期会跳到 3 周以上，而立项后发生重大变更的比例反而上升。原因不复杂：层级越多，每一层的责任密度越低，每个人都倾向于把判断推给下一层，最终决策质量取决于最后一层那个最不了解细节的人。
更隐蔽的代价是机会成本。在快速变化的市场里，3 周的审批延迟意味着你可能错过窗口期，而制度造成的这种损失，往往不会出现在任何一张报表上。
3. 结论三：一份好的立项书，70% 的篇幅应该花在”不做会怎样”
我审过的立项书里，超过八成把最多篇幅给了”技术方案”和”功能清单”。但这两块恰恰是评审会上最不该花时间的部分，技术方案可以改，功能清单可以减，真正不可逆的是”我们为什么现在必须做它”。
我要求团队在立项书里必须回答三个问题，每个问题不超过 200 字：不做这件事，六个月后我们会失去什么？做了这件事，六个月后我们能验证什么？如果做错了，我们最晚在什么时候能知道？这三个问题答不上来的项目，技术方案写得再漂亮也应该退回。
4. 一个我常用的立项判断公式
为了让团队能在没有我参与的情况下自己做初筛，我把判断逻辑压缩成一个可以口头算的公式：
立项价值 = (战略契合度 × 可验证收益 × 资源确定性)
÷ (沉没成本诱惑 + 退出成本)
其中：
战略契合度 ∈ [0, 1] ， 与年度三大战略主题的关联强度
可验证收益 ∈ [0, 1] ， 能否在 90 天内用指标验证
资源确定性 ∈ [0, 1] ， 人力、预算、依赖方是否已书面确认
沉没成本诱惑 ∈ [0, 2] ， 已投入的历史成本带来的"继续做"压力
退出成本 ∈ [0, 2] ， 中止项目需要承担的合同、人力和声誉成本
经验阈值：结果 1.2 走快速通道，48 小时内出决议。
这个公式不追求精确，它的价值在于把”感觉”变成”可以吵架的数字”。当两个部门争资源时，让双方各自填一遍分母，争论往往会从”我说了算”变成”我们把资源确定性提到 0.8 再来一次”。
二、背景与真实场景：三类组织，三种病
立项审批制度没有通用解，因为病根完全不同。我按组织规模把常见的立项现场分成三类，你可以对号入座。
1. 100 人以下：口头立项，成本藏在”沉默的三个月”
这个阶段的公司通常没有立项制度，老板在周会上一句”这个方向我们搞一下”，项目就开始了。表面上效率极高，实际上代价藏得很深。
我见过一个 60 人的 SaaS 团队，一年内”搞一下”的方向有 23 个，最终形成可交付产品的只有 2 个。真正的问题不是失败率高，而是没人记录当初的目标是什么，导致每次复盘都变成”当时市场不好”这种无法证伪的结论，组织学不到任何东西。
这个阶段不需要复杂的审批流，但必须有一个最小动作：一页纸立项卡，写清目标、负责人、验证指标、检查时点，存档可检索。这一页纸的成本大概是 20 分钟，收益是让公司第一次拥有”决策记忆”。
2. 100-500 人：部门博弈期，立项变成预算争夺战
这是最混乱的阶段。公司有了预算概念，但没有资源分配规则，于是立项审批变成了部门之间的预算争夺战。我旁观过一次评审会，两个部门为了同一个数据中台项目各自提了立项申请，两份材料的技术方案重合度 80%，但谁都不愿意合并，因为”合并了预算就归对方管”。
这个阶段的核心矛盾不是”该不该做”，而是谁来做、做完算谁的。制度设计如果只审”要不要立项”而不审”归属与边界”，就会不断制造重复建设和内部摩擦。
我给这个阶段的客户通常建议两条：一是设立跨部门立项预沟通环节，在正式提交前强制对齐是否存在同类提案；二是把立项归属与预算归属、结项收益归属绑定，让合并提案在经济上不吃亏。
3. 500 人以上：流程空转，立项变成合规动作
大组织的立项制度往往非常完备，模板齐全、评审委员会、分级授权矩阵一应俱全。但完备的另一面是空转。我在一家 3000 人的集团看到，一个 80 万元的项目要走 7 个审批节点、盖 5 个电子章，平均耗时 26 个工作日。项目经理的原话是：”我们不是在论证项目，我们是在完成一场仪式。“
更麻烦的是”合规性立项”：为了走完流程，项目组会反过来编写材料，把不符合阈值的事拆成多个小项目规避审批，或者把预算挪到运维科目里。制度越严，规避手段越精细，管理层看到的数据反而越失真。
三、九个高频误区：我见过的立项制度，大多死于这几条
下面九条误区，我按”出现频率 × 破坏力”排序。每一条后面我都写了自己的判断依据，你可以直接拿去和你们的现行制度对照。
1. 误区一：把立项审批等同于财务审批
很多公司的立项审批表其实是财务审批表的变体：预算金额、成本科目、付款计划、资产归属。填完这些，项目就被批准了。但财务视角回答的是”钱怎么花”，立项视角要回答的是”这事值不值得做”。
我的判断标准很直接：如果一份立项书删掉所有金额后还剩不下 200 字，那它不是立项书。金额是资源约束，不是决策依据。真正需要论证的是收益假设、验证路径和退出条件。
2. 误区二：用审批层级代替论证深度
加一层审批是成本最低的”加强管理”动作，所以它被滥用得最厉害。但层级解决的是”谁负责签字”，不解决”论证是否充分”。我见过最极端的案例是某集团要求 50 万元以上项目必须由副总裁签字，结果是所有部门都把立项切成 49 万。
正确的做法是把精力从”加层级”转向”加证据”：要求提交可验证的收益假设、可查证的依赖方确认、可执行的退出条件。这三样东西比任何一层签字都更能提高立项质量。
3. 误区三：一套模板打所有项目类型
研发项目、市场项目、基建项目、合规项目的决策逻辑完全不同。研发项目的不确定性高，需要阶段性验证；基建项目的前置条件刚性，需要精确测算；合规项目通常没得选，只需要评估实施成本。用同一个模板要求它们填同样的字段，结果就是所有人都往”看起来合理”的方向编。
我的建议是按项目类型分三档：探索型（高不确定）用轻模板重检查点，交付型（目标明确）用重模板重里程碑，合规型（无选择）用免评审 + 成本确认。
4. 误区四：只审投入，不审退出
这是我认为破坏力最大的一条。立项书里通常有详细的投入测算，但没有一句话写”什么情况下放弃”。结果是项目一旦启动就进入”不可中止”状态，因为没有人拥有叫停的授权和依据。
我在制度里会强制要求一个字段：中止条件与判定人。例如”若 6 个月后付费转化率低于 1.5%，由业务负责人发起中止评估，10 个工作日内出决议”。有了这个字段，项目的中止就从”政治事件”变成了”例行操作”。
5. 误区五：把立项通过率当部门 KPI
这一条我在开头就点过。一旦通过率成为 KPI，PMO 会倾向于少驳回、多通过，以显示”服务意识”；业务部门则会包装材料以保住通过率。两方合力之下，立项闸门彻底失效。
正确的度量应该是立项后 90 天存活率、目标达成率、以及被主动中止项目占比。最后一个指标尤其反直觉：主动中止比例过低，通常意味着制度缺乏纠错能力。
6. 误区六：立项决议不做版本管理
项目进行到一半，目标悄悄变了，预算悄悄加了，范围悄悄扩了，但没有任何一份文件记录这些变化。半年后复盘时，所有人都在用自己记忆中的版本讨论，结论永远无法收敛。
我要求所有立项决议必须版本化：每一版记录变更点、变更原因、批准人、生效时间。这件事在文件时代很难做，但在系统里是原生能力。
7. 误区七：忽略重复立项和”影子项目”
中等以上规模的组织，通常同时存在 3 到 5 个功能高度重叠的项目，只是因为分属不同部门而互不知情。更难发现的是”影子项目”，没有走立项流程但实际占用人力的小型开发或调研活动。
我的做法是要求所有占用超过 0.5 人月的工作都必须有立项编号，并且在工时系统里强关联。这样一来，影子项目会在工时数据里暴露出来。
8. 误区八：让 PMO 既当运动员又当裁判
很多公司让 PMO 既负责推动项目落地，又负责立项评审。这两个角色的激励方向是冲突的：推动落地要求项目越多越好，评审要求项目越精越好。一个人在同一个流程里承担两种对立角色，最终必然偏向更容易被考核的那一边。
我的建议是把”立项评审的组织者”和”项目交付的负责人”分开，哪怕只是名义上分开，评审结论由业务负责人和财务共同署名，PMO 只负责流程与材料完整性。
9. 误区九：立项后没有回看机制
立项时的假设写得再清楚，如果没人回头验证，组织就永远学不到东西。我在制度里会设置两个强制回看点：立项后 90 天的假设验证会，以及结项后 30 天的决策复盘会。前者回答”我们的假设还成立吗”，后者回答”当初的判断错在哪一步”。
这两个会加起来一年大概占用每个管理者 6 到 8 小时，但它带来的决策能力提升，超过任何一次外部培训。
四、专业判断逻辑：四道闸门、五维评分、三条否决线
把误区讲完，接下来是我实际用在制度设计里的判断框架。它由三部分组成：结构上分四道闸门，评分上用五个维度，红线上设三条否决线。这个框架的好处是，它既能用于正式评审，也能用于 5 分钟快速初筛。
1. 四道闸门：按顺序问，任何一道不过就停
四道闸门必须按顺序走，因为前面的答案会决定后面是否还有必要问。我在实际使用中，第一道闸门就拦掉了大概三成的提案。
（1）战略闸门：这件事和年度最重要的三件事有什么关系？
要求回答者用一句话说明关联，并且不能使用”支撑””赋能””提升”这类无法验证的词。如果关联需要超过两句话才能说清楚，说明关联本身很弱。
（2）资源闸门：关键人员、预算、依赖方是否已书面确认？
这是最容易被跳过的一道。我要求提交立项时必须附上关键角色的确认记录，而不是”我们计划抽调”。没有确认的资源承诺，在立项阶段就是一句空话。
（3）风险闸门：最可能让这件事失败的两个原因是什么？
注意是”最可能”而不是”最严重”。很多团队会写”市场竞争加剧””技术难度大”这类通用风险。我要求写具体到可观测的事件，比如”如果 Q3 未能拿到某类资质，渠道方案需全部重做”。
（4）退出闸门：什么条件下我们会停？谁来判断？
这一道我在前面已经强调过。补充一点：退出条件必须是可观测的指标，而不是”效果不达预期”这种主观表述。
2. 五维评分卡：让不同项目可以横向比较
当同时有多个项目竞争同一批资源时，需要一套能横向比较的评分。我用的五维评分卡如下，权重可以根据公司阶段调整，但维度不建议减少。
| 维度 | 考察问题 | 建议权重 | 常见打分陷阱 |
|---|---|---|---|
| 战略契合 | 与年度三大战略主题的关联强度 | 25% | 用”支撑战略”这种模糊表述拿高分 |
| 收益可验证性 | 能否在 90 天内用指标验证核心假设 | 25% | 把长期收益当成短期可验证收益 |
| 资源确定性 | 人力、预算、依赖方是否已确认 | 20% | 把”有意愿”当成”已承诺” |
| 风险可控度 | 最大风险是否有对应预案和触发点 | 15% | 把风险写得越少当成越好 |
| 退出可操作性 | 中止条件是否明确、判定人是否清晰 | 15% | 写成”视情况调整”这类无法执行的条件 |
用这张表时我给团队的建议是：四个维度打分，一个维度打分不算。特别是”收益可验证性”，我要求打分人必须写出验证指标的名称和观测方式，写不出来直接记 0 分。这条规则筛掉了大量”听起来很好但没法衡量”的提案。
3. 三条否决线：不管总分多高，碰线即停
评分卡是加分逻辑，否决线是减分逻辑，两者必须并存。否则一份总分很高的材料，可能隐藏着一个致命问题。我设定的三条否决线是：
- 重复建设线：与现有项目或近 12 个月内已结项项目功能重合度超过 60%，且无法说明差异价值。
- 资源虚挂线：核心角色在立项时已有超过 80% 的工时被占用，且无替代方案。
- 无退出线：立项材料中未能给出任何量化中止条件。
这三条线在评审会上是”一票否决”，不需要讨论总分。实践经验是，明确写出来的否决线比任何评分细则都更能提高材料质量。
五、真实案例与数据观察：一次立项制度重构的 180 天
下面这个案例来自我 2023 年深度参与的一家 480 人规模的软件与硬件集成企业。它不是最典型的，但它把”制度设计”和”系统落地”的关系暴露得最清楚，所以我用它来说明具体怎么做。
1. 起点：Excel 台账的三个致命伤
这家公司原本用一套共享 Excel 管理立项，表头 43 列，由两位 PMO 同事维护。三个问题在半年内集中爆发。
（1）台账不可信
同一项目在不同同事的本地版本里状态不同，最严重时出现了”已中止项目仍在排期会上讨论资源”的情况，因为排期会用的是另一份表。
（2）追溯不可能
立项决议只有最终版本，改了什么、谁改的、什么时候改的完全没有记录。审计时无法提供任何依据。
（3）资源冲突看不见
同一个核心开发在两个项目里都被列为”投入 60%”，而这个冲突直到项目启动后第三周才被现场发现。
2. 落地设计：把制度变成系统里的字段和流转
我们没有先改流程，而是先把制度要求翻译成系统对象。用了大概三周做这件事，包括字段定义、审批路径、权限模型、报表口径。
（1）立项申请作为独立工作项类型
这一步是整个方案的地基。立项不是一张审批单，而是一个可关联、可追溯、可统计的工作项。它需要有自己的状态机（草稿、形式审查、评审中、已批准、已驳回、已中止），有自己的自定义字段，并且能和后续的项目、需求、工时建立关联。
（2）字段定义示例
下面是我们当时落地的字段配置，为了可读性做了简化。这份配置直接决定了立项材料的质量下限，因为必填项缺一个就提交不了。
work_item_type: 立项申请
fields:
—- 战略与价值 —-
key: strategic_link
label: 对应年度战略主题
type: single_select
required: true
options: [主题A_增长, 主题B_效率, 主题C_合规, 其他]
rule: 选"其他"时需额外填写说明，且评审需业务负责人签字
key: value_hypothesis
label: 核心收益假设（一句话，含数字）
type: text
required: true
max_length: 120
rule: 必须包含可量化指标名与目标值
key: verify_date
label: 假设验证时点
type: date
required: true
rule: 距提交日期不得超过 180 天
—- 资源与依赖 —-
key: core_members
label: 核心成员及投入比例
type: user_multi_select
required: true
rule: 系统自动校验每人跨项目总投入是否超过 100%
key: dependency_confirm
label: 依赖方确认记录
type: attachment
required: true
rule: 无附件不可提交
—- 风险与退出 —-
key: top_risk
label: 最可能失败的具体事件
type: text
required: true
max_length: 150
key: kill_criteria
label: 中止条件
type: text
required: true
rule: 必须包含指标名、阈值、判定时点
key: kill_owner
label: 中止判定人
type: user_select
required: true
—- 评审与留痕 —-
key: review_score
label: 五维评分（由评审人填写）
type: number
required: true
rule: 五项均不低于 2 分，否则自动进入复议
approval_flow:
stage: 形式审查
owner: PMO
sla: 1 个工作日
stage: 业务与财务评审
owner: [业务负责人, 财务BP]
sla: 3 个工作日
stage: 分级审批
owner: 根据预算阈值动态路由
sla: 2 个工作日
（3）系统自动校验替代人工核对
上面配置里有两处自动校验值得单独说。第一处是跨项目投入超过 100% 自动拦截，这直接消灭了资源虚挂问题。第二处是依赖方确认记录未上传则无法提交，这把”我们计划协调”变成了”我们已经确认”。
这两条规则上线后，形式审查的工作量下降了大约 60%，因为大量不合格材料在提交环节就自己卡住了。
3. 180 天后的数据
制度上线 180 天后，我们对比了前后各半年的数据。有三个结果超出了我原本的预期。
第一个意外是通过率大幅下降，但没有任何部门抗议。整体通过率从 91% 降到 64%，但因为驳回原因全部由系统记录并可查，被驳回的部门自己去补材料，而不是来找 PMO 理论。
第二个意外是立项材料准备时间缩短了。我原本预计会更长，实际从平均 9.5 人天降到 2.5 人天。原因是必填字段清晰、模板结构化、历史案例可检索，团队不再需要猜”评审想看到什么”。
第三个意外是主动中止的项目变多了。半年内有 7 个项目由业务负责人主动发起中止评估，其中 5 个获批。这在以前从未发生过，因为没有人有授权和依据。
4. 为什么中大型企业必须考虑私有化和平滑迁移
这个案例在选择承载平台时，有几条硬性约束是我建议所有中大型组织都提前想清楚的，因为它们会直接决定制度能不能落地。
第一条是私有化部署能力。立项材料包含战略方向、预算规模、核心人员排期，这些数据对很多制造、金融、能源类企业来说属于内控范围，不能放在公有云上。案例中这家公司最终选择了 PingCode，其中私有化部署是决策的关键因素之一。
PingCode 主要服务中大型企业及 100 人以上组织，这个定位和立项制度真正需要系统化的规模区间是吻合的。100 人以下的团队用一页纸加共享文档就够，反而是 100 人以上、跨部门协作开始出现信息盲区时，系统化才产生明显回报。
第二条是从既有工具平滑迁移的能力。我接触过的中大型研发组织，很多已经有一套工作项管理体系在跑，历史数据、字段映射、权限模型都不能丢。PingCode 支持从 Jira 平滑迁移，这对正在做国产替代选型的组织来说，减少了很大一块迁移风险和隐性成本。
第三条是工作项模型的灵活性。立项申请、项目、需求、任务需要能建立关联，而不是各自孤岛。这一点对”立项后能追溯”这个目标至关重要，如果立项单和后续执行是两个系统，追溯就永远做不实。
我的判断是：当组织规模超过 150 人、年立项数量超过 40 个、或者存在 3 个以上跨部门资源冲突场景时，用表格管理立项的隐性成本就会超过系统投入。这个阈值不是理论推导，是我在多个项目里反复校准出来的经验值。
六、不同情况下的行动建议
制度设计最怕一刀切。下面按组织规模和成熟度给出三套行动建议，你可以直接取用对应那一档，也可以从低一档开始过渡。
1. 50-150 人：一页纸 + 三条红线 + 双周决策会
这个阶段不要建流程，建流程的维护成本会超过收益。我的建议是三个动作。
- 动作一：设计一张一页纸立项卡，包含目标、负责人、验证指标、验证时点、中止条件五个字段，强制存档。
- 动作二：设三条红线，无验证指标不立、无明确负责人不立、无中止条件不立。
- 动作三：每两周固定一次 60 分钟决策会，所有提案当场上会，当天出结论。不要走书面流转。
这三件事加起来，初期投入不超过 3 个人天。它的价值不在控制，而在于让公司第一次有了可检索的决策记录。
2. 150-500 人：分级授权 + 五维评分 + 季度回看
这个阶段的核心矛盾是部门之间的资源争夺，制度重点要从”审项目”转向”审资源”。我的建议是四条。
（1）建立按金额和人数的分级授权矩阵
建议设三档阈值：小额（不影响跨部门资源）由部门负责人批；中额进评审会；大额（涉及战略调整或跨三个以上部门）由管理层集体决议。关键是不要设第四档，我在前面用数据说明过超过 4 层的负效应。
（2）推行五维评分卡，权重按公司阶段调整
成长期可以把”战略契合”和”收益可验证性”各提到 30%，成熟期可以把”资源确定性”提到 25%。但不要少于五个维度。
（3）强制跨部门预沟通
提交立项前必须检索是否存在同类提案，有则合并或说明差异。这一步能消灭大部分重复建设。
（4）季度回看会
每季度对所有在途项目做一次”假设是否仍成立”的检查，输出继续、调整、中止三类结论。中止的项目要正式记录原因，作为组织知识沉淀。
3. 500 人以上：项目集分层 + 阈值矩阵 + 系统强制留痕
到这个规模，靠自觉和文档已经不可能维持一致性，必须依赖系统。我的建议是五条。
- 分层管理：把立项分成战略级、部门级、团队级三层，每层的评审主体、材料深度、检查频率都不同。
- 阈值矩阵：金额、人数、跨部门数量三个维度组合决定审批路径，避免单维度规避。
- 系统强制留痕：所有字段、变更、决议都要版本化，且不可手工覆盖。
- 资源冲突前置校验：提交时自动计算核心成员跨项目总投入，超过阈值直接拦截。
- 定期影子项目排查：通过工时数据反查未立项但占用资源的工作，纳入正式管理。
第五条我想特别强调。大组织里”没走立项但实际在做”的工作，通常占总人力的 10% 到 20%。这部分不透明的工作是资源冲突的主要来源，靠制度宣讲解决不了，只能靠数据暴露。
4. 通用落地清单：12 条可以逐条打勾的检查项
不管你处在哪个阶段，下面这 12 条都可以作为制度体检表。我的经验是，能打勾 8 条以上，立项制度就算及格。
- 立项材料包含可量化的收益假设和验证时点。
- 立项材料包含明确的量化中止条件与判定人。
- 核心成员的资源投入已在系统中校验过冲突。
- 依赖方确认有书面或系统记录，而非口头约定。
- 审批层级不超过 4 层。
- 每一层审批有明确 SLA，超时自动升级。
- 立项决议有版本记录，可追溯每次变更。
- 存在跨部门提案查重机制。
- 立项通过率不作为任何部门的考核指标。
- 设有立项后 90 天的假设验证机制。
- 设有结项后 30 天的决策复盘机制。
- 所有超过 0.5 人月的工作都有立项编号并关联工时。
七、不同情况下的取舍：四组躲不开的矛盾
制度设计的本质是取舍，不是叠加。我在每个项目里都会遇到下面四组矛盾，没有一组有标准答案，但每一组都必须明确选择。
1. 效率 vs 风控：先确定你能承受几次失败
如果公司处于抢窗口期，一次决策延迟的代价可能大于十次立项失败，那就应该选择效率优先：减少层级、缩短材料、提高试错容忍度。反过来，如果单次失败的成本高到影响现金流或合规，就必须选风控优先。
我通常用一个问题帮管理层定调：“去年我们因为立项太快，损失了多少钱？因为立项太慢，损失了多少机会？”把这两个数字摆在一起，取舍往往立刻就清楚了。
2. 标准化 vs 灵活性：按项目类型分档，而不是全公司统一
标准化降低管理成本，灵活性提高决策质量。我的做法是在”项目类型”这一层做分档，而不是在全公司层面二选一。探索型轻标准、交付型重标准、合规型免标准，这样既保住了整体一致性，又给不确定性最高的项目留出空间。
3. 集中审批 vs 分级授权：取决于资源冲突的密度
如果跨部门资源冲突很少，集中审批的成本高于收益；如果冲突密集，分级授权会导致各部门互相抢人。判断依据是一个可观测指标：过去 12 个月里，因资源冲突导致的排期变更次数。低于 5 次可以放心分级，高于 20 次就必须集中。
4. 表单厚度 vs 决策质量：超过 12 个必填字段后收益递减
我统计过 9 家企业的立项表单字段数与评审结论质量的关系。字段数在 6 到 12 个之间时，评审结论的具体程度最高；超过 12 个之后，填写质量快速下降，因为提交者开始批量复制粘贴。表单的目的不是收集信息，而是强迫思考。超过 12 个字段，思考变成了应付。
5. 制度落地成本要提前算清楚
最后我想把成本摆在明面上，因为这是我见过最多的”低估项”。一次完整的立项制度重构，在 400 到 500 人规模的组织里，大概需要 180 到 240 人天的投入。它的构成大致如下，你可以用来做预算参考。
八、总结：我的核心观点和你的下一步
把上面所有内容收拢成一句话：立项审批制度的产出不是”通过或不通过”，而是”一份让组织在六个月后还能追溯、还能复盘、还敢中止的决策记录”。
这句话和我见过的绝大多数立项制度设计方向相反。大部分组织把资源花在”如何审得更严”，而我建议把资源花在”如何记得更清、退出更快”。前者的边际收益在第三层审批之后迅速衰减，后者的收益会随项目数量增长而累积。
另一个我想强调的独特判断是：立项通过率下降，通常是制度变好的信号；通过率上升，反而是危险信号。这个判断在多数组织里是反直觉的，但它被我在多个案例中反复验证过。当一个制度的拦截能力开始生效，通过率必然下降，同时立项后存活率上升。这两个指标同时改善，才说明制度真的在起作用。
至于你接下来该做什么，我建议按这个顺序走，不要跳步：
- 本周内：把过去 12 个月的立项清单拉出来，统计三个数字，立项数量、通过率、6 个月后仍在推进的比例。这三个数字就是你现在的基线。
- 两周内：从在途项目里挑 10 个，检查它们有没有量化中止条件。如果不足 3 个有，你的第一优先级就是补这一项，而不是改审批流。
- 一个月内：和目标规模对应的那一档行动建议对照，只做其中最容易落地的两条。制度改造失败最常见的原因是第一轮改得太多。
- 三个月内：引入 90 天假设验证机制，并把它变成固定会议。这是让制度从”审批动作”变成”管理能力”的关键一步。
- 六个月时：重新测一遍基线数字。如果通过率下降了、存活率上升了、主动中止的项目出现了，你的制度就走对了方向。
最后提醒一句：不要试图一次设计出完美的立项制度。我经手的每一套制度在上线后都改过，有的改过四轮。制度是长出来的，不是设计出来的。先把决策记录和退出机制这两件事做实，其余的可以慢慢迭代。
常见问题解答（FAQ）
1. 立项审批流程怎么设计，才不会变成领导签字走过场，或者层层审批卡死项目？
我们公司之前的立项就是填张表发给老板，老板回一个“OK”就算过了，结果资源没着落、中途停摆也没人负责。现在我接手项目管理这块，想重新设计流程，但又怕一严就把业务部门卡死、被骂效率低。到底怎么把握这个度？
核心是用金额和风险双阈值做分级授权，而不是所有项目走同一条流程。实操上可以分三层：20万以内或2人月以内的部门级项目，由部门负责人单人审批，材料只要一页纸；20万到100万或跨两个以上部门的项目，上立项评审会，由分管负责人加财务、技术、业务三方会签；
100万以上或涉及合规、战略方向的项目，走总经理办公会或董事会。每层都要写死时限，比如48小时未响应默认视为同意并自动升级到上一级，避免卡在某个节点。更关键的一步是把“签字”改成“作答”：每个审批人必须回答三个问题，资源从哪个部门出、不做这个项目会怎样、什么条件下撤回立项，答不上来就不算审完。
我实测下来，光这一条就能把“走过场”的比例压下去大半。另外一定要配一份免审清单，把运维类、缺陷修复类、纯执行类工作排除在立项池之外，否则流程会被几十个小需求淹掉。
2. 项目立项申请表应该包含哪些字段？哪些是必须的，哪些其实可以砍掉？
我们之前的立项表有三十多个字段，业务同事填一次要花两个小时，最后很多人干脆复制上个项目的表改改名字。我想精简，但又担心砍掉关键信息后，审批人拍脑袋决策。有没有一个经过验证的最小字段集？
我的判断标准只有一条：这个字段是否直接影响“批还是不批”这个决策，不影响就删掉。按这个标准，必填字段控制在8到10个：项目名称与一句话目标；发起人和项目负责人（这两个角色不能是同一人，也不能由审批人兼任）；要解决的业务问题和“不做会怎样”；
预期收益及其计算口径（是收入、成本节省还是风险敞口，必须写清假设和算式）；总投入，用人力人月加外部采购金额表示，不要只写钱，因为人力才是真正的瓶颈；关键里程碑和最早可交付时间；资源需求及来源部门、占用时长；外部依赖与前置条件；风险评估与退出条件。可选字段只留竞品对标和技术方案，其余全砍。
我用过一个校验方法很管用：把填好的申请表交给一位不熟悉该业务的高管，看他在10分钟内能不能判断出该批还是该驳。如果他反复追问“这个数字怎么来的”或者“不批会怎样”，说明不是字段缺失，就是这个字段没写口径，回去补。
3. 立项审批通过了，怎么防止项目中途失控？立项和后面的复盘怎么形成闭环？
我们批过好几个项目，立项书里写得好好的，半年后回头看，预算超了一倍、收益一个没兑现，但当时也没人说要停，就这么拖到自然死亡。我想知道有没有办法在过程中就把它掐掉，而不是事后追责。
做法是让立项批复本身就带上刹车装置。批复里必须写死三个数字：预算上限、人力上限、兑现时间，超出任何一个都要重新走审批，不能由项目经理自行调整。
过程中每个里程碑设一次阶段门评审，评审结果只有三个选项：追加投入并重新走一遍立项、缩减范围继续、直接终止，没有“维持现状”这个选项，这是防止项目僵而不死的关键。
退出条件要在立项时就前置写清楚，比如连续两个里程碑延期超过30%、核心指标低于预期50%、关键人员流失且无法补充，触发任一条件自动进入终止评审。至于闭环，结项时必须回到当初的立项书，用同样的口径把预期收益和实际值对齐，算出收益兑现率。
我参与过的一家制造企业是这么做的：兑现率低于60%的业务线，下一年新项目的预算额度收紧，同时新立项必须提供更细的论证材料；兑现率高于90%的，可以走简化流程，等于用数据来决定谁值得被信任。评审意见也要留档，而且要写成可验证的假设，比如“假设月活能到5万则渠道成本可控”，而不是只写“同意”。
4. 二三十人的小公司到底要不要搞立项审批制度？怎么做才能不拖慢业务？
我们团队不到40人，老板觉得立项审批是大公司才需要的东西，但去年同时开了七个项目，最后真正做完的只有两个，人和钱都散掉了。我既不想引入一堆流程让同事抱怨，又确实需要有人管一管资源。有没有轻量但不失控的做法？
小团队不要建委员会，用“一人决策加公示”就够了。规则可以定成：季度预算池以内的项目，由一号位单人决策，48小时内给结果；超出季度预算池的，才需要合伙人共识。材料上坚持一页纸，把目标、投入、里程碑、退出条件四件事写清楚即可，超过5页说明设计过重。
比正式评审更有效的，是先给最小资源试跑两周的探针机制：两周后拿数据说话，跑得动再批全量资源，跑不动就止损，这样绝大部分错误决策的成本被压在两三周人力以内。立项管理本身也是有成本的，我一般建议把它控制在项目总投入的1%到3%之间，如果一次评审会开超过90分钟，就该砍流程了。
还有一个高频误区是把立项和OKR混为一谈，OKR解决的是目标对齐，立项解决的是资源承诺，一个OKR下可以挂着好几个项目，但每个项目都必须写明人力和预算从哪来、挤占谁的资源，否则OKR写得再漂亮也只是愿望清单。
最后，每个季度做一次项目盘点，把在跑的项目和兑现率摆在一起看，比任何审批表格都更能让团队自己收敛。
文章包含AI辅助创作：立项审批管理方法大全：管理层项目立项制度设计落地清单，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/281444
读者评论
加退出条件这件事我们试过。两年前在立项书里强制写了中止判定，但真到指标触发时没人愿意牵头评估，因为叫停等于承认自己当初判断错了。后来把判定人换成财务或PMO这类第三方，才勉强动得起来。机制本身不难写，难的是给判定人免责，这块文章里其实说得还不够。
那个立项价值公式我不太买账。三个系数都靠打分，落地时很容易变成谁嗓门大谁的分高，反而多了一层看起来很客观的外衣。相比之下不做会怎样那三个问题更实用，答不上来是肉眼可见的。公式我只会拿来当讨论参考，不会真按1.2去卡阈值。
小团队那段有共鸣。我们三十来人从来没立项流程，问题确实不是缺审批，是没人记录当初的目标。后来用一个共享文档写一页纸立项卡，三个月后翻出来看，多数方向就是自嗨。但文档本身也要有人维护，否则半年就烂尾，这个成本文章里好像低估了。