我见过最贵的立项审批，不是被否决的那个，而是被秒过的那个。2023年我参与一家约400人规模的To B软件公司的项目治理改造，翻出上一年度的立项台账：全年通过147个项目，其中只有31个能说清楚”这个项目做到什么程度算成功””谁在什么时间点投入多少人力””什么条件下我们会主动叫停”。剩下的116个项目，立项单上写的成功判据是”按期上线”，而按期上线的定义是”完成开发并部署”，至于上线之后有没有人用、有没有带来收入、有没有把三条产品线的研发资源同时占满，没人记录，也没人复查。
这不是某家公司的问题，是绝大多数把”立项审批”当成”预算审批”的组织会踩的同一个坑。立项审批管理的核心难点从来不是”怎么把流程设计得更严谨”，而是怎么在信息最不完整的时刻，让一群人做出可以事后复盘的资源承诺。下面这篇内容，我会把立项审批的落地方法拆成可执行的清单，包括流程分级、表单字段、评审会节奏、决策结论模板、阶段门复查机制，以及把这些落到系统里时我踩过的坑。
一、先把结论说透：立项审批的产出不是”同意”，是三个可被审计的承诺
先说结论，方便你判断这篇文章后面哪些部分值得花时间。我认为立项审批管理的有效性，只由三件事的定义清晰度决定，其他都是包装。
1. 结论一：立项审批的最小有效产出是”成功判据 + 资源承诺 + 退出条件”
一次立项审批通过，必须同时产出三个可被审计的承诺，缺一个都不算通过。成功判据指的是6个月后可以用什么数据判断这个项目做成了，例如”Q3末目标客户中至少5家上线使用，月度活跃管理员≥30人”。资源承诺指的是谁在什么时间段投入多少人天、哪几个关键角色被占用、这些资源从哪个项目或哪条产品线里挪出来。退出条件指的是什么信号出现时必须叫停或降级，例如”第2个阶段门时业务方使用率低于20%即暂停”。
在数据侧,经过改造的那家企业,立项单上能写清三项承诺的项目占比从2023年的21%提升到2024年的93%,对应的是项目中止决策的前置化，中止发生在第2个阶段门的比例从14%上升到68%,也就是伤害在扩大之前就被截断了。
2. 结论二：分级审批，别用一套流程管所有项目
我见过最典型的低效设计是：一个1人月的小工具开发，要走和千万级平台建设完全相同的六级审批链。结果是两条路同时坏掉，小项目被流程拖死，发起人开始绕过系统用邮件和口头审批；大项目因为审批量太大，评审会变成流水线，每个项目只有7分钟，实质是盖章。
审批强度应该跟随”不可逆成本”缩放，而不是跟随项目数量缩放。我通常用金额和资源占用两个维度做一个二维分级，取两者中更高的那一档。金额小但占用关键角色（如架构师、核心算法工程师）的项目，同样应该走高一级的审批。
3. 结论三：评审会只做决策，不做汇报
把”汇报”从评审会里拿掉，是我做过的所有改造里投入产出比最高的一步。汇报放到前置的预读环节，评审会现场只允许三种发言：补充材料没说清的、质疑数据口径的、给出决策结论和附加条件的。未完成预读的评委不得参会，这条规则我建议写进制度而不是倡议。
4. 结论四：有条件通过必须带”复查日期 + 复查人”
“有条件通过”是立项审批里最容易被滥用的结论。没有复查日期和复查人，它就等价于”通过”，只是让评委心理上舒服一点。我在制度里把有条件通过强制绑定两个字段：条件清单（每条可验证）、复查日期（默认不晚于立项后30天）、复查责任人（必须是评委之一，不能是发起人自己）。
5. 结论五：用两个反向指标监控闸门是否失效
绝大多数公司的立项看板只看”通过数量”和”通过金额”，这两个指标永远在增长，看不出问题。我建议至少加两个反向指标：立项通过率和阶段门主动中止率。我的经验基准是，通过率长期高于90%说明闸门形同虚设，低于40%说明受理端没有做初筛，把否决工作全部推给了评审会；阶段门主动中止率长期低于5%，说明没人真在阶段门做判断。
二、真实场景：一个400人企业的立项拥堵是怎么形成的
这一节讲具体的现场，因为立项审批的方法论只有在具体节奏里才有意义。我参与改造的那家企业，研发人员约260人，产品线三条，2023年的立项流程是这样的：立项申请随时提交，PMO收到后转发给分管副总，副总在周会上口头拍板，PMO事后补录台账。听起来很轻，实际结果是三个月内积压了61份待审申请，平均从提交到获得明确答复要11.4天，发起人普遍反映”不知道卡在谁那里”。
1. 拥堵的真正原因不是审批人多，而是受理端没有统一入口和排会节奏
我复盘了那61份积压申请，发现只有9份是真正需要公司级评审的重大项目，其余52份里，有28份属于部门内可决策范围，只是没人告诉发起人”这个不用上报”。拥堵的第一成因是分级不清，让低价值决策占用了高价值评审资源。
改造后我们做了三件事：把受理窗口固定在每周一和周四（超期提交顺延到下一窗口）；把分级规则写成三条判断句放在申请页面最上方；把公司评审会固定在每周四14:00，16:00，单场最多4项，每项25分钟。三个月后平均答复周期降到3.2天，评审会单场产出从平均2.1项提升到3.8项。
2. 一场25分钟的评审会，时间应该这样切
25分钟不是拍脑袋定的。我们把单项目时间切成三段：发起人陈述8分钟（只讲三件事：要解决什么问题、成功判据是什么、要谁投入多少）、评委提问与答辩10分钟、现场决策与结论记录7分钟。超过25分钟未形成结论的项目，一律转为”暂缓”，要求补充材料后重新排会。禁止在评审会上开放式讨论技术方案，那是技术评审的职责，不是立项评审的职责。
这条规则刚推出时遭到不少反对，有人认为8分钟讲不清一个千万级项目。实际执行后发现，讲不清的原因通常是发起人自己也没想清成功判据，而不是时间不够。我们给发起人提供了8分钟陈述模板，前三个月由PMO陪着演练一次，第四个月起大部分项目能在6分钟内讲完。
3. 预读机制是整套流程的支点
预读的具体做法是：材料在评审会前3个工作日的18:00截止提交，系统自动分发给评委；评委在会前1个工作日完成阅读并在系统里留下至少一条书面意见；无书面意见的评委，系统不生成其参会资格，也不计入决策人数。
这条规则的作用远超预期。它把评委从”现场被动听”变成”会前主动挑”，同时留下了一份可追溯的判断记录，项目后期复盘时，我们能查到当初是哪位评委提出了哪个风险点。在那家企业，预读机制上线后，评审会上因为”材料看不懂需要现场解释”而消耗的时间下降了约62%。
三、拆解七个常见误区：大部分立项审批失效都从这里开始
下面七个误区，是我在三家企业做诊断时反复见到的，排序按出现频率从高到低。每条我都给出识别信号和修正动作。
1. 把立项审批当成预算申请
识别信号：立项单上金额字段必填，成功判据字段可选或根本不存在。修正动作：把成功判据设为必填且要求可量化，金额设为选填但在B档以上要求附带测算依据。预算只是资源的一种表达形式，把它当成立项审批的全部，等于只看成本不看收益。
2. 材料越厚越安全
我见过一份立项材料有38页，其中21页是行业趋势和竞品截图。厚材料的实际功能是心理防御，发起人希望用信息量换取通过率，评委则因为读不完而直接跳过关键页。修正动作：强制材料页数上限（我通常设12页正文，附件不限但评委无阅读义务），并给出固定章节结构。
3. 评审会变成汇报会
识别信号：会议纪要里出现大量”某某总对项目表示认可””建议进一步优化方案”这类无决策含金量的表述。修正动作：纪要模板只允许记录决策结论、附条件清单、复查日期、复查责任人、否决理由五类信息，其他内容不进纪要。
4. 只审”要不要做”，不审”谁来做、什么时候做完、做完怎么算成功”
这是最隐蔽也最致命的误区，因为它不影响审批效率，只影响后期执行。识别信号：项目启动后两周内必有一次关于”这个项目到底谁负责”的争论。修正动作：立项单增加”资源承诺表”，逐行填写角色、姓名、投入比例、起止时间。
5. 所有项目都上公司级评审
识别信号：评审会议程里有明显不属于公司级决策的小项目，同时重大项目的讨论时间被压缩。修正动作：把分级规则写死成金额+资源占用的双维阈值，并授权部门负责人在A、B档内直接决策，但要求100%在系统里留痕以供抽查。
6. 通过即放行，没有阶段门复查
识别信号：项目台账里有”立项日期”和”验收日期”，中间是空白。修正动作：为每个立项项目设定不超过4个阶段门，每个阶段门必须有一个可量化检查项和一个明确责任人，且阶段门结论同样走”通过/有条件通过/暂停/终止”四选一。
7. 用”通过率”考核PMO
这是制度设计层面的错误，一旦把通过率纳入考核，PMO会系统性地避免否决，闸门失效只是时间问题。修正动作：考核PMO的应该是”立项周期中位数””阶段门主动中止率””立项后30天内资源到位率”。
四、专业判断逻辑：三闸门、四张表、六维评分
这一节是我实际使用的一套判断框架。它不是理论模型，是经过多次调整后固定下来的操作结构，你可以直接拿去做适配。
1. 三闸门：受理闸、评审闸、阶段门闸
受理闸解决”这个申请该不该进入评审”，由PMO或指定的受理人执行，判断依据只有三条：是否属于本年度战略主题之一、材料是否齐全、是否走了正确的分级档位。三条中任一不满足，直接退回，不进评审队列，且退回理由必须具体可操作。
评审闸解决”要不要做、怎么算成功、用什么资源做”，由评审会执行，结论只能是四选一：通过、有条件通过、暂缓、否决。四类结论都必须写明理由，且”暂缓”必须写明重启条件，”否决”必须写明何种情况下可重新提交。
阶段门闸解决”做到中途还该不该继续”，由项目发起人和业务方共同执行，不设评委。我的建议是阶段门数量不超过4个，且每个阶段门的检查项必须能在系统里用数据回答，不能是”请描述当前进展”。
2. 四张表：立项单、资源承诺表、风险与退出表、阶段门检查表
四张表的字段设计，我列在下面的表里。核心原则是每个字段都必须有人能据此做判断，否则删掉。很多公司的立项单有40多个字段，实际被评委使用的不到10个。
| 表名 | 关键字段 | 字段设计意图 | 常见错误 |
|---|---|---|---|
| 立项单 | 问题描述、目标用户、成功判据（含数值与时间点）、不做会怎样 | 迫使发起人说清价值和可验证结果 | 成功判据写成”完成上线” |
| 资源承诺表 | 角色、姓名、投入比例、起止时间、资源来源 | 让资源冲突在决策前暴露 | 只写”需投入3人”，不写是谁 |
| 风险与退出表 | 主要风险、触发信号、退出或降级方案、沉没成本预估 | 把”叫停”变成事先约定而非事后追责 | 风险栏写”进度风险” |
| 阶段门检查表 | 阶段门名称、检查指标、阈值、责任人、结论选项 | 让中期评估有据可依 | 阶段门只写时间点不写指标 |
3. 六维评分与权重：把主观判断变成可比的分数
评分不是为了算出一个精确分数，而是为了让不同评委的分歧点显性化。我使用的六维与权重是：战略契合度20%、收益可量化度20%、资源可得性20%、技术可行性15%、风险可控性15%、退出成本10%（此项为反向计分，退出成本越高得分越低）。
判定规则：加权总分≥75为建议通过；60，74为建议有条件通过；45，59为建议暂缓；<45为建议否决。评分只是决策输入，不是决策本身。评委有权在充分说明理由的前提下推翻评分结论，但推翻必须记录在案，这一条让评分体系保持了弹性，同时保留了对偏差的追踪能力。
4. 关键判断原则：先看资源冲突，再看收益
这是我个人的一条经验性排序。绝大多数立项争议表面上是”收益够不够大”，实质是”资源够不够用”。当两个项目收益都很高但只能做一个时，先比较的不是收益差，而是资源购置成本和退出成本的差。收益预测的误差通常很大，而资源约束是当下确定的。
五、落地案例：把立项审批搬到系统里，我踩过的坑和实际数据
流程设计完不代表能跑起来。上面那家企业的流程文件定稿后，前两个月仍然靠邮件和共享表格运转，问题很快暴露：资源冲突查不出来、评审意见散落在邮件里、阶段门到期无人提醒。第三个月我们开始做系统化，选型时把”能承载立项到交付全链路”和”数据不出内网”作为硬性条件，最终落地在 PingCode 上。
1. 选型判断：为什么中大型组织要按”链路完整度”选，而不是按”审批流好不好用”选
立项审批系统化的第一个常见错误，是把它当成一个独立的审批工具来做。这样做的后果是：立项通过后，项目的资源、里程碑、工作项全部要重新录入一遍，数据割裂，阶段门检查拿不到执行数据。
我的判断标准是三条：能不能自定义立项单字段并做字段级权限控制；能不能把审批结论直接转化为项目结构（里程碑、工作项、责任人）；能不能用统一的度量看板回答”立项周期、通过率、阶段门达成率”这几个问题。PingCode 这类面向中大型企业、主要服务100人以上组织的研发管理平台，在第二和第三条上的适配度是我最终选它的主要原因，同时它支持私有化部署，可以让立项涉及的预算和客户信息完整留在内网，另外它支持从 Jira 平滑迁移，能保留历史项目的立项与阶段数据，这对做国产替代且有历史数据追溯要求的团队是实际考虑项。
2. 具体配置：立项单、审批流、项目集三层结构怎么搭
我们实际搭建的结构是：用自定义工作项类型承载”立项申请”，用状态流对应决策结论（草稿→待预读→评审中→有条件通过→已立项→已启动／已否决／已暂缓），用项目集，项目，工作项三层结构承接立项通过后的执行，用里程碑承载阶段门。
下面是我当时定义立项单字段用的配置片段，写成了结构化形式，你可以直接对照改成自己平台的字段方案。
work_item_type: 立项申请
fields:
key: strategy_theme # 战略主题
type: single_select
required: true
options: [营收增长, 成本优化, 合规达标, 技术债治理]
key: success_criteria # 成功判据，必须含数值与时间点
type: long_text
required: true
validation: "正则校验必须包含数字与日期"
key: budget_level # 预算档位，驱动审批路由
type: single_select
required: true
options: [A_10万以内, B_10-50万, C_50-200万, D_200万以上]
key: resource_commitment # 资源承诺，逐行填写
type: table
required: true
columns: [角色, 姓名, 投入比例, 起止时间, 资源来源]
key: exit_condition # 退出条件
type: long_text
required: true
key: budget_amount # 金额字段，字段级权限：仅财务BP与分管领导可见
type: currency
permission: [finance_bp, vp]
state_flow:
草稿 -> 待预读 # 提交后自动校验必填字段
待预读 -> 评审中 # 预读满48小时且评委留痕数>=3 自动流转
评审中 -> 已立项 # 结论=通过，自动创建项目并套用模板
评审中 -> 有条件通过 # 必填条件清单、复查日期、复查责任人
评审中 -> 已暂缓 # 必填重启条件
评审中 -> 已否决 # 必填否决理由与可重提条件
这段配置里最关键的两处是审批路由和字段级权限。审批路由按 budget_level 自动决定节点，避免发起人选错档位；字段级权限则解决了立项审批里一个很现实的矛盾，财务需要看金额，技术评委只需要看方案，把金额对技术评委隐藏，能显著减少讨论被带偏到预算数字上的概率。
3. 三个真实踩坑
（1）把状态流设计得太细。最初我们设计了11个状态，包括”待财务复核””待技术复核””待分管领导确认”等，结果发起人搞不清当前卡在谁那里，PMO每天要回答十几遍同样的问题。后来压缩到6个状态，用审批节点而不是状态来表达中间环节，问题消失。
（2）阶段门提醒只发给项目经理。第一版自动化规则把阶段门到期提醒发给了项目经理，结果连续两个阶段门被静默跳过。原因是阶段门的实际决策人是业务方，项目经理没有动力去推动一次可能叫停自己项目的评审。改成同时提醒业务方负责人和PMO后，阶段门按期执行率从51%升到89%。
（3）过早引入评分排名。我们一度在系统里做了立项申请的自动评分排名，并按排名决定排会顺序。执行一个月后，发起人开始针对评分规则优化材料措辞，评分与后续实际表现的相关性反而下降。最终我们取消了自动排名，评分只作为评委参考，排会顺序回归按战略主题归类和提交时间。
六、不同情况下的行动建议
下面的建议按组织规模和业务特征分层。你可以先找到最接近自己的一档，再往上一档看半条，只做当前档，通常会在一到两年内遇到上限。
1. 50人以下团队：只做一张表和一个结论
- 立项单压缩到一页，字段只保留四个：要解决什么问题、成功判据（含数值与时间点）、需要谁投入多少、什么情况下不做了。
- 不设评审会，由创始人和业务负责人当场做结论，但结论必须在共享文档里留痕，包含日期和决策人。
- 不设阶段门，改为每月一次的项目清单复核，重点只看一件事：上个月那个成功判据有没有往前走。
2. 100至500人组织：建受理窗口、分级审批、预读机制
- 把受理窗口固定为每周两次，超期顺延，避免”随时提交、随时等待”。
- 按金额和资源占用做四档分级，A、B档授权部门负责人决策，但要100%留痕。
- 建立预读机制，未留书面意见的评委不计入法定人数。
- 评审会固定时间、固定时长、单场项目数上限。
- 为每个通过项目设不超过4个阶段门，检查项必须可用系统数据回答。
3. 500人以上或多事业部组织：统一规则、分布执行、集中度量
- 总部只定义分级阈值、材料模板、结论枚举、阶段门规则四件事，具体评审由事业部执行。
- 统一度量口径，按季度输出立项周期中位数、通过率、阶段门主动中止率三项指标，按事业部对比但不排名。
- 建立跨事业部资源冲突仲裁机制，由PMO牵头，冲突升级时限不超过3个工作日。
4. 强监管或数据敏感行业：把合规评估设为强制前置
- 合规与安全评估从”评审时提及”改为”受理前附件”，无评估意见不接受提交。
- 敏感数据相关字段做字段级权限控制，评审材料按角色脱敏。
- 优先采用可私有化部署的管理平台，确保立项材料、预算与客户信息不出内网。
5. 从外部研发管理平台迁移的场景：保留历史立项记录的可追溯性
很多团队在立项审批系统化时会遇到历史数据迁移问题。我的建议是不要把历史立项数据只做一次性导出归档，而要尽量保留其结构与查询能力，否则两年后做项目复盘时无法回溯当初的决策依据。这也是我在选型时看重平台迁移能力的原因，支持从既有平台平滑迁移的管理平台，能让历史立项单、评审结论、阶段门记录保持可检索状态，对国产替代且有历史追溯要求的团队是实际加分项。
七、不同情况下的取舍：没有全都要的方案
立项审批管理里几乎每一个决策都是取舍。下面五组取舍我在不同企业都遇到过，把两边的代价写清楚，方便你自己选。
1. 审批效率与风险控制
取效率意味着接受一定比例的”错放”，取控制意味着接受一定比例的”错杀”和更长的周期。我的经验是：错放的成本通常是可逆的（阶段门还能叫停），错杀的成本往往不可逆（机会窗口和人心的损耗）。因此我倾向于把闸门收紧放在受理端和阶段门，把评审端放宽，让更多项目有机会进入小规模验证，而不是在评审会上做生死判断。
2. 统一标准与事业部自治
统一标准便于横向比较和资源统筹，代价是对业务差异大的事业部会显得不适配。我建议统一的部分只限四件事：分级阈值、材料模板、结论枚举、度量口径。其他一律下放，包括评审会节奏、评委构成、附加材料要求。
3. 流程刚性与发起人体验
流程越刚性，可追溯性越好，发起人越容易感到被官僚化对待。缓解方式不是放松流程，而是提升流程的可预期性：固定受理窗口、固定评审日、明确时限承诺。发起人抱怨的往往不是”要审批”，而是”不知道要等多久”。
4. 自建系统与采购成熟平台
自建的优势是贴合内部特殊规则，代价是持续维护成本和与其他系统打通的隐性工作量。我的判断依据是：如果立项规则每年变化不超过两次，且需要与研发执行链路打通（这是绝大多数情况），采购成熟平台更划算；如果是纯行政性审批且与研发执行无关，轻量自建或使用通用审批工具即可。对100人以上、需要私有化部署和完整研发链路的组织，选择支持私有化部署、具备项目集与阶段门能力的平台，长期总成本通常低于自建。
5. 度量与考核
度量本身有价值，一旦与考核挂钩就会被系统性优化。立项通过率、材料页数、评审会按时率这些指标，只要跟绩效挂钩，很快就会失真。我建议度量数据只用于诊断和改进，不用于个人考核，且每季度公开口径供全员查验。
八、写在最后：立项审批的独特价值不在”拦住”，而在”提前说清楚”
如果这篇文章只能留下一个判断，我希望是这个：立项审批管理真正解决的问题，不是阻止坏项目，而是让好项目在启动的第一天就拥有可复盘的判据、可追踪的资源和可执行的退出线。一家公司立项审批做得怎么样，不用看流程文件写得多漂亮，只用问三个问题：通过的每个项目，能不能在30秒内说出它的成功判据；资源承诺表里有没有具体到人；过去一年有没有项目是在阶段门被主动停掉的。
如果三个问题的答案都是否，那不是执行问题，是设计问题。也不必一次改完，动起来的顺序我建议是：先改立项单字段（一到两天能完成，收益立刻显现），再建受理窗口和预读机制（约两周形成习惯），最后把它落到管理系统里并加上阶段门提醒（一到两个月）。工具选型上，看两条就够：能不能承载从立项到执行的完整链路，能不能满足你对数据不出内网的要求。
下一步你可以直接做的一件事：把现在正在跑的五个项目调出来，试着用一句话写出每个项目的成功判据，要求包含数值和时间点。写不出来的那些，就是你下次立项审批流程改造的起点。
常见问题解答（FAQ）
1. 立项审批到底要审哪些内容，有没有一份能直接抄的审批清单？
我们团队第一次搭立项流程的时候，我作为项目成员被拉进评审会，结果四十分钟里有一半时间在争论项目该挂在哪个部门、名字怎么起，真正该问的收益和风险反而没人提。后来我就特别想知道，一份不啰嗦、又能拦住问题的审批清单到底长什么样。
把审批项压缩成四块、九到十二个必填字段就够了。第一块是价值与目标：要解决什么问题、成功指标用什么口径衡量、不做会怎样。第二块是范围与交付：首期做什么、明确不做什么、关键里程碑日期。第三块是资源与成本：人力工时、外部采购、预算上限。第四块是风险与责任：最大的三个风险、风险责任人、最终决策人。
判断依据很简单，任何一块答不上来就退回补充，不要在会上现编。审批表单尽量控制在一页之内，我们实测超过二十个字段的表单，填写质量会断崖式下降。我们后来把字段收敛到九个必填加三个条件必填（涉及采购、外包、数据合规才填），平均审批时长从六天半降到两天出头。
2. 我不是项目经理，只是被拉进项目的成员，立项阶段我到底要交什么？
我第一次当项目成员的时候，PM 在群里说“大家准备一下立项材料”，我完全懵，不知道哪些是我该写的、写到什么程度算合格。最后我交了一段很虚的描述，被退回来三次，白折腾了一周。
成员在立项阶段只需要交三样东西，不要越界去写整体商业论证。第一是自己的工作量估算，把任务拆到能估出天数的粒度，同时给乐观和悲观两个数。第二是依赖清单，写清楚需要谁、在什么时间点、交付什么东西给你。第三是自己职责范围内能感知到的风险登记。
判断依据是“最小可估算单元”，一个任务如果你估不出天数，说明它拆得还不够细；PM 汇总时，成员提交估时偏差超过百分之五十的项必须附一句说明。一个很实用的动作是：提交前每个人自己写一句“如果这个环节延期，我会在第几天发出预警”，这句话能明显减少立项后前两周的救火。
3. 商机很急，立项审批走完要两周，能不能先开工再补流程？
客户那边催得紧，走完整立项审批两周就过去了，可我心里也发虚，万一先干起来最后没批，投入算谁的。这个问题我纠结了很久，也见过同事因为“先采购后立项”被通报。
建议用分层放行，而不是一刀切地禁止或放行。按金额、风险和是否涉及对外承诺分三档：低档走备案制，二十四小时内自动通过、事后抽查；中档走简化审批，一个决策人签字即可；高档才开完整评审会。先开工的硬性前提是“可回退”，也就是立项被否时，已投入的工作不会产生不可撤销的对外承诺或大额沉没成本。
落地做法是设一个“预立项”状态，允许做调研、方案比选、客户访谈，但不允许采购、签约、对客户承诺交付日期。这条边界划清之后，我们把紧急项目的平均启动等待从九天压到一天，同时没有出现过未批先采购的事故。真正危险的不是快，而是边界不清。
4. 怎么判断我们的立项审批是真在起作用，还是大家点个同意走过场？
我们的流程文档写得很漂亮，模板也齐全，但我总觉得大家就是扫一眼点同意。我想知道有没有能拿数据说话的办法，判断这套审批到底是真把关还是形式主义。
看三个指标，比看通过率有用得多。第一是退回补充率，健康区间大概在百分之十五到三十，长期低于百分之五，基本说明评审环节没在挑问题。第二是立项估时与结项实际工时的偏差中位数，持续高于百分之四十，说明立项的估算环节已经失效。
第三是变更率，立项后发生范围重大变更的次数，如果每月超过一次，通常是前期范围定义太粗。做法上，每月抽十条立项记录回看，核对当时的假设是否成立、登记的风险有没有真的发生、有没有人跟进。特别提醒一句：不要拿审批通过率或流程覆盖率当 KPI，那只会催生走过场。
我们曾经把通过率设成考核指标，三个月内通过率到了百分之九十九，同期项目延期率反而上升；换成盯退回补充率之后，评审质量才明显好转。
文章包含AI辅助创作：立项审批管理方法大全：项目成员项目立项实操方法落地清单，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/283226
读者评论
预读规则写得漂亮，但真正卡住的是评委席上的高管。我们试过“不留言不给参会资格”，结果副总让秘书代写一句“已阅”，系统拦不住，反倒多了一道形式主义。后来改成会前把材料关键页压成三页摘要发出去，才有点效果。制度能约束的只有愿意被约束的人，这条建议在写进制度前最好先想想谁会第一个绕过去。
通过率那段我持保留意见。我们公司战略是自上而下拆解的，立项基本是承接动作，通过率常年95%以上，但项目确实该做。用单一阈值判断闸门失效容易误伤。反倒是“阶段门主动中止率”更实在，问题是没人愿意当那个喊停的人，这比设指标难得多。
退出条件写得不难，难在执行时谁开口。发起人是利益相关方，PMO缺业务判断，评委散会后各回各家。我们最后把阶段门复查绑进季度经营会，用同一套财务口径过一遍，才勉强转起来。8分钟陈述我赞同，但前提是受理端能顶住发起人“让我多讲两页”的压力。