立项管理指南：管理层如何做好项目立项，实操方法全流程

三年前我旁听过一场典型的立项评审会。三个项目，从汇报到宣布通过，总共 26 分钟。会后我问主持评审的副总：这三个项目里，哪一个你们认真讨论过”它不该做”的理由？他愣了一下说：我们讨论的是怎么做。

六个月后我回头看这三个项目的执行数据。A 项目范围改了四次，最初承诺的交付内容只剩不到四成；B 项目在第四个月被”暂时搁置”，但十七个人的人力编制一直挂到年底；C 项目倒是按时上线了，只是上线之后没有业务部门愿意接手运营。三个项目，没有一个是”失败”的，也没有一个达成了当初评审会上承诺的东西。

这件事让我形成了一个判断：大多数企业的立项管理不是失灵，而是空转。审批链条很长，文档很厚，会议记录很完整，但真正决定项目命运的那几个关键判断，几乎从来没有被认真触碰过。

这篇指南来自我过去几年在不同规模企业里做流程设计、旁听评审会、复盘执行数据的经历。它不打算再复述一遍”立项要有商业论证、要有风险评估”这类正确的废话，而是把重点放在管理层真正需要动手的三件事上：设置哪些决策闸门、在每个闸门上问什么、以及信息不足时怎么做出”可撤销的承诺”。

一、核心结论：立项管理的本质，是在高成本承诺发生前买一次低成本纠错

先把结论放在最前面。如果你只记得这一节，后面的内容都可以当成它的展开。

1. 立项不是审批环节，是”承诺分级”机制

很多管理层把立项理解成一道门：过了就干，没过就不干。这是错的。立项真正的作用，是把”我们要投入多少资源”这件事，从一次性的大承诺拆成若干个可撤销的小承诺。

一个健康的立项决策，输出的不是一个”同意”或”不同意”，而是四个明确的档位：批准全额投入、附带条件缩小投入、降级为验证性投入、不予立项。这四档之间的差别，本质上是资源承诺规模和时间承诺长度的差别，而不是态度强弱的差别。

我见过最糟糕的立项会，是把所有通过的提案都归到”批准全额投入”这一档。表面上看是效率高，实际上是管理层主动放弃了最便宜的纠错机会，因为一旦人力编制、预算科目、考核目标都按全量承诺建立起来，后面想收回的成本会高出一个数量级。

2. 管理层在立项里唯一不可替代的职责，是判断”依据够不够”

这句话听上去像废话，但执行起来经常被违背。典型场景是：提案人讲了十五分钟技术方案，管理层开始追问技术选型、架构设计、第三方组件性能，这些本应由技术负责人判断的事，被拿到了决策桌上讨论，而真正只有管理层能判断的事，比如”这个方向和公司未来两年的资源投向是否冲突”，反而没人问。

我的判断标准很直接：凡是团队内部能通过技术评审解决的问题，都不该占用立项会的时间；凡是需要跨部门让渡资源、需要牺牲其他项目优先级、需要改变组织考核目标的问题，才必须由管理层拍板。立项会的议程如果不符合这个标准，说明它退化成了技术评审会的加长版。

3. 三个可以直接观测的立项质量指标

立项管理难落地，很大原因是它看起来太”软”。但实际上有三个硬指标可以量化它的质量：

• 范围稳定率：立项通过后 6 个月内，交付内容变动幅度不超过 30% 的项目占比。这个指标衡量的是立项时的边界是否清晰。
• 止损执行率：达到预设止损条件的项目中，真正按约定停止或缩减投入的比例。这个指标衡量的是退出机制是不是装饰品。
• 决策依据完备率：评审记录中，明确写出”不建议做的理由”并在决策时被讨论的项目占比。这个指标衡量的是评审是否真的在思辨。

我在 2021 到 2024 年间，以外部顾问或旁听者身份完整跟踪过 9 家企业的立项流程，覆盖 42 场评审会、118 份立项提案。这不是严谨的统计样本，更像一份纵向观察记录。在这份记录里，范围稳定率是 61.5%，止损执行率不到 20%，决策依据完备率只有 7.6%。最后一个数字最值得警惕，它意味着超过九成的立项决策，从记录上看是”只有正面论证、没有反面讨论”的。

二、背景和真实场景：为什么 100 人以上的组织，立项一定会开始失控

30 人的公司不需要立项管理，老板一个人就能记住所有在跑的事。但组织一过某个规模，同一个决策逻辑就会失效，而且失效得非常突然。

1. 从”老板拍板”到”系统决策”的临界点在哪里

我的观察是，临界点出现在同时并行推进的项目数超过核心管理者能够记住细节的数量时。对一个 100 人左右的组织来说，这个数字大概是 8 到 12 个活跃项目。超过之后会出现一个非常典型的症状：立项时的承诺靠记忆维持，而不是靠记录维持。

一旦承诺靠记忆维持，就会出现三种失真。第一种是时间失真，三个月前说的是”Q3 上线”，传到执行层变成”今年内完成”。第二种是范围失真，原始承诺里的某个模块被悄悄延后，但没有任何一方认为这是变更。第三种最隐蔽，是责任失真：当项目出问题时，没有人能拿出当时到底承诺了什么。

这三种失真的共同根源是同一个：立项决策没有被对象化，只留下了会议纪要和一份 PPT。

2. 三种立项发起源，对应三套完全不同的评审逻辑

很多企业用同一套评审表处理所有提案，这是立项质量低的头号原因。因为不同来源的提案，风险结构完全不同，用同一把尺子去量，等于都没量准。

• 战略驱动型：来自管理层战略共识或年度规划。它的风险不在价值，而在”可量化度”，战略项目的收益往往难以在 90 天内被验证。
• 客户/销售驱动型：来自具体客户需求或销售承诺。它的风险不在价值，而在”资源可控性”和”退出灵活性”，一旦答应客户，项目就很难中止。
• 技术/团队自驱型：来自架构升级、技术债清理或团队创新。它的风险在”战略贡献”和”收益可量化度”，但资源可控性和退出灵活性通常最好。

我整理过这三类提案在五个评审维度上的相对权重分布。注意，这是我在观察样本中做的相对评分推演，不是行业统计数据。

3. 真实场景：季度末的立项冲刺是怎么形成的

这是我在六家企业里反复观察到的同一个现象：立项提案的提交时间高度集中在每个季度的最后两三周。在我统计的 118 份提案里，约 58% 集中在季度末提交。

原因不是团队拖沓，而是预算机制。很多企业的年度预算是按科目切分的，科目余额不跨期结转，于是”本季度用不掉的钱会被收回”变成了一条硬约束。在硬约束下，立项决策的目标函数就从”这个项目该不该做”悄悄变成了”这笔钱该不该花掉”。

这两者的差别是致命的。前者问的是收益，后者问的是消耗。我见过一个团队在季度最后一周提交了四个”技术预研”项目，理由写得非常漂亮，实质是把预算指标用满，避免下季度被削减盘子。这四个项目在次年第一季度全部无声无息地停了。

所以讨论立项管理，不能只讨论流程，必须同时讨论预算和考核机制。如果预算机制在鼓励”把钱花完”，再完备的评审流程也会被绕过。

4. 工具真正改变的不是审批速度，而是数据的留存结构

当立项还停留在”邮件 + PPT + 会议纪要”阶段时，数据是散落的。你想回头查某个项目立项时承诺了什么，需要翻三层文件夹、找当时的纪要附件、再对着 PPT 里的某一页做解读。

而当立项被做成平台上的一个可追踪对象时，变化不只是方便。更关键的是承诺变成了可对比的字段：当时的预算口径、当时的里程碑、当时的退出条件、当时的责任人，全部结构化留存。变更发生时，系统能直接算出”与原承诺的偏离度”，而不是靠人去回忆。

这种变化对管理层的意义在于：它把”你当初说好的”从一句情绪化的质问，变成了一条可核对的数据。这是立项治理能否长期维持的分水岭。

三、拆解常见误区：七个让立项评审彻底失效的做法

下面这七条，每一条我都见过实际发生，而且见到的频率高得惊人。

1. 把立项等同于预算审批

症状是：评审材料里 80% 是预算明细，收益部分只有一句话”预计提升效率”。评审提问也集中在”这个人力配置是不是高了””服务器费用能不能压一压”。

问题在于，预算只是立项决策的一个输出，不是输入。先确定要达成什么、再估算需要多少钱，这个顺序一旦颠倒，就会出现”为了花掉这笔钱而设计一个项目”的倒推逻辑。我见过的最极端的例子，是一个团队为了匹配 80 万的项目预算，把一个本该 20 万完成的验证型项目拆成了四个子项目，最后四个都没做完。

2. 用可行性报告替代不可行性论证

“可行性研究报告”这个词本身就带着倾向。它要求提案人证明”能做”,却没有要求任何人写出”不该做的十条理由”。

在我观察的 118 份提案里，明确写出”不建议做的理由”的只有 9 份，占 7.6%。而这 9 份提案，在后续 6 个月内的范围稳定率是 100%，没有一份发生重大范围变更。样本太小，不能过度解读，但这个对比方向相当一致：能把反对理由写清楚的提案人，对这件事的理解深度明显不同。

3. 用通过率考核评审流程

这一条危害最大，因为它会系统性地摧毁整个机制。某企业曾经把”评审一次通过率”作为流程健康度指标，目的是减少返工。结果半年内，一次通过率从 61% 升到 94%，看起来流程成熟度大幅提升。

但同期其他数据出现了明显反向变化：评审会上的平均提问数从 18 个降到 6 个，明确记录否决理由的提案从 14 份降到 3 份，而立项后 6 个月的重大范围变更率从 37% 升到 55%，12 个月内的项目取消率从 19% 升到 31%。

逻辑很简单：当通过率成为考核项，最省事的做法不是把提案做好，而是把评审做松。这是典型的指标反噬。

4. 交付边界写成愿景描述

“打造行业领先的客户运营体系”，这不是交付边界，这是口号。判断一段描述是不是边界，有一个很简单的测试：它能被证伪吗？

如果一个描述在任何情况下都能被解释成”我们已经在做了”，说明它不是边界。有效的交付边界必须包含三个要素：谁用、用它完成什么动作、什么条件下算完成。三者缺一，立项后的范围争议就一定会发生。

5. 没有退出条件，只有成功目标

绝大多数立项材料里写的是里程碑，不是止损点。里程碑告诉你”什么时候应该完成什么”，止损点告诉你”什么信号出现时必须停”。

这两者的差别在于心理机制。里程碑是承诺，一旦定下，团队和发起人都会本能地维护它；止损点是约定，它必须在情绪上来之前就写好，否则永远写不出来。我的建议是：止损条件必须在立项会上当场确定，并且由决策层而不是提案人来定。因为提案人天然不愿意为自己的项目设置终止线。

6. 审批链越长越安全

五级审批不等于五重把关，它更可能等于责任稀释。当一条链上有五个人都有审批权时，每个人的心理预期都是”前面还有人在看”，最后的结果往往是没有人真正在看。

我对比过两家规模相近的企业：一家是三级审批加一个明确的”质疑人”角色，另一家是六级串联审批。前者的评审会平均时长 52 分钟，问题密度高；后者平均时长 14 分钟，大部分环节的审批意见是”同意”。六个月后的范围稳定率，前者 68%，后者 43%。

7. 一套模板评审所有类型的项目

前面已经用数据说明过：战略型、客户型、技术型的风险结构完全不同。用同一套 ROI 模板去卡技术债清理项目，结果一定是技术债永远排不上号；用同一套战略对齐模板去卡客户型项目，结果一定是销售绕过流程私下承诺。

正确的做法不是取消标准，而是按类型切换评审表单和评审人。这一点在后文会给出具体设计。

四、专业判断逻辑：立项的四道闸门和一张决策卡

下面这套框架是我在实际项目里反复调整过的版本。它的设计原则只有一条：每道闸门都必须有一个可以当场判定”过或不过”的问题。做不到当场判定的闸门，本质上都是无效闸门。

1. 第一道闸门：战略闸门，它是否在”现在必须做的事”清单里

这道闸门最容易被做成形式主义，因为它很容易被”这也算战略相关吧”糊弄过去。我的做法是强制提案人回答一个反事实问题：

如果这个项目今年完全不做，我们会在哪个具体指标上、在多长时间内、看到什么程度的损失？

如果答不出具体指标和时间窗，说明它不在”必须做”清单里，只属于”做了也好”。战略闸门的通过标准不是”与战略相关”，而是”不做会有可描述的损失”。

2. 第二道闸门：价值闸门，收益能不能被证伪

这道的核心问题不是”收益有多大”，而是“收益假设如果错了，我们第几天能知道”。

我见过太多提案的收益论证方式是”行业报告显示该领域平均效率提升 30%”。这句话在评审会上几乎无法被反驳，正因为它无法被反驳，它也就无法被验证。

有效的价值论证必须包含一个验证节点：在项目启动后的某个时间点，用某个可观测的数据来判断核心假设是否成立。我在实践中要求这个节点不晚于 90 天。超过 90 天才能验证的收益假设，实际上已经失去了指导决策的价值，因为到那时投入规模已经很难回头了。

3. 第三道闸门：可行性闸门，资源、能力、外部依赖

这道闸门的关键词是”是否已经确认”，而不是”是否计划确认”。

典型的失守场景是：提案里写”由数据团队支持两人月”，但数据团队负责人从未被问过。项目批准后，数据团队说”我们现在排不开，下个季度吧”，项目一开始就延期三个月。

所以可行性闸门的判定标准很硬：核心人员、预算科目、外部依赖，必须全部有名有姓、有具体承诺时间。任何一项写了”届时协调”，就是不通过。

4. 第四道闸门：可退出闸门，分阶段承诺与止损点

这道闸门是四道里最重要、也最常被省略的。它的产出是三条明确的止损线：投入止损（累计投入超过多少且验证指标未达标就停）、时间止损（到某个时间点仍未通过验证节点就降级）、价值止损（某个业务条件不再成立就终止）。

需要强调的是，止损点不是”惩罚机制”，而是”降低决策门槛的机制”。它的存在让管理层可以更大胆地批准探索性项目，因为下行风险被明确限定了。没有止损线的项目，看上去更安全，实际上把风险敞口无限打开了。

5. 一张可以直接拿去用的立项决策卡

把四道闸门落成一张表，就是下面这个样子。我建议把它做成评审记录的标准模板，而不是让评审人自由发挥。

用这张表去看具体的项目，差异会非常直观。下面是我在一次评审中实际打分的三个项目，它们的最终结局也验证了得分。

6. 评审会本身的规则设计

框架对了，会议规则不对，结果还是会走偏。以下是我实际推行过、并且确实改变过评审质量的六条规则：

1. 提案人陈述不超过 10 分钟。陈述时间越长，讨论时间越短，这是几乎所有评审会的通病。
2. 设置轮值的质疑人角色。每场评审指定一人专门负责提出反对意见，并且要在记录中署名。这个角色不能由提案人的直接上级担任。
3. 每份提案必须包含至少一条”不建议做的理由”。写不出来就不进入评审议程。
4. 决策只允许四种结果：批准、附带条件批准、缩小范围后重提、不批准。取消”原则同意”这种模糊结论，它只是把问题推到下一周。
5. 止损条件当场确定，由决策层写入记录。不允许”提案人回去补”。
6. 评审记录必须包含被否决的理由。被否决提案的否决理由，半年后回看，价值往往高于通过提案的批准理由。

五、案例与数据观察：把立项从 PPT 搬到平台上之后发生了什么

这一节讲一个具体案例。我不会只讲”用了工具就变好了”，而会把变化拆成可以核对的口径。

1. 案例背景

案例主体是一家约 1200 人的制造业企业，有三个事业部、一个中央 IT 部门和一个企业级 PMO。他们在 2022 年之前用的是自建的立项流程：OA 表单提交 + 邮件会签 + Excel 台账登记。PMO 有两个人专门负责维护这份台账。

问题很典型：立项材料分散在 OA 附件和邮件里，PMO 台账只登记了项目名称、负责人、预算金额和立项日期四个字段，没有交付边界、没有退出条件、没有与后续需求及迭代的关联。结果是立项与执行之间断链，PMO 每季度做一次项目健康度盘点，需要手工向 20 多个项目负责人发问卷。

2022 年下半年，他们开始把立项流程迁到研发管理平台上。他们选择的是 PingCode，主要原因有三个：这家企业属于中大型组织，需要打通立项、需求、迭代、测试到发布的完整链路；有数据合规要求，需要支持私有化部署；同时他们此前部分团队在使用海外工具，希望走一条平滑迁移的路径，降低切换成本。

2. 迁移前后四个关键指标的变化

下面的数据来自该企业 PMO 提供的前后对比（示意数据，用于说明机制而非评价具体产品）。

3. 为什么”立项对象化”比”立项文档化”有效

这个案例里最值得复制的动作，不是换了工具，而是把立项从一份文档改成了一个结构化的对象。具体做法是把立项申请做成一个带必填字段的工作项，字段结构大致如下：

立项对象字段结构（示意）
├── 基本信息

│ ├── 提案名称 / 发起人 / 业务归属

│ └── 提案类型：战略型 | 客户型 | 技术型

├── 战略关联

│ ├── 对应战略目标（必选，来自目标库）

│ └── 不做的具体损失（必填，至少 50 字）

├── 价值假设

│ ├── 核心收益假设

│ ├── 验证节点日期（必填，不得晚于立项后 90 天）

│ └── 验证指标与口径

├── 交付边界

│ ├── 使用者 / 使用场景 / 完成判定标准

│ └── 明确不包含的内容

├── 资源与依赖

│ ├── 人力（含责任人确认状态）

│ ├── 预算科目与金额

│ └── 外部依赖及承诺日期

└── 退出条件

├── 投入止损线

├── 时间止损线

└── 价值止损线

关键不在字段多，而在“验证节点日期”和”三条止损线”是必填项。这两个字段一强制，提案人就必须在立项阶段把”怎么算成功”和”什么时候该停”想清楚，而不是留到执行阶段再说。

配套的是审批流设计。这家企业把审批拆成了条件分支：金额低于 50 万且属于技术型提案，走两级审批；金额 50 万以上或涉及跨事业部资源，走三级审批并强制进入投委会；涉及外部客户承诺的提案，必须附加法务或商务部门的确认节点。这样做的结果是，审批层级不是按组织级别定的，而是按风险类型定的。

4. 一个被低估的收益：立项与执行的数据不再断链

这个案例里，PMO 感知最强的变化其实不是评审变快了，而是季度盘点不再需要发问卷。立项对象与后续需求、迭代、测试用例建立关联之后，系统可以直接算出每个项目”原承诺范围”和”当前实际范围”的偏离度，以及里程碑的实际达成情况。

立项时的承诺从一句话，变成了一组可对比的基线数据。这个变化的治理价值在于：它让”承诺偏离”从一个人际冲突问题，变成了一个数据核对问题。过去 PMO 要和项目负责人争论”这算不算重大变更”，现在只需要打开对比视图。

对于中大型组织来说，这类链路打通通常需要平台级支持，尤其是当组织有私有化部署要求、或者需要从既有工具平滑迁移时，是否具备完整的迁移路径会直接影响落地周期。这一点在选型阶段往往被低估。

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

立项管理没有通用解。下面按组织规模和业务特征给出四套建议，你可以直接对号入座。

1. 30 人以下的团队：不要建立流程，只建立一件事

这个阶段建立完整评审流程的代价大于收益。你只需要建立一件事：每个项目的启动必须写下一句”什么情况下我们会停”。

写在一页文档里，写清楚项目名、发起人、验证日期、止损条件，就够了。不要审批链，不要模板库，不要评审会。这个阶段管理层的注意力本身就是最稀缺的资源，把它花在流程上会得不偿失。

2. 100 到 300 人的组织：建立四道闸门，但压缩到一页纸

这个规模是立项管理收益最高的区间。此时并行项目数已经超过管理者的记忆容量，但还没有形成复杂的部门政治。建议做法是：

• 用一页纸的决策卡（即第四节的表格）作为唯一评审模板，按提案类型切换问题清单。
• 评审会固定在每周或每两周一次，每次不超过 90 分钟，最多评审 4 个提案。
• 强制设置”验证节点日期”和”三条止损线”两个字段，其余可以宽松。
• 暂不引入复杂工具，用共享表格或轻量看板记录即可，重点是字段结构而不是系统能力。

3. 500 人以上、多业务线的组织：必须做对象化和分层授权

这个阶段的核心问题不是流程缺失，而是流程不统一。不同事业部各自一套立项标准，导致跨部门资源协调时缺少共同语言。建议做法是：

• 把立项做成平台上的结构化对象，打通与需求、迭代、里程碑的关联，避免立项与执行断链。
• 按金额和风险类型做分层授权，而不是按组织级别做串联审批。低风险小金额提案由事业部自主决策，高风险或跨部门提案上收。
• 建立统一的项目组合视图，让管理层能看到”当前所有在跑项目的总资源占用”，而不只是单个项目的信息。
• 如果组织有数据合规要求或需要从既有工具迁移，选型时优先确认私有化部署能力和迁移路径的完整度。

这一层级的工具选型，评估重点应该放在链路完整性和迁移成本上，而不是单个功能点的丰富程度。以 PingCode 这类面向中大型组织的平台为例，其价值主要体现在立项、需求、迭代、测试到发布的链路打通，以及私有化部署和对既有工具数据的平滑迁移能力，对一个 1000 人级组织来说，迁移成本往往是决定项目成败的隐性变量。

4. 强监管行业：把合规检查前置到立项闸门里

金融、医疗、军工等行业的立项评审，必须额外增加一道合规闸门，而且它应该放在战略闸门之前。原因是这类行业的项目一旦在合规上走不通，后面的价值论证、资源规划全部作废。

具体做法是把合规判定做成一个”是/否”的前置分流：涉及哪些监管条款、需要哪一级审批、是否需要外部评估。这个分流不通过，提案不进入后续流程。这样可以避免大量资源浪费在注定无法落地的提案上。

七、不同情况下的取舍

立项管理本质上是一系列取舍。没有哪一套配置是全面占优的，关键在于知道自己正在放弃什么。

1. 决策速度与决策严谨性

加快评审速度最直接的办法是减少提问、缩短材料准备时间，代价是决策质量下降，而这个代价通常在 6 个月后才显现。所以真正的取舍不在于”快还是慢”，而在于把严谨性集中在哪一道闸门上。

我的建议是：如果只能保住一道闸门，保”可退出闸门”。因为前三道闸门判断错了，代价还可以通过止损来限定；而第四道闸门缺失，代价是无限的。

2. 标准化与灵活性

标准化降低协调成本，但会让边缘类型的提案被系统性忽视。灵活性保护了创新，但会让跨部门资源协调变得困难。

我的判断是：流程格式标准化，判定标准按类型切换。即所有人都用同一张决策卡，但战略型、客户型、技术型在每一道闸门上的问题和权重不同。这样既保留了统一语言，又避免了”一把尺子量所有人”。

3. 集中审批与业务自治

集中审批的优势是能看清全局资源占用，劣势是决策慢、离业务远。业务自治的优势是响应快，劣势是容易重复建设和资源抢占。

分界线应该按”是否占用跨部门稀缺资源”来划，而不是按金额。一个 20 万但需要占用数据平台核心人力的项目，比一个 200 万但完全在事业部内部消化的项目更需要集中审批。

4. 自建流程与采购平台

自建的优势是灵活、可控、初期成本低。劣势是随着组织规模增长，维护成本会非线性上升，而且很难打通立项与执行的数据链。

我的经验判断是：并行项目数在 30 个以下时，自建或轻量工具足够；超过 50 个，或者组织有多个事业部需要统一视图时，平台化投入的回报开始明显。此时的评估重点应该放在链路完整性、私有化部署能力和历史数据迁移路径上，而不是功能数量对比。

5. 私有化部署与 SaaS

这是一个常被简化成”安全 vs 便宜”的取舍，但实际维度更多。私有化部署的优势在数据主权、内网访问和定制空间，代价是运维投入和版本升级滞后。SaaS 的优势是开箱可用、迭代快，代价是数据边界和长期成本曲线。

我的建议是分场景判断：涉及核心研发资产、受监管数据或与生产系统深度集成的场景，优先私有化；面向协作、轻量协作类的场景，SaaS 更划算。对中大型组织来说，很多情况下不是二选一，而是混合部署。

八、把立项管理真正做起来：从下周一开始的三个动作

回到最开始那场 26 分钟的评审会。它的问题不在于时间短，而在于没有人被要求回答”这个项目不该做的理由是什么”。这是一个可以在一周内改变的事情。

如果你现在就想动手，我建议只做三件事，不要一次性铺开。

第一件，把”不做的具体损失”和”三条止损线”加进你的立项模板，作为必填项。不需要改流程，不需要开会讨论，直接改模板即可。这两个字段本身就足以改变提案人的思考方式。

第二件，在下一次评审会上安排一个轮值的质疑人，并要求他在记录中署名。先试三次，看看评审质量有没有变化。以我的经验，只要质疑人这个角色存在，会议的平均提问密度会明显上升。

第三件，把”评审一次通过率”从任何考核指标中删掉。如果它已经在考核体系里，这一条比前两条加起来都重要。因为它是一个会系统性地反向激励整个机制的指标。

立项管理最难的地方，从来不是设计一套制度，而是让这套制度在没有明显回报的前六个月内保持运转。四道闸门、一张决策卡、三次会议规则，这些东西不会立刻让项目变好，它们只是让”不该继续的项目”更早被发现。

而这件事的价值，只有在你回看那些曾经挂着一整年人力编制、最后无声停止的项目时，才会真正被感知到。