立项管理指南：企业管理者如何做好项目立项，最佳实践全流程

去年 Q4，我陪一家做工业设备的中型企业复盘全年 47 个立项项目，结果比预想的更刺眼：真正走完流程并产生可衡量业务价值的只有 19 个，占比 40%。更刺眼的是另一组数字，这 47 份立项书里有 31 份是在同一套 PPT 模板上改出来的，立项评审会的平均时长是 14 分钟。用一个季度的人力，批量生产了 47 份看起来很像样的”决策依据”，而其中大部分并没有改变任何决策。

这不是个案。我过去几年参与过 60 多家企业的立项流程诊断，从 30 人的创业团队到 3000 人的多事业部集团，发现一个高度一致的规律：立项环节省下的时间，会在交付环节以十倍以上的成本还回来。而绝大多数企业的立项管理，恰恰是整套研发管理体系里最薄、最随意的一环。

这篇文章不讲”立项要写哪几份文档”这类模板化内容。我想讲清楚三件事：立项管理的本质是什么，什么样的判断逻辑能真正把无效项目挡在门外，以及不同规模的企业应该把立项流程做到什么颗粒度。文中会给出我在实际项目中反复验证过的漏斗模型、闸门设计、评分卡，也会完整拆解一家 800 人制造企业的改造过程、真实取舍和数据变化。

一、先给结论：三个反常识判断

如果你只有三分钟，先把这三个结论拿走。它们和大多数公司立项制度文件里写的东西不太一样，但都是我被打脸多次之后才敢下笔的。

1. 立项管理的目标不是”挡住项目”，而是”把不确定性提前暴露”

很多公司给立项管理设的 KPI 是”立项通过率下降”，或者”今年砍掉了多少个项目”。这是把手段当成了目的。立项环节真正的产出，不是一份通过或不通过的决议，而是一组被验证过或被明确标注置信度的关键假设：用户真的需要这个东西吗？现有技术路线能撑住吗？做完之后谁付费、付多少？

当一家公司的立项会主要在做”这个项目要不要做”的表态时，它就注定要在交付阶段反复回答”这个需求到底是谁提的”。反过来，如果立项会讨论的是”我们打算用什么证据来验证这三个假设”，即使项目最终被否，这次立项也是成功的，因为它省下了后面几个月的沉没成本。

2. 立项质量的分水岭在评审之前，不在评审会上

我观察过一个很稳定的现象：立项评审会的质量，几乎完全由会前的材料准备决定，会议本身只能放大或缩小材料质量，无法创造质量。一场 45 分钟的评审会，如果参会人是第一次看到材料，那么无论主持人多强势，最后大概率会退化成”业务方讲愿景、技术方讲难度、财务方讲预算”的三方表态。

所以真正值得投入的不是把评审会开得多正式，而是把闸门前置：谁在什么时点必须补齐哪几个字段、谁必须在会前 48 小时给出书面意见。这些看起来琐碎的约束，才是立项质量的实际杠杆。

3. 立项的松紧程度，应该由”决策可逆性”决定，而不是由金额决定

这是我最想纠正的一条。大多数企业的立项分级标准是金额：50 万以下部门批，50 万到 200 万总监批，200 万以上上管委会。但金额只是资源投入的一个维度，真正决定该不该严审的是这个决策能不能低成本撤回。

一个花 30 万但会锁死底层数据模型、影响未来三年架构的项目，其决策不可逆性远高于一个花 200 万但可以随时下线的营销活动。前者需要五道闸门，后者可能一道初筛就够。按可逆性而不是按金额定立项强度，是我见过最能立竿见影的一条改进。

二、背景与真实场景：三种典型的立项失控

讲完结论，回到现实。下面三个场景几乎覆盖了我见过的八成立项问题，你可以对照看看自己公司有没有中招。

1. 场景 A：一句话立项，三个月后才发现是伪需求

一家做 SaaS 的公司在一次高管会上听到大客户抱怨”报表太慢”，当场拍板立项做一套新的报表引擎。项目启动后投入 4 名后端、2 名前端，第三个月做出来才发现：那位客户真正抱怨的是数据源接入不规范，根本不是计算性能。

这个项目的失败不在技术，而在立项环节没有做最基本的一步，把一句模糊的抱怨翻译成一个可验证的假设。”报表慢”是一个现象，”客户愿意为报表提速 50% 而多付 15% 年费”才是一个假设。

2. 场景 B：80 页立项书，核心假设一个都没验证

另一家制造企业，立项材料规范得令人感动：市场分析、竞品对比、技术方案、五年财务预测一应俱全，附件加起来 80 多页。但翻到最后一页我发现，整份文档里唯一可验证的数据是”预计第三年营收 1.2 亿”，而这个数字的来源写的是”参照行业平均水平估算”。

这是一个典型的”文档厚度替代验证深度”。80 页里 78 页在描述未来会是什么样，只有 2 页在说明我们凭什么相信它会是这样。评审会开了两个半小时，没有一个人问”这个 1.2 亿是怎么算出来的”。

3. 场景 C：立项归立项，执行归执行，系统两张皮

第三种更隐蔽，也更普遍。立项流程跑在 OA 或邮件里，项目执行跑在项目管理平台里，两边唯一的交集是一份 PDF 版立项书。等到季度复盘时，管理者想回答”当初承诺的三个里程碑现在完成了几个”，需要人工比对两个系统。

我做过一次实测：在数据分散的情况下，统计 30 个在研项目的”立项承诺兑现率”，两个人花了两天，最后还有 6 个项目的口径对不上。立项数据一旦与执行数据割裂，立项就会从管理动作退化为仪式动作。

三、拆解七个常见误区

下面七个误区，我按”出现频率 × 破坏力”排序。前三个我几乎在每一家企业都能看到。

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

立项会变成财务汇报会，讨论焦点从”这件事值不值得做”滑向”这笔钱该记在哪个成本中心”。财务视角天然关注确定性和可核算性，而早期项目的核心特征恰恰是不确定。让财务主导立项决策，结果通常是两类：要么把有潜力的探索性项目以”收益无法量化”为由砍掉，要么让业务方学会编数字。

正确的分工是：财务负责提供资源约束和成本口径，业务负责论证价值路径，技术负责给出可行性边界，决策者负责在信息不完整时拍板。四者角色不能互相替代。

2. 用文档厚度替代验证深度

前面场景 B 已经说过。补充一个判断标准：一份立项材料里，描述性内容与验证性内容的比例不应超过 3:1。也就是说，每三页在讲方案，至少要有一页在讲”我们已经用什么证据验证过什么”。如果做不到，说明这个项目的真实成熟度还没到可以立项的程度。

3. 一次性审批，没有阶段门

很多公司的立项是”一锤定音”：通过之后全额拨款，直到结项才复盘。这等于放弃了过程中所有的纠偏机会。我在一家企业看到过一个项目连续走了 18 个月才被叫停，累计投入 400 多人天，而项目组其实在第 5 个月就已经发现方向有问题，只是没有人有权限、也没有机制去终止它。

阶段门的价值不在于增加审批，而在于给项目一个体面终止的合法出口。没有出口，团队只能硬撑。

4. 标准模糊，最后靠职级拍板

“这个项目战略意义重大”，这句话在立项会上出现的频率，和立项标准的清晰度成反比。当评审标准无法被拆解成可比对的维度时，决策依据就只剩下话语权。这也是为什么很多团队抱怨”我们的立项会就是看谁嗓门大”。

解法不复杂：把标准写成可打分的维度，哪怕权重是拍脑袋定的，也比没有标准好。因为一旦有了分数，讨论就会从”我觉得”转向”你为什么给这个维度打 8 分”。

5. 只算直接成本，忽略机会成本和切换成本

立项材料里的成本几乎永远只包含人力、采购、外包三块直接成本。但真正吃掉利润的往往是另外两块：机会成本（这三个人做 A 项目，就做不了 B 项目）和切换成本（新系统上线后，原有流程改造、数据迁移、人员培训的隐性投入）。

我见过一个 ERP 替换项目，立项时预算 180 万，最终实际支出 340 万，超支部分几乎全部来自迁移和培训，而这两项在立项书里只占了一行字。

6. 立项后不复盘，标准永不迭代

立项决策本身也应该被评估。半年后回头看：当初预测的收益实现了多少？当初最大的风险真的发生了吗？当初给高分的那几个维度，事后看是否真的有预测力？

我建议每季度做一次立项决策回测：抽取 10 个已进入交付的项目，比对立项时的评分与实际表现，看哪些维度的预测力最强。通常做两三轮之后，评分卡的权重就会自然收敛到一个比拍脑袋合理得多的状态。

7. 立项流程和执行系统分离

这一条是工具层面的，但影响极大。立项在 A 系统，执行在 B 系统，度量靠人工。结果就是：立项时承诺的里程碑没人跟踪，执行中发现的重大偏差没人回溯到立项假设，组织永远学不会。

解决方向只有一个，让立项对象和执行对象在同一个数据模型里是同一个实体，立项书不是附件，而是项目的属性字段。

四、专业判断逻辑：三层漏斗 + 五道闸门 + 一张评分卡

前面讲的都是”不该怎么做”。这一节给出我实际在用的正向方法论：一个三层漏斗确定决策层级，五道闸门确定流程节点，一张评分卡确定判断依据。

1. 三层漏斗：战略层、组合层、项目层

很多企业立项失控的根源，是把三个不同层级的决策混在一张表上评。这三层的问题、判断标准和数据来源完全不同。

战略层回答的是”我们未来 3 年要在哪几个方向下注”。这一层的输入应该是市场结构变化、竞争格局、自身能力评估，判断周期以年为单位。组合层回答的是”在这些方向下，我们今年的资源该怎么分”。这一层关注的是项目之间的配比、风险对冲和资源峰谷，判断周期以季度为单位。

项目层才回答”这个具体项目要不要做”。它的判断依据是商业论证、可行性、资源可行性。如果一家公司只在项目层做立项评审，却从未在战略层和组合层明确过取舍，那么项目层的评审再严谨也是低效的，因为你在为错误的方向精挑细选。

2. 五道闸门：从想法到立项决议

我推荐的闸门设计是五道，每一道都有明确的输入、输出和决策人。关键在于每道闸门只解决一个问题，不要把商业论证和技术可行性塞进同一场会。

1. 闸门 1 · 想法登记：任何人可以提交，只需填四个字段，业务场景、预期收益、可逆性等级、提出人。目的是让想法进入统一池子，避免口头立项。
2. 闸门 2 · 初筛：由业务负责人 + 一名技术代表在 30 分钟内完成。判断标准只有两条：是否与当前战略方向相关，是否已有同类项目在做。约 50% 的想法死在这一步。
3. 闸门 3 · 商业论证：产出不超过 8 页的论证材料，必须包含至少三个可验证假设及其验证方式。这一道闸门是质量分水岭。
4. 闸门 4 · 立项决议：按可逆性分级确定评审层级，产出立项书 + 里程碑 + 首期资源承诺。注意是”首期”而非全额。
5. 闸门 5 · 阶段门复盘：通常设在项目 30% 和 70% 进度处，回答两个问题：假设还成立吗？继续投入的边际价值是否仍然为正？

3. 一张评分卡：六个维度，权重可调

评分卡的价值不在于分数本身，而在于把”我觉得”变成”我们这个维度上给几分，为什么”。下面是我常用的一张基础版，你可以按行业调整权重，但建议不要删维度。

实践中有个细节很关键：把”退出机制清晰度”单独设为一个维度并给足权重。绝大多数立项书里根本没有”什么情况下我们承认失败”这一段，而这恰恰是控制损失规模最有效的条款。

4. 可逆性分级：决定用几道闸门

在评分卡之前，先做一次可逆性分级。我的分法是三档：

（1）一级：可逆决策

错了可以低成本撤回，比如营销活动、试点功能、临时组织调整。这类决策只需要闸门 1、2，甚至可以走”事后备案”。对这类项目走完整立项流程，是典型的过度管控。

（2）二级：半可逆决策

撤回需要付出明显代价，但不会伤筋动骨，比如单个业务系统的建设、单条产线改造。走闸门 1 到 4，加一次阶段门复盘。

（3）三级：不可逆决策

一旦决策会影响架构、组织或长期合同，比如核心平台选型、底层数据模型设计、战略级合资。五道闸门全走，且必须由最高决策层参与闸门 4。

按这套分级执行后，我服务过的一家企业把全年走完整立项流程的项目从 63 个压缩到 22 个，而管理者的立项会议总时长反而下降了 35%。大部分立项负担，其实来自把可逆决策当成不可逆决策在管。

五、数据观察：从立项复盘里看到的三个规律

这一节的数据来自我为企业做立项流程诊断时收集的复盘记录。需要说明的是，它们不是行业统计，而是样本推演和经验归纳，请把它们当作判断参考而非精确事实。

1. 问题发现得越晚，修复成本呈指数增长

这个规律在软件和制造业都成立，但很多人低估了它的陡峭程度。立项阶段发现一个需求假设是错的，成本可能就是一次会议；上线后发现，成本是重构加客户信任损失。

我统计过一家企业近两年的 38 个重大变更，按问题首次被发现的阶段归类，折算成相对修复成本后大致是这样的分布：立项阶段 1 倍、设计阶段 6 倍、开发阶段 15 倍、测试阶段 40 倍、上线后 100 倍。这意味着立项阶段每多投入 1 个人天，理论上可以节省后续 6 到 100 个人天。

2. 立项通过率不是越高越好，也不是越低越好

我见过两种极端。一种是通过率 90% 以上，立项会基本等于走过场，这类企业的项目组合里通常堆着大量”半死不活”的项目。另一种是通过率压到 30% 以下，结果业务团队学会了一件事，把项目拆成多个小额项目分批申报，绕过评审。

根据我接触过的样本，比较健康的立项通过率区间大致在 50% 到 65% 之间。低于这个区间，说明筛选标准可能过于保守，组织会失去试错能力；高于这个区间，说明闸门没有起到过滤作用。当然这个区间对探索型业务要放宽，对基础设施类项目要收紧。

3. 案例：一家 800 人制造企业的立项流程改造

这家企业做工业自动化设备，研发与交付人员合计约 800 人，年立项数在 110 个左右。改造前的状态很有代表性：立项走 OA 表单，附件是一份 PPT 模板；评审会由研发副总主持，平均 20 分钟一个项目；立项通过率 82%；项目执行在项目管理平台里，但立项信息和执行信息完全不通。

我们做的第一件事不是改流程，而是把立项对象和执行对象合并成同一个实体。具体做法是在他们已有的项目管理平台 PingCode 里，把”立项”设计为需求/项目的一种生命周期状态，而不是一张独立的表单。这样立项书里的里程碑、负责人、预算、假设清单，天然就是项目本身的字段，不需要人工同步。

第二件事是把五道闸门配置成工作流状态流转，闸门 3 的论证材料设置为必填字段校验，关键假设少于三条、退出条件为空、成本测算未包含迁移和培训项的，系统直接不允许提交到闸门 4。这一条上线后效果立竿见影：立项材料返工率从 55% 降到 16%，因为不合格的材料根本进不了评审池。

第三件事是设置阶段门自动提醒。项目进度到 30% 和 70% 时，系统自动生成复盘任务并触发一次轻量评审，评审结论有三个选项：继续、调整、终止。其中”终止”被明确设计成一个正常选项，而不是失败标签。

改造后运行了三个季度，几个关键指标的变化如下。需要说明的是，这是单一企业的脱敏案例，效果受行业、组织成熟度影响，不宜直接外推。

最后一行数据是我最看重的。立项后 30 天内主动终止的比例从 4% 上升到 19%，意味着组织终于具备了”快速承认错误”的能力。这 19% 的项目平均只消耗了 6 人天，如果放到过去，它们中的大部分会走到 3 到 6 个月才被叫停。

六、工具落地：立项流程怎么在项目管理平台里跑起来

前面讲的模型如果没有系统承载，三个月后一定会退回原状。这一节讲落地细节。对于中大型企业，我通常建议直接复用已有的项目管理平台，而不是单独建立一个立项系统。

1. 四类核心数据对象

无论用什么工具，立项管理至少需要四类对象，且它们之间要有明确关联：

• 想法（Idea）：轻量对象，字段少，任何人有权限创建。它的生命周期终点是”转为项目”或”关闭”。
• 立项申请（Business Case）：承载论证材料和评分卡结果，与想法一对一关联。
• 项目（Project）：立项通过后生成，继承立项申请的全部关键字段，包括假设清单、退出条件、首期资源承诺。
• 阶段门记录（Gate Record）：每次复盘产出的结构化结论，包含结论类型、依据、决策人和后续动作。

关键设计原则是：立项申请和项目之间不是”附件关系”，而是”继承关系”。项目创建时自动带入假设清单和退出条件，这样复盘时才有对照物。

2. 流程配置实操

下面是一份可直接参考的立项流程配置示例。它描述的是状态机、必填校验和 SLA，用 YAML 表达，大多数支持工作流自定义的项目管理平台都能映射过去。

project_initiation:
version: 1.0

gates:

id: G1

name: 想法登记

state: idea_logged

required_fields:

提出人

业务场景

预期收益

可逆性等级 # 一级 / 二级 / 三级

sla_hours: 8

auto_actions:

通知业务负责人

id: G2

name: 初筛

state: screened

required_fields:

是否与当前战略方向相关

是否已有同类项目

sla_hours: 24

pass_rule: 两项均为"是"

reject_action: 关闭并归档，不占用立项编号

id: G3

name: 商业论证

state: case_prepared

required_fields:

关键假设 # 最少 3 条，每条需含验证方式与时间点

价值路径 # 需包含前三个使用或付费场景

成本测算 # 必须包含迁移成本与培训成本

风险与应对

退出条件 # 为空则不允许流转

validation:

rule: len(关键假设) >= 3

message: 关键假设少于 3 条，请补充后再提交

rule: 退出条件 is not empty

message: 未定义退出条件的立项申请不可提交评审

id: G4

name: 立项决议

state: approved_or_rejected

reviewer_by_reversibility:

一级: 业务负责人

二级: 业务负责人 + 技术负责人

三级: 事业部负责人 + 技术委员会

output:

立项书

首期资源承诺 # 仅承诺首个阶段，不作全额承诺

里程碑清单

id: G5

name: 阶段门复盘

state: gate_reviewed

trigger:

progress == 30%

progress == 70%

options:

继续

调整

终止

note: 终止为正常选项，不计入团队绩效扣分项

这份配置里有三个细节值得强调。第一，可逆性等级在闸门 1 就要填，因为它决定了后续走几个闸门、由谁评审。第二，退出条件是硬性校验，为空直接不允许提交，这比在评审会上口头提醒有效得多。第三，阶段门复盘的”终止”选项必须在制度上被明确为正常结果，否则没人敢点。

3. 私有化部署与历史数据迁移：中大型企业的两个硬约束

我接触的 500 人以上企业，在选型时几乎都会提出两个硬约束：数据必须留在自己的服务器上，历史项目数据必须完整迁移。前者是合规和保密要求，后者是连续性要求。

以 PingCode 为例，它支持私有化部署，这一点在制造、金融、军工类客户中是刚性门槛。同时它提供从主流海外项目管理工具平滑迁移的路径，包括字段映射、附件迁移、历史工作项关系重建。我在一家企业实测过迁移过程：约 1.2 万条工作项、3400 个附件、6 年历史数据，实际迁移加校验用了 5 个工作日，其中大部分时间花在字段映射规则确认上，而不是工具本身。

这里有个经常被忽略的坑：历史数据的价值不在于”能查到”，而在于”能统计分析”。如果迁移后历史项目的时间字段、状态字段丢失了语义，那么迁移动作就只完成了一半。所以迁移验收清单里一定要加上”能否按年份统计立项通过率”这类统计验证项，而不只是”随机抽取 20 条看内容对不对”。

4. 立项管理必须盯的六个指标

立项上了系统之后，最怕的是没人看数据。我建议在平台里固定挂一块立项管理看板，只放六个指标，每个季度看一次趋势。

这六个指标里，“早期终止率”是最容易被误读的。它不是越低越好，而是过低说明组织没有止损能力，过高说明立项筛选太松。我建议把它明确定义为正向指标，并且和团队考核解耦。

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

方法论讲完，接下来是”你该怎么办”。不同规模的组织，立项管理的重点完全不同。用小公司的做法管大公司会失控，用大公司的做法管小公司会窒息。

1. 50 人以下团队：把立项做成”一页纸 + 一次对话”

这个阶段不要建立正式立项制度，它只会拖慢你的试错速度。你需要的是一页纸：要解决什么问题、凭什么是我们、三个月后怎么判断成败。然后花 30 分钟和核心成员过一遍。

唯一必须坚持的是写下退出条件。小团队死得最快的方式不是选错方向，而是一个错误方向舍不得停。把”如果三个月后付费用户少于 20 个就停”写在纸上，比任何流程都管用。

2. 100-500 人：建立闸门 1、2、3，重点解决资源冲突

这个规模的企业第一次遇到真正的资源冲突：项目数超过产能，但还没有组合管理的意识。核心动作是把闸门 1、2、3 建起来，尤其是闸门 2，用半天成本挡掉一半无效想法。

同时开始做资源折算：立项时的人力承诺不要按人头算，要按”实际可用产能的 70%”算。这一个动作通常能让按期交付率提升 10 到 15 个百分点，因为大部分排期乐观都来自高估了人的可用时间。

3. 500-2000 人：五道闸门全上，重点是把立项和执行放进同一个系统

到了这个规模，靠人协调已经不可能了。五道闸门和评分卡都应该上线，同时必须解决立项与执行的数据割裂问题。这也是我建议这类企业优先考虑支持私有化部署、支持历史数据迁移的项目管理平台的原因，数据连续性比功能多少重要得多。

这个阶段的另一个重点是按可逆性而不是金额分级。500 人以上的企业，立项分级标准一旦按金额切，很快就会出现”拆小项目绕评审”的现象，而且几乎无法监管。

4. 2000 人以上或多事业部：从项目立项升级到组合立项

这个规模下，单个项目的立项质量已经不是主要矛盾了，真正的矛盾是组合层面的资源配置。你需要回答的是：A 事业部和 B 事业部同时申报三个重点项目，产能只够两个，按什么规则取舍。

我的建议是引入组合层的季度评审：先把所有立项申请按战略对齐度和可逆性分级做一次分池，然后在池内做资源分配，最后才进入项目层的闸门 4。顺序一旦颠倒，项目层的评审就会被事业部之间的博弈绑架。

八、不同情况下的取舍

所有管理动作都是取舍，立项管理尤其如此。下面四组取舍，我在咨询中几乎每次都会被问到。

1. 速度 vs 严谨：先看项目是否可逆，再谈速度

这两个不是天然对立的。正确做法是分层：可逆决策走快通道，不可逆决策走慢通道。真正糟糕的状态是”所有项目都走快通道”或者”所有项目都走慢通道”。

一个可操作的判断：如果这个项目失败后，你只需要发一封邮件通知相关方，那它就该走快通道；如果需要发公告、赔违约金、重做数据迁移，那它必须走完整流程。

2. 集中管控 vs 业务自治：边界设在”资源”而不是”想法”

我的建议是：想法入口放开，资源出口收紧。任何业务单元都可以自由提交想法，但一旦涉及跨部门资源占用，就必须走统一评审。这样既保留了业务侧的创新活力，又避免了资源被局部最优消耗掉。

很多企业的做法恰好相反：想法要层层审批才能提交，但一旦立项就全额拨款、无人跟踪。这是把管控点放错了位置。

3. 自建流程 vs 采购平台：看你的立项对象是否需要与执行数据打通

如果立项只是为了走合规流程、留个记录，那么用 OA 或自建表单完全够用，成本也低。但如果立项的目的是持续管理项目组合、做决策回测、跟踪承诺兑现率，那么自建会很快遇到瓶颈，你需要的不只是表单，而是工作流引擎、权限模型、关联对象和统计能力。

我见过一家企业自建立项系统，前两年很好用，第三年开始频繁出问题：数据量上来后查询变慢，跨系统关联靠定时任务拼，历史数据结构调整一次就要停机。最后迁移到成熟平台，迁移成本远超当初省下的开发成本。

4. 严格立项 vs 快速试错：用”阶段门”而不是”立项门槛”来平衡

这组取舍最容易被误解题意。严格立项和快速试错并不矛盾，关键在于把严格度放在哪个位置。

我的做法是：降低立项门槛，提高阶段门标准。让项目更容易启动，但每一次阶段门复盘都必须有明确结论，不允许”再观察观察”。这样组织既能快速试错，又不会让错误项目无限期消耗资源。数据上看，这通常表现为立项通过率上升而早期终止率同步上升，这两个数字同时上升，往往是立项管理变健康的信号。

九、下一步：30 天立项管理改进路线图

如果你认同上面的判断，但不知道从哪里下手，可以按这个顺序推进。我把它设计成 30 天，是因为超过一个月没人看到变化，改进就会被日常业务淹没。

1. 第 1 周：盘家底，只做一件事

把过去 12 个月所有立项项目拉出来，做一张表，字段包括：项目名称、立项时间、当前状态、实际投入人天、是否产生可衡量价值、如果重来还会不会立。这张表不用很精确，目的是让管理层第一次直观看到立项的真实有效率。

根据我的经验，这张表做出来的当天，通常就会有人提出要改流程。先制造认知冲击，再推动流程变更，成功率比直接宣布新制度高得多。

2. 第 2 周：定可逆性标准，砍掉一半闸门

不要一上来就加流程，先做减法。定义清楚什么是一级、二级、三级可逆决策，然后把一级决策从立项流程里拿出来，改成事后备案。这一步通常能立刻减少 40% 到 60% 的立项工作量，为后续改进腾出空间。

同时确定闸门 2 的初筛标准，只需要两条：战略相关性、是否重复。标准越少越容易执行。

3. 第 3 周：上线评分卡和退出条件字段

把六个维度的评分卡做成一页纸，先在两三个项目上试跑，看看打分是否会产生分歧。有分歧是好事，说明这个维度有区分度。退出条件则直接作为立项书必填项，没有就退回。

如果你已经在用项目管理平台，这一步应该配置成字段校验而不是人工检查。以 PingCode 这类支持自定义工作流和字段校验的平台为例，把”关键假设少于 3 条不允许提交”配置成流转规则，执行成本几乎为零。

4. 第 4 周：设置阶段门，跑第一个完整闭环

给现有在研项目设置 30% 和 70% 两个触发点的复盘任务，然后完整跑一次。第一轮不要追求结论正确，只追求流程走通，并且让”终止”这个选项真实地被使用一次。

只要有一个项目在阶段门被正常终止，而且团队没有因此受到负面评价，这个机制就算立住了。

5. 90 天后：做第一次立项决策回测

三个月后，抽取 10 个已进入交付的项目，比对它们的立项评分与实际表现，看哪个维度的预测力最强、哪个维度几乎没区分度。然后调整权重，把没用的维度删掉或者合并。

这个过程重复两到三轮，你的评分卡就会从”通用模板”变成”这家公司专属的立项判断模型”。这才是立项管理真正的护城河，不是流程本身，而是组织积累下来的判断力。

结语：立项管理真正管理的不是项目，是组织的判断力

回到开头那家工业企业。他们后来做的最重要的一件事，不是上线了什么系统，而是在每次立项复盘后，把”当初我们错在哪一步”写进一份共享文档，半年后这份文档变成了他们自己的立项检查清单。

我始终认为，立项管理的最终产物不是一份决议，而是一个组织越来越准的直觉。流程、闸门、评分卡、工具，都只是让这种直觉可以被记录、被讨论、被迭代的载体。缺少这个载体，优秀判断散落在几个资深管理者脑子里，人一走就归零；有了载体，判断力才会变成组织资产。

如果你今天只做一件事，我的建议是：把过去一年所有立项项目拉成一张表，标出哪些真正产生了价值。这张表会让你知道，下一步该改的是流程、标准，还是人。