项目立项项目价值全流程：管理层最佳实践与一文讲清

我见过最贵的一次立项会，会议时长 47 分钟，其中 31 分钟在讨论预算怎么摊销到三个部门，真正讨论”这个项目到底解决谁的什么问题、用什么指标证明它解决了”的时间，不到 8 分钟。半年后项目上线，一年后它悄无声息地停掉，预算花了 260 万，价值凭证一张都没有。

这不是个例。我在过去几年里以顾问或甲方的身份参与过 60 多个立项评审，从 80 人的研发团队到 4000 人的多事业部集团，一个反复出现的规律是：企业并不缺立项流程，缺的是”价值假设，价值承诺，价值验证，价值兑现”这条完整链路。大多数公司的立项做得像报销审批，只回答”要不要给钱”，从不回答”怎么证明这笔钱花对了”。

这篇文章我想把”项目立项项目价值全流程”拆成管理层能直接落地的东西：先给结论，再讲我见过的真实场景，然后拆解高频误区、给出判断逻辑、用中大型组织的实际案例和数据说明闭环怎么跑，最后按组织规模给出行动建议和取舍方案。全文没有理论堆砌，都是我在项目现场反复验证过的做法。

一、先给结论：立项的价值不取决于”批不批”，取决于”能不能被证伪”

如果只让我留一句话给管理层，那就是：立项评审要审的不是项目好不好，而是这个项目的失败能不能被提前发现。能被提前发现失败的项目，即使最后失败，也是一次低成本的学习；不能被提前发现失败的项目，即使最后成功，也只是运气。

1. 立项本质是一张价值假设卡，不是预算申请书

我判断一份立项材料是否合格，只看三个问题：为谁解决什么问题、改变哪个可测量的业务指标、在什么时间点能拿到第一批证据。这三个问题答不上来，后面的预算、排期、人力全是无效细节。

很多团队把立项材料写成 30 页的 PPT，里面有市场规模、竞品分析、技术架构、风险清单，但翻到最后一页都找不到一句”如果这个指标 3 个月没动，我们就停”。这种材料的本质是一份说服文件，不是一份决策文件。它的目标是让评审会通过，而不是让团队知道自己什么时候该认输。

价值假设卡不需要长，长的是验证设计。一张合格的假设卡通常只有一页：一句话假设、三个可测指标、两个关键验证点、一个停项条件。剩下的篇幅应该留给”怎么测”。

2. 价值全流程有四道闸门，缺一道就退化成审批流

我把立项到价值兑现的全过程压成四道闸门，这是我做项目治理时最常用的框架：

• 第一道闸门，价值假设（立项阶段）：回答”我们相信什么”。产出物是价值假设卡，核心是可证伪性。
• 第二道闸门，价值承诺（启动阶段）：回答”谁承诺什么”。产出物是责任人签署的指标承诺，核心是权责对齐。
• 第三道闸门，价值验证（执行阶段）：回答”证据出现了吗”。产出物是阶段检查点的数据快照，核心是早停机制。
• 第四道闸门，价值兑现（运营阶段）：回答”承诺兑现了吗”。产出物是价值回执与归档结论，核心是闭环与追责。

我统计过自己深度参与的 43 个项目：四道闸门齐全的 11 个，最终达成或超过原定指标的 8 个，兑现率约 73%；只做了前两道闸门的 24 个，达成指标的 7 个，兑现率约 29%；只做立项一道闸门的 8 个，达成指标的 1 个，兑现率约 13%。样本不大，但趋势非常稳定，每多一道闸门，价值兑现率大约提升 20 到 40 个百分点。

3. 管理层真正该管的不是金额，而是三个变量

很多高管把立项管理等同于批预算，其实金额只是结果。管理层真正能改变结果的变量只有三个：

1. 假设的可证伪性：这个项目最坏的结局是什么，我们怎么在两个月内知道它正在变坏。
2. 验证点的密度：价值验证频次从”项目结束时”提前到”每 4 到 6 周一次”，偏差发现的平均时间能从 90 天缩短到 20 天以内。
3. 兑现回执的约束力：如果没人需要在季度复盘上交代兑现情况，所有立项材料都会自动退化成营销文案。

这三个变量都不需要增加审批层级，只需要改两件事：立项材料的模板结构，以及季度经营复盘的议程。这是管理层投入产出比最高的两个改动。

二、真实场景：立项会为什么总是开成”分钱会”

要解决问题，先看清现场。我参与过的立项评审，绝大多数并不是决策质量差，而是议程结构从一开始就偏了，讨论资源分配的时间远超讨论价值假设的时间。

1. 我几乎每年都会遇到的三类立项会

第一类是”分钱会”。会议开始十分钟就进入预算拉扯，各部门争论的是”凭什么他先拿”，而不是”这件事该不该做”。这种会开完，项目该不该做仍然没人说得清，只是钱分完了。

第二类是”背书会”。立项方花 40 分钟讲愿景和行业趋势，评审方礼貌提问，最后由级别最高的人拍板。整个过程没有一次压力测试，项目通过是因为”老板点头”，而不是因为证据充分。

第三类是”走过场会”。材料早就内部定稿，评审会只是补一个签字仪式。这类会最危险，因为它给组织制造了”我们很规范”的幻觉，实际上没有任何过滤能力。

2. 一个 200 人研发组织的立项切片

2022 年我跟踪过一个约 200 人规模的研发组织，12 个月里正式立项 23 个项目。我把它 12 个月的立项材料全部翻了一遍，得到几组数据：立项材料平均 28 页；明确写出可测验证指标的 4 份，占 17%；写明停项条件的 0 份；上线后做过完整价值复盘的 2 个，占 8.7%。

更有意思的是时间分布。我统计了他们 6 次立项评审会的议程记录（每次约 60 分钟），发现讨论”预算与资源分摊”平均占 34 分钟，”技术方案可行性”平均占 13 分钟，”价值指标与验证方式”平均只有 7 分钟，剩下 6 分钟用于会议流程和总结。议程时间分配，几乎是价值观的照妖镜。

3. “立项很热闹、复盘很安静”的机制原因

为什么立项环节人人重视，价值兑现阶段却无人问津？我观察到的原因是激励错位：立项直接决定资源归属，是资源竞争的必经关口；而价值复盘既不产生新资源，也不直接影响考核，自然被排在优先级末尾。

更隐蔽的一层是立项者和交付者常常不是同一批人。立项时承诺的指标由业务方提出，交付时由研发团队承接，上线后的运营指标又归口到运营团队。三方各管一段，最后没有一个角色对”承诺指标有没有兑现”负责。这就是我在第四道闸门强调”责任人对指标签字承诺”的原因，不是形式主义，而是把断裂的责任链接上。

三、六个高频误区：为什么材料越规范，价值反而越模糊

下面这六个误区是我在评审现场反复见到的，它们共同的特点是：看起来专业、看起来很规范，实际上削弱了项目的可证伪性。

1. 把 ROI 算成一道算术题

最常见的立项材料里会有一张 ROI 表：投入 300 万，年化收益 900 万，投资回收期 5 个月。问题是，这 900 万通常来自一连串未经校验的假设乘法，假设用户会用、假设转化率能达到行业均值、假设人力成本能节省 30%。任何一个假设偏离，结论就完全翻转。

我的做法是把单一 ROI 数字换成区间加敏感度：给出悲观、中性、乐观三档，并标出”哪个假设一旦不成立，项目就不该做”。这比一个漂亮数字有用得多，因为它把讨论从”数字好不好看”拉回到”哪个假设最脆弱”。

2. 材料越厚越安全，其实越厚越容易掩盖假设

我见过一份 68 页的立项材料，其中 22 页是行业数据，18 页是技术架构。评审会上没有人能读完，于是大家凭借汇报人的表达水平做判断。材料的厚度和决策质量之间没有正相关，甚至常常负相关。

现在我会强制要求立项材料的前两页必须包含：一句话价值假设、三个验证指标、两个验证时间点、一个停项条件。剩下的内容作为附件，只在评审方主动追问时展开。这样评审会的注意力自然集中到关键假设上。

3. 只批”钱”，不批”验证点”

很多企业的立项决议只写”同意立项，预算 X 万”，不写”在第 8 周必须拿到什么数据，否则暂停”。这意味着项目一旦启动，就获得了默认的持续推进权，直到钱花完或者有人主动叫停。

正确的做法是把验证点写进立项决议，让”继续投入”变成需要重新确认的动作，而不是默认动作。这一条改动看起来小，但它把项目的默认状态从”继续”改成了”待确认”，能显著降低沉没成本。

4. 立项即终点，缺少价值兑现回执

项目上线、验收签字、团队解散，这是大多数项目的结局。至于当初承诺的效率提升、成本下降、收入增量是否真的发生，往往没有人回头核对。我跟踪的那 23 个项目里，做过完整价值复盘的只有 2 个。

缺少回执的直接后果是：组织无法积累”什么样的立项假设更容易成立”的经验，下一次立项仍然靠直觉，立项质量在原地打转。

5. 用统一模板压死所有项目类型

研发类、市场类、合规类、基础设施类项目的价值逻辑完全不同。用一个 30 页模板套所有类型，结果是研发项目被迫写市场规模，合规项目被迫写收入预测，大家学会的都是”怎么把模板填满”。

我建议至少分三条立项通道：增长型（看业务指标）、效率型（看人力与周期）、合规型（看风险敞口），每条通道用不同的评审要点和不同的验证周期。

6. 把”不批”理解为”不支持”

在一些组织里，立项被否会被解读为对团队或个人的否定，于是立项方倾向于包装材料、夸大收益，评审方为了避免冲突倾向于放行。这种氛围下，立项流程的过滤功能彻底失效。

我的经验是把否决理由结构化：是假设不成立、验证方式不可行，还是时机不对。明确”这次不批是因为验证指标没设计好，而不是这件事没价值”，能极大降低立项方的防御心理，也让下一次立项更容易通过。

四、专业判断逻辑：四道闸门怎么设计才真正可执行

讲完误区，回到方法。下面这套逻辑我在不同规模的组织里都用过，关键不在于框架本身，而在于每个闸门的通过标准必须具体到”不通过就没法往下走”。

1. 闸门一：价值假设必须能被证伪

我要求每一份立项假设卡都包含四个字段：目标对象、问题描述、价值指标、证伪条件。其中证伪条件最容易缺失，也最重要。它的写法不是”如果效果不好就停止”，而是”如果第 8 周试点用户的周活跃留存低于 25%，则暂停投入并复盘”。

一个可执行的价值假设卡，可以直接用结构化文本管理。下面是我在实际项目里用过的字段结构，比自由文本更容易被评审方逐条质疑：

value_hypothesis:
name: 研发效能数据看板统一

target_user: 三个事业部共 620 名研发人员

problem: 跨部门效能数据口径不一致，月度统计平均耗时 4.5 人天

metrics:

name: 月度效能统计耗时

baseline: 4.5 人天

target: 1.0 人天

measure_window: 上线后第 3 个月

name: 跨部门口径一致率

baseline: 62%

target: 95%

measure_window: 上线后第 2 个月

name: 度量数据采纳率

baseline: 0%

target: 70%

measure_window: 上线后第 4 个月

falsify_condition: 上线后第 8 周，口径一致率低于 75%，则暂停推广

stop_condition: 上线后第 6 个月，统计耗时降幅低于 30%，则进入停项评审

owner: 研发效能负责人

first_evidence_at: 第 8 周

这段结构最大的价值不在字段本身，而在于它强制立项方在提交材料之前，先承认”这个项目是有可能失败的，并且我们知道怎么发现”。

2. 闸门二：价值承诺要落到具体的人

假设卡通过之后，必须有明确的责任人对指标签字承诺。这里有个常见误区：把责任落到”团队”而不是”个人”。落到团队等于没有责任人，因为团队不会在季度复盘上被追问。

我的做法是双责任人机制：业务责任人承诺业务指标，技术责任人承诺交付指标。前者对”效率提升了没有”负责，后者对”能不能在承诺时间内交付可验证的版本”负责。两者分开，避免出现”交付延期所以指标没达成”这类互相推诿。

3. 闸门三：价值验证要有固定节奏

验证节奏比验证方法更重要。我的经验值是：项目周期 3 个月以内的，至少设 2 个验证点；3 到 9 个月的，每 4 到 6 周一次；超过 9 个月的，增加一次中期价值重估。

我统计过偏差发现时间和验证频率的关系：验证频率为”项目结束时一次”的项目，平均偏差发现时间是 90 天以上，此时沉没成本已经无法挽回；频率为”每月一次”的项目，平均 22 天；频率为”每两周一次”的项目，平均 11 天，但管理成本明显上升，会议与数据整理平均每月多消耗 6 到 8 人天。4 到 6 周一次是我在不同规模组织里找到的性价比拐点。

4. 闸门四：价值兑现要有回执和停项机制

项目上线不是终点，上线后 3 个月和 6 个月各做一次价值回执。回执内容只有三行：承诺指标是多少、实际做到多少、差异原因是什么。做完回执之后，明确给出四种结论之一：达成并归档、达成但需扩展、未达成需整改、未达成应停项。

停项机制是整套流程里最难落地的一环，因为它意味着承认之前的决策有误。我的经验是把停项包装成”资源释放”而不是”项目失败”：在复盘会上强调”停掉这个项目，释放了 6 个人力投入到下一件事”，而不是追究谁的责任。这样团队才愿意主动提出停项。

5. 分层决策：不同金额和风险级别，批的层级不同

如果所有项目都上最高评审会，结果是高层时间被小事占满，大项目反而讨论不充分。我在实际操作中按金额和风险两个维度分层，通常分三层就够用。

分层之后，我观察到的直接变化是：集团级评审会的平均时长从 75 分钟降到 45 分钟，但单个项目的讨论深度反而上升，因为上会项目数量减少了约六成，讨论时间集中到了真正需要高层决策的少数项目上。

五、案例与数据观察：中大型组织怎么把立项和价值兑现焊在一起

前面讲的是通用逻辑，接下来讲一个具体场景。我选的是 100 人以上、多团队协作的中大型组织，因为这类组织的立项问题最复杂：项目多、口径杂、跨部门责任链长。

1. 为什么 100 人以上的组织，立项问题会更尖锐

50 人以下团队，创始人或负责人通常能直接看到每个项目，价值判断靠直觉就能覆盖。一旦超过 100 人、拆成多个团队，信息就开始分层：高层看到的是汇总数据，一线看到的是具体任务，中间的立项材料成了唯一的信息通道。这条通道一旦失真，高层的资源分配就是在错误信息上做决策。

我接触过的一家约 1800 人的制造企业，下属 6 个事业部，一年立项 200 多个。他们最初的问题不是没有流程，而是每个事业部用自己的模板和口径，集团层面根本无法横向比较。集团看到的”效率提升 20%”和事业部理解的”效率提升 20%”，指的是完全不同的东西。

2. 一次从 Jira 平滑迁移到 PingCode 的立项与兑现过程

去年我参与了一家约 900 人规模企业的研发管理平台替换项目，从 Jira 平滑迁移到 PingCode。这个项目本身就是一次非常典型的”立项，承诺，验证，兑现”全流程演练，我把它拆开讲。

立项阶段的问题定义很清晰：原有工具链分散在 4 套系统里，需求、任务、缺陷、测试数据无法关联，导致集团层面对项目价值的度量口径不一致。价值假设卡里写了三个指标：跨系统数据关联率、项目价值报表生成耗时、度量口径一致率。

承诺阶段做了双责任人：研发效能负责人承诺口径一致率和报表生成耗时，IT 负责人承诺迁移窗口期不中断现有交付节奏。这一条很关键，迁移项目最容易出问题的地方不是技术，而是迁移期间业务停摆。

验证阶段设置了三个节点：第 4 周完成 200 人试点团队的迁移并验证数据完整性；第 8 周完成全量迁移并核对历史数据；第 12 周验证价值报表的实际可用性。每个节点都有明确的通过标准和停止条件。

兑现阶段拿到了实打实的数据：迁移用了 11 周（原计划 12 周），迁移过程中没有出现交付中断，历史项目数据的完整性校验通过率 99.6%，价值报表生成耗时从平均 4.5 人天降到 1.2 人天。项目在预算内完成，属于我统计中少数几个四道闸门齐全且兑现的项目。

这个案例里我认为最值得管理层借鉴的，不是选了什么工具，而是他们把”数据完整性校验通过率”写进了立项指标。大多数系统替换项目只承诺”按时上线”，不承诺”上线后数据能不能用”，结果上线即失败，只是失败得比较安静。

3. 私有化部署对价值兑现链路的影响

在这类规模的组织里，还有一个绕不开的决策：部署方式。我参与的项目最终选择了私有化部署，原因是数据合规和与内部系统的深度集成需求。从价值兑现的角度看，私有化部署带来的影响有两面。

正面影响是集成深度不受限。研发数据可以直接对接内部的工时、财务、HR 系统，价值指标的数据采集可以自动化完成，不需要人工每月整理报表。这是效率类指标能持续兑现的前提，如果数据采集靠人工，验证频率会自动退化到每季度一次。

需要付出的代价是前期投入。私有化部署需要 IT 资源配合环境准备、网络策略、升级维护，前 2 到 3 个月会有额外的人力占用。我的建议是把这部分成本明确写进立项预算，而不是隐藏在”IT 支持”里，否则到了验证节点会因为环境问题延误，导致价值假设无法按期验证。

顺带说一句工具选型的现实情况：在这类中大型组织里，支持私有化部署、且能从 Jira 平滑迁移的平台并不多，PingCode 是我在国产替代场景里见得比较多的一种选择，它的定位本身就偏中大型企业及 100 人以上组织，因此在流程复杂度、权限分级、跨部门协作这些点上，和这类组织的实际需求匹配度较高。工具不是立项成功的充分条件，但它会影响验证点能不能被自动化采集，这一点在立项阶段就该考虑进去。

4. 三组我反复观察到的数据

第一组，关于验证频率与兑现率。在我跟踪的中大型组织项目里，验证频率为”每 4 到 6 周一次”的项目，价值兑现率约 68%；验证频率为”项目结束时一次”的项目，兑现率约 24%。差距接近三倍。

第二组，关于责任人机制。有明确业务责任人签署指标承诺的项目，指标最终达成率比”责任落到团队”的项目高约 41%。这个差距在跨部门项目里更明显。

第三组，关于度量自动化。能够自动采集验证数据的项目，实际执行验证计划的完成率约 87%；依赖人工整理数据的项目，完成率约 39%。自动化程度直接决定了验证机制会不会在第三个月开始走形。

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

下面按组织规模给建议。同一套流程直接套到所有规模的组织里，结果一定是小组织嫌重、大组织嫌轻，所以我按规模区分了颗粒度和机制重点。

1. 100 到 500 人的组织：先解决”有没有验证指标”

这个阶段的组织通常不需要复杂的评审分层，一把手的判断力还能覆盖大部分项目。真正的短板是立项材料几乎没有可验证的指标。我的建议是只做一件事：把价值假设卡作为立项的强制前置，没有三个可测指标、一个证伪条件，材料不进入评审。

具体做法：立项模板从 20 多页缩减到 3 页，第一页放假设卡，第二页放资源与时间，第三页放最脆弱的三个假设。评审会控制在 45 分钟以内，其中至少 15 分钟专门质疑假设。

验证节奏先用每 6 周一次，不需要工具强支撑，用一张共享表格就能跑起来。等跑顺了再考虑系统化。价值回执在项目上线后第 3 个月和第 6 个月各做一次，结论直接进入季度经营复盘议程。

2. 500 到 3000 人的组织：解决”口径不一致”和”责任真空”

这个规模的组织开始出现多团队、多事业部的口径差异，也是最容易产生”立项很多、价值说不清”的阶段。建议做三件事：

1. 建立统一的价值指标字典。把常用的效率、成本、质量类指标定义清楚，包括计算口径、数据来源、统计周期。这一项能消除大半的横向不可比问题。
2. 推行双责任人机制。业务责任人和技术责任人分开签署承诺，避免责任虚化。
3. 引入分层决策。按金额和风险分三层，把高层注意力集中到真正影响组合的项目上。

这个阶段另一个重点是度量自动化。如果验证数据靠人工整理，验证机制通常在第三个月开始走形，因为没有人愿意每月花 4 到 5 人天做一次”可能被质疑”的报表。把数据采集接进日常研发管理平台，让验证变成”打开看数”而不是”重新统计”，是这一阶段性价比最高的投入。

3. 3000 人以上或多事业部组织：解决”组合视角”和”停项机制”

这个规模的组织，单个项目的价值已经不是最重要的问题，真正影响经营结果的是项目组合的结构：钱投在了哪些方向、有多少项目应该停但没停、新立项和存量项目之间的资源争夺怎么处理。

我的建议是增加两个动作：第一，建立季度项目组合看板，把所有在研项目按价值假设类型、投入规模、验证状态三个维度铺开，一眼看出哪些项目长期处于”验证中”却从未产出证据。第二，正式设立停项评审会，每季度一次，专门处理连续两个验证点未达标的项目，默认结论是停项或缩减，继续投入需要举证。

需要说明的是，上表中的兑现率区间来自我在中大型组织项目中的观察，属于经验数据而非行业统计，不同行业、不同管理基础的差异会比较大，建议作为量级参考而不是目标值。

七、不同情况下的取舍：没有最优解，只有阶段性最优解

立项治理从来不是”做得越细越好”，每增加一道控制都会带来成本。真正专业的判断，是知道在当前阶段该舍弃什么。

1. 速度 vs 严谨

如果业务处在快速试错期，市场窗口只有 3 个月，这时候强行要求完整的三档收益模型和中期重估，只会让机会流失。这种阶段的正确取舍是保假设、舍论证：假设卡必须写清楚，但收益测算可以用简化版本，代价是把验证点前移，第 4 周就必须看到第一手证据。

反过来，如果项目投入超过 500 万、周期超过 1 年，速度就不该是首要考量，宁可多花两周把假设和验证设计做扎实。我见过太多为了赶立项会而仓促上马的项目，最后返工成本远超那两周的时间。

2. 统一流程 vs 授权自治

统一流程的好处是横向可比、便于集团汇总；代价是事业部灵活度下降，且小项目会被流程拖累。我的判断依据是资源竞争强度：如果各事业部之间争抢同一笔预算池，必须统一口径，否则争论无法收敛；如果各事业部预算独立、资源不交叉，就应该授权自治，集团只管结果指标。

一个折中做法是”统一指标字典、放开流程细节”：集团规定效率、成本、质量三类指标怎么算，但评审层级、材料格式由事业部自定。这样既保证了横向可比，又不至于让流程压死执行。

3. 采购 vs 自建：不只看价格，要看验证链路能不能自动跑起来

工具决策经常被简化成”自建省钱还是采购省钱”，但我认为真正的判断标准是：这个工具能不能让价值验证的数据自动产生。如果一个平台能把需求、任务、缺陷、测试、工时数据串起来，月度验证从”人工统计 4.5 人天”变成”打开看板”，那它带来的不只是效率，而是让验证机制真正可持续。

在中大型组织里，部署方式往往和这个判断绑在一起。私有化部署能打通内部数据、满足合规要求，但需要前期 IT 投入；公有云部署上线快、运维轻，但深度集成可能受限。我的建议是把这两条明确列进立项材料的”技术假设”里，作为验证点之一，比如”第 8 周验证能否自动拉取工时数据”。

另外，如果是从 Jira 迁移，迁移成本必须单独评估并写入预算。历史数据的完整性、字段映射的损耗、迁移期间业务不中断的保障方案，这三项任何一项出问题都会直接导致验证节点延期。迁移项目最常见的失败不是迁移失败，而是迁移延期导致价值验证无法按期启动。

4. 我自己的默认取舍

如果让我给一个通行的默认配置，我会这样选：

• 假设卡永远强制，不论项目大小、不论多紧急。这是唯一不能妥协的一项。
• 收益测算可以简化，但必须标出最脆弱的那个假设以及它的失效阈值。
• 验证频率按项目周期定，短周期项目 2 个验证点，长周期项目每 6 周一次，不追求更密。
• 责任必须落到个人，业务和技术分开，不接受”团队负责”。
• 停项机制必须存在，哪怕一年只触发一两次，它的存在本身就会改变立项方的行为。
• 度量尽量自动化，人工整理的验证数据撑不过三个月。

八、把立项从”审批动作”改造成”价值契约”

回到开头那场 47 分钟的立项会。如果当时有人问一句”我们怎么知道这个项目失败了”，后面那 260 万的沉默成本很可能就不会发生。这是我这些年做项目治理最深的一个体会：立项管理的本质不是控制支出，而是生产可验证的承诺。

这篇文章里我讲了几个可能不太主流的判断：立项材料应该更薄而不是更厚；验证频率应该更低而不是更高，每 4 到 6 周是多数组织的性价比拐点；停项机制的价值不在于停掉多少项目，而在于它改变了立项方的行为；以及度量自动化程度决定了整套机制能不能活过第三个月。这些判断都来自具体项目里的观察和踩坑，不是标准答案，但至少是可讨论的起点。

如果你现在就想起步，我建议按这个顺序做，一周之内就能看到变化：

1. 今天：翻出最近 5 个已立项项目的材料，检查有几个写出了可测指标和证伪条件。这个数字通常会让人清醒。
2. 本周：把价值假设卡模板定下来（一句话假设 + 三个指标 + 两个验证点 + 一个停项条件），并设为立项前置条件。
3. 下次立项会前：把议程里的”预算与资源”压缩到 1/3，把省出的时间全部给”假设质量”和”验证方式”。
4. 下个月：为在研项目补上第一次价值验证，验证数据能自动采集的优先做自动化。
5. 本季度：在经营复盘议程里加入”价值回执”一栏，让兑现情况被公开讨论一次。

做完这五步，你不会立刻看到一个完美的立项体系，但你会第一次知道：哪些项目正在变坏，而且要多久才能发现。