项目价值落地方案：企业管理者开展项目立项的制度设计案例解析

去年年底，我帮一家 320 人的 B2B 软件公司做年度项目复盘，翻出他们当年的立项档案：全年立项 96 个，立项文件平均 4.2 页，签字栏一个不少，流程走得很齐。但当我问”这 96 个项目里，有几个能拿出结项时对照立项承诺的收益数据”，会议室安静了大概十秒，最后项目经理说了一句：11 个。

更有意思的是第二天的追问。我问那 85 个”对不上账”的项目里，有没有人是故意虚报的？答案是几乎没有。真正的原因是：他们的立项制度只管”要不要批”，不管”批完之后拿什么去验证”。立项书是入场券，不是对赌协议。项目一旦开跑，立项时写的那几行收益承诺就再也没人打开过。

这件事让我把过去六年做过的立项制度咨询案例全部拉出来重看了一遍，覆盖制造、软件、零售、医药和两个国资背景的组织，规模从 80 人到 2600 人。我发现一个相当稳定的规律：立项制度做得好不好，跟流程有多长、模板有多厚基本无关，只跟一件事有关，立项时写下的价值假设，在结项时有没有一个强制的、结构化的回看动作。下面我把这套判断逻辑、制度设计结构和落地细节完整拆开讲。

一、核心结论：立项制度的产出不是”批准”，而是”可验证的价值假设”

大多数管理者对”立项”的理解是审批动作：谁提、谁审、谁签字、什么时候给钱。这种理解在项目数量少、老板亲自盯盘的阶段能work，但一旦组织超过 150 人、同时在跑的项目超过 20 个，它就必然失效。因为老板的注意力是稀缺资源，而审批链条会随着人数增长而指数级变长。

1. 立项制度的三种失败形态

我把见过的失败形态归成三类，这三类往往同时存在，只是比例不同。

第一类是”无门禁”。任何需求都可以变成项目，靠的是谁嗓门大、谁跟老板关系近。这种组织的典型症状是项目数量逐年增长但交付质量逐年下降，因为资源被摊薄，每个项目都在等排期。

第二类是”重门禁、轻回看”。立项审得很严，一个项目要过五轮会、填十二张表，但项目结束就是结束了，没人回头对一次账。这比第一类更危险，因为它给了组织一种”我们管得很规范”的错觉，实际上管理成本全部沉没在审批环节，没有产生任何学习效应。

第三类是”一刀切”。所有项目，不管预算 3 万还是 3000 万，都走同一条审批链。结果是 3 万的小项目被拖了半个月，3000 万的大项目反而因为”流程大家都很熟”而草草过会。

2. 我给的立项制度定义

如果把立项制度压缩成一句话，我的定义是：立项制度是一套把”业务想法”转换成”带资源承诺、带验证指标、带退出条件、可以在结项时被审计的价值假设”的组织机制。

注意这里面有四个关键词：资源承诺、验证指标、退出条件、可审计。缺任何一个，制度都会漏气。只有资源承诺没有验证指标，项目会变成”做完就行”；只有验证指标没有退出条件，亏损项目会一直拖到把预算烧完；前三者都有但不可审计，制度就退化成一次性的会议纪要，第二次没人再认真填。

二、真实场景：三种立项失控的现场

抽象讲制度容易空转，我把三个现场的细节还原出来，你对号入座会更快。

1. 现场一：老板一句话就是立项书

2022 年我在一家做工业配件的公司做诊断，他们的”立项”发生在周会上。老板听完销售汇报说”这个方向可以做，小王你牵头弄一下”，小王点头，会议纪要里记一句”XX 项目启动”，这事就算立了。

三个月后我问小王项目的验收标准是什么，他说”老板满意就行”。再问预算，他说”花多少报多少”。这个项目最后花了 118 万，做出来的系统上线两个月后无人使用，悄悄下线了。复盘时老板的原话是：”我以为你们会自己算一下划不划算。”

这个现场的根因不是老板随意，而是组织里没有把”口头指示”转译成”书面假设”的标准动作。口头指示天然是模糊的，它只表达方向，不表达边界；而项目必须处理边界，花多少钱、到什么程度算成功、什么情况下停。

2. 现场二：立项表填得很漂亮，结项时没人回头看

另一家企业的立项表有 21 个字段，包括市场分析、竞品分析、财务测算、风险评估，填完大概需要一天半。我当时抽样看了 30 份，发现”预期年化收益”这一栏的填法高度趋同，基本都是”预计提升效率 20%-30%”或者”预计带来营收增长 500 万”。

问题的关键在于：这些数字是为了通过评审而写的，不是为了日后被检验而写的。它们没有口径、没有计算过程、没有基准值、没有责任人。等到结项时，即使有人想对账也无从对起，你能证明自己没提升 20% 吗？证明不了，因为没人定义过这 20% 怎么量。

我后来统计过，在这类”重审批轻回看”的组织里，项目经理平均每月要花 16 个小时在填表、催签、做汇报材料上。这是纯粹的行政摩擦，不产生任何价值。

3. 现场三：所有项目都走同一条审批链

第三家是某集团下属的技术公司，他们的立项审批固定要过技术委员会、财务、法务、分管副总四个节点。这套流程对预算 800 万以上的项目是合理的，但他们把一个预算 4.2 万、周期两周的报表优化项目也送进了同一条链。

结果是可以预见的：这个两周能做完的项目，光审批走了 23 天，等批下来业务场景已经变了，最后项目取消。更糟的是，业务部门从此学乖了，他们不再立项，而是以”日常优化”的名义偷偷做，彻底绕开了治理体系。

一刀切的审批链会逼出影子项目，这是我在多个组织反复观察到的反直觉现象：制度越僵硬，制度外发生的事情越多。

三、拆解常见误区：把立项当合规流程的五个坑

下面五个误区，是我在复盘时出现频率最高的。它们单独看都不致命，叠加起来会让整套制度空转。

1. 误区一：把”通过率”当成制度健康指标

很多组织会用”立项通过率”来评价审批效率，认为通过率越高说明流程越顺畅。这个指标单独看是误导性的。如果一个组织的立项通过率长期在 90% 以上，几乎可以断定它的立项评审没有起到筛选作用，只是个签批仪式。

我建议把通过率和驳回率成对看。健康区间的经验值是正式评审通过率落在 55%-75% 之间。低于 55% 说明制度太苛刻，业务会把需求藏起来；高于 80% 说明门槛形同虚设。

2. 误区二：所有项目都用一套模板

一套模板管所有项目，看起来是”标准化”，实际是让重要项目被稀释、次要项目被过度管理。正确的做法是按项目类型和金额分层，不同层级用不同厚度的材料。我在第四章会给出具体的分级矩阵。

3. 误区三：立项与预算、人力脱钩

这是隐蔽性最强的一个坑。项目批了，但预算没跟着走，人力也没从部门排期里扣出来。表面上项目已经”立项”，实际上它从来没有真正拿到资源，只能靠成员加班硬撑。

判断方法很简单：看立项决议里有没有明确的资源出处。如果写的是”由相关部门配合”，那这条立项决议等于没有下发。合格的写法是”从产品二组抽调 2 名后端、1 名测试，从 3 月 1 日起投入 60% 工时，为期 4 个月”。

4. 误区四：没有终止条件

绝大多数立项书只有成功标准，没有失败标准。这导致一种普遍现象：项目到了中期已经明显不该继续，但因为没有触发任何”停下来”的条件，只能靠人的主观感受去争论，最后往往是谁的话语权大谁说了算。

终止条件必须是可观测的、带阈值的、有观察窗口的。比如”上线后 8 周内，日均活跃使用率低于 25%，且未达到 40% 的修复目标，则项目进入终止评审”。这种写法才有约束力。

5. 误区五：立项数据不进系统，靠邮件和 Excel 流转

很多公司的立项流程是：Word 模板填好 → 邮件发给评审人 → 评审意见回在邮件里 → 汇总到 Excel 台账。这套方式的致命问题是数据无法聚合。你想知道今年哪一类项目的收益达成率最低，得手工翻 96 份邮件。

立项数据不进系统，制度就无法自我进化。因为制度优化的输入，恰恰来自对历史立项-结项数据的横向分析。

四、专业判断逻辑：立项制度设计的四层结构

讲完误区，我给你一套可以直接照着搭的结构。我把它拆成四层，从入口到闭环，每一层解决一个明确的问题。这四层不是可选项，缺一层制度就会在某处漏气。

1. 第一层：入口分级，解决”谁该被审、审多深”

分级的核心变量有三个：预算金额、跨部门程度、战略关联度。任何一个变量超过阈值，项目就升级。我用得最多的是三级授权矩阵，实际落地时各组织的金额阈值需要按自己的管理半径调整。

这张表看上去平平无奇，但它是整套制度里省钱最多的一层。我统计过，在一家年立项 90 个左右的企业里，C 类项目通常占 55%-65%。把这部分项目的审批周期从平均 11 天压到 2 天，释放出来的管理工时相当于多雇了半个项目经理。

2. 第二层：价值假设结构化，解决”批完之后拿什么验证”

这一层是整套制度的心脏。我给客户设计立项单时，会强制要求填五个要素，任何一个为空都无法提交。这五个要素是：价值假设、量化收益指标、收益口径与基准值、资源承诺、终止条件。

关键在于”口径与基准值”。举个我自己踩过坑的例子：早年我帮一个团队设计立项单，收益指标写的是”提升客服响应效率 30%”。项目做完了，团队说实现了，业务方说没感觉到。争论半天发现，团队算的是”工单平均处理时长”，业务方感受的是”客户投诉率”。指标对了，口径没对齐。

从那之后我在所有立项单里加了一个必填字段：这个指标的当前基准值是多少、由谁在哪个系统里取数、多久取一次。这三句话写完，扯皮的空间基本就没了。

（1）立项单的字段结构示例

下面是我在某 320 人企业落地的立项单字段定义，用 YAML 描述的结构，可以直接映射到大多数项目管理系统的自定义字段里。

work_item_type: 立项申请
fields:

name: 价值假设

type: text

required: true

hint: 一句话说清"我们相信做这件事会带来什么改变"

name: 量化收益指标

type: text

required: true

hint: 必须是可计数或可测量的指标，禁止写"提升效率"

name: 收益口径与基准值

type: text

required: true

hint: 当前基准值 / 取数系统 / 取数频率 / 责任人

name: 资源承诺

type: text

required: true

hint: 人员、工时比例、起始日期、持续周期、出处部门

name: 终止条件

type: text

required: true

hint: 可观测阈值 + 观察窗口 + 触发后的动作

name: 项目分级

type: select

options: [A, B, C]

required: true

name: 收益对照责任人

type: user

required: true

hint: 默认不设为项目经理，避免自己给自己打分

（2）为什么收益对照责任人不能是项目经理

这是我在第三个项目里才想明白的细节。最初我把收益对照的责任放在项目经理身上，结果发现对照结果系统性偏乐观，因为项目经理也是最不希望自己被判定为”没做出价值”的人。

后来改成由业务受益方或独立的项目管理办公室来出对照结论，客观性明显改善。这不是不信任项目经理，而是承认一个基本的人性事实：验证者不能同时是被验证者。

3. 第三层：资源承诺与决策权，解决”批了到底给不给资源”

这一层要处理的是权力问题，比流程问题难得多。我的做法是把”决定做不做”和”决定给不给资源”拆成两个独立动作，由不同角色承担。

在 A 类项目上，我通常建议设一个三人决策小组：业务负责人（判断价值）、资源负责人（判断能不能给人和钱）、技术或合规负责人（判断能不能做成）。三个人里任何一个投否决票，项目就不能立项，但否决必须写明理由。

这套机制的好处是把”人情审批”逼到明面上。以前一个项目通不过，提报人不知道是谁挡的；现在否决理由必须书面记录，半年后可以回看这个否决是否正确。让否决也留下数据，是提升制度质量的隐藏杠杆。

4. 第四层：结项回看，解决”制度如何自我进化”

这一层是我看到的组织里最普遍缺失的。大家都在立项上花力气，几乎没人在结项对照上花力气。

我设计的结项回看不复杂，就是三个动作：拉出立项时的收益指标和基准值 → 用同一口径重新取数 → 写一段不超过 200 字的原因分析（为什么达成或没达成）。整个动作熟练后大约 40 分钟，但它产生的东西非常值钱。

因为它会告诉你：哪一类项目的收益假设系统性偏乐观、哪一类业务的执行能力被高估、哪一类评审环节最容易放水。这些结论会反向修正下一年的立项标准。制度因此具备了自我进化的能力，而不是靠某个人拍脑袋改模板。

五、案例与数据观察：一家 320 人企业的立项制度改造

上面四层结构听着完整，但真正落地时的阻力往往来自执行细节。我把一家 320 人 B2B 软件企业的完整改造过程还原出来，包含选型环节的具体考量，你可以直接参考。

1. 改造前的基本盘

这家公司我叫它 H 公司，主营 SaaS 产品，研发人员约占 60%，其余是销售、市场和职能。改造前的立项状态是这样的：

• 全年立项 96 个，数量在三年里从 52 涨到 96，几乎翻倍；
• 立项平均审批时长 11 个工作日，最长的走了 34 天；
• 立项书里含可验证量化收益指标的，占 14%；
• 立项后 3 个月内被终止或事实停摆的项目 31 个；
• 结项时能对照立项承诺做收益验证的项目 11 个；
• 项目经理每月花在填表、催签、汇报材料上的时间约 16 小时；
• 单个被终止项目的平均沉没成本约 26 万元。

这些数字不是我估算的，是从他们的邮件台账和财务付款记录里一个个对出来的。改造前他们甚至没有一个统一的立项编号体系，同一个项目在销售口里和技术口里叫法都不一样。

2. 我们做了四件事

第一件事，建立分级授权矩阵。按第四章那张表落地，C 类项目砍到 2 天审批，A 类项目集中到委员会。这一步阻力最小，效果最直接。

第二件事，重写立项单，从 21 个字段砍到 9 个字段。砍掉的是市场分析、竞品分析这类”看起来很专业但没人真用”的内容，留下的是五个强制要素加四个管理字段。字段少了，但每一个都必须填实，填不实就退回。

第三件事，引入预审环节。每周三上午固定为预审窗口，由项目管理办公室的一名成员花 30 分钟过一遍本周提交的立项申请，材料不全的直接退回补充，不进入正式评审。这一招把正式评审的一次通过率从 41% 提到了 74%。

第四件事，也是最关键的一件，把立项到结项的全过程搬进系统。这一点决定了前面三件事能不能持续。如果还在邮件和 Excel 里流转，三个月后一切照旧。

3. 系统落地：为什么选了 PingCode

H 公司的选型条件比较硬：研发团队 200 人原本用的是海外工具，需要平滑迁移；金融行业客户要求数据不出境，必须支持私有化部署；同时要跟现有的 LDAP 打通，避免再做一套账号体系。

他们最后选了 PingCode。我没有拿任何推荐费用，这里只讲我在落地过程中观察到的实际适配点。

PingCode 主要服务中大型企业及 100 人以上组织，这个定位跟 H 公司的规模和复杂度是匹配的，他们需要的是能承载分级授权、多项目并行、跨部门协作的体系，而不是一个轻量看板工具。选型时我也评估过几款面向小团队的国产工具，在自定义工作流和多层级权限上明显吃不住，用到 A 类项目就变形了。

第二个关键点是支持 Jira 平滑迁移。这件事的难度被严重低估。H 公司原来在 Jira 上有 1200 多个 issue、几十个自定义字段、大量附件和评论。如果迁移过程中历史数据丢失或者字段映射错乱，团队会对新系统立刻失去信任。他们实际的迁移节奏是：先在两个试点团队做了两周的字段映射验证，把原 issue 类型映射到项目工作项类型、把自定义字段逐一对照，确认无误后再做全量迁移，全量迁移本身只花了一周。

整个过程里我最关注的一点是评论和附件的历史保留，很多迁移工具会丢这两块，而这两块恰恰是团队做结项回看时最常翻的东西。

第三个点是私有化部署。对 H 公司来说这不是加分项而是准入门槛，因为他们的客户里有需要做数据合规审计的机构。私有化部署带来的额外成本是运维人力，大约每月 4 小时，相比满足合规要求带来的签约可能性，这个成本可以接受。

（1）我们具体怎么把它用起来

落地方式不复杂，但有几个细节值得说。

我们把”立项申请”做成一个独立的工作项类型，把第四章那 9 个字段配成自定义字段，其中五个设成必填。工作流状态设计为：草稿 → 预审 → 价值评审 → 资源确认 → 已立项 → 执行中 → 结项对照 → 已关闭 / 已终止。分级字段决定工作流走哪条分支：C 类项目从”预审”直接跳到”已立项”，A 类项目必须经过”价值评审”和”资源确认”双节点。

另一个用得最多的功能是自动化规则。我们配了三条：里程碑到期前 3 天提醒负责人；里程碑逾期 5 天自动升级给部门负责人；项目进入”执行中”超过 90 天仍未更新状态，自动打上”待复核”标签。第三条规则上线后，长期无人跟进的僵尸项目从系统里被自动揪出来 14 个。

还有一点是数据看板。我们在系统里搭了一个立项-结项对照看板，横轴是季度，纵轴分别是立项数量、收益对照完成率、终止项目数。每季度评审会直接用这个看板开场，不再需要任何人做 PPT 汇总。这个变化听起来小，但它把”数据准备”从一项耗时的工作变成了一件零成本的事，管理层看数据的频率因此上升了一个数量级。

4. 12 个月后的数据

改造满一年后，H 公司的核心指标变化如下。

我特别想指出最后一行的意义。立项制度做对了，项目经理的行政负担应该下降，而不是上升。如果一次制度改造之后，一线的填表时间反而变长了，那基本可以判断方向做反了，你是在加强控制，不是在提升治理。

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

制度设计没有通用解，组织规模、业务复杂度和合规要求会显著改变优先级。我按四种典型情况给出建议。

1. 100 人以下的组织：先把”写下来”这件事做对

这个阶段的组织最不需要的是复杂流程。你真正缺的是把老板的口头指示转化为书面假设的习惯。

1. 只做一件事：任何一个超过 2 人、超过 2 周的事情，必须有一张不超过半页的立项卡，包含价值假设、验收口径、负责人三项。
2. 不设评审委员会，由业务负责人和一名技术负责人双签即可。
3. 结项时做一次 15 分钟的对照，口头结论也要记录在项目卡上。
4. 不要采购重型工具，一张结构化表格加上固定的每周评审时间就够了。

这个阶段的目标不是治理，而是建立”所有项目都有书面假设”的组织肌肉记忆。肌肉记忆建立了，规模上去之后制度才有承载的基底。

2. 100-500 人、多业务线：分级授权 + 系统承载是主线

这是最典型的场景，H 公司就落在这个区间。核心矛盾是资源冲突，而不是流程缺失。

1. 先落地第四章的分级授权矩阵，金额阈值按自己的管理半径设定，初期可以保守一点，跑三个月再调。
2. 把立项单字段砍到 10 个以内，但五个强制要素一个都不能少。
3. 建立固定频率的评审窗口（我推荐每周一次 90 分钟），而不是随到随审。批量评审能显著提升决策一致性。
4. 把立项到结项搬进系统，配套三条以上的自动化提醒规则，重点盯长期不更新的项目。
5. 每季度用系统看板做一次立项-结项对照回顾，把结论写成一页纸发给所有业务负责人。

3. 500 人以上、强合规或多法人：资源承诺与审计留痕优先

这个规模的组织通常已经有立项流程，问题往往出在”流程有了但执行变形”和”多法人主体之间口径不统一”。

优先级建议调整为：第一，统一立项编号与字段口径，确保跨法人主体的数据能聚合；第二，把资源承诺做成可被审计的书面记录，包括人员、工时比例、期间、出处；第三，建立否决理由的书面留档机制，这是防止审批权力滥用的最有效手段。

这个阶段我不建议再增加审批层级，而应该增加事后审计。抽查 10% 的立项项目做完整对照，比让所有项目多过一道审批有效得多。

4. 正在从海外工具迁移的组织：迁移质量决定制度落地成败

如果你的组织立项数据已经在某个海外项目管理工具里积累了几年，迁移这一步必须当成独立项目来做，而不是当成一次 IT 操作。

1. 先做字段映射清单，逐条确认原系统的自定义字段在新系统里对应什么。这一步至少要花一周。
2. 选两个试点团队做两周的验证，重点检查历史评论和附件是否完整。这两块丢失最隐蔽，但对结项回看是致命的。
3. 确认部署方式。有数据合规要求的组织，必须把私有化部署作为准入门槛而不是加分项。像 PingCode 这类支持私有化部署、同时提供 Jira 平滑迁移能力的国产平台，在这类场景下适配度较高，也是国产替代路径上比较稳妥的选择。
4. 全量迁移后保留两个月的双系统只读期，让团队能随时回查历史数据，减少迁移带来的焦虑和抵触。

七、不同情况下的取舍

制度设计本质上是取舍，不是找最优解。下面四组取舍我在不同组织里给过完全相反的建议，判断依据是组织的具体处境。

1. 严格把控 vs 快速试错

取舍的判断变量是单次失败的代价。如果失败的代价是几十万预算和一个季度的团队精力，那应该严格把控，宁可慢一点。如果失败的代价只是两周时间和一个人，那应该快速试错，把决策权下放。

我在制造业客户那里通常建议偏严格，因为一次产线改造失败可能带来停线损失；在纯软件产品团队那里通常建议偏宽松，因为一个功能试错了下线就行。这两条建议看起来矛盾，其实是同一个判断标准在不同场景下的应用。

一个实用的判断方法：把项目按”可逆性”分类。可逆的（能删除、能回滚、能下线的）走轻量通道，不可逆的（已经签合同、已经动土、已经对外承诺的）走严格通道。

2. 统一模板 vs 差异化模板

统一模板的好处是数据可聚合、培训成本低；坏处是重要项目被稀释、次要项目被过度管理。

我的经验判断是：字段结构统一，字段必填程度差异化。也就是说所有项目都填同样九个字段，但 C 类项目只需要填满其中三个，剩下六个可以留空。这样既保证了数据表结构一致（方便后续聚合分析），又不会让小项目承担不合理的管理负担。

反过来做，不同级别用完全不同的模板，会导致数据无法横向对比，这是我在两三个客户那里踩过的坑。看起来灵活，实际上把制度的数据价值废掉了。

3. 自建 vs 采购

立项管理系统的自建诱惑很大，因为它看起来只是表单加审批流。但我见过至少四个自建项目最终烂尾，原因都指向同一处：自建团队低估了权限体系和跨项目数据聚合的复杂度。

分级授权意味着复杂的角色权限；跨项目数据聚合意味着需要一套能承载多项目、多层级、多维度的数据模型。这两块自己搭，投入远超预期。

我的建议是：100 人以下用通用表格工具就够；100 人以上、项目数量超过 30 个、需要分级授权和跨项目看板的，直接采购成熟的项目管理平台。省下来的自建周期可以用来做制度建设，后者才是真正难的部分。

4. 私有化部署 vs SaaS

这里我想强调一个容易被简化成口号的原则：合规要求是准入门槛，不是加分项。如果一项业务因为数据托管方式无法通过客户审计，那么再便宜、再好用的 SaaS 也是错的答案。反过来，如果没有任何合规约束，私有化部署带来的运维负担就是纯成本。先确认门槛，再比功能。

八、总结与下一步：把立项制度做成能复利的资产

回过头看 H 公司这一年的改造，我最想分享的不是那组从 14% 到 88% 的数据，而是一个更底层的判断：立项制度的价值不在”卡住多少项目”，而在”沉淀多少可复用的判断”。

一个年立项 60 个、每个都能做收益对照的组织，五年后会积累 300 条关于”什么类型的项目在这个组织里能成”的实证经验。这些经验会反向提升立项质量，让下一年的判断更准。这就是复利。反之，一个年立项 150 个、从不做对照的组织，五年后除了疲惫什么都留不下。

还有一个反直觉的结论值得重复：规范化和减负应该同向，而不是反向。H 公司的项目经理行政耗时从 16 小时降到 6 小时，同时立项质量大幅提升。如果一次制度改造让一线更累了，那不是制度在起作用，是流程在膨胀。判断标准很简单，问一线：这次改完，你填表的时间是变多了还是变少了。

最后是具体的下一步，按你现在的状态分三档：

• 如果你现在完全没有立项制度，本周就可以做一件事：挑三个正在进行的项目，让负责人各写一张半页纸的立项卡，包含价值假设、验收口径、责任人。不要设计流程，先建立习惯。
• 如果你有流程但对不上账，下个季度做一件事：把最近结项的 10 个项目拉出来，尝试用它们立项时的承诺做一次对照。大概率你会发现根本对不上，这个发现本身就是推动改革的动力。
• 如果你已经有制度想优化，先算一个数：过去一年终止的项目，平均在第几周被终止，沉没成本是多少。如果终止时点晚于第 8 周，说明你的退出机制需要重做，这通常比优化立项评审带来更直接的经济回报。

制度设计的最终目的，从来不是让审批更严谨，而是让组织在下一次做判断时，比上一次更准一点。这条曲线能不能抬起来，取决于你今天有没有把那张立项卡上的三个数字写清楚。