项目价值落地方案：企业管理者开展项目立项的入门指南案例解析

2023 年我接手一家 800 人规模离散制造企业的 PMO 时，做的第一件事不是建流程，而是把过去两年通过的 217 份立项书全部调出来，逐份对照 12 个月后的经营数据。结果很难看：89 个获批项目里，只有 31 个能在财务或运营报表上找到对应的可量化收益，占比 34.8%；有 11 个项目连”是否真正上线”都需要打电话向业务确认。更刺眼的对比是，收益无法追溯的那批项目，平均立项材料厚度是收益可追溯项目的 2.6 倍，材料写得越厚，越没人对结果负责。

这不是某个团队的偶然失误，而是一种系统性偏差：大多数企业把立项当成”写材料、走审批、拿预算”，而不是”签一份可被证伪的价值合约”。材料是写给审批人看的，合约是写给 12 个月后的自己看的，两者要求的能力完全不同。

这篇文章不讲模板范本，而讲我在这家企业（下称 H 公司）以及后续几家客户现场验证过的一套方法：立项三张纸 + 价值落地四道闸门。文中数据来自我参与的 H 公司内部立项复盘样本（N=217）与后续三个咨询项目的跟踪记录，属于单一组织的经验样本，不作为行业基准，但它的结构性问题在 100 人以上的组织里反复出现。

一、核心结论：立项的本质是”价值假设签约”，不是”资源申请”

先把结论摆出来。如果你只记住这一节的四句话，后面所有方法都可以推导出来。

1. 结论一：立项书唯一的硬标准是”可证伪”

一份立项书里最重要的不是”我们要做什么”，而是”我们凭什么认为做完之后某个业务指标会变，以及如果没变，我们怎么承认自己错了”。

我审过的立项书里，超过七成写着”提升效率””优化体验””加强管控”这类无法证伪的目标。无法证伪的目标，等于自动获得永久免责权，项目做完了，没人能说它失败，也没人能说它成功。这就是为什么很多企业项目越做越多，价值感却越来越弱。

2. 结论二：批准的应该是”验证预算”，不是”完整项目预算”

传统立项的隐含逻辑是”这个项目值得做，所以批全额预算”。而价值假设型的逻辑是”这个假设值得花 8% 的成本去验证，验证成立再给后续 92%”。

差别在执行层面非常具体：前者一旦立项，团队规模、服务器采购、外包合同全部锁定，即便中途发现方向错了，沉没成本也让人下不了手砍；后者第一笔钱只买”证据”，不买”完整交付”。

3. 结论三：价值落地靠四道闸门，缺一道就会烂尾

四道闸门分别是：立项门（值不值得验证）、价值门（假设是否成立）、交付门（能否在约束内交付）、收益门（收益是否真的进了报表）。

绝大多数企业的流程只有第一道和第三道，中间的价值门被跳过，最后的收益门干脆没有。结果就是立项时热闹、交付时辛苦、上线后无人认领。

4. 结论四：立项的数字化载体决定后面 12 个月的隐性成本

这一点被严重低估。立项流程如果只是一张 Word 加一封邮件，那么价值假设、验证指标、退出条件、价值责任人这些字段，在项目进入执行期后会全部丢失。团队在执行系统里只看到需求和任务，看不到当初为什么要做。

我的判断是：立项信息必须和执行系统同源，否则制度只能停留在会议室。这也是我后来推动 H 公司把所有立项信息直接建在项目管理系统里的原因，具体做法在第五节展开。

二、背景与真实场景：为什么”立项越严格、失败率越高”

很多管理者会本能地认为，立项失败是因为审批太松。我在 H 公司看到的情况恰恰相反：流程越复杂，失败率越高。原因不复杂，复杂流程会把真正该被审的东西挤出去。

1. 三个我亲历的场景

场景一：一份 42 页的立项书，没有一个可核对的数据源。这是 H 公司 2023 年一个”供应链协同平台”项目，立项书写得非常漂亮，包含背景分析、竞品对标、技术架构、实施计划、风险矩阵。但当我问”改善前订单交付周期的基线是多少、从哪张表取数”时，会议室安静了整整十秒。最后答案是”大概是 15 天左右，具体要问运营”。

项目最终上线了，花了 340 万。12 个月后复盘时，没人能说清交付周期到底变了没有，因为中间换了两次 ERP 报表口径。没有基线的目标，本质上不是目标，是愿望。

场景二：三个部门为同一个需求立了三个项。销售要”客户 360 视图”，客服要”工单统一入口”，运营要”客户健康度看板”。三份立项书描述的数据源、目标用户、上线时间高度重叠，但因为分属三条汇报线，各自过审、各自采购、各自开发。最后的结果是三个入口、两套客户主数据、一笔重复投入约 90 万。

这不是政治问题，而是立项阶段缺少”价值去重”机制。审批人只对”本部门的申请”负责，没有人对”组织整体的价值重复”负责。

场景三：一个被连续批了三年的项目。这个项目每年立项、每年获批、每年延期，三年累计投入 610 万，从未上线。每年立项书的措辞几乎一样，只是把工期往后推一年。没有人叫停它，因为从来没有人在立项时写下”什么情况下必须停”。

2. 三个视角的错位：老板、业务、交付

立项评审最容易出现的僵局，是三方的评价标准根本不在一个维度上。

老板关心的是”这件事和我今年的三件大事是什么关系”，业务负责人关心的是”我今年的考核指标能不能靠它改善”，交付负责人关心的是”资源够不够、时间够不够、依赖能不能协调”。三方都问得对，但立项书往往只回答了其中一方的问题。

我后来在 H 公司强制要求立项书首页只放一张表，把这三种关切映射成三行：战略关联度、业务指标改善、交付可行性，每行必须有具体证据，不能写形容词。评审时间从平均 90 分钟压缩到 25 分钟，但决策质量反而提高了，因为讨论被迫聚焦在证据上。

3. 五类触发源，决定了立项该怎么审

不是所有项目都值得用同一套标准审。我按触发源把项目分成五类，每类的审查重点完全不同。

• 战略要求类：审查重点不是”值不值得做”，而是”哪一部分必须先做、如何验证战略假设”。这类项目不需要 ROI 论证，但必须有阶段性战略验证点。
• 合规驱动类：审查重点是”验收标准是否足够客观”。这类项目最容易成功，也最容易被做大，要防的是范围膨胀。
• 一线痛点类：审查重点是”痛点能否转为可测量指标”。转不出来的，一律退回补充基线数据。
• 竞品跟随类：审查重点是”如果竞品没做这件事，我们还会做吗”。答案是否定的，直接拒。
• 组织内部诉求类：审查重点是”价值责任人是谁、他愿意为哪个指标负责”。找不到人，直接拒。

三、拆解七个常见误区

下面七个误区是我在复盘 217 份立项书时归纳出来的高频问题，按出现频率和破坏力排序。每个误区我都给出识别信号和改法。

1. 误区一：把”需求清晰”当成”价值清晰”

这是最普遍的一个。立项书用大量篇幅描述功能清单、流程图、字段定义，读起来非常专业，但通篇没有回答”这些功能做完，哪个业务指标会变化多少”。

识别信号：立项书里出现”实现……功能”超过十次，但”从 X 提升到 Y”出现不到一次。

改法：把功能清单降级为附件，首页只保留”基线，目标，验证方式”三要素。功能是实现手段，不是立项理由。

2. 误区二：用 ROI 数字装饰立项书

我见过大量写着”投资回收期 8 个月””ROI 达 240%”的立项书，追问计算过程时，通常是一张 Excel 里几个拍脑袋的数字相乘。被装饰的 ROI 比没有 ROI 更危险，因为它给了审批人一个虚假的安全感。

改法：ROI 可以算，但必须标注三个东西，数据来源、口径定义、假设前提。任何一个说不清，就把这一栏删掉，改成”验证方式”。

3. 误区三：没有退出条件

217 份立项书中，明确写了退出条件的只有 9 份。其余项目一旦启动，就只能靠”领导拍板”来中止。

退出条件的价值不在于真的会停项目，而在于它会强制团队在立项时就想清楚”什么信号意味着假设不成立”。写不出退出条件，通常说明这个项目根本没有可验证的假设。

4. 误区四：把审批链长度当成风控

H 公司曾经一个 30 万的项目要走 7 级审批，一个 3000 万的项目也是 7 级审批。审批人越多，责任反而越分散，每个人都认为别人会认真看。

改法：审批强度应该与”不可逆程度”挂钩，而不是与金额绝对值挂钩。可逆的小额投入应该一级审批快速放行，不可逆的大额投入才需要多级。

5. 误区五：立项时不定”价值责任人”

项目里有项目经理、技术负责人、测试负责人，但几乎没人被指定为”价值责任人”，即那个在项目上线 90 天后必须拿数据说话、为业务指标变化负责的人。

没有价值责任人，就会出现一种典型现象：项目上线当天就是团队解散日，所有人交完文档就撤，剩下指标变化无人跟踪。收益无人认领，是价值落地失败最直接的原因。

6. 误区六：把预算一次性批满

一次性批满预算的问题不是浪费，而是剥夺了组织在信息更充分时重新决策的机会。项目启动时信息最少，但恰恰在这时做出了最大金额的承诺，这在逻辑上是反的。

我在 H 公司推的做法是：立项只批”验证阶段预算”（通常为总额的 20%，30%），验证通过后再批交付预算，交付上线后再批运营与推广预算。三期批复，每期都必须有明确的进入条件。

7. 误区七：立项材料与执行系统两张皮

立项书存在共享盘或 OA 里，执行任务存在项目管理工具里，两者之间没有任何字段关联。结果是：三个月后新加入的成员看到的只有任务列表，看不到”为什么做这件事”、”成功了长什么样”、”什么情况下该停”。

改法：立项的关键字段必须成为项目实体本身的属性，而不是附加文档。这一点决定了立项制度能不能真正落地，我在第五节会用一个具体案例说明如何实现。

四、专业判断逻辑：价值落地四闸门与立项三张纸

讲完误区，说方法。这一节是我整套判断逻辑的核心，也是我认为大多数企业真正缺的东西。

1. 第一道闸门：立项门，值不值得验证

立项门回答的问题不是”这个项目好不好”，而是”这个价值假设值不值得花这笔验证成本去证伪”。

通过标准有四条，必须全部满足：基线可测（有数据源、有当前值）、目标可量化（有目标值和达成时限）、假设可证伪（写得出反向证据）、责任可归属（有明确的价值责任人）。

四条中任何一条不满足，都不应该进入下一阶段。立项门的作用不是筛掉坏项目，而是筛掉”说不清”的项目，因为说不清的项目无论好坏都无法被管理。

2. 第二道闸门：价值门，假设是否成立

价值门是整个流程中最容易被跳过、但价值最高的环节。它发生在验证阶段结束时，可能是立项后 30，90 天。

这时候要做的是一次诚实的对照：我们当初假设的业务指标变化，有没有出现？如果出现了，是全部归因于这个项目，还是同时有其他因素？

我在 H 公司立了一条硬规矩：价值门评审必须由价值责任人主讲，而不是项目经理主讲。这个细节非常关键。项目经理讲的时候，他会自然地讲”我们做了什么”；价值责任人讲的时候，他只能讲”指标变了多少，我的判断是什么”。

3. 第三道闸门：交付门，能否在约束内交付

交付门是大多数企业唯一认真在做的一道门，所以我不展开讲流程本身，只强调一个容易被忽略的点：交付门的通过标准应该包含”范围冻结率”。

所谓范围冻结率，指验证通过后到上线前，新增需求的规模占原始范围的比例。我在 H 公司观察到，范围冻结率超过 30% 的项目，按期上线率从 82% 掉到 37%，而且这些项目上线后的收益达成率也明显更低。原因是范围一旦膨胀，交付就变成了”把功能做完”，而不再是”把指标改善”。

4. 第四道闸门：收益门，收益是否真的进了报表

收益门通常安排在项目上线后 90，180 天，由价值责任人和财务或运营数据负责人共同确认。

它的核心动作只有一个：把立项时写下的指标口径，重新在真实数据源里跑一遍。这里有个反直觉的经验，收益门最常见的结论不是”收益没达成”，而是”口径变了，无法比较”。这说明立项时的指标定义不够硬。

我在 H 公司推的做法是，收益门复核必须使用立项时锁定的数据源和计算公式，任何口径变更都要在变更记录里留下痕迹，并同时给出新旧口径下各自的结果。

5. 立项三张纸的模板

我把整套方法压缩成三张纸。不需要复杂的工具，任何组织都可以下一周开始用。下面是可直接复制的结构示例。

# 立项三张纸 · 第一张：价值假设卡
project_code: H-2024-031

value_hypothesis:

statement: "把订单评审环节的平均等待时长从 4.2 天压缩到 1.0 天以内"

baseline:

metric: "订单评审平均等待时长"

current_value: "4.2 天"

data_source: "ERP 订单工单表 / 2024Q1 全量数据"

measured_by: "运营数据中心 王某"

target:

metric: "订单评审平均等待时长"

target_value: "≤ 1.0 天"

deadline: "上线后第 90 天"

falsify_condition: "上线 60 天后降幅不足 30%，或降幅出现但同期订单量下降超 15%"

attribution_note: "需剔除同期组织架构调整带来的审批人变更影响"

owner:

value_owner: "运营副总 张某"

delivery_owner: "IT 经理 李某"

这张卡的关键不是格式，而是三个字段：baseline（基线）、falsify_condition（证伪条件）、attribution_note（归因说明）。绝大多数立项书缺的正是这三个。

# 立项三张纸 · 第二张：资源占用表
resource_plan:

phase_1_validation:

budget: 12 万元

duration: 45 天

headcount: "2 人全职 + 1 人兼职"

exit_condition: "价值假设验证完成并出具对照报告"

phase_2_delivery:

budget: 56 万元

entry_condition: "价值门通过，且基线变化方向正确"

duration: 90 天

exit_condition: "按冻结范围上线，范围冻结率 ≤ 15%"

phase_3_adoption:

budget: 18 万元

entry_condition: "交付门通过，且试点部门使用率 ≥ 70%"

duration: 60 天

exit_condition: "收益门完成复核并出具结论文档"

立项三张纸 · 第三张：退出条件书

exit_rules:

trigger: "验证阶段结束时基线指标改善幅度
action: "终止项目，回收 phase_2 及后续全部预算"

decision_maker: "价值责任人 + PMO 负责人"

trigger: "交付阶段范围冻结率 > 30%"

action: "重新走立项门，评估是否拆分"

trigger: "上线后 90 天目标指标未进入上升通道"

action: "停止推广投入，转入复盘"

trigger: "价值责任人岗位发生变动超过 30 天无人接替"

action: "项目自动挂起，直至指定新责任人"

第三张纸是整套方法里最反常识、也最有效的一张。愿意写下退出条件的团队，立项通过率反而更高，因为审批人看到的不再是一个无限承诺，而是一段有边界、可回收的投入。

五、案例与数据观察：一个 1200 万”必做项目”如何被压缩成 90 天验证

前面讲的是方法，这一节讲一次完整的实战，包含失败的部分。

1. 案例背景

H 公司是一家年营收约 18 亿的离散制造企业，800 余人，订单以多品种小批量为主。2023 年第二季度，销售和运营联合提出一个”全流程订单协同平台”项目，预算 1200 万，计划周期 14 个月，覆盖订单、计划、采购、生产、物流五个环节。

这个项目在当年的立项会上被标记为”必做项目”。理由有三条：客户投诉交付延期增多、各部门数据口径不一致、竞品已经上了类似平台。三条理由听起来都成立，但每一条都无法验证。

2. 第一版立项书的问题

第一版立项书 46 页，内容详尽。我用四道闸门的标准过了一遍，发现四个硬伤。

1. 没有基线。文中写”交付延期问题突出”，但没有给出当前准时交付率、平均延期天数、延期订单占比中的任何一个数字。
2. 目标不可证伪。目标是”实现全流程可视化与协同效率提升”，没有任何可测量的指标和时限。
3. 范围与假设脱节。五个环节全部纳入，但没有任何一页说明”哪个环节是延期的真正主因”。
4. 没有价值责任人。只有项目经理和技术负责人，没有人为”交付延期是否真的改善”负责。

我的判断是：这不是一个 1200 万的项目，而是五个 240 万的项目被捆在一起，用”必做”这个词代替了论证。

3. 重构后的价值假设卡

我们做的第一件事不是砍预算，而是找数据。运营数据中心用两周时间拉了过去 12 个月的订单全流程时间戳，做了一次延期归因分析。结论出乎所有人意料。

在全部延期订单中，订单评审环节的等待时长贡献了 41% 的总延期天数，而计划与采购环节合计只贡献 23%。也就是说，投入最大、最难做的计划与采购模块，对核心痛点的贡献不到四分之一。

基于这个发现，价值假设卡被重写为：基线 4.2 天，目标 1.0 天以内，验证周期 45 天，首期预算 12 万，证伪条件是”上线 60 天后降幅不足 30%”。原计划的五个环节，首期只做订单评审这一个。

4. 90 天验证结果与决策

首期验证做了 45 天开发加 45 天试运行，投入 11.6 万，覆盖两个事业部。第 60 天时，订单评审平均等待时长从 4.2 天降到 2.6 天，降幅 38%，超过了 30% 的证伪阈值。

但同时出现了一个意外信号：其中一个事业部在同期做了审批人调整，该事业部的数据改善幅度明显高于另一个，这提示改善可能部分来自组织调整而非系统本身。我们在验证报告里把这个归因风险如实写了进去。

基于这份报告，管理层的决策是：批准第二阶段，但预算从原计划的 1188 万压缩到 268 万，且只覆盖评审与信息确认两个环节。计划、采购、生产、物流四个模块无限期搁置，等待第二阶段收益门再评估。

第二阶段的最终结果是：上线后第 90 天，订单评审等待时长稳定在 0.9 天，准时交付率提升 11.4 个百分点。整个项目最终花费 296 万，是原预算的 24.7%，但拿下了原项目论证中 41% 的核心痛点贡献。

5. 载体：立项流程怎么落到系统里

案例讲完了，说一个容易被忽略但决定成败的问题：这套方法靠什么承载。

H 公司最初的做法是立项书存共享盘、任务存项目管理工具，两者靠人工同步。结果是第二阶段启动时，新加入的 6 名成员里只有 1 人读过立项书，其余人只知道要做”订单评审优化”，不知道目标值是 1.0 天，也不知道退出条件是什么。

我们后来把所有立项字段直接建到项目管理平台的项目实体上，作为项目的必填属性：基线值、目标值、目标时限、证伪条件、价值责任人、范围冻结率上限。项目一创建，这些字段就跟着项目走，任何一个成员打开项目就能看到。

我们选的是 PingCode。选择理由很具体，不是因为它功能多，而是三点恰好对上我们的约束。

第一，PingCode 主要服务中大型企业及 100 人以上组织，H 公司 800 人的规模、五个事业部并行的立项节奏，需要的是能承载多项目并行、又能把立项属性固化到项目实体上的平台，而不是一个轻量看板工具。第二，PingCode 支持私有化部署，H 公司涉及订单、客户、供应商数据，立项信息里包含营收口径和客户名单，这部分数据不能出内网。第三，我们此前用海外工具管理研发流程，历史数据量大，PingCode 支持 Jira 平滑迁移，历史项目、需求、缺陷的对应关系可以保留，这也是我把它列为国产替代不二选择的原因。

落地后的一个具体变化是：价值门的评审材料不再需要人工整理，评审人直接在系统里调取立项时锁定的基线字段与当前指标看板做对照，单次评审准备时间从 6 小时降到 40 分钟。

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

方法不是一刀切的。不同规模、不同行业的组织，能承受的流程强度完全不同。以下是我在实际项目中给出的分档建议。

1. 100 人以下组织：只做一张卡

不要建流程，不要做门禁，只做价值假设卡。把基线、目标、证伪条件、价值责任人四个字段填完，一份立项书就结束了。评审一个人拍板即可。

这个阶段最大的风险不是项目乱，而是流程把速度拖垮。100 人以下的组织，决策速度本身就是核心竞争力，不要用流程把它换掉。

2. 100，500 人组织：三张纸 + 两道门

这个规模开始出现跨部门协作和信息不对称，建议启用三张纸，但门禁只设两道：立项门和价值门。交付门可以简化为例会跟踪，收益门由财务在季度经营复盘中顺带完成。

关键动作是把立项字段落到项目管理平台，而不是停在文档层。这个规模的组织还没有专职 PMO，靠人工维护流程必然失败，必须依赖系统。

3. 500 人以上或多业务线组织：四道门 + 立项分类分流

这个规模必须解决两个问题：价值重复和审批效率。建议按五类触发源做分流，战略类和合规类走快速通道，痛点类和内部诉求类走标准评审，竞品跟随类默认拒。

同时需要建立跨部门价值去重机制，最简单有效的做法是在立项申请中强制填写”关联项目”字段，由系统自动提示数据源重叠。

4. 强监管与数据敏感行业：先解决数据不出内网

金融、医疗、军工、部分制造业客户数据的行业，立项信息本身就包含敏感口径，这类组织的流程数字化必须先满足私有化部署要求，再谈流程设计。

我看到过不止一个案例，流程设计得很完整，但因为数据合规无法满足，最终又退回到邮件加 Excel，制度随之失效。合规约束不是流程的附加条件，而是流程能否存在的前提。

5. 正在从海外工具迁移的组织：把立项字段一起迁

很多组织迁移工具时只迁需求和缺陷，把立项信息留在原处。这等于把最需要保留的价值上下文丢掉了。

我的建议是：迁移方案里必须包含”立项属性映射表”，明确原系统中的项目描述、目标、里程碑如何映射到新平台的立项字段。PingCode 支持 Jira 平滑迁移，这类映射可以在迁移过程中一次性完成，比起迁完再补要省力得多。

七、不同情况下的取舍

任何方法都有代价。这一节我把常见的几组取舍摊开讲，并给出我的选择倾向和适用条件。

1. 速度 vs 严谨：取决于试错成本可不可逆

我的判断标准不是项目金额，而是错误决策的可逆程度。可逆的（比如内部流程调整、软件配置变更），速度优先，先做再看；不可逆的（设备采购、数据迁移、组织重构），严谨优先，必须走完整闸门。

1200 万的项目里，真正不可逆的部分其实只有硬件采购和外部咨询合同，软件开发部分高度可逆。这意味着整个项目完全可以拆成”可逆部分快速试、不可逆部分慢审”。

2. 统一流程 vs 业务自治：取决于业务差异度

业务线差异大（比如既有制造又有 SaaS 又有渠道分销），统一流程会变成形式主义；业务线差异小，放任自治会导致价值重复和数据口径混乱。

我的折中是：统一立项字段，不统一评审流程。字段全组织一致（因为要横向比较和去重），评审谁参加、开几次会，由业务线自己定。

3. 一次性大预算 vs 分期小验证

分期验证的代价是管理成本增加和采购议价能力下降。如果你的组织每年立项数量少于 15 个，分期带来的管理成本可能超过收益；如果超过 40 个，不分期的沉没成本几乎一定超过管理成本。

4. 自建 vs 采购 vs 私有化

关于私有化部署这一点，我的态度比较明确：如果立项信息包含客户名单、营收口径、供应商数据，公有云 SaaS 带来的合规沟通成本，通常高于私有化部署的运维成本。PingCode 支持私有化部署，这也是它在数据敏感行业里被选中的主要原因之一。

5. 收益复核的严格度

最后这组取舍最容易被忽视：收益门要不要做得那么硬？

如果复核太软（只问一句”效果不错吧”），收益门就形同虚设；如果太硬（要求精确归因到单一项目），会因为归因困难而引发大量争论，最后不了了之。

我的建议是采用方向性复核加区间表述：不要求精确数值，但要求给出一个区间和归因置信度。比如”订单评审等待时长下降 2.9，3.3 天，高置信度归因于本项目”。这样既保留了证据，又避免了无谓的精确性争论。

八、把立项从”写材料”变成”签合约”：下一步怎么做

回到最开始那个数字：34.8% 的收益可复核率。它不是因为团队不努力，而是因为组织从来没有要求过”可复核”这件事。要求变了，行为才会变。

1. 30 天启动清单

1. 第 1 周：调取过去 12 个月的立项书，随机抽 20 份，用四个字段检查，有无基线、有无目标值、有无证伪条件、有无价值责任人。统计命中率，这就是你的现状基线。
2. 第 2 周：选一个正在推进的中型项目，重写价值假设卡，用真实数据补齐基线，把原立项书的目标改成可测量表述。
3. 第 3 周：为这个项目指定价值责任人，明确他在上线后 90 天要交付什么。这一步最容易遇到抵抗，因为它在给人加责任，务必由高层明确授权。
4. 第 4 周：把价值假设卡的字段配置到项目管理平台里，设为项目创建必填项。不要用 Word 模板，模板会被绕过。

2. 90 天见效清单

• 召开第一次价值门评审，由价值责任人主讲，只看指标不看功能。
• 为一个已上线项目补做收益门复核，哪怕结论是”无法比较”，这个结论本身就暴露了口径问题。
• 统计范围内新增需求占比，把范围冻结率纳入交付门的通过标准。
• 检查立项信息完整率是否达到 90% 以上，如果低于这个数，说明字段配置或培训没做到位。

3. 我认为最值得强调的三点

第一，立项的产出不是一份文档，是一个可以在 12 个月后被验证或被推翻的假设。衡量立项质量的唯一标准，是它在未来能不能被证伪。

第二，预算释放节奏比审批严格度更能决定项目成败。一次性批满预算，等于在信息最少的时刻做出了最大的不可逆承诺；分期批复，本质上是给自己保留了重新决策的权利。

第三，制度必须寄生在系统上才能存活。我在 H 公司的经验是，任何依赖人工维护和自觉执行的立项字段，六个月后的完整率都会掉到 50% 以下；而写在项目实体上、创建即必填的字段，一年后完整率仍在 95% 以上。对于 100 人以上、多项目并行的组织，选择支持私有化部署、能承载立项属性的平台，把价值假设、退出条件、价值责任人固化进项目本身，是让这套方法活下来的前提。

如果你打算下周就开始做，我的建议是先不要改流程、不要发制度文件，只做一件事：找一份正在推进的立项书，试着写出它的证伪条件。如果你写不出来，你就找到了自己组织立项体系最真实的那个漏洞。