立项管理指南：项目负责人如何做好项目立项，制度设计全流程

立项管理的真实困境，不是”流程太松”，而是”通过了不等于想清楚了”。我复盘过一家年营收 30 亿的制造企业 2023，2024 年的立项数据：全年提交 217 个立项申请，评审通过 204 个，通过率 94%；一年后逐项回看，真正达成立项书里那份商业目标的项目只有 78 个，占 38%。更刺眼的是另一组数字，被否决的 13 个项目里，有 9 个在半年内以”特批”或”改名重报”的方式重新启动。

这说明审批环节并没有在做筛选，它只是在做登记。

我后来把这个问题拆成了三层：立项决策需要的最小信息集是什么，制度该怎么设计才能强制产出这套信息，以及用什么工具把过程数据留下来、让下一次立项比上一次更准。这篇指南就是这三层的完整答案，包含我实际踩过的坑、改过四版的评审模板、以及在中大型组织落地时验证过的阈值设定。

一、先给结论：立项管理的本质是风险定价，不是资源审批

绝大多数公司的立项制度是从”资源分配”出发设计的：钱有多少、人有多少、今年该做几个项目。于是立项书变成了一份”要资源”的申请书，评审会变成了一场资源争夺战的裁判席。我见过最典型的场景是，一个项目负责人在评审会上花了 20 分钟讲技术方案有多先进，却没法回答”如果关键假设错了，我们在第几个月能知道”。

立项真正要解决的问题只有一个：在投入大量资源之前，把不确定性定价。定价的方式包括说清楚关键假设、设定可观测的验证信号、约定止损点和退出条件。这四件事做完了，哪怕项目后来失败，组织也学到了东西；这四件事没做，哪怕项目侥幸成功，组织也只是运气好。

1. 立项制度必须强制产出的四样东西

我总结的判定标准很朴素：一份立项材料如果不包含下面四样，它就不具备被评审的资格，应该退回补充，而不是”先过会再说”。

• 可证伪的目标。不是”提升客户满意度”，而是”把华东区工单首次响应时长从 4.2 小时压到 1.5 小时以内，2025 年 Q2 末验收”。目标必须包含指标、基线、目标值、验收时点四个要素。
• 关键假设清单。逐条列出”我们相信 X 成立，因为 Y”，并标注每条假设的验证成本和失效影响。一般 3，7 条，超过 10 条说明还没想清楚。
• 止损与退出条件。写清楚什么信号出现时必须重新评审、暂停或终止，以及谁来触发。没有退出条件的项目，本质上是一次不可逆的赌注。
• 分阶段资源承诺。不要一次性批全年预算，而是”第一阶段批 3 人月 + 20 万，验证通过再批第二阶段”。这一条对控制组织级风险的效果最明显。

2. 一个能快速自检的问题

如果你想知道自己公司的立项制度到底有没有用，问一个追问就够了：“过去 12 个月，有几个项目是因为立项阶段设定的退出条件而被主动终止的？”

如果答案是 0，那大概率不是你的项目都很成功，而是退出条件写在文档里但从来没人执行。我服务过的一家企业，第一次统计这个问题时答案是 0；把退出条件做成系统里的强制检查项之后，第二年主动终止了 7 个项目，同时把这些项目的人力提前释放到了两个战略项目上，年底整体交付准时率反而提高了 11 个百分点。

二、真实场景：立项流程是怎么一步步变成”走过场”的

制度失效从来不是某一天突然发生的，它有清晰的退化路径。下面四个场景我在不同规模的组织里都见过，几乎可以当作立项退化的四个阶段。

1. 场景一：KPI 驱动的年度立项洪峰

年初集中立项，各部门为了不被砍预算，把能报的项目全报上去，形成”立项洪峰”。评审会一天过 20 个项目，平均每个项目 18 分钟，其中有 11 分钟在讨论预算数字，剩下 7 分钟走形式。

我见过最夸张的一次，评审组成员在会前 10 分钟才拿到 40 页的立项书。这种情况下，评审的实质决策依据不是材料质量，而是汇报人的表达能力和部门话语权。评审速度一旦超过信息消化速度，评审就退化成投票。

2. 场景二：老板拍板后的补签流程

战略项目往往先由高层拍板，然后倒回去补立项材料。这本身没错，错的是补签的材料被当成真实决策依据进入数据库。三年后回头看历史数据，你会发现所有立项书的质量都很高，因为它们是”结果已知”之后写的。

我建议的做法是：把”战略立项”和”申请立项”分成两条通道，用不同的模板和不同的评估侧重，但两条通道都必须产出假设清单和退出条件。区别只在于谁来验证假设，战略立项验证的是执行风险，申请立项验证的是商业风险。

3. 场景三：技术团队的”先做后报”

技术重构、架构升级类项目最容易出现这种情况：团队已经写了两个月代码，然后补一份立项申请，理由是”已经做了，不立项没法走报销”。这类补报的项目往往有一个共同特征，没有可量化的业务目标，只有”技术债太重了”这种感受性描述。

我的处理方式是：允许技术类项目用技术指标立项，但必须把技术指标翻译成一个业务影响假设。比如”把接口 P99 从 800ms 降到 200ms”，对应的业务假设是”因超时导致的订单失败率从 0.7% 降到 0.2%，按日均 3 万单计算，每年减少约 5.5 万单失败”。翻译不出来，说明这个项目可能不该立。

4. 场景四：跨部门项目的责任真空

跨部门项目的立项书通常写得很漂亮，因为没有哪个部门需要为它真正负责。我统计过一家企业的 41 个跨部门项目，其中有 33 个的立项书上”项目负责人”一栏写的是某位总监，但这位总监在项目上投入的时间不到每周 2 小时。

跨部门立项必须解决三个归属问题：谁对结果负责、谁对资源负责、谁对退出决策负责。这三个角色可以是同一个人，但必须在立项书上明确写出名字，而不是写部门。

三、四个高频误区，以及它们各自的对策

下面这四个误区，我在做立项体系诊断时的出现频率超过 80%。它们的共同点是：看起来是在加强管理，实际上是在削弱决策质量。

1. 误区一：把立项当审批，而不是当假设检验

审批的思维模式是”够不够格、该不该批”；假设检验的思维模式是”我们相信什么、怎么知道对不对”。前者导向的是证明自己正确，后者导向的是尽快暴露错误。

判断一个组织的立项文化属于哪种，看一个问题就够：立项会后，项目负责人是被要求”按计划执行”，还是被要求”优先验证第 2 条假设”？如果是前者，假设清单就是摆设。

2. 误区二：用文档厚度替代决策信息密度

我见过 68 页的立项书，核心决策信息大约只有半页。剩下的 67.5 页是行业分析、竞品截图和技术架构图，这些内容在网上一搜就有，对”该不该投、投多少、什么时候停”这三个问题几乎没有贡献。

我的建议是强制”一页决策书”制度：立项材料可以附长篇，但第一页必须是决策书，且第一页必须能独立支撑决策。评审会只讨论第一页。这一条改完之后，我们有一次评审会从 3.5 小时压缩到 50 分钟，而决策质量评分反而上升了。

3. 误区三：只有”通过”和”否决”两个选项

二元决策会逼着评审组在信息不足时做全量承诺。真实项目里，绝大多数值得做但还不确定的事情，正确的决策是“有条件通过”，批一小笔钱、批一段时间、设定明确的验证节点，到点看信号再决定。

我把有条件通过的标准结构定义成三段：验证目标（要证明什么）、资源上限（最多花多少）、决策节点（什么时间看什么数据）。这三段写清楚，一个”不确定”的项目就变成了一个”可控的实验”。

4. 误区四：立项通过即归档，没有立项后验证

这是我认为损失最大、修复最容易的一个误区。项目立项后 30，90 天是假设被证伪的黄金窗口期，但绝大多数组织的立项流程在这个窗口期是完全缺席的。

我推动落地的一个做法是”三段回看”：第 30 天看关键假设的验证进度，第 60 天看资源消耗与产出的比例，第 90 天看第一版可观测指标是否出现预期的方向性变化。90 天之后的回看，基本只能发现问题，无法纠正问题。

四、专业判断逻辑：立项四问与决策阈值

制度是壳，判断逻辑是核。我把所有行业、所有项目类型的立项评审收敛成四个问题，它们构成了我的决策框架。

1. 第一问：这个项目要改变什么可观测指标

关键词是”可观测”。我要求每个立项必须绑定一个大盘指标，这个大指标能拆成 2，3 个过程指标。拆不出来的项目，说明还没有找到抓手，应该继续做探索而不是立项建设。

（1）指标绑定的三个硬性要求

一是必须带基线，没有基线的目标无法验证；二是必须有数据来源，如果这个指标当前采集不到，立项的第一阶段就必须包含采集能力建设；三是必须有归属人，指标对应的负责人不能是”某某部门”。

（2）什么情况可以不绑定大盘指标

合规强制类项目可以只绑定合规节点，比如”某认证必须在 Q3 前通过”。但即便是这类项目，也应该写出”不做的后果”，罚款额度、执照风险、客户流失，这些都是可量化的。

2. 第二问：关键假设是什么，错了会怎样

我用的是一张”假设，验证，影响”三列表。每一行写一条假设，标注验证方式和验证成本，以及如果这条假设不成立会带来多大影响。

经验上，一个健康的立项书里应该有 3，7 条假设，其中至少 1 条是”高影响 + 低验证成本”的，这种假设应该在第一阶段优先验证。把高影响假设留到最后验证，是项目失败最常见的技术性原因。

3. 第三问：最坏情况下的止损点和退出条件

止损点的设计有三个维度：时间、成本、信号。三个维度至少要设定两个，只设一个容易被绕过。比如只设了”预算超支 30% 就停”，团队就会通过压缩范围来控制预算，把问题藏起来。

（1）退出条件的三种写法

第一种是阈值型：某个指标在 N 周内没有达到 X，自动触发重新评审。第二种是里程碑型：某个关键验证节点未通过，项目降级或暂停。第三种是外部触发型：政策、客户、竞品发生特定变化，主动重新评估。三种写法都有效，关键是必须写清楚”谁来触发”。

（2）为什么退出条件经常失效

因为触发人往往是项目负责人本人，而没有人愿意主动承认自己的项目该停。所以我的做法是：退出条件的触发权交给一个第三方角色，通常是 PMO 或者立项评审组里的一名固定成员。这一条改完之后，退出条件的实际执行率从不足 10% 提升到了 60% 以上。

4. 第四问：为什么是现在，为什么是我们

这两个问题专门用来对抗”跟风立项”。我把它叫做反向证伪：如果这个项目换一个团队做、或者推迟两个季度做，结果会有什么不同？如果答案没有实质性差别，那这个项目的优先级就应该往后排。

这个问题在评审会上经常能问出很有价值的信息。有一次评审一个数据中台项目，问到”为什么是现在”，回答是”因为友商做了”，随后我们把它降级成了一个 6 周的预研，省下了本来要批的 180 人月。

五、全流程设计：从触发到归档的六个阶段

前面讲的是判断逻辑，这一节讲制度落地的具体流程。我把它设计成六个阶段，每个阶段有明确的产出物、责任人和时限要求。中小团队可以合并阶段，但不要删掉产出物。

1. 阶段零：立项触发与预登记

触发有两种：主动提报和被动响应。这个阶段只需要极简的信息：一句话描述项目要解决的问题、预计规模、提出人、期望决策时间。预登记的目的是让 PMO 提前判断走哪条通道，而不是让评审组提前看到材料。

我坚持保留预登记这一步，是因为它能让立项洪峰可视化。当你在系统里看到某个季度有 47 个项目在排队，本身就是对组织的一次提醒。

2. 阶段一：初筛（30 分钟规则）

初筛由一个 2，3 人的小组完成，每人独立阅读不超过 15 分钟，合计不超过 30 分钟。判断标准只有三条：问题是否真实存在、目标是否可观测、规模是否与预期匹配。任何一个不满足，退回补充或者直接否决。

初筛的价值在于把 80% 的精力留给真正需要深度讨论的项目。我经手的一次落地里，初筛把 62 个申请过滤到了 19 个进入深度评估，评审会的平均质量立刻上来了。

3. 阶段二：深度评估

深度评估不是写文档，而是做验证。这个阶段的核心动作有三个：一是找数据验证问题规模，二是找一线人员验证假设，三是找技术负责人验证可行性。评估结束后产出的不是”更厚的立项书”，而是”假设清单的更新版”。

我要求深度评估阶段必须至少完成一次”反方质询”，由一名不参与项目的人扮演质疑者，专门攻击最关键的假设。没有经历过反方质询的立项，风险溢价应该被打高。

4. 阶段三：评审会与决策

评审会的设计要点是”先看一页决策书，再看附件”。议程我固定为四段：项目负责人 8 分钟陈述、反方质询 5 分钟、评审组提问 12 分钟、现场决策 5 分钟。合计 30 分钟一个项目，超过 30 分钟的项目说明信息不足，应该退回而不是延长会议。

决策结果我建议设四档，而不是两档：通过、有条件通过、延期再议、否决。有条件通过要当场写清楚验证目标、资源上限和决策节点，这三句话直接写入系统成为后续的检查项。

5. 阶段四：立项后 30/60/90 天验证

这是我强烈建议所有组织增加的一个阶段。30 天看假设验证进度，60 天看资源消耗与阶段产出的比例，90 天看首个可观测指标的方向性变化。三次验证都通过，项目转为常规管理；任何一次不通过，触发重新评审。

这个阶段最容易遇到的阻力是”项目刚起步，别打扰他们”。但我的经验恰恰相反：早期发现方向偏差的纠正成本，大约是项目中期发现时的十分之一。

6. 阶段五：变更、暂停与终止

立项不是一次性事件，而是一份持续履行的协议。所以变更、暂停、终止都应该是立项流程的正常出口，而不是失败。我建议对”主动终止”给予正面评价，把它纳入 PMO 的绩效指标，而不是当成事故。

下表是我在落地时使用的阶段产出物与责任分配表，可以直接作为制度草案的基础。

六、工具与数据：立项管理数字化怎么落地

制度设计好了，如果只靠邮件和共享盘，三个月就会退化成”谁记得谁做”。立项管理必须落到一个能承载流程、数据和时间节点的系统里。

1. 立项管理需要哪几类数据

我把立项相关的数据分成四类，缺任何一类都无法形成闭环。

• 决策数据：每个项目的假设清单、退出条件、决策结论、决策时间和参与人。
• 过程数据：各阶段停留时长、补充材料次数、退回次数。这些数据用来诊断流程本身的瓶颈。
• 结果数据：30/60/90 验证记录、指标实际变化、变更和终止记录。
• 关联数据：立项与后续需求、任务、缺陷、发布之间的关联链路，用来回溯”立项时的假设”和”交付时的现实”之间的差距。

第四类数据是大多数组织的盲区，也是最难通过表格维护的。如果立项系统和研发过程系统是两套割裂的工具，你永远做不出立项准确率的长期趋势。

2. 用某项目管理平台承载立项流程的实践

我在给中大型组织做落地时，通常会把立项流程配置成一个独立的项目类型，使用自定义工作流承载六个阶段，用自定义字段承载假设清单和退出条件，用自动化规则承载 30/60/90 的定时提醒。

这类平台里，PingCode 在立项流程配置上的适配度比较高。它主要服务中大型企业及 100 人以上组织，支持自定义工作流、字段级权限和跨项目的度量看板，正好覆盖立项管理最需要的三件事：流程可配置、数据可追溯、指标可看板化。

一个具体的配置思路是这样的：用”需求”承载立项申请，用”状态流”承载六个阶段，用”自定义字段”存放假设清单（多行文本）和退出条件（结构化字段，含触发人、触发阈值、触发时间），再用自动化规则在立项通过后的第 30、60、90 天自动创建验证任务并指派给第三方触发人。

# 立项对象的关键字段设计（配置示例，非代码依赖）
project_initiation:

id: INIT-2025-0417

title: 华东区工单响应加速

stage: deep_assessment # 阶段：预登记/初筛/深度评估/评审/验证/归档

decision: conditional_pass # 结论：pass/conditional_pass/defer/reject

owner: 张明 # 项目负责人（实名）

business_owner: 李静 # 业务归属人（实名）

target_metric:

name: 工单首次响应时长

baseline: 4.2h

target: 1.5h

source: 工单系统 TICKET_RESP

verify_at: 2025-Q2

assumptions:

id: A1

content: 80% 工单集中在 3 类问题，可模板化处理

impact: high

verify_cost: low # 优先验证

verify_method: 抽样 500 条工单分类

id: A2

content: 一线坐席一周内可掌握新流程

impact: medium

verify_cost: medium

verify_method: 试点小组 5 人培训 + 考核

exit_conditions:

type: threshold

signal: 响应时长 60 天内未降至 2.5h 以下

trigger_owner: PMO # 第三方触发人，非项目负责人

type: cost

signal: 累计投入超过 45 人月

trigger_owner: PMO

resource_commitment:

phase_1: 3 人月 + 20 万

phase_2: pending # 验证通过后再批

这个配置的价值不在于它多复杂，而在于它把”退出条件的触发人”变成了系统里的一个必填字段。当触发人不是项目负责人时，退出条件的执行率会显著提升，这一点我在前面已经用数据说明过。

3. 关于私有化部署与迁移的现实考虑

立项数据包含商业目标、资源预算和战略方向，属于组织的高敏感数据。100 人以上的组织在选择平台时，私有化部署往往是硬性要求。

PingCode 支持私有化部署，这一点对金融、制造、政企类客户尤其重要。另外，很多组织在立项和研发过程上已经有历史沉淀，迁移成本是真实存在的顾虑。PingCode 支持 Jira 平滑迁移，可以把历史项目、工作流和自定义字段映射过来，避免”新系统上线，历史数据断档”这种常见问题。从国产替代的角度看，它属于可选范围内需要考虑的选项之一。

我建议在做这类迁移时，不要一次性迁全部历史数据。先迁移最近 12 个月的活跃项目，把立项与交付的关联链路打通，历史归档数据按需查询即可。一次性迁十年数据的项目，我见过太多最后烂尾的。

4. 立项健康度看板应该看什么

我通常给客户配置五组指标，这五组指标能覆盖立项体系的健康状况。

1. 立项漏斗转化率：各阶段之间的转化比例，用来判断筛选强度是否合理。
2. 决策周期：从预登记到决策结论的平均工作日，用来判断流程效率。
3. 有条件通过占比：健康值通常在 40%，70% 之间，过低说明评审过于二元，过高说明评审组在回避决策。
4. 退出条件触发率：过去 12 个月有多少项目真正触发了退出条件，低于 5% 说明条件写得没有意义。
5. 目标达成率与立项准确率：立项时承诺的目标，一年后达成了多少；这个数字是立项体系唯一的终极指标。

5. 一个容易被忽略的度量：立项返工率

立项返工是指项目在通过后 90 天内因为立项时的信息缺失而需要重新上会评审。这个指标直接反映立项材料的质量。

我服务过的一家企业在改造前，立项返工率是 34%；推行一页决策书和反方质询之后，降到了 11%。这个指标的好处是它完全在组织内部可控，不需要依赖外部市场变化来解释。

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

同一套制度不可能适配所有组织。下面按规模和项目类型给出差异化的落地建议，你可以直接对照自己的情况取用。

1. 30 人以下团队：轻量立项，重退出条件

这个规模不需要立项评审组，也不需要六个阶段。我建议只保留三样：一句话问题描述、一页假设清单、一条退出条件。评审形式就是创始人或负责人和项目负责人聊 20 分钟。

但退出条件必须写。小团队最大的风险是把全部人力压在一个错误方向上，而没有人有余力踩刹车。人数越少，止损机制越重要，因为缓冲资源越少。

2. 100，500 人组织：建立初筛与深度评估的两级结构

这个规模是立项制度收益最明显的区间。核心动作是把初筛独立出来，由 PMO 或技术委员会成员兼职承担，用 30 分钟规则过滤掉明显不合格的申请。

同时建议引入”有条件通过”这一档决策。这个规模的组织通常已经能承担小规模实验的成本，用有条件通过把不确定性项目变成可控制的实验，比一刀切地通过或否决要有效得多。

3. 500 人以上 / 多事业部：统一门槛，分级授权

大组织的核心矛盾是标准化与灵活性。我的建议是统一决策书的格式和必填字段，但按预算规模分级授权：50 万以下由事业部自行决策，50 万，300 万由跨部门评审组决策，300 万以上由公司级投资委员会决策。

分级授权的前提是数据统一。如果各事业部用不同的模板和不同的系统，公司层面就永远无法做出横向对比，也无法识别重复立项。这类场景下，选择支持多项目空间、统一度量口径的平台就变得很关键，PingCode 在这方面的项目集管理和度量能力可以覆盖这类需求。

4. 强监管行业：把合规节点前置到立项阶段

金融、医疗、汽车等行业的项目，合规风险往往是最大的风险来源。这类组织的立项材料必须包含合规评估结论，且合规负责人需要作为共同决策人签字。

我见过一个教训深刻的案例：某项目立项时未评估数据出境合规要求，开发完成后才发现架构需要大改，最终延期 7 个月、追加投入 220 人月。合规问题在立项阶段的评估成本通常不到 5 人天，在交付阶段却是几十倍。

5. 创新探索型项目：小步快跑，重假设轻计划

这类项目的立项书不应该写详细的项目计划，而应该写验证路径。资源分阶段承诺的重要性远高于目标精确性。

我的建议是给这类项目设一个硬上限：单个探索项目的第一阶段资源不超过 5 人月，验证周期不超过 8 周。8 周后必须给出明确的”继续/调整/终止”结论，不允许”再看看”。

6. 客户交付型项目：前置锁定范围与验收标准

这类项目的风险几乎全部来自范围蔓延和验收标准模糊。立项阶段必须完成的动作是：范围清单双签、验收标准可测量化、变更流程和变更计价规则明确。

我通常会要求在立项材料里附一份”被排除项清单”，明确写出哪些内容不在本次范围内。这份清单在后期争议中的价值，往往超过范围清单本身。

八、取舍：立项严格度与组织速度的平衡

所有关于立项制度的讨论，最后都会落到一个问题上：严一点慢，松一点快，到底怎么选。我的答案是不做全局选择，而是做结构性选择。

1. 严格度换来的三种成本

第一是决策周期成本，这是最直观的，也是最容易被放大的。第二是创新抑制成本，当立项变得很麻烦，员工会倾向于不提报新想法，而是”先做出来再说”，反而绕过了所有管控。第三是形式主义成本，为了通过评审而精心包装材料，材料越来越漂亮，信息含量越来越低。

第三种成本最隐蔽也最危险。我的判断标准是：如果立项材料里开始出现大段行业趋势和竞品分析，而假设清单只有寥寥两条，说明形式主义已经开始侵蚀决策质量。

2. 三种可以放宽的情形

1. 可逆性高的项目。决策容易回退、损失容易回收的项目，比如内部工具的界面改版，可以走简化流程。
2. 规模小且有先例的项目。同类项目做过 3 次以上、结果可预测的，可以把立项简化为登记。
3. 时间窗口极短的机会型项目。这类项目可以”先批后审”，但必须在启动后 30 天内补齐假设清单和退出条件，否则由 PMO 强制暂停。

3. 三种绝不能放宽的情形

1. 不可逆的投入。涉及大额硬件采购、长期合同、专有架构绑定的项目，一旦投入就难以回退，必须完整立项。
2. 跨部门资源占用超过 3 个部门的项目。协调成本高，责任容易真空，必须明确三个归属角色。
3. 涉及合规、数据安全、客户承诺的项目。这三类问题的纠正成本是指数级的，必须前置评估。

4. 用组合策略替代一刀切

我的落地建议是建立一个二维分类矩阵：横轴是可逆性（高/低），纵轴是投入规模（小/大）。四个象限对应四种流程强度：低可逆性 + 大投入走完整六阶段；高可逆性 + 小投入走登记制；低可逆性 + 小投入走简化立项加退出条件；高可逆性 + 大投入走完整评估但可以缩短验证周期。

这样做的效果是，组织既不会在所有项目上平均用力，也不会因为个别高风险项目而给所有项目加码。把管控资源集中投在不可逆的决策上，才是立项管理的杠杆点。

九、总结与下一步：把立项从关卡变成学习机制

回到开头那组数据，94% 的通过率和 38% 的目标达成率。这两者之间的差距，不是执行力问题，也不是市场问题，而是立项这个动作本身没有被定义为”验证假设”的环节，而是被定义成了”申请资源”的手续。

我这几年最核心的一个判断是：立项管理的上限，取决于组织愿意多大程度地承认”我们不知道”。一个能在立项书上坦率写下”这条假设我们没把握，打算用 3 周和 2 万块验证”的组织，比一个每份立项书都论证得滴水不漏的组织，实际上更接近成功。

如果要给一个下一步的行动清单，我会按顺序建议这五件事。

1. 这周先做一件事：把最近半年的项目拿出来，统计一下”有多少个是因为立项阶段的退出条件被终止的”。答案是 0 的话，你就找到了最优先要修的地方。
2. 两周内推出”一页决策书”：规定立项材料的第一页必须包含目标、假设、退出条件、分阶段资源四块内容，且评审会只讨论第一页。
3. 一个月内建立退出条件的第三方触发机制：把触发人从项目负责人改成 PMO 或评审组的固定成员，并把这个字段写进系统成为必填项。
4. 一个季度内上线 30/60/90 验证：先在一个事业部试点，不要全公司铺开，跑顺了再推广。
5. 一年后回看两个指标：立项返工率和目标达成率。前者应该下降，后者应该上升。如果两个都没动，说明制度做了但判断逻辑没变，需要回到第四节的四个问题重新对齐。

立项制度的价值不在于拦住多少项目，而在于让组织更快地知道哪些事情不该继续做。当你开始能用一个季度而不是一年判断一个方向的价值，立项管理才算真正生效。