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

2023 年下半年，我帮一家做工业软件的公司复盘他们过去 18 个月的立项记录：47 个正式立项的项目，有 11 个在上线后 6 个月内被下线或合并，占比 23.4%；另外 9 个项目预算超支超过 30%。但真正让我意外的不是这些数字，而是复盘会上一位项目经理说的话，”这些项目立项的时候，我们自己心里也没底，只是没人问我们这个问题。”立项管理出问题，往往不是审批不严，而是评审的对象错了：评审委员会在评审一份文档，而不是在评审一组可以被检验的假设。

项目经理在其中被迫扮演”资源争取者”，而不是”风险揭示者”，制度也就自然退化成了文笔比赛和排期游戏。

一、先说结论：立项管理是给不确定性定价，不是走流程

我把立项管理定义为一件很具体的事：在资源不可逆投入之前，把项目最关键的几个不确定性，用可验证的方式写下来、标上价格、约定谁来验、什么时候验。它不是一次签字仪式，而是一个持续到项目结束的风险定价过程。这个定义听起来抽象，但它直接决定制度该怎么写。如果你认同它，你的立项模板里就不会只有”项目背景、目标、预算、排期”，而会多出”关键假设、验证方式、证伪信号、退出条件”这四栏。

1. 立项通过率不是越高越好

很多公司会把”立项通过率”当成效率指标考核 PMO，我强烈建议把这个指标删掉。立项通过率长期高于 90%，通常意味着立项门槛形同虚设，前端筛选没有真正发生，所有分歧和不确定性都被推迟到了开发阶段。

我给客户做诊断时更看三个反向指标：立项后被否决或终止的比例、立项后发生重大范围变更的比例、立项材料中被证伪的假设数量。最后一个尤其关键，如果一份立项材料提交上去，没有任何一条假设被评审质疑或证伪，那这次评审基本等于没开。

2. 项目经理是风险揭示者，不是资源争取者

项目经理在立项环节最常见的动机冲突是：他想拿到这个项目，所以倾向于把风险写小、把收益写大。制度设计必须承认这个人性现实，而不是靠”要求客观”来解决它。我的做法是把角色拆开：项目经理负责写”关键假设清单”和”证伪信号”，业务方负责写收益承诺，技术负责人负责写可行性边界，评审委员会负责交叉质询。同一个人不能既承诺收益又评估收益。

3. 制度设计要盯住三个硬指标

一套立项制度好不好，不用看文档写得多漂亮，看三个数字就够了：决策周期、假设可验证率、退出触发率。决策周期指的是从材料提交到给出结论的自然日数；假设可验证率指的是立项时的关键假设中，有明确验证方式和验证时点的比例；退出触发率指的是达到预设证伪信号后，真正被执行终止或重估的项目比例。

第三个指标最能暴露制度真假。我见过太多公司的立项文档里写着”若三个月内用户留存低于 15% 则终止”，结果没有一个项目真的被终止过，这种条款等于没有。

二、真实场景：立项失控的四种典型现场

抽象讲制度没意义，我先还原四个我亲身参与过的现场。这些场景你大概率也见过，只是当时未必意识到问题出在立项环节。

1. 现场一：三周写材料，二十分钟拍板

一家做供应链 SaaS 的公司，项目经理为了一个 280 万元预算的项目，花了三周时间准备 46 页 PPT。立项会开了 20 分钟，CEO 问了三个问题：”客户是谁？””竞品做了吗？””什么时候能上线？”得到回答后当场通过。

问题在于，那三个问题都得到了”是”的回答，但没有一个回答是可验证的。客户是谁，回答是”三家头部制造业客户”，但没有签约意向书；竞品做了吗，回答是”看过两家”，但没有功能对比矩阵；什么时候能上线，回答是”Q3″，但没有资源日历支撑。这个项目在 Q4 才上线，且三家客户中只有一家真正采购。

2. 现场二：立项即巅峰，预算一次性给满

另一家做金融科技的公司，立项流程非常规范，材料齐全、评审严格、签字完整。但他们的制度里有一个致命设计：预算在立项时一次性全额拨付。结果就是，项目一旦立项，即使中途发现方向有问题，团队也会倾向于”先把钱花完”，因为停止意味着承认失败，而预算不会回收。

我统计过他们 2023 年的 26 个立项项目，其中 7 个在中期已经出现了明确的负面信号（用户增长停滞、客户续约率下滑、技术方案被证伪），但无一被终止。这 7 个项目合计消耗了约 640 人月。

3. 现场三：立项会变成跨部门协调会

第三个现场更常见。立项评审会请了 12 个人，包括市场、销售、研发、测试、运维、法务、财务。会议开了 90 分钟，其中 60 分钟在讨论”这个需求到底该归哪个部门做””上线后运维谁值班””测试资源怎么排”。

这些问题都重要，但它们不是立项问题，是交付规划问题。把两类问题混在一个会上，结果是立项决策被交付细节稀释，最后既没有把方向定清楚，也没有把排期排明白。我的建议是明确切开：立项会只回答”要不要做、做到什么程度、什么条件下停”，交付规划会再回答”谁做、怎么排、怎么验”。

4. 现场四：没有”不立项”的正式通道

最隐蔽的问题是这个。绝大部分公司的立项制度只规定了”怎么立项”，没有规定”怎么体面地不立项”。于是产生两个后果：一是评审委员会倾向于”先立了再说”，因为否决需要给理由、要面对业务方的追问；二是被否决的提议没有沉淀，半年后同样的想法会被重新提一遍，重新走一遍流程。

我后来在制度里加了一个动作：所有被否决的提议进入”观察池”，记录否决理由和重新触发条件（比如”当某客户明确表达付费意愿时重新评估”）。这个池子后来成了我们最有价值的信息资产之一，因为它记录了公司对机会的判断轨迹。

三、拆解六类常见误区

上面四个现场背后，是六类反复出现的制度误区。我把它们按危害程度排序，前两类属于结构性问题，后四类属于执行层问题。

1. 误区一：把立项当作文笔比赛

这是最普遍的问题。立项材料要求”逻辑清晰、论据充分、格式规范”，但没有任何一栏要求”写出你认为这个项目最可能失败的三个原因”。

结果是，材料写得最好的项目经理往往拿到资源，而不是最想清楚了的那个人。我的修正办法是强制加入一栏”最可能失败的前三条原因及证伪信号”，并规定如果这三条写得含糊，材料一律退回。这一栏没法靠文笔糊弄，因为它要求你具体到”哪一天、用什么数据、判定什么结果”。

2. 误区二：用单点 ROI 替代区间判断

“预计年化收益 1200 万，投入 300 万，ROI 为 4。”这类表述在立项材料里随处可见，但它掩盖了最大的信息，这个 1200 万是怎么算出来的，波动区间有多大，最坏情况是多少。

我现在的做法是强制三点估算：乐观值、基准值、悲观值，并且规定悲观值必须由技术负责人和业务负责人分别独立给出。实践中最有价值的不是基准值，而是乐观与悲观之间的差距，差距越大，说明可行性验证越不充分，就越应该先做小规模验证再全额投入。

3. 误区三：门槛一刀切

有些公司规定”所有项目都要走完整立项流程”，包括一个两周就能做完的运营活动页面改版。结果是流程被滥用，大家对流程产生抵触，真正重要的大项目反而因为”反正都一样”而被轻慢对待。

另一些公司走向另一个极端，只有超过 500 万预算的项目才需要评审，结果 480 万的项目被拆成两个 240 万，规避了所有审查。门槛设计必须同时考虑金额和风险类型，我在第四节会给出一张具体的分级表。

4. 误区四：立项即冻结范围

“立项通过后范围不得变更”这条规定，表面上维护了严肃性，实际效果是团队把变更藏起来，用”优化””调整”的名义做，变更不再被记录，也就无法被分析。

我的判断是：立项应该冻结的是”目标”和”约束”，不是”范围”。目标指的是要达成的业务结果，约束指的是预算上限、合规要求、上线时间窗。范围反倒应该允许在明确条件下调整，只要每次调整都有记录、有人批、并且触发对目标达成率的重新评估。

5. 误区五：制度只写”谁批”，不写”批什么”

我看过大量立项管理办法，八成的篇幅在讲审批权限和流程节点，只有两成在讲评审内容。这是本末倒置。审批权限错了可以改，评审内容错了，整个制度就失去了筛选功能。

一份合格的立项制度，应该用至少一半篇幅明确规定：不同级别项目必须提交哪些材料、每份材料要回答哪些具体问题、评审人必须针对哪些项给出书面意见。把”批什么”定义清楚，比把”谁批”排明白重要得多。

6. 误区六：没有立项后的再评估点

最后一个误区最容易被忽略。立项是一次决策，但项目周期往往长达 6-18 个月，环境会变，假设会被证伪。如果制度里只有一个决策点，那前面所有的严谨都只是把风险推迟暴露而已。

我坚持在制度里设置至少一个中期再评估点，通常在项目周期的 30%-40% 处，评估内容不是”进度是否正常”，而是”立项时的关键假设是否仍然成立”。如果假设已经失效，进度再正常也要重估。

四、专业判断逻辑：立项制度的四层结构

把上面所有问题翻译成可执行的制度，我通常按四层来搭建。这四层是有顺序的：门槛决定谁需要评审，材料决定评审什么，评审结构决定怎么得出结论，再评估决定结论能维持多久。顺序颠倒会导致制度空转。

1. 第一层：分级门槛

门槛的设计要解决两个问题：不同风险级别的项目配不同强度的评审，以及防止通过拆分规避审查。我的做法是三维定级，预算规模、风险类型、组织影响面，取最高级别作为项目级别。

风险类型是很多公司忽略的维度。一个 50 万元的合规改造项目，风险可能高于一个 300 万元的内部效率工具，因为它涉及对外承诺和法律责任。组织影响面则看这个项目是否会改变多个部门的协作方式，如果是，即使金额小也需要更高级别评审。

这张表最关键的设计不是金额分档，而是拨付方式和再评估节点的联动。L1 一次性拨付是因为风险可控、周期短；L4 按里程碑逐段审批，是因为一次决策无法覆盖长周期的不确定性。

2. 第二层：立项材料的最小充分集

我不主张材料越全越好。我见过要求提交 11 份附件的立项制度，结果是项目经理花两周填表，评审人花十分钟翻页。我的做法是定义”最小充分集”，只保留四份材料，但每份都必须扎实。

1. 一页纸项目定义：要达成的业务结果、不做什么、成功判据、约束条件。限定一页，是因为写长容易，写短才是真思考。
2. 关键假设清单：三到七条最可能出错的假设，每条都要有验证方式和证伪信号。这是我要求写得最细的一份。
3. 三点估算表：乐观、基准、悲观三档的资源投入、周期、收益，并说明悲观值的依据来源。
4. 退出条件：明确写出什么情况下应该终止或重估，包括时间点、指标阈值、决策人。

四份材料之外，我允许评审委员会按需索取补充材料，但规定必须在 24 小时内提出，避免无限追加。材料清单的确定性，本身就是项目管理制度成熟度的一个标志。

3. 第三层：评审结构与决策规则

评审会最容易犯的错，是把所有话题混在一起。我的做法是拆成三段，每段有不同的参与人和不同的产出。

第一段是质询段，只做一件事：攻击假设。参与人是技术负责人、业务负责人、风控或财务，项目经理只做答，不做辩护式陈述。这一段的产出是”哪些假设被接受、哪些需要补证、哪些已被证伪”。

第二段是定级段，确定项目级别和拨付方式。这一段通常不需要全员参与，由决策主体内部完成即可。产出是级别、预算上限、拨付节奏。

第三段是约定段，明确再评估的时间点、指标和决策人。这一段最容易被省略，但它是整个制度能否闭环的关键。产出是再评估备忘录，进入项目档案。

关于决策规则，我强烈建议明确写出”否决需要理由，且理由必须进入观察池”，同时规定评审委员会中必须有一名”专职质疑者”，由不承担该项目交付责任的人担任。这个角色很反人性，但没有它，评审会很容易变成集体背书。

4. 第四层：再评估与退出

再评估不是进度汇报。我在制度里明确区分：进度汇报回答”做得怎么样”，再评估回答”还该不该做”。这两件事由不同的人组织，前者由项目经理，后者由 PMO 或独立评估人。

再评估的核心动作是逐条复核关键假设：当时的假设现在是否仍然成立？验证数据是什么？如果不成立，应该缩小、暂停还是终止？我要求再评估的默认选项是”缩小”而不是”继续”，因为继续往往是惯性选择，而缩小或终止需要主动决策。

五、案例与数据观察：一家 400 人企业怎么做立项改造

讲到这里都是判断和结构，我用一个完整案例把前面的逻辑串起来。这是我 2023 年深度参与的一个项目，客户是一家 400 人规模的软件企业，主营业务是行业解决方案，客户集中在制造业和能源。

1. 改造前的状态

改造前，他们的立项制度有三个特点：立项材料是一份 12 页的 Word 模板；评审会由技术副总主持，参会 9 人；预算在立项通过后由财务一次性划拨到项目账户。

2022 年全年，他们立项 31 个项目，其中 8 个在上线后一年内被判定为”未达成预期目标”，5 个项目预算超支超过 25%，立项平均决策周期 4.2 天。这里有个反常识的地方：决策周期短并不是效率高的表现，而是评审没有真正发生。4.2 天的周期里，项目经理提交材料到上会平均只用 1 天，说明没有任何人认真读材料。

2. 改造动作

我们做了四件事，没有一件是”加强审批”。

1. 把立项材料从 12 页压到 4 份，新增”关键假设清单”和”退出条件”。删掉了原有的市场分析、竞品分析等模板章节，改为按需提交。
2. 评审会拆成质询段和定级段，并设专职质疑者。质疑者由不承担交付责任的资深技术专家轮流担任，任期半年。
3. 预算改为三段拨付，中期再评估成为硬性节点。中期评估未通过，剩余预算自动冻结，需重新申请。
4. 把制度落到系统里，而不是停留在文档上。他们在项目管理平台上把立项做成了一个独立的工作项类型，材料按字段结构化填写，缺少关键字段无法提交；中期再评估自动生成任务并指派到独立评估人；退出条件被写成系统内的规则提醒。

第四点值得多说几句。这家公司评估后选择了 PingCode 作为底座，主要原因是他们要私有化部署，同时需要把立项、需求、迭代、测试串在一条链路上。PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署，并且支持从 Jira 平滑迁移，对于有国产替代诉求的团队来说是一个值得纳入选型短名单的选项。

我特别看重的是它的可配置性：立项单的字段、必填校验、审批分支、再评估触发规则，都可以按自己的制度来配，而不是反过来让制度迁就工具。制度先行、工具固化，这个顺序不能反。

3. 用系统固化制度的一个具体做法

他们把”关键假设清单”做成了子工作项，每条假设是一个独立条目，包含验证方式、验证时点、责任人、当前状态四个字段。状态只有四种：未验证、验证中、已证实、已证伪。

中期再评估时，系统自动列出所有”未验证”和”已证伪”的假设，评估人必须逐条处理。这个设计消灭了”假装评估”的空间，你不能说”整体看还行”，因为系统在一条一条问你要结论。下面是他们立项单的核心字段结构，我做了脱敏简化：

project_charter:
project_name: ""

level: L1 | L2 | L3 | L4 # 由预算、风险类型、影响面三维取最高

business_outcome: "" # 要达成的业务结果，一句话，可度量

out_of_scope: [] # 明确不做什么

success_criteria:

metric: ""

baseline: ""

target: ""

measure_at: "" # 判定时点

key_assumptions: # 3-7 条，本项目的核心

statement: "" # 假设内容

verify_method: "" # 用什么方式验证

verify_at: "" # 什么时间验证

owner: "" # 谁负责验证

status: unverified | verifying | confirmed | falsified

estimation:

optimistic: { cost: "", duration: "", benefit: "" }

baseline: { cost: "", duration: "", benefit: "" }

pessimistic:{ cost: "", duration: "", benefit: "" }

pessimistic_basis: "" # 悲观值的依据来源，必填

funding:

tranches: [] # 拨付段数与比例

release_condition: "" # 每段释放条件

exit_conditions:

trigger: "" # 触发条件

threshold: "" # 阈值

decision_maker: "" # 谁有权决定终止

review_points:

at_progress: 40% # 项目进度百分比

reviewer: "" # 独立评估人

focus: "assumption_revalidation"

这份结构里，我认为最有价值的三行是 pessimistic_basis、status 和 exit_conditions.decision_maker。第一行强迫你解释悲观值从哪来，第二行让假设状态可追踪，第三行明确了谁有权喊停。没有第三行，退出条件就只是一句口号。

4. 十二个月后的数据

改造从 2023 年 4 月开始，我跟踪了前后各 12 个月的数据。需要说明的是，这些数据来自企业内部统计，样本量有限，不能当作普遍规律，但趋势足够清晰。

立项数量从 31 个降到 22 个，下降了 29%。这个数字一开始让管理层很紧张，以为是效率下降。但同期交付的项目数量只从 19 个降到 17 个，而达成预期目标的项目从 11 个升到 14 个。换句话说，少立了 9 个项目，达标的反而多了 3 个。

立项平均决策周期从 4.2 天升到 11.5 天，增加 7.3 天。但立项后需求变更率从 61% 降到 19%，预算超支率从 34% 降到 8%，按期交付率从 46% 升到 78%。用 7 天的前端投入，换回 42 个百分点的变更率下降，这笔账很好算。

还有一笔账我们当时算过，但没有写进对外汇报里：立项环节的隐性成本。改造后评审更严格，会议时间、材料制作、等待审批的时间都增加了，这些是看得见的成本。但改造前那些无形成本从没被计算过，无效项目的沉没投入、因方向错误导致的重做、被占用却产出为零的关键人力。

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

制度和组织规模强相关。同一套立项流程，在 40 人团队里是负担，在 2000 人公司里是不够用。我按四个规模段给出可操作建议，你可以直接对照自己的情况取用。

1. 50 人以下团队：只保留一份清单

这个阶段不要建制度，建模板就够。我建议只保留一份”关键假设清单”，三到五条，写清楚验证方式。评审会不需要正式流程，找业务负责人和技术负责人各花 30 分钟过一遍就行。

这个阶段最应该避免的是照搬大公司的审批流程。我见过 35 人的初创公司搞三级审批加立项委员会，结果是所有人都在等签字，产品迭代速度直接砍半。

2. 50-200 人团队：建立分级与拨付节奏

这个阶段的核心矛盾是资源开始稀缺，但还没有正式的资源分配机制。建议做两件事：一是建立 L1/L2/L3 三级门槛，明确各级的决策主体；二是把预算拨付从一次性改为两段式。

两段式拨付是性价比最高的动作。它不需要增加任何评审工作量，只是把”给钱”这个动作拆成两次，却能让中期检查真正有约束力。我见过一家 120 人的公司只做了这一个改动，半年内主动终止了 3 个项目，节省了约 210 人月。

3. 200-1000 人团队：把制度落到系统里

这个规模段最常见的问题是制度存在但执行不一致，有的部门认真填，有的部门走形式，PMO 靠催。根本原因是制度停留在文档层面，没有工具约束。

我的建议是选择可配置性强的项目管理平台承载立项流程，把关键字段设成必填、把再评估做成自动生成的任务、把退出条件做成规则提醒。中大型企业在这个阶段通常有私有化部署和安全合规的诉求，选型时可以重点关注这类能力。

4. 1000 人以上或多产品线组织：分层治理

这个规模段的难点不是流程设计，而是避免所有项目都挤到同一个决策通道上。我的做法是建立”两层决策”：产品线内部决策 L1/L2，公司级决策 L3/L4，并且允许产品线在统一框架下自定义字段。

统一的是：假设清单、退出条件、再评估机制。可自定义的是：具体指标、评审参与人、拨付比例。这样既保证了公司能看到全局数据，又不至于让每个产品线都被同一套细节绑住。

5. 强监管与信创场景：把合规前置到立项

如果你的项目涉及数据合规、行业监管或国产化替代，立项阶段必须加入一组专门的评估项。这类项目的特点是一旦方向错误，纠正成本极高，甚至不可逆。

我的建议是增设”合规与依赖评估”专栏，至少包含：涉及的数据类型与流向、外部组件或平台的替换可行性、迁移方案与回退方案、停摆容忍时间。其中”停摆容忍时间”是我认为最关键的一项，它直接决定了迁移方案是激进还是保守。很多国产替代项目失败不是因为技术不行，而是因为低估了业务停摆的代价。

七、不同情况下的取舍

制度设计本质是一系列取舍，没有最优解，只有匹配。我把最常见的三组取舍摊开讲，给出我的判断依据。

1. 速度与严谨的取舍

这组取舍的答案取决于你的错误成本结构。如果错误可以被快速纠正且代价可控，就选速度；如果错误的纠正成本极高或不可逆，就选严谨。

具体判断方法是问一个问题：这个项目如果做错了，多久能发现，发现后多久能改回来？如果答案分别是”一个月内发现、两周改完”，那就不需要重型评审；如果是”半年后发现、需要重构”，那前面多花两周完全值得。我在第四节里提到的中期再评估点，本质上就是在缩短”发现错误”的时间。

2. 集中决策与分散决策的取舍

集中决策的优势是资源可以全局最优分配，劣势是决策者对一线信息的掌握有限，且容易成为瓶颈。分散决策反之。

我的判断依据是资源冲突的频率：如果各业务单元之间争夺同一批人、同一笔预算的情况频繁发生，就必须集中；如果基本各管各的，就应该分散。一个实用的折中是”分散立项、集中定级”，项目由各业务单元自己发起和评审，但级别和资源配额由中央统一裁定，避免出现级别注水。

3. 自建与采购的取舍

很多团队会考虑自研一套立项管理系统。我的建议是：除非立项流程本身就是你的核心竞争力，否则不要自研。

立项管理的功能本质上不复杂，表单、审批流、字段校验、任务触发、报表。自研的成本不在于开发，而在于后续的维护、权限体系、审计合规、与研发链路的集成。我见过一个 300 人团队自研立项系统，两年投入约 180 人月，最后因为无法与需求和测试链路打通而弃用。

选型时我建议重点看三件事：一是字段和流程的可配置程度，能否不改代码就适配你的制度；二是与需求、迭代、测试、发布链路的贯通程度，立项不该是一个信息孤岛；三是部署方式与迁移路径。对于中大型企业和有信创诉求的组织，私有化部署能力和从 Jira 平滑迁移的能力通常是必须项，选型阶段建议直接要求厂商提供迁移方案与数据映射说明，而不是停留在”支持”这两个字上。

4. 制度刚性与例外空间的取舍

制度必须刚性，但刚性不等于没有例外。我的做法是设置”紧急立项通道”，但给它配上三重约束：事后补材料的时间上限、更高一级的审批人、以及必须记录触发紧急通道的原因。

原因是：如果没有正式例外通道，人们会创造非正式例外，而后者完全不可追踪。我见过一家公司，明文规定所有项目必须走立项，实际上有相当一部分项目是以”技术预研”的名义绕过立项的。把例外合法化并加上约束，比假装例外不存在要健康得多。

八、明天就能用的立项制度骨架

最后我给一份可以直接拿去改的骨架。它的设计原则是制度先行、工具固化、数据可回溯，你不需要一次做完，可以先从前三步开始。

1. 四步落地顺序

1. 第一步（1 周）：定义分级门槛。确定 L1-L4 的预算区间、风险特征、决策主体。这一步只需要一次会议。
2. 第二步（2 周）：定义材料最小充分集。写出四份材料的模板，重点是关键假设清单和退出条件两栏。
3. 第三步（2 周）：设计评审结构。把评审拆成质询段、定级段、约定段，指定专职质疑者人选和轮换机制。
4. 第四步（持续）：把制度配到系统里。字段必填、再评估自动触发、退出条件规则化，让制度不依赖人的自觉。

2. 关键假设清单的填写规范

这份清单是整个制度的重心，我给出四条硬性规范，可以直接写进制度。

• 假设必须是可证伪的陈述句。“用户会喜欢这个功能”不合格；”至少 5 家目标客户在试用后 30 天内表达付费意愿”合格。
• 必须写明验证方式和验证时点。没有时点的假设等于没有假设，因为它永远不会被检验。
• 必须指定验证责任人。这个人不能是项目经理，否则会变成自我验证。
• 数量控制在三到七条。少于三条说明没认真想，多于七条说明没有抓重点。

3. 再评估会议的三个必答问题

再评估不是进度会，我要求会议纪要必须逐条回答三个问题，缺一条则会议无效。

1. 立项时的每一条关键假设，现在的状态是什么？未验证的必须给出原因和新的验证时点。
2. 如果今天重新做决策，我们还会立这个项目吗？这个问题的作用是打破惯性，把”继续”从默认选项变成主动选项。
3. 剩余资源如果投到别处，产出会不会更高？这是在制度里内置机会成本视角，避免沉没成本绑架决策。

4. 一份可直接复用的立项评审清单

这张表可以直接印出来贴在立项评审会议室里。我自己的经验是，这七项里有三项以上不合格，项目基本不该在这次会议上通过，而应该退回补充材料。

结语：立项管理的独特价值，在于它是一次可以被追溯的思考

写了这么多，如果只留一个观点，我希望是这个：立项管理真正的产出不是一份批准文件，而是一份可以被追溯的思考记录。当项目在半年后陷入困境时，你能翻回立项材料，看到当时是基于什么假设做的决策、哪些假设被证伪了、谁负责验证、为什么没有触发退出条件，这份记录的价值远超审批本身。

大部分公司的立项制度只解决”谁批”，不解决”批什么”和”批完之后怎么办”。这两个缺口，才是项目失败率居高不下的结构性原因。我在本文里反复强调关键假设清单、三点估算、退出条件、再评估节点，都是围绕这两个缺口设计的。

下一步我的建议是分三步走，不要一次全上。第一步，先在你当前正在带的项目里试填一份关键假设清单，三到五条，看自己能不能写出来，写不出来的部分，就是你项目里最危险的地方。第二步，在你负责的范围内推行两段式拨付，这是改造成本最低、约束力最强的动作。第三步，当流程跑顺之后，再考虑选一个可配置性强的平台把制度固化下来，让字段必填、任务自动触发、数据可统计，而不是靠人盯着。

制度不是越严越好，而是越匹配越好。你的组织规模、业务节奏、错误成本结构，决定了你应该选择什么样的立项强度。先把不确定性写下来，再决定要不要投钱，这个顺序在任何规模的组织里都不会错。