周期落地方案：产品经理开展项目立项的最佳实践案例解析

2023年6月，我以外部顾问身份介入一个CRM重构项目的复盘：项目在立项评审会上全票通过，11周后开发完成度到了72%，却没有一个业务部门愿意上线试用。会后我翻完它的立项材料，一份48页的PRD、一张排得很漂亮的甘特图、一份”三年ROI 320%”的测算表，唯独没有写清楚一件事：这个项目用什么节奏推进，每个周期结束时谁来判断继续、暂停还是停止。

这是我见过最高频的立项失败模式。产品经理把立项当成”证明这件事值得做”，而组织真正需要的是”这件事怎么按周期落地”。前者是一篇议论文，后者是一份施工图。两者最直观的差别是：议论文写完之后没人再翻，施工图从第一天开始就被反复对照。

下面这套内容来自我在十几家企业观察和参与过的立项项目，覆盖50人到3000人规模的组织。我会把周期怎么切、证据怎么分层、闸门怎么设、工具怎么承载、什么情况下应该果断砍掉，一次讲完整。你可以把它当作一份可以直接改改就用的立项周期落地方案模板，而不是一篇方法论散文。

一、核心结论：立项的产物不是一份文档，而是一份可复现的周期落地方案

1. 我的三条结论

先说结论，后面的所有内容都是给这三条结论找证据。第一条：立项的交付物不是PRD，也不是商业计划书，而是一份包含时间周期、决策节点、退出条件的落地方案。没有周期和退出条件的立项，本质上是给团队发了一张没有终点的长期票。

第二条：立项的失败大部分不是判断错误，而是节奏错误。我统计过手上23个被中途叫停或上线后无人使用的项目，其中17个在立项阶段的判断其实是对的，方向没错，但周期切得太长，等到第一次真实验证时，外部条件已经变了，团队也已经把沉没成本堆到了不能撤的高度。

第三条：周期落地方案的价值不在于”快”，而在于”早失败、便宜失败”。一个8周完成一次价值验证的立项周期，比一个24周才交付首个可用版本的立项周期，能省下的不是时间，而是团队在错误方向上的投入总量。

• 可复现：另一批人拿到同样的方案，能跑出接近的节奏和结论，而不是依赖某个人的临场判断。
• 可度量：每个周期结束时有明确的数字指标，而不是”感觉差不多了”。
• 可终止：任何周期节点都可以干净地停下来，且停下时产生的资产（调研、原型、数据）仍然可复用。

2. 为什么”周期”是立项方案的最小单位

很多人会问：为什么不是”里程碑”，而是”周期”？因为里程碑只标结果，周期同时约束节奏和决策权。里程碑思维下，立项方案会写”6月底完成需求评审、8月底完成开发”，这是一种没有人负责的表述，如果6月底没完成，没有任何机制会自动触发调整。

周期思维下，立项方案写的是”每2周一个验证周期，第2周末做Go/No-Go判断，连续两个周期未达阈值则暂停”。这两句话的差别是：前者描述期望，后者描述机制。项目管理系统能承载的是后者，前者的结局通常是一张被截图发在群里的甘特图。

我在实际项目里用的判断标准很简单：如果一份立项方案里找不到至少两个”可以在中途停下来的位置”，它就还不算落地方案。这个标准帮我筛掉过大量看起来很完整、实际无法执行的立项文档。

3. 立项方案必须能被三类角色分别读懂

立项文档的读者从来不是一类人，而三类读者关心的东西完全不同。业务负责人关心”这件事和我今年的目标怎么挂钩”，技术负责人关心”我需要投入多少人、多长时间的稳定资源”，财务或管理层关心”最坏情况下的损失上限是多少”。

周期落地方案的结构天然能同时回答这三类问题：周期长度回答了技术资源的投入节奏，每个周期的验收指标回答了业务目标的对齐方式，退出条件回答了最坏损失的上限。一份方案如果不能在一页之内让这三类人各自找到答案，它就会被退回重写。

二、真实场景：我在三种组织里见过的立项周期形态

1. 小步立项：2周一个周期的验证型立项

第一次接触这种形态是在一家60人的工具类SaaS公司。他们的立项不是一次会议，而是一个持续2周的验证周期：第1周做问题证据采集和最小原型，第2周做5-8个真实用户的可用性测试，第2周末做一次45分钟的评审。

这种形态最大的特点是立项结论可以是”不做了”，而且”不做了”是被鼓励的结果。他们的产品负责人跟我说过一句话我印象很深：”我们不怕立项被否，怕的是没人愿意提立项，因为提了就一定要做出来。”这句话背后是一个组织心理问题：如果立项通过率是100%，说明立项流程没有起到筛选作用。

小步立项的代价是它不适用于重资产、强依赖、涉及硬件或合规审批的项目。你没法用2周验证一个需要等保三级认证的项目是否值得做。它适合的是需求不确定、试错成本低、可以快速拿到用户反馈的产品方向。

2. 标准立项：6周周期的三段式立项

100人到1000人规模的组织，最常见的立项周期是6周，切成三段：第1-2周做问题与价值验证，第3-4周做方案与可行性验证，第5-6周做资源与排期确认。每一段结束都设一个轻量评审，只有全部通过才进入下一段。

这种形态的关键设计是”分段投入”：如果第2周末价值验证不通过，你损失的只是两周的调研成本，而不是整个6周的方案设计成本。我在一家300人的企业服务公司推动过这种改法，改造前他们的一次立项平均耗费1.5个人月，其中约60%的工作是在”已经决定要做”的前提下完成的。

需要提醒的是，6周周期不是硬标准。我见过把它压缩到4周反而更有效的团队，也见过因为涉及跨三个部门的资源协调必须拉长到8周的团队。周期的长度应该由”最短验证闭环”决定，而不是由管理层的会议排期决定。

3. 战略立项：季度周期的组合式立项

在千人以上、有多条产品线的组织里，立项会变成一种组合决策：不是判断”这一个项目做不做”，而是判断”这个季度有限的人力应该投给哪几个方向”。这时的周期单位通常是季度，但内部依然要切成月度检查点。

这种形态最大的风险是立项变成资源争夺战，产品经理写方案的目的从”证明价值”变成”抢到人头”。我观察到的一个有效对策是：把立项方案的评估维度从”预期收益”改成”单位人力的验证速度”，也就是同样投入3个人，哪个方向能更快拿到可证伪的结论，就优先给谁。

三、拆解常见误区：产品经理在立项阶段最容易踩的七个坑

1. 误区一：把立项当成写PRD

最普遍的一个。产品经理接到立项任务，第一反应是打开文档开始写功能列表，因为这是他们最熟练的动作。结果是立项会上讨论的全是”这个功能要不要做、那个字段怎么设计”，而没有一句话讨论”我们凭什么认为这个问题值得解决”。

PRD回答的是”怎么做”，立项回答的是”要不要做、做到什么程度停”。顺序反了，就会出现方案做得越细、越难被否掉的局面，因为投入的情感成本已经太高了。

2. 误区二：用”我觉得值得做”代替证据链

“我在客户现场待了三天，明显感觉到他们很痛。”这是我在立项会上最常听到的开场。它可能是真的，但它不是证据，它是印象。印象可以启动立项，但不能作为立项通过的依据。

我要求的证据链至少包含三环：问题发生的频次（多少次/周）、问题造成的可量化损失（多少人时/万元）、现有替代方案为什么不够好（用户现在怎么凑合解决的）。缺第三环的立项方案，通常会在开发到一半时发现”用户其实用Excel也能忍”。

3. 误区三：周期排成一条直线

甘特图的美学陷阱。一条从左到右平滑推进的直线，看起来专业，实际上隐藏了所有不确定性。真实的立项周期应该是有岔路的：在某个节点上，要么继续，要么调整，要么终止。

我的做法是在周期图上显式画出决策点，并且标注每个决策点的判断依据。这样做的额外好处是：当项目后来真的出问题时，你可以回溯到具体是哪个决策点的判断依据不充分，而不是笼统地归因于”需求变化太快”。

4. 误区四：立项输入只有需求，没有产能和成本

很多立项方案只写”我们要做什么”，不写”我们为此要放弃什么”。这是产品经理视角的天然盲区，需求侧思维强，供给侧思维弱。而管理层的决策逻辑恰恰是供给侧：人力是固定的，做A就做不了B。

有效的做法是在立项方案里强制加一页”机会成本说明”：这个项目占用的3名后端和1名数据工程师，原本在排期里准备做什么，那些事情延后或取消的代价是什么。这一页往往比十页收益测算更能推动决策。

5. 误区五：把评审会开成表决会

表决会的特征是”大家举手表态”，而立项评审会应该是”围绕证据链质询”。我参加过一次非常高效的立项评审：会议全程55分钟，没有一次表决，评审人只问了三个问题，你的问题证据来自几个真实用户？如果第4周发现假设错了，你打算怎么处理？这个项目最坏情况下的损失是多少？

这三问背后是三个判断维度：证据强度、调整机制、风险上限。如果一个立项评审会不能稳定地问出这三个问题，它就只是在走流程。

6. 误区六：立项之后没有退出条件

立项方案里最常见的一句话是”根据实际情况调整”，这句话等于什么都没说。退出条件必须是可观测的、带阈值的、有时限的。例如”如果第8周末付费转化试点用户数少于15家，则暂停二期投入”。

我在实际项目里会要求退出条件的数量控制在2-4条，因为超过4条之后没有人会记得住，也就没有人会在节点上真的去检查。退出条件的价值不在于被触发，而在于它的存在会让执行者在过程中持续自我校准。

7. 误区七：工具缺位，靠Excel和群接龙

这是最容易被低估、但对周期落地影响最直接的一条。当立项周期靠Excel维护、评审靠群消息通知、决策记录散落在会议纪要里时，周期落地方案就变成了一份”只在立项当天有效”的文件。

我见过太多团队的做法是：用文档写方案，用表格排周期，用IM做通知，用邮件存档结论。四套工具、四个数据源、四种口径，等到第4周需要判断是否继续时，没人能快速说清楚当前状态。这也是为什么后面我会专门用一节讲工具如何承载周期，而不是把它当成一个可选项。

四、专业判断逻辑：四层证据、三道闸门与一个评分模型

1. 四层证据：让立项判断有据可依

我把立项所需的证据分成四层，缺一层就说明方案还不成熟。第一层是问题证据：这个问题真实存在、发生频次可观测、影响人群可界定。第二层是价值证据：解决它带来的收益能被量化，哪怕只是粗颗粒的估算。

第三层是可行性证据：技术路径清楚、依赖项明确、没有未知的关键卡点。第四层是代价证据：需要投入的人力、时间、外部成本，以及机会成本。这四层里，最常被跳过的是第四层，而它恰恰是决策层最关心的。

每一层证据都有一个”最小充分量”的标准，不需要穷尽。例如问题证据，我的经验值是5个以上真实用户的具体描述加上一组可观测数据，就足以支撑立项判断，再多的访谈对结论的边际贡献很小。

2. 三道闸门：让周期有明确的决策节点

闸门是周期落地方案里最关键的机械结构。我通常设三道：准入闸（立项是否受理）、投决闸（是否投入开发资源）、复盘闸（是否继续后续周期）。

准入闸的作用是过滤掉那些连问题证据都不完整的立项请求，通常只需要一次30分钟的快速沟通，成本极低。投决闸是真正的资源决策，需要完整的三层证据加代价说明。复盘闸发生在第一个交付周期结束之后，判断依据是事先约定好的指标阈值。

三道闸门的设计要点是决策权分离：准入闸由产品负责人判断，投决闸由跨部门评审组判断，复盘闸由业务方和产品共同判断。如果三道闸都在同一个人手上，闸门就退化成流程装饰。

3. 一个可复用的立项评分模型

为了让评审不依赖主观印象，我用一个加权评分模型把四层证据量化。总分100分，其中问题强度25分、价值规模25分、可行性25分、代价可控性25分。评分不是替代讨论，而是让讨论聚焦在分歧最大的维度上。

实践中的经验阈值是：总分低于60分暂缓，60-75分进入小规模验证周期，75分以上进入标准立项流程，90分以上才考虑战略级资源倾斜。这个阈值不是绝对的，但它能显著减少”看起来都挺重要”的模糊判断。

立项评分模型配置（YAML 示例）
scoring_model:

dimension: 问题强度

weight: 25

criteria:

问题发生频次 >= 3次/周 → 10分

有可观测的量化损失数据 → 10分

现有替代方案被验证不足 → 5分

dimension: 价值规模

weight: 25

criteria:

收益可被量化估算 → 10分

影响用户群可界定 → 8分

与年度目标直接挂钩 → 7分

dimension: 可行性

weight: 25

criteria:

技术路径已验证 → 10分

无未知关键外部依赖 → 8分

关键角色资源可承诺 → 7分

dimension: 代价可控性

weight: 25

criteria:

首周期投入 = 90 → 可申请战略级资源倾斜

4. 从立项请求到通过的转化路径

把闸门和评分放在一起看，立项其实是一条有明确流失率的转化路径。我在一家企业服务公司推动立项流程改造后，统计过连续12个月的转化数据：受理38个立项请求，通过准入闸29个，通过投决闸14个，通过第一个周期复盘闸9个。

整体通过率约24%，而这个数字在改造前是接近70%。通过率下降不是坏事，它意味着流程开始承担筛选功能。更关键的是，通过复盘闸的9个项目里，有7个在后续两个季度内产生了可量化的业务指标改善，这个比例在改造前只有4/11。

五、案例拆解：一家300人SaaS公司的立项周期改造（以PingCode为载体）

1. 改造前的真实状态

这家公司做企业服务SaaS，产品、研发、交付合计约300人，产品团队18人。改造前他们的立项状态是：平均立项耗时6.5周，一次立项平均调用1.5个人月，立项通过率71%，但立项后6个月内被叫停或大幅缩减范围的项目占43%。

更棘手的是过程状态不可见。立项方案存在共享文档里，周期计划在个人Excel里，评审结论散落在会议纪要和各人记忆里。当第4周需要判断项目是否继续时，产品经理需要花半天时间收集各方状态，最终结论仍然依赖个人判断。

我介入时提的第一个要求不是改流程，而是先把立项过程本身变成一个可追踪、可度量、有状态的对象。当时他们已经用了某项目管理工具做研发管理，但立项阶段完全在工具之外运行，导致立项和交付是两套割裂的数据。

2. 把立项拆成四个可度量周期

我们最终确定的立项周期是6周，切四个阶段，每个阶段都有明确产出和判断标准。这里的关键设计是：每个阶段都是一个独立可终止的工作项，而不是一个大任务下的子任务，这样在任何阶段终止，已完成的工作仍然是可以被检索和复用的资产。

1. 问题验证阶段（第1-2周）：产出用户访谈记录、问题频次数据、现有替代方案分析，判断标准是问题证据是否达到最小充分量。
2. 价值测算阶段（第2-3周）：产出收益估算模型、影响用户群界定、与年度目标的对应关系，判断标准是收益是否可被量化到可讨论的程度。
3. 方案可行性阶段（第3-5周）：产出技术路径、关键依赖清单、最小可交付范围，判断标准是是否还存在未验证的关键卡点。
4. 资源与排期阶段（第5-6周）：产出人力投入表、机会成本说明、退出条件清单，判断标准是资源承诺是否来自实际执行方。

3. 用PingCode承载立项周期

选择PingCode的原因很直接：他们的研发体系已经在同一个平台上运行，立项如果继续留在工具之外，就无法实现”立项状态自动驱动交付排期”。PingCode主要服务中大型企业及100人以上组织，这家300人的公司正好落在它的典型服务区间内。

具体落地时，我们用PingCode做了四件事。第一，把每个立项周期建成独立的迭代，四个阶段对应四个迭代，阶段产出作为完成条件，避免”阶段结束了但产出没交付”的情况。第二，把四层证据做成立项工作项的必填字段，没有填写问题证据和代价说明，工作项无法流转到投决闸。

第三，用自定义工作流把三道闸门做成状态流转，每一次流转都强制记录决策人和决策依据，这样半年后复盘时能准确回溯当时的判断逻辑。第四，把退出条件写成可关联的指标项，在周期结束时由系统提示检查，而不是依赖人的记忆。

立项周期在项目管理平台中的结构示例
立项工作项（类型：立项）

├── 阶段迭代 1：问题验证（2周）

│ ├── 必填字段：问题频次数据 / 访谈样本数 / 替代方案分析

│ └── 完成条件：证据完整度评分 >= 70

├── 阶段迭代 2：价值测算（1周）

│ ├── 必填字段：收益估算模型 / 影响用户群 / 目标对应关系

│ └── 完成条件：收益口径经业务方确认

├── 阶段迭代 3：方案可行性（2周）

│ ├── 必填字段：技术路径 / 依赖清单 / 最小交付范围

│ └── 完成条件：无未验证的关键外部依赖

└── 阶段迭代 4：资源与排期（1周）

├── 必填字段：人力投入表 / 机会成本 / 退出条件（2-4条）

└── 完成条件：执行方资源承诺已确认

闸门状态流转

待受理 → 准入通过 → 投决评审 → 通过 / 暂缓 / 不启动

↓

首周期复盘 → 继续 / 调整 / 暂停

值得一提的是他们的工具选型背景。这家公司早期用的是Jira，后来因为成本、协作体验和国产化要求考虑迁移。他们评估时最看重的一点是历史数据的迁移成本，三年积累的工作项、迭代记录和度量数据如果无法平滑迁移，等于把历史资产清零。

PingCode支持Jira平滑迁移，这一点在他们做国产替代评估时是重要加分项。对于有私有化部署要求的组织，它还支持私有化部署，这让后续在数据合规层面的推进会简单很多。不过我要强调的是：工具只解决”周期是否被如实执行”的问题，它不解决”周期设计是否合理”的问题，后者仍然要靠方法。

4. 改造后的数据观察

改造运行12个月后，我们对比了关键指标。需要说明的是，这是单一组织样本，数据经过脱敏和近似处理，不具备行业统计意义，但趋势本身有参考价值。

5. 12个月的周期时长趋势

还有一个值得单独看的现象：立项周期时长不是稳定值，它在改造后的第3到第6个月出现了明显波动。原因是团队在学习新的立项方法，前期证据采集反而变慢了，到第7个月之后才稳定下来，最终稳定在5.8周左右。

这说明流程改造不会立刻见效，通常存在3-6个月的能力建设期。如果你在第2个月看到效率下降就急着回滚，等于把最关键的适应期给掐掉了。我在推动这类改造时，会提前和管理层沟通这个曲线，避免中途被叫停。

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

1. 组织规模在100人以下：不要引入完整立项流程

如果你所在的组织不到100人，我建议不要照搬上面这套三层闸门和四阶段周期。小组织的沟通成本本来就低，引入重流程只会制造等待。你真正需要的是两样东西：一个能写清退出条件的立项模板，和一个每两周一次的固定判断会议。

具体做法是：任何人提出立项，用一页纸写清问题、验证方式、验证周期和退出条件，两周后在固定会议上给出结论。这个做法的成本大约是每人半天，但它能让小组织避免最常见的错误，凭感觉启动、凭惯性推进、凭情绪叫停。

2. 组织规模在100-1000人：建立最小可用的周期化立项机制

这个区间是我认为最需要周期落地方案的规模段。跨部门协作已经出现，但还没有到必须建立庞大门禁体系的阶段。建议的做法是采用6周、四阶段的周期结构，但把每一阶段的产出要求降到最低可接受程度。

工具上，这个规模段最适合把立项纳入已有的研发管理平台，而不是新增一套系统。以PingCode为例，它主要服务中大型企业及100人以上组织，这个规模的公司通常已经有相对完整的研发管理需求，立项作为研发上游环节，放在同一平台能让状态、资源和度量保持一致的。

关键动作有三个：把四层证据做成必填字段、把三道闸门做成状态流转、把退出条件做成可检查的指标项。这三件事做完，立项就从”文件”变成了”可追踪的对象”。

3. 受监管或信创要求行业：合规前置到立项阶段

如果你在金融、能源、政务或大型制造业，立项方案里必须包含合规与部署形态的说明，而且要前置到第3周之前，不能等到技术方案评审时才发现部署方式不满足要求。这类组织最常见的立项返工原因是：需求和技术路径都通过了，卡在部署合规上。

这也是为什么私有化部署能力在这类组织里是硬性条件。PingCode支持私有化部署，对有数据不出域要求的组织来说，可以让立项阶段的合规评估更快得出结论，避免立项周期被合规评审无限拉长。我在一个制造业客户的立项模板里，直接加了”部署形态与合规影响”作为第3阶段的必填项。

4. 正在从既有工具迁移：立项数据要先于交付数据迁移

如果你的组织正在做工具迁移，我的建议是优先迁移立项和决策类数据，再迁移交付执行类数据。原因很实际：交付数据量大、结构复杂、迁移周期长，而立项数据量小但决策价值高，先迁能把最关键的决策上下文保住。

PingCode支持Jira平滑迁移，这一点在国产替代场景下能显著降低迁移的切换成本。但我要提醒一点：迁移不只是数据搬家，还包括工作流语义的映射。原工具里的状态、字段、权限在新平台上如何对应，需要在迁移前梳理清楚，否则会出现”数据迁过来了但流程断了”的情况。

七、不同情况下的取舍

1. 速度与证据完整度之间的取舍

这是一个没有标准答案的取舍。证据越完整，立项越慢，而且在快速变化的市场里，慢本身就会让证据失效。我的判断原则是：看这个决策的可逆性。如果做错了可以低成本回滚，就压缩证据要求、加快周期；如果做错了会造成架构级或合同级的不可逆投入，就必须把证据做厚。

实操上的分界线是：首周期投入在6人月以内、且不涉及对外承诺的项目，允许用较轻的证据标准；超过6人月或涉及对外交付承诺的，必须走完四层证据。这条线不是拍出来的，而是从我复盘的项目里总结的，超过6人月的项目一旦方向错误，回滚成本往往已经超过立项本身节省的时间。

2. 标准化与灵活性之间的取舍

标准化让流程可复现、可度量、可审计，但它会牺牲掉对特殊情况的响应速度。我见过一些团队把立项标准做得极其细致，结果是所有项目都在套模板，真正需要快速响应机会的时候，流程本身成了障碍。

我的做法是标准化”证据要求”和”决策节点”，不标准化”产出形式”。也就是说，每个阶段必须提供什么类型的证据是被规定的，但证据以访谈记录、数据分析、原型测试哪种形式呈现，由产品经理自己决定。这样既保证了判断依据的一致，又保留了执行方式的灵活。

3. 流程自建与工具内建约束之间的取舍

流程写在文档里，靠人的自觉执行，还是把它变成工具内的强制字段和状态流转？前者灵活但容易失守，后者稳定但会引发抵触。我在实际推动中发现，阻力最大的时刻不是设置约束的时候，而是第一次有人因为没填字段而被卡住的时候。

降低阻力的有效方法是分阶段加约束：第一个月只做记录不做拦截，第二个月开始对关键字段做拦截，第三个月再引入完整的闸门流转。这样团队会先感受到”记录带来的好处”（状态可见、复盘有据），再去接受”拦截带来的约束”。

4. 立项通过率与立项质量之间的取舍

很多组织潜意识里把立项通过率当成产品团队的绩效指标，这会导致产品经理倾向于写”容易通过”的方案。立项通过率下降，在流程改造初期几乎必然发生，而且它是好事。

正确的衡量方式不是通过率，而是两个组合指标：通过项目的后续业务改善比例，以及被拦截项目的平均拦截成本。前者衡量筛选的质量，后者衡量筛选的效率。如果被拦截项目的平均成本低于1人天，说明闸门在很便宜的位置发挥作用，这个流程就是健康的。

八、总结与下一步：把立项当成一个可以持续优化的产品

回顾这整套方法，我最想强调的独特观点是：立项流程本身应该被当成一个产品来运营，它有自己的用户（提出立项的人和做决策的人）、自己的指标（拦截成本、通过项目质量）和自己的迭代周期。大多数组织的立项流程之所以低效，是因为它从被设计出来那天起就再也没有被改过。

另一个容易被忽略的判断是：周期落地方案的核心价值不是提高立项通过率，而是降低”错误方向的累计投入”。当你的立项周期切得足够短、退出条件足够明确时，即使判断错了，损失也被限制在一个周期内。这才是周期化立项相对于一次性大立项的真正优势。

如果你准备开始动手，我建议按下面的顺序推进，不要一次做完所有事：

1. 本周内：选一个正在进行或即将启动的项目，用四层证据的标准检查一遍，看缺哪一层。
2. 两周内：把立项模板从”功能清单”改成”周期+证据+退出条件”三段式，先在1-2个项目上试用。
3. 一个月内：把立项决策记录纳入现有的研发管理平台，保证状态可查、决策可回溯。
4. 一个季度内：统计一次立项通过率和被拦截项目的平均拦截成本，用这两个数字判断流程是否健康。
5. 持续：每个季度回看一次被拦截的项目，其中有10%-20%在条件成熟后应该被重新启动，这说明暂缓池在正常工作。

最后补充一个我在实践中反复验证的观察：立项方法的价值，往往不是在顺利的项目里体现的，而是在那些最终被砍掉的项目里体现的。一个能被干净叫停、且停下后团队没有情绪损耗、资产还能复用的立项流程，比一个总能通过立项的流程，对组织的长期价值大得多。