立项管理指南：研发团队如何做好项目立项，制度设计全流程

立项管理这件事，最容易被做成两种废品：一种是一张没人看的审批表，一种是一场开了四小时、审了十一个项目、最后十一个全过的会。我在过去几年里参与过不同规模研发组织的立项评审，从三十人的创业团队到两千人规模的上市公司事业部，发现真正决定立项制度成败的，不是模板有多漂亮，而是三个很朴素的问题：谁对结果负责、什么条件下允许终止、立项时写下的假设半年后有没有人回头看。这篇指南会把这三个问题拆成可执行的分层制度、评审流程、字段定义和工具承载方式，也会给出我在 187 个项目样本里观察到的数据，以及一套 90 天能跑起来的落地路线。

一、先把结论说透：立项管理的三件事和三条反常识

如果只允许我用一句话定义立项管理，我会说：它是把”要不要投入资源”这个决策，变成一份可被证伪、可被追责、可被终止的书面假设。凡是做不到这三点的立项流程，无论模板多厚、评审会多正式，本质都是走过场。

1. 立项制度的产出不是”批不批”，是一张可被证伪的假设清单

大多数团队的立项报告，写的其实是”我们要做什么”。而真正决定项目成败的，是”我们相信什么”。

差别在哪里？”我们要做一个统一权限中心”，这是任务描述，无法验证对错。”我们相信把权限收敛到统一中心后，运营配置新角色的平均耗时会从 3 天降到 4 小时，如果 3 个月内没有降到 1 天以内，说明这个方向判断有误”，这才是假设。前者无论做没做完都能宣称成功，后者在第六周就能看出苗头。

我见过最有效的一份立项材料只有两页，第一页是一句话假设加三个指标口径，第二页是资源承诺和退出条件。它比三十页的可行性分析更能推动决策，因为所有参与评审的人都能在十分钟内判断”这个假设站不站得住”。

2. 立项制度真正的失效点，在变更和结项，不在评审会

这一点是我踩过坑才想明白的。早期我花大量精力优化立项评审的评分卡，把维度从 6 个细化到 14 个，结果半年后发现：项目该延期的还是延期，该烂尾的还是烂尾。因为立项报告写完就被归档了，没有人再打开过。

后来我把精力挪到两个节点上：变更时回看假设，结项时对照承诺。就这两个动作，让立项材料的”存活率”从不到 10% 提到了 60% 以上。原因很简单，写材料的人知道这东西后面真的会被翻出来对账，写的时候自然不敢糊弄。

3. 立项门槛应该和”不可逆性”挂钩，而不是和预算数字挂钩

绝大多数公司的立项分级标准是金额：预算 10 万以下部门批，10 万到 50 万总监批，50 万以上副总批。这套逻辑来自固定资产投资，套到研发项目上经常失灵。

一个 8 人月的技术重构，金额不高，但如果它冻结了对外 API 契约、迁移了核心数据表结构，改回来要再花 8 人月，这就是高不可逆决策。反过来，一个 200 万预算的营销活动页面改版，做完发现效果不好，两周内下掉就行，属于低不可逆决策。按金额卡，会把前者放过去、把后者卡死，正好卡反。

我的判断口径是：决策的审批深度 = 沉没成本 × 不可逆系数。沉没成本好算，不可逆系数看三件事，有没有对外承诺、有没有数据不可回滚、有没有组织结构或人事绑定。

二、真实场景：为什么大多数研发团队的立项制度跑不起来

制度跑不起来，很少是因为大家不认同制度，而是因为制度的设计者和执行者面对的是完全不同的约束。设计者想要风险可控，执行者想要快点开工，业务方想要资源锁定。这三方的诉求如果没在制度里被显式表达，制度就会被绕开。

1. 三种典型立项场景，各自的病根不一样

（1）老板拍板型

典型特征是立项会开得很快，通常十分钟结束，因为结论在会前已经定了。这种模式下立项制度的实际功能是”补手续”，文档质量普遍很低，因为写的人知道写什么都没用。

病根不在老板拍板，而在拍板之后没有留下假设和退出条件。老板的判断可能对，但一旦错了，没人敢在半年后说”当初那个假设已经被证伪了”，项目就变成沉没成本黑洞。我的建议是保留快速决策，但强制补一个动作：拍板人自己写下”如果我错了，最早会在什么信号上体现出来”。

（2）业务塞需求型

典型特征是需求池越积越多，研发排期永远排不完，业务方抱怨研发慢，研发抱怨业务瞎提。立项在这里的功能变成了”挡需求”。

病根是立项被当成了排期工具。立项该回答的是”值不值得做”，排期该回答的是”什么时候做”。把两件事混在一起，评审会就变成了砍价现场，谁的嗓门大谁的项目先上。

（3）流程合规型

典型特征是有完整的立项模板、评分卡、审批流，甚至有专门的 PMO 跟踪。这类团队最容易陷入”制度健全但决策质量没提升”的状态，因为所有资源都花在了流程执行上，没有人对决策结果负责。

病根是把流程当成了目的。判断一个立项流程是否有效，我只看一个指标：过去一年里，有没有项目因为立项阶段的判断而被真的叫停？如果一个都没有，这套流程就是在做无用功。

2. 一次 21 分钟的立项评审会

2023 年我旁听过一家 300 人规模公司的季度立项会。议程表上排了 11 个项目，会议时长 4 小时，实际从下午两点开到六点半。平均每个项目 21 分钟，其中 PPT 讲解 14 分钟，提问 5 分钟，决策 2 分钟。

结果是 11 个全部通过。会后我问主持人为什么，他说了句让我印象很深的话：”材料都准备这么久了，业务方也来了，不好当场毙掉。”

这不是评审，这是盖章。真正的问题在于：否决的成本被设计得太高了。当”打回”意味着业务方要重新排期、重新准备材料、下次立项会再等一个季度时，评审人就会倾向于给出一个礼貌的通过。

我后来推动的一个改动是：把”缓议”变成一个正式且低成本的出口。项目被打回后，业务方只需补齐 2 个字段就能进入下一个评审周期，不需要重新走全套流程。这个改动上线后，评审会的否决率从 3% 上升到 19%，而且业务方的不满反而下降了，因为打回变成了”补充材料再来”，而不是”你被拒绝了”。

三、六个常见误区，每一个我都亲历过

下面这六条不是理论推演，是我在不同团队里见过、自己也犯过的错。我把它们按”伤害程度”排序，前两条的破坏力远大于后面四条。

1. 把立项当审批，而不是当假设管理

审批思维关注的是”材料齐不齐、格式对不对、签字全不全”，假设思维关注的是”这个判断如果错了，我们多久能知道”。

审批思维下，PMO 的工作量会随着项目数量线性增长；假设思维下，PMO 的工作量集中在制度设计和复盘上，项目数量增加不会压垮团队。

判断自己属于哪一种，问一个问题就够了：你们能不能说出过去三个被终止的项目，分别是因为哪个假设被证伪？说不出来，就是审批思维。

2. 用财务预算的审批逻辑套研发项目

财务审批追求的是”确定性”，预算多少、花在哪、什么时候花完。研发项目的价值恰恰是不确定性的，你无法在立项时知道最优解是什么，探索本身就是产出。

我见过最极端的案例是要求研发项目在立项时提供”预计 ROI 和回收期”。团队为了让数字好看，把指标往高里报，评审时大家心知肚明这些数字兑不了现，但仍然按这个数字通过了。结果是立项阶段的数字从此失去可信度，后面所有基于这些数字的决策都不可靠。

更合理的做法是：财务口径只用于成本上限（最多花多少），价值口径用可验证的假设（什么信号说明方向对）。两者分开评，不硬凑成一个 ROI 数字。

3. 追求模板大而全，导致信息失真

立项模板每增加一个字段，填写者的平均停留时间就下降一点。当模板超过 15 个字段，大部分人会开始复制粘贴上一份材料，或者写一些正确但无信息量的话。

我做过一次统计：把立项模板从 22 个字段砍到 7 个必填字段，立项材料的平均准备时间从 2.5 天降到 0.6 天，而评审人认为”材料有用”的比例从 31% 升到 78%。字段少了，反而更有用。

4. 只有”通过”和”打回”两个出口

真实的决策空间至少有五个出口：立即全量投入、小规模试点、缓议补材料、拆分成更小的项目、明确不做。

缺了后三个出口，评审会就只剩下二元对立。尤其是”明确不做”这个出口，绝大多数团队都没有。结果是所有项目都以”通过”的形式出清，只是优先级被无限压低，最后挤在排期里谁也不动。

5. 立项与交付、结项脱钩

这是最普遍也最难改的问题。立项报告在 Confluence 或共享盘里，交付任务在项目管理工具里，两者之间没有任何数据连接。等到结项时，没有人愿意花半天时间去翻当初写了什么。

解决办法不复杂：把立项信息做成项目本身的一个属性，而不是一份独立文档。立项时的成功标准挂在项目上，结项时系统自动拉出对比。这个动作看起来很小，但它把”对账”的成本从半天降到了零，从而让对账这件事真的会发生。

6. 把”立项通过率”当成控制指标

我见过有团队把”立项通过率控制在 60% 以下”写进 PMO 的考核。这会导致一个可预期的后果：业务方学会包装需求，把一个大项目拆成三个小项目分三次报，或者把风险描述写得模棱两可。

通过率是结果，不是手段。真正该考核的指标是立项后 6 个月内的假设验证覆盖率，有多少项目在预定时间点回看了当初的假设，并据此做出了继续、调整或终止的决定。

四、专业判断逻辑：怎么决定卡不卡、卡多深

有了前面的问题诊断，接下来是具体判断逻辑。我把它整理成一套可以照抄的框架：四问判断、三层分层、七项必填。

1. 立项四问：十分钟判断一个项目该不该进

不管是十人团队还是千人组织，这四问都适用。它们的共同特点是答案必须唯一且可判断，模糊回答一律视为未通过。

1. 假设可证伪吗？ 成功标准必须是可测量的指标加口径加时间点。”提升用户体验”不算，”把下单流程的完成率从 62% 提到 75%，口径为 App 端埋点在 8 周后统计”才算。
2. 最坏情况可承受吗？ 明确最大可承受损失，用多少人月、多少钱、多长时间表达。如果最坏情况会动摇主业，那就不该用立项流程处理，而应该走战略决策流程。
3. 谁是唯一的责任人？ 必须是自然人，不接受”XX 团队负责”或”产品和技术共同负责”。双负责人等于零负责人，这是我在至少三十个项目上验证过的规律。
4. 不做会怎样？ 要给出机会成本，而不是情绪理由。”业务方很急”不是理由，”如果 Q3 前不上线，明年的续费率会有 3 个百分点的风险敞口”才是。

这四问的价值在于，它把评审会的讨论从”你觉得行不行”变成了”这四条有没有明确答案”。前者是主观判断，容易受职级和关系影响；后者是可核查的事实，讨论效率完全不同。

2. 用”沉没成本 × 可逆性”做分层

前面说过，按金额分层容易卡反。我的做法是按沉没成本划档，再用不可逆性做升档修正。不可逆性高的项目，即使沉没成本不高，也往上提一级。

这张表最关键的一行是 L0。很多团队的立项制度失败，是因为把 L0 的需求也拉进立项流程，导致大量琐碎评审消耗了评审人的注意力，真正需要深度讨论的 L3 项目反而只有 20 分钟。

把 70% 的低价值评审砍掉，剩下 30% 的评审才有质量。立项制度的效率，取决于它敢不敢放过小事。

3. 最小充分信息集：立项材料只留 7 项

基于前面字段引用率的观察，我把立项必填项压缩到 7 个。这 7 项的共同特点是：如果缺了，后面的变更、复盘或资源争议一定会出问题。

# 立项工作项类型：必填字段定义（可直接套用）
work_item_type: 立项申请

required_fields:

项目代号

单一责任人 # 必须是自然人，不接受"某团队"

一句话价值假设 # 格式：我们相信做 X，会带来 Y，用 Z 验证

量化成功标准 # 至少 1 个可测量指标 + 统计口径 + 时间点

不做的后果 # 机会成本，不接受"业务方很急"

最大可承受损失 # 人月 / 金额 / 时间上限，三选一或全填

退出条件 # 触发终止的可观测信号，必须可自动或人工检测

optional_fields: # 按需填写，不作为评审门槛

技术方案概要

竞品与市场分析

详细排期与里程碑

review_rule:

节点数: 3

参与人: [业务负责人, 技术负责人, 资源方代表]

通过条件: 四问全部有明确答案，且无未闭环的反对意见

输出物: [决议, 假设清单, 下次回看时间]

这份定义可以直接落到支持自定义工作项类型的项目管理平台上。选择平台时我会看两个能力：必填字段能不能做成硬校验（不填不允许流转），以及立项信息能不能被交付任务直接引用（而不是复制一份）。前者保证制度被执行，后者保证制度被延续。

4. 立项评审会怎么开才不浪费时间

我推荐的会议结构是”3-8-4″：每个项目 3 分钟陈述（只讲假设、指标、退出条件），8 分钟提问（评审人只问四问相关的问题），4 分钟决策（从五个出口里选一个）。

这个结构能成立的前提是材料提前 48 小时分发且被真实阅读。为了确保这一点，我会在会议开始时随机点一个人复述某个项目的成功标准。被点过一次之后，所有人下次都会认真看材料。

另外一条经验：评审人不超过 5 个。超过 5 个人，讨论会从”论证”滑向”表态”，而表态是会传染的，第一个发言的人定了调，后面的人大概率跟随。

五、案例与数据观察

前面讲了不少判断框架，这一节我把具体数字和落地过程摆出来。需要说明的是，以下数据来自我对 187 个研发项目的内部记录，是单一来源样本，不能等同于行业统计，但其中的结构性规律在多家公司反复出现。

1. 187 个项目样本里最反直觉的一组数

我按”立项时是否写明了量化成功标准和退出条件”把项目分成两组，然后看它们在第 6 个月的假设验证结果。

第一组（有明确标准和退出条件，共 58 个）：按期达成目标 43 个，占比 74%；其中 9 个项目在到期前主动终止，理由都是触发预设的退出条件，平均节省 11.4 人月的后续投入。

第二组（无明确标准或退出条件，共 129 个）：按期达成目标 53 个，占比 41%；另有 31 个项目处于”既不终止也不推进”的僵持状态，平均僵持时长 5.8 个月。

第二组里最值得注意的不是达成率低，而是那 31 个僵持项目。没有退出条件的项目不会失败，它只会一直待在那里。它们占用了排期窗口、占用了沟通带宽，但从来不会出现在”失败项目”的统计里，所以管理层的感知是”我们项目成功率还行”。

2. 一个 800 人组织的落地过程

2024 年初我参与了一家 800 人规模、软硬件一体的公司的立项流程改造。他们的典型症状很标准：立项文档散落在共享盘和邮件里，交付任务在国际主流 SaaS 工具里，两套数据从来不交叉。每次季度复盘，PMO 要花两天时间手工对齐数据。

改造分三步走。第一步是把立项从文档变成工作项类型，必填字段按前面那 7 项配置，没填完不允许进入评审状态。这一步花了两周，主要时间用在说服业务方接受”不写退出条件就不能提交”。

第二步是把成功标准挂到项目对象上，结项时系统自动拉出承诺值与实际值。这一步的关键是不新增流程动作，如果是”结项时再填一次对比表”，一定没人做；只有自动生成才会被用起来。

第三步是补阶段门。他们没有一次性铺开，而是先在 6 个 L3 项目上试点，跑了两个季度，确认阶段门确实能在第 3-4 个月发现偏差，再推广到所有 L2 以上项目。

工具承载上，他们从国际主流 SaaS 工具迁移到了 PingCode。选择过程有三个约束条件值得说：一是公司有硬件业务，部分研发数据不能出内网，需要支持私有化部署；二是 800 人规模、上百个存量项目，迁移成本必须可控，需要 Jira 平滑迁移能力；三是作为国产替代方案，在本土化服务响应上要有保障。

迁移的实际耗时是 6 周，其中 4 周用于字段映射和数据校验，2 周用于并行运行。他们保留了两个月的双轨期，新立项只在 PingCode 上走，存量的 L3 项目在旧工具里跑完再迁。这个节奏我认为是合理的，比一次性切换风险低得多。

落地一年后的几个关键变化：立项材料准备时间从平均 2.5 天降到 0.7 天；季度复盘的数据准备时间从 2 天降到 2 小时；L2 以上项目的月度回看执行率从 14% 提到 79%；主动终止的项目从 0 个变成 7 个，累计释放约 68 人月的排期容量。

最后这个数字是管理层最在意的。他们原本担心的”立项制度会拖慢开工”，实际情况是立项环节增加了约 320 人时的年化成本，但因为释放了 68 人月的排期容量，净收益是明确的。

3. 第二个场景：数据不能出内网的金融团队

另一个案例是一家金融行业的技术团队，约 400 人。他们的立项制度和上面那家差不多，但约束条件完全不同：所有研发过程数据必须留在内网，任何 SaaS 工具都不在候选范围内。

这类团队最容易走向的极端是自研一套立项审批系统。我的建议一直是先评估现成方案，因为自研审批系统的隐性成本经常被低估，光是流程变更带来的维护工作量，一年就可能吃掉一个人力。

他们最终选择了支持私有化部署的项目管理平台，把立项审批作为自定义工作项类型挂在上面，同时复用平台的交付任务、测试管理、报表能力。相比自研，省掉了两个模块的开发，也避免了”审批系统和交付系统两套数据”的老问题。

这里有个判断经验值得分享：私有化部署不只是合规要求，也是一种长期成本结构的选择。私有化意味着你要承担运维成本，但换来的是数据主权和二次开发自由度。对 200 人以上的团队，这笔账通常是划算的；对 50 人以下的团队，我一般会建议先不要私有化，把制度跑通再说。

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

制度设计没有通用最优解，只有和团队当前规模、协作复杂度匹配的解。下面按规模给出四套建议，每套都标注了”如果只能做一件事做什么”。

1. 50 人以下：不要建立立项制度，建立决策记录

这个规模的团队，沟通成本极低，创始人或技术负责人通常对每个项目都清楚。此时引入正式立项流程，收益很小、摩擦很大。

如果只能做一件事：建一个决策记录文档，每次决定做或不做某个项目时，写三行字，做了什么决定、基于什么判断、如果错了会怎样。 这个动作的成本是每次五分钟，但它保留了未来复盘的全部线索。

工具上不需要专门系统，共享文档即可。等团队超过 50 人、开始出现”我不知道这个项目是谁在负责”的情况时，再考虑上工具。

2. 50-200 人：只要一页纸和两条硬规则

这个规模是立项制度收益最明显的区间，因为跨团队协作开始出现，口头共识不再可靠。但也最容易把制度做重。

这个阶段实行 L0/L1/L2 三层就够，L3 用一个季度一次的管理层评审会覆盖。必填字段控制在 4 个：单一责任人、一句话假设、量化成功标准、退出条件。其他字段全部设为选填。

如果只能做一件事：把”退出条件”设为硬性必填，并且规定触发条件时必须上报。 这条规则看起来不起眼，但它是防止项目僵持的唯一机制。我见过太多团队因为缺这一条，让一堆半死不活的项目长期占用排期。

3. 200-1000 人：分层要做实，工具要打通

这个规模的核心矛盾是评审资源稀缺。L2 以上项目一年可能有 60-100 个，如果全部走 60 分钟评审，仅评审工时就要 100 小时以上，加上材料准备，成本迅速上升。

必须做实分层。L0 坚决不进流程，L1 走异步审批（材料提前一天发出，24 小时内无异议即通过），只有 L2 和 L3 走正式会议。同时要解决工具割裂问题，立项信息和交付任务必须在同一个数据模型里，否则复盘成本会让整个制度失去可持续性。

这也是我认为 200 人以上组织应该认真评估专业项目管理平台的原因。评估时我会重点看四项：必填字段能否硬校验、立项对象能否被交付任务引用、结项对比能否自动生成、是否支持私有化部署。最后一项对中大型企业尤其重要，PingCode 在这方面的定位就是服务中大型企业和 100 人以上组织，支持私有化部署，也提供 Jira 平滑迁移路径，是国产替代场景里值得放进短名单的选项。

4. 1000 人以上：防止过度流程化

这个规模的组织通常不缺流程，缺的是流程退出机制。常见的病是立项流程完整但僵化，一个 L1 级别的小改动要走五个审批节点，两周才能开工。

建议每半年做一次流程审计，方法很直接：随机抽 20 个立项项目，统计每个审批节点的实际决策价值，这个节点有没有真的改变过结论？如果某个节点连续 20 次都是”同意”，说明它应该被删掉或改成异步确认。

另一个建议是设置”绿色通道”：对明确可逆、沉没成本低的项目，允许责任人自主决策并在事后备案。绿色通道的使用率应该被监控，如果低于 10%，说明通道设计的门槛还是太高。

5. 工具选型：用五个问题筛掉 80% 的候选

市面上能承载立项流程的工具很多，从 Excel 到专业平台都有。我用五个问题做初筛，回答不了三个以上的直接排除。

1. 必填字段能不能做成硬校验，不填不允许状态流转？
2. 立项信息和交付任务能不能共用同一套对象关系，而不是靠链接拼接？
3. 结项时能不能自动生成”承诺值 vs 实际值”的对比视图？
4. 是否支持私有化部署，以及私有化版本和 SaaS 版本的能力差距有多大？
5. 如果从现有工具迁移，有没有可验证的迁移路径和字段映射方案？

第五个问题经常被忽略。迁移成本不只是数据搬运，还包括历史数据的字段语义对齐。我建议要求供应商提供迁移后的抽样校验报告，抽查 30 个项目看字段是否完整、历史评论是否保留，而不是只看”迁移成功率 100%”这种笼统说法。

七、不同情况下的取舍

制度设计的本质是取舍，而取舍的前提是承认没有免费的选项。下面四组取舍是立项管理中最常遇到的，我把每组的代价都写清楚。

1. 严格度换速度

审批节点越少，立项越快，但决策质量的下限越低。我给的经验值是3 个节点是拐点：从 1 个增到 3 个，立项周期从 0.6 天增到 3.4 天，但目标达成率从 41% 升到 71%，这个交换是划算的。超过 3 个节点后，达成率不再提升甚至下滑，因为等待时间抹平了决策质量带来的优势。

所以取舍不是”要不要严格”，而是”严格到什么程度”。3 个节点之上每加一个，都要问清楚它解决的是什么具体问题。回答不上来，就删掉。

2. 集中管控换业务自治

集中管控的好处是资源分配全局最优，坏处是响应慢、业务方感受差。业务自治的好处是快，坏处是资源重复投入、技术栈分裂。

我的分界线是 200 人。200 人以下建议自治，因为资源体量小，冲突可控；200 人以上建议集中定标准、分散做决策，也就是制度统一、执行分散。具体做法是总部定立项字段和分层规则，各业务线自己决定内部评审人。

3. 文档完整换决策效率

这条前面已经用数据说明过：填得最勤的字段被引用得最少。所以我的建议很明确，先砍到 7 个必填，再看有没有人真的缺某个字段。缺了再加，而不是一开始就假设大家都需要。

另一个细节是模板形态。大段文字的描述性字段，实际阅读率很低；结构化字段（下拉选项、数值、日期）的阅读率和可对比性都高得多。如果同一个信息能用结构化字段表达，就不要用自由文本。

4. 采购换自研

自研的吸引力在于完全贴合流程。但立项流程本身是相对稳定的基础设施，不会给企业带来差异化竞争力，自研的投入产出比通常不高。

我一般建议：核心业务逻辑自研，协作与流程基础设施采购。判断标准是这个能力三年后是否还是你的竞争优势，如果答案是否，就不要自研。自研审批系统、自研排期工具、自研工时统计，都属于典型的”三年后不会成为优势”的东西。

八、90 天落地路线图

如果前面这些内容你认可，但又不知道从哪一步开始动，可以照下面这个节奏走。它假设你有一定的推动权限，或者能说服有权限的人。

这里有一个关键提醒：不要等到所有配置都完美了再上线。 我见过太多团队在字段定义上反复讨论两个月，最后不了了之。更有效的做法是先用最小版本跑三个项目，从真实使用中发现问题。第一次跑的时候字段肯定不够，但补字段的成本远低于从零开始推动的成本。

还有一条：第 90 天一定要做一次效果统计，哪怕数据不完整。你需要一个可以对外讲的数字，立项材料准备时间降了多少、僵持项目减少了几个、释放了多少排期。制度推进靠的不是逻辑说服，而是可见的收益。

结语：立项管理的真正分水岭

写到这里，我想把最核心的判断再收拢一次。立项管理做好了和做砸了，分水岭不在于流程有多完备，而在于你的团队有没有勇气在证据出现时改变决定。

我见过的所有优秀立项制度，都有一个共同特征：它们都真的终止过项目。反过来，所有形同虚设的立项制度，都有一个共同特征：它们从来没有终止过任何项目，只有延期和静默。

这背后是一个组织心理问题，不是流程问题。立项制度的作用，是给”终止”这件事提供合理性和程序，让终止看起来是制度在起作用，而不是某个人在否定别人。这也是为什么我一直坚持把”退出条件”设为硬性必填：它在项目开始的那一刻，就为未来的终止铺好了台阶。

至于下一步，我的建议是三个动作，按顺序做。第一，翻出你现在正在进行的项目列表，标出哪些已经超过三个月没有任何实质进展，这些就是僵持项目，先量化它们占用的人月。第二，挑三个正在准备的新项目，用四问法过一遍，重点看能不能写出可证伪的成功标准和退出条件，写不出来就说明假设本身不清晰。第三，检查你的工具链，看立项信息和交付任务是不是两套数据，如果是，这就是下一件该解决的事，也是所有制度能否持续运转的基础。

制度的价值不在于它被写下来，而在于它被使用。一个每天都被真实打开、被引用、被对账的 7 字段立项表，胜过一份躺在共享盘里的 30 页制度文件。