项目类型最佳实践：企业管理者项目立项制度设计，常见问题

去年冬天，我参与了一家年营收约 12 亿元的装备制造企业的年度项目复盘。他们的项目管理平台里躺着 187 个已立项项目，其中 63 个在立项后 90 天内没有产生任何交付记录，也没有被正式关闭，它们只是安静地躺在列表里，占用着预算编号和人力池。而管理层手里那份 14 页的《项目立项管理制度》签批流转完整，从发起、评审、会签到总经理审批，一应俱全。

问题不在流程是否完整，而在流程前面少了一步：没有人定义过”这个项目属于哪一类”。所有项目走同一条流水线，一个 3 人两周的产线小改造，和一个跨 5 个事业部、预算 800 万的新产品平台，用的是同一张申请表、同一套评审标准、同一个决策层级。结果就是：小项目被拖死，大项目被放过。

这篇文章不讲”立项制度应该包含哪些章节”，那种内容到处都是。我想拆的是更底层的东西，项目类型分类如何决定立项制度的成败，以及我在多个中大型企业落地过程中反复见过的八类具体错误、四种判断维度、五类项目定义，和一套可以直接抄改的分级决策矩阵。

一、先给结论：立项制度是分类决策系统，不是审批流水线

如果只能记住一句话，那就是：立项制度的本质不是”卡住什么”，而是”用不同的成本去对待不同类型的项目”。审批只是它最表层的动作。

1. 结论一：项目类型先于流程，流程必须由类型反推

我见过太多企业先画流程图，再往里塞项目。正确的顺序恰好相反：先把企业里真实存在的项目分成几类，再针对每一类设计不同的材料要求、决策层级、评审周期和终止机制。

一个反直觉的判断是：项目类型应该由”不确定性”和”不可逆性”来定义，而不是由”部门”或”预算科目”来定义。按部门分类（研发项目、市场项目、IT 项目）看起来很整齐，但完全无法指导决策，因为研发项目里既有探索性的前沿预研，也有确定性极高的定制交付，两者的管理成本差 5 倍以上。

2. 结论二：门槛要用”不可逆性”设定，不能只用金额

大多数企业的立项门槛只有一个数字：预算超过 50 万上评审会，超过 200 万上报总经理。这个设计有个致命缺陷，金额衡量的是投入，不是损失。

一个预算 300 万、分 12 个月投入、每月都有可撤销节点的项目，真实的”下车成本”可能只有 30 万；而一个预算 80 万、需要一次性采购专用设备并培训 200 名一线员工的项目，一旦启动几乎无法回退。后者对组织的实际风险更高，却因为金额没到线而走了轻流程。

我在实践中的做法是加一个”不可逆性评分”（1-5 分），金额、不可逆性、跨部门耦合度三者中任意一项触发阈值，就升级决策层级。这三项构成的组合门槛，比单一金额门槛有效得多。

3. 结论三：立项的产出是”成功标准 + 终止条件”，不是一个通过章

立项评审最容易走过场的环节是结论。评审完只留下”同意立项”四个字，项目组拿走一个预算编号就散了。真正有价值的立项产出应该包含三样东西：

• 可证伪的成功标准：不是”提升客户满意度”，而是”上线后 90 天内，工单平均响应时长从 4.2 小时降到 2 小时以内”。
• 明确的终止条件：在什么时间点、什么指标下，这个项目会被主动关闭。
• 下一个决策点：立项不是一次决策，而是第一次决策，后面必须排好第二次、第三次。

4. 结论四：制度能不能进化，取决于立项数据是否回流

我评估一家企业的立项制度是否健康，只看一个动作：他们有没有把”立项时的承诺”和”交付时的实际”做定期比对。如果两者从不放在一起看，这套制度无论写得多漂亮，都只是一张纸。因为制度本身失去了唯一的反馈信号。

二、背景与真实场景：立项制度为什么被重新捡起来

立项制度不是新话题，但过去三年它被大量企业重新翻出来修订，背后有几个非常具体的原因，我在项目现场都能直接观察到。

1. 场景一：预算收紧后，”立项数量”第一次成为问题

2021 年之前，很多企业的立项逻辑是”能立就立”，反正人力池是共享的，多一个项目只是多一行记录。当资源开始收紧，人力池变成了硬约束，管理层突然发现：他们不知道哪个项目该停。

因为没有分类，也就没有优先级；没有优先级，砍项目只能靠部门博弈。我参与过一次这样的会议，三个事业部负责人花了 90 分钟争论两个项目的去留，最后用”各砍一半”收场，这是典型的分类缺失导致的决策退化。

2. 场景二：交付型项目与产品型项目混用一套指标

我服务过一家做工业软件的企业，他们的项目立项表里有一个必填项叫”预期毛利率”。这条规则对定制交付项目是合理的，但对内部平台研发项目完全无效，一个内部研发平台根本不产生毛利率。

结果就是项目组只能编。我见过最极端的一份立项材料，把一个内部数据平台项目的毛利率填成 18%，理由是”降低外部采购成本折算”。当制度要求填写无法计算的指标时，组织收到的不是数据，是表演。

3. 场景三：国产化替代带来的工具切换窗口期

另一个真实背景是工具层的迁移。过去几年，不少中大型企业在做研发管理工具的国产化替换，这个窗口期恰好是重构立项制度的好时机，因为制度最终要落到工具里，而工具切换时是阻力最小的时刻。

这里我要提一个具体的观察。在这类迁移项目中，我参与过几次基于 PingCode 的落地。PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持从 Jira 平滑迁移，是国产替代里比较常被考虑的选项。它的价值不在于替代本身，而在于它允许你把”项目类型”做成结构化的对象，而不是流程表单上的一个下拉框，这一点对分类驱动的立项制度极其关键，后面第五章我会展开。

4. 立项制度的四个输入条件

在动手设计之前，我会先确认四个输入条件是否具备，缺一个就会导致制度悬空：

1. 战略解码颗粒度：年度战略能不能拆到”可立项的举措”级别。如果战略只有口号，立项就只能凭感觉。
2. 预算节奏：预算是年度一次锁定，还是季度滚动。这直接决定立项评审的频率和决策点的设置。
3. 组织形态：是职能制、事业部制还是矩阵制。矩阵制下”谁批谁负责”的问题会显著放大。
4. 工具底座：立项数据能不能被结构化存储、查询和回溯。这一条决定了制度的天花板。

三、拆解常见误区：我在现场反复见到的八类错误

下面这八条，不是从教科书上抄的，是我在项目复盘会、制度评审会、流程走查中反复遇到的真实问题。每一条后面我都附了判断依据和修正方向。

1. 误区一：一套流程管所有项目

这是最普遍、也最致命的一条。表现形式是：所有项目都要填同一张 5 页的立项申请表，都要开同一场 90 分钟的评审会，都要走同样的三级审批。

它的代价是可以量化的。我做过一次内部测算：某企业把一个 8 万元的产线小改造，和一个 400 万元的系统平台项目放在同一条流程上，前者的立项管理成本（人工工时折合）约为 1.6 万元，占项目预算的 20%；后者约为 2.1 万元，占 0.5%。同一套流程对不同项目的”管理税”差了 40 倍。这就是小项目绕流程、走特批的根本原因。

（1）判断标准

如果你的立项流程里存在”金额低于 X 万元可简化流程”这样的条款，说明你已经意识到问题，但用错了方法，简化不应该只看金额，应该看类型。

2. 误区二：把立项等同于审批

很多企业的立项制度，读完之后你只知道”要提交什么、谁签字”，完全不知道”这个项目要解决什么问题、成功长什么样”。这类制度本质上是财务管控文件，不是项目管理文件。

我判断一份立项制度是否合格，方法是看它的目录：如果 80% 的篇幅在讲提交材料清单和审批权限，只有 20% 讲项目定义和成功标准，那它管的是钱，不是项目。

3. 误区三：立项材料越厚，项目质量越高

有一次评审会，我拿到一份 47 页的立项报告，其中 31 页是行业分析和市场规模测算。评审组花了 20 分钟讨论市场规模数据是否准确，却没人问”这个项目第一阶段的验证目标是什么”。

核心问题是：材料是给谁看的？如果材料是给决策者看的，那它应该聚焦在”决策所必需的最少信息”上；如果材料是给项目组自己看的，那它应该在立项后继续演进。把这两者混在一份文档里，结果就是又厚又没用。

我推荐的替代方案是”一页纸 + 按需附录”：主文档一页，包含问题、目标、成功标准、资源、终止条件、关键假设六项；支撑性材料作为附录，评审时按需调取。评审会的时间应该花在假设上，不是花在材料完整性上。

4. 误区四：只卡金额，不卡不可逆性

前面已经提过，这里补一个具体案例。我经历过一个项目，预算 65 万元，没达到 100 万元的评审门槛，走了部门内审批。项目内容是给一个已运营 6 年的核心业务系统做底层架构替换，替换过程中新旧系统需要并行 4 个月，涉及 300 多名一线操作人员的双系统培训。

项目在第 5 个月发现新架构无法承载峰值并发，此时旧系统的技术栈已被部分下线，回滚成本超过 400 万元。它在立项时被判定为”小额项目”，在出事时变成了重大事故。不可逆性从来不体现在预算数字里。

（1）判断标准

我在实践中用三个问题快速评估不可逆性：这个决定能不能在 30 天内撤销？撤销的成本是否超过已投入的 50%？撤销是否会影响到项目组以外的部门或客户？三个问题里两个答案为”是”，不可逆性至少 4 分。

5. 误区五：立项通过即终局，没有终止机制

这是”僵尸项目”的根源。项目一旦立项，就获得了永久身份，除非有人主动提出关闭，而没有人愿意主动提出，因为那等于承认自己当初判断错了。

有效的做法是把”终止”设计成流程的默认选项，而不是例外。比如：所有项目在第 90 天必须做一次”继续/调整/终止”的三选一决策，不做选择则自动进入”待终止”状态。这个机制的关键在于，终止不再是某个人的失败，而是制度的常规动作。

6. 误区六：没有项目类型定义，全靠”感觉”分类

很多企业的制度里其实提到了项目分类，比如”重大项目、一般项目、小型项目”。但这种分类是按规模分，不是按性质分，落到实际操作中完全无法判断。一个 50 万元的合规改造项目和一个 50 万元的新技术预研项目，规模相同，管理方式应该完全相反。

7. 误区七：立项数据不回流，制度无法自我修正

我在第一章提过判断标准，这里给出具体做法。立项数据回流至少要做三组比对：

• 承诺 vs 实际：立项时承诺的周期、成本、收益，与实际发生的偏差分布。
• 假设 vs 验证：立项时列出的关键假设，有多少被验证、多少被证伪。
• 类型 vs 结果：不同类型项目的成功率、延期率、终止率对比。

第三组最有价值。我服务过的一家企业做完这个比对后发现：他们的”战略探索型”项目成功率只有 19%，但”效率改善型”项目的成功率是 78%，而后者恰恰是流程最简化的一类。这个发现直接推翻了他们”重要项目要严管”的直觉，严管并没有提升成功率，反而可能拉长了周期。

8. 误区八：决策者与责任人不匹配

最常见的形式是：评审会上坐的是职能代表，签完字就走；项目的实际后果由另一个部门承担。这种结构下，评审人的理性选择是”尽量通过”，因为否决需要理由，通过不需要。

修正方式是引入发起人（Sponsor）实名制：每个项目必须有且只有一位发起人，这位发起人必须是能调动项目所需资源的人，且其考核指标中包含该项目的交付结果。这一条看似简单，但它能淘汰掉相当一部分”谁都不想负责但谁都不想否决”的项目。

四、专业判断逻辑：四维分类、五类定义、三段门禁

讲完问题，该讲方法了。下面这套框架我在不同行业的企业里迭代过十几轮，核心逻辑是：用四个维度给项目打分，落到五类标准定义上，再匹配三段式门禁。

1. 四个分类维度

我筛选维度的标准是”必须能直接改变管理动作”，不能改变动作的维度一律不要。

（1）不确定性（1-5 分）

核心问题是：”我们是否知道怎么做？”如果答案、路径、技术方案三者中任意一项未知，不确定性至少 3 分。不确定性高，意味着需要更短的计划周期、更频繁的检查点，而不是更严格的初始审批。

（2）不可逆性（1-5 分）

核心问题是：”做错了能不能退回来？”包括技术不可逆（数据迁移、架构替换）、组织不可逆（人员调整、供应商锁定）、市场不可逆（客户承诺、品牌动作）。

（3）价值实现路径（1-5 分）

核心问题是：”价值怎么被测量？”直接收入类路径清晰，效率改善类需要折算，战略卡位类几乎无法短期测量。路径越模糊，立项材料的核心就应该越从”收益预测”转向”假设清单”。

（4）资源耦合度（1-5 分）

核心问题是：”需要几个部门同时让路？”涉及 1 个部门记 1 分，涉及 3 个及以上部门或跨事业部记 4-5 分。耦合度高的项目，真正的风险不在技术，在协调成本。

2. 五类项目标准定义

我建议企业直接采用这五类定义作为起点，再按行业特点微调。关键是每一类都要有可操作的识别规则，而不是模糊描述。

3. 三段式门禁设计

立项不是一次决策，而是三次。我在实践中固定使用这三个门禁点：

1. 门禁 0（立项）：确认问题真实、假设明确、资源可获得。产出是项目章程和终止条件。
2. 门禁 1（第 30-45 天）：确认关键假设有初步验证、资源实际到位。这个门禁的淘汰率应该最高，我观察到的健康区间是 15%-25%。
3. 门禁 2（第 90 天或阶段交付点）：确认价值路径是否仍然成立，做出继续/调整/终止决策。

这三个门禁的强制性和项目类型相关：效率改善型通常只需要门禁 0，战略探索型三个门禁都必须走，合规强制型的门禁 1 和门禁 2 可以合并。

4. 立项材料的最小集

我把立项材料压缩到六个必填项，每一项都对应一个决策用途：

• 问题陈述：现在发生了什么，为什么需要现在做。
• 成功标准：可测量的结果，含指标、口径、时间窗。
• 关键假设：3-5 条，每条都要写明”如果这条不成立会怎样”。
• 资源承诺：具体到人和人天，不是”相关部门配合”。
• 终止条件：什么情况下主动关闭。
• 不可逆性自评：按四维度打分，作为决策层级的输入。

这六项能写在一页 A4 上。写不下的部分，说明你对项目的理解还不够清晰，这是我在评审时最常用的筛选标准。

5. 立项后的 30 天校准与终止机制

最后一个关键设计是”校准点”。立项通过不等于资源到位，我在多个企业都观察到：立项后 30 天内未实际启动的项目占立项总数的 20%-30%。这些项目如果不做处理，就会变成僵尸项目。

校准点的动作很简单：第 30 天由系统自动发起一次确认，由发起人回答三个问题，资源是否到位？首个子任务是否已开始？关键假设是否有新信息？三个问题中两个为否，项目自动进入”待终止”队列，由门禁 1 会议统一处理。

五、具体案例与数据观察：把分类落到 PingCode 这类平台上

制度设计完成后，下一个问题是承载。如果立项分类只停留在 Excel 和邮件里，它会在三个月内退化成一张表单。我下面用 PingCode 的落地方式作为一个具体参考，讲清楚”分类如何在工具里被结构化”。

1. 为什么”项目类型”必须在工具里是一等公民

这里有个关键判断：如果项目类型只是表单里的一个下拉选项，它就无法驱动流程。举例来说，一个项目被标记为”战略探索型”，但如果工具不支持按类型自动匹配审批流、自动加载不同的字段集、自动设置不同的检查点节奏，那这个标记就毫无作用，最终还是靠人去提醒、去推动。

PingCode 在这方面的结构性优势在于，它把项目本身作为可配置的工作项类型来管理，不同类型的项目可以挂载不同的字段、工作流、权限和自动化规则。这意味着”分类”不再是纸面约定，而是可执行的系统逻辑。

2. 一个可落地的配置思路

下面是我在几个中大型企业用过的配置思路，脱敏后整理成结构化形式。核心是把四维度评分和类型判定做成规则，而不是靠人工判断。

# 立项分类与门禁规则（配置思路示意）
project_types:

code: STRATEGIC

name: 战略探索型

trigger_rules:

uncertainty_score >= 4

OR involves_new_tech == true

OR involves_new_market == true

decision_level: 战略委员会

required_fields: [问题陈述, 成功标准, 关键假设, 资源承诺, 终止条件]

gate_policy: [GATE_0, GATE_1, GATE_2]

gate_1_deadline_days: 45

auto_terminate_days: 90

code: GROWTH

name: 业务增长型

trigger_rules:

revenue_linked == true

AND value_path_clarity >= 4

decision_level: 业务负责人 + 财务

required_fields: [问题陈述, 成功标准, 收益测算, 资源承诺]

gate_policy: [GATE_0, GATE_2]

gate_2_deadline_days: 90

code: EFFICIENCY

name: 效率改善型

trigger_rules:

budget < 300000

AND reversibility_score <= 2

AND revenue_linked == false

decision_level: 部门负责人

required_fields: [问题陈述, 预期改善指标]

gate_policy: [GATE_0]

auto_close_days: 180

code: COMPLIANCE

name: 合规强制型

trigger_rules:

external_deadline_exists == true

decision_level: 合规负责人 + 资源方

required_fields: [合规要求清单, 排期表, 依赖清单]

gate_policy: [GATE_0, GATE_2]

code: HOTFIX

name: 紧急修复型

trigger_rules:

severity in [P0, P1]

decision_level: 值班决策人

required_fields: [影响范围]

gate_policy: [POST_FACT_RECORD]

post_record_within_hours: 72

这段配置思路里有两个设计要点值得单独说。第一，触发规则是”或”和”与”的混合，不是单一条件，比如战略探索型是”不确定性高或涉及新技术或涉及新市场”三者任一，而效率改善型是三个条件同时满足。第二，不同类型的门禁数量不同，紧急修复型甚至没有前置门禁，只有 72 小时内的事后补录。

用 PingCode 落地这套逻辑的价值在于，这些规则会变成系统行为：提交立项时，系统根据填写内容自动识别类型、自动加载对应字段集、自动路由到正确审批人、自动在对应时间点生成门禁任务。我在落地现场观察到的最直接变化是：立项表单的平均填写时长从 40 分钟降到了 12 分钟，而立项信息完整度反而提升了。

3. 数据观察：三个落地样本的前后对比

下面这组数据来自我跟进的三个企业样本（规模分别为 320 人、650 人、1100 人，均为研发或研发密集型组织）。这些数字是落地记录的整理与区间化处理，属于样本推演，不是行业统计，请按参考值理解，不要当作基准。

有几个数字需要特别解读。门禁 1 淘汰率 18.4% 是我最关注的指标，它说明制度真的开始筛选了，而不是走过场。而立项承诺偏差从 62% 降到 31%，说明立项材料的质量提升不是靠”写得更认真”，而是靠分类之后材料要求的精准化。

另外，PMO 工时下降 64.6% 这个数字容易被误读。它不是”PMO 工作量减少了”，而是 PMO 从”催收材料、核对表单”这类事务性工作中解放出来，转向了门禁评审和数据分析。这是分类结构化最容易被低估的价值。

4. 落地中踩过的三个坑

我不想只讲成功面。下面三个坑是我实际踩过的，写出来供参考。

（1）坑一：一开始就把规则写得太细

第一版我设计了 11 种项目类型，结果没人记得住，实际使用时大家还是随便选。后来砍到 5 类，识别规则压缩到每条不超过 3 个条件，使用率才上来。分类的可用性比完整性重要得多。

（2）坑二：忽略历史数据迁移

在工具切换场景下（比如从旧平台迁移到 PingCode 这类支持 Jira 平滑迁移的平台），历史项目的类型重新标注是个大工程。我吃过一次亏：迁移时没做历史数据的类型回填，导致上线后前 6 个月的报表是空的，管理层看不到趋势，制度推行失去说服力。

后来我的做法是：迁移时至少回填过去 12 个月的项目类型和四维度评分，哪怕评分是粗粒度估算。因为在立项制度推行的前半年，趋势数据的说服力远大于规则本身的严谨性。

（3）坑三：把门禁做成”审批”

门禁 1 一开始被设计成了第二道审批，需要签字才能继续。结果是项目组为了拿到签字，会花大量时间准备汇报材料，门禁本身变成了负担。

后来改成”三选一决策会”：继续、调整、终止，当场给出结论，不需要额外签字流程。会议时长控制在 15 分钟/项目，材料就是立项时的那一页纸加上实际进展。这个改动的效果很明显，门禁 1 的参与率从 61% 上升到 96%。

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

制度没有通用解，我按组织规模和业务形态给几组具体建议。你对照自己的情况选一组作为起点，不要试图一次做全。

1. 100-300 人组织：先解决”没有分类”问题

这个规模的组织通常不需要复杂的决策层级，但极度需要项目类型的区分。建议动作：

1. 先把五类项目定义写出来，识别规则每条不超过 3 个条件。
2. 立项材料统一压缩到半页到一页，取消所有”必填但没人看”的字段。
3. 只设门禁 0 和门禁 2，门禁 1 用邮件或系统提示的轻量方式代替。
4. 选择支持自定义工作项类型的工具，把分类落到系统里。

这个阶段的常见错误是引入大企业的流程。我见过 180 人的公司搞三级评审委员会，结果半年后没人再提委员会的事。

2. 300-1000 人组织：重点解决”决策层级错配”

这个规模是立项制度收益最明显的区间。建议动作：

• 引入四维度评分，把”不可逆性”作为独立于金额的升级条件。
• 建立三段式门禁，门禁 1 的淘汰率目标设在 15%-25%。
• 设定 Sponsor 实名制，并把项目结果写入 Sponsor 的考核。
• 每季度做一次”类型 vs 成功率”的数据回流分析。

这个阶段最大的价值点是把决策权从”职级”转移到”类型”。一个 30 万元的效率改善项目，部门负责人就能拍板；一个 30 万元但不可逆性 5 分的架构替换，必须上最高层级。这个转变往往需要一次管理层共识会来推动。

3. 1000 人以上或多事业部组织：重点解决”一致性”

这个规模下，最大的挑战不是设计制度，而是让不同事业部执行同一套制度。建议动作：

• 统一项目类型定义和字段，但允许各事业部在门禁节奏上有差异。
• 建立集团级立项数据看板，按事业部、类型、结果三个维度切片。
• 对战略探索型项目单独设立预算池，避免与业务项目争夺常规预算。
• 部署支持私有化的管理平台，确保立项数据在集团内可统一分析。

在工具选型上，我建议优先考虑支持私有化部署、能承载大规模组织结构的平台。这也是我在一些中大型企业项目里会推荐 PingCode 的原因之一，它面向中大型企业及 100 人以上组织，支持私有化部署，也能承接从既有平台（包括 Jira）的平滑迁移，在多事业部统一数据口径这件事上比较省事。

4. 强监管行业：把”合规强制型”独立出来

金融、医疗、能源等行业的合规项目占比往往超过 25%。这类项目的特点是：目标不可协商、时间不可延期、价值无需论证。把它们的立项流程独立出来，能显著减轻常规评审会的压力。

我的建议是：合规强制型项目走”清单式立项”，只填要求来源、截止时间、依赖资源三项，决策重点放在资源排期而非价值判断。

5. 交付型 vs 产品型组织：两套材料模板

如果是交付型业务为主（定制开发、系统集成），立项材料中应加重”合同条款、验收标准、变更边界”三项。如果是产品型业务为主，应加重”目标用户、假设清单、验证方式”三项。

我见过一家混合型业务的公司用同一份模板，结果交付团队抱怨”要填假设清单很奇怪”，产品团队抱怨”没有合同哪来验收标准”。后来拆成两个版本，投诉率立刻下降。

七、不同情况下的取舍

制度设计的本质是取舍，不是叠加。下面四组取舍是我在现场最常需要帮企业做判断的，每组我都给出适用边界。

1. 取舍一：控制力 vs 决策速度

控制力强的制度表现为：决策层级多、材料要求全、评审频率高。它的代价是决策周期长，且会催生”提前准备充分材料以通过评审”的行为模式，项目组把精力花在说服评审者上，而不是验证假设上。

我的判断逻辑是：不确定性越高的项目，越应该牺牲控制力换速度。因为高不确定性项目的最优策略是快速试错，而不是深度论证。反之，不可逆性高的项目应该牺牲速度换控制力，因为它没有试错空间。

很多企业恰好做反了：战略探索项目要走五道审批，架构替换项目反而因为”技术性强”交给技术委员会快速决定。

2. 取舍二：标准化 vs 灵活性

标准化带来可比数据，灵活性带来适配性。这两者不可能同时最大化。

我的做法是分层：顶层字段强制标准化（项目类型、四维度评分、成功标准、终止条件），业务细节允许灵活。这样既保证了跨部门数据可比，又不会让业务团队觉得制度不接地气。

具体判断标准：如果某个字段需要跨部门横向比较，就标准化；如果只在部门内使用，就放开。

3. 取舍三：自建 vs 采购工具

立项分类制度的承载方式有三种：Excel + 邮件、轻量工具、专业研发管理平台。三者的适用边界很清晰。

我要强调一个反直觉的判断：如果年立项数量超过 100 个，Excel 方案一定会崩。不是因为 Excel 不好用，而是因为超过这个量级后，”立项承诺 vs 实际结果”的比对工作会变成人力不可承受的负担，而这项比对恰恰是制度进化的唯一信号。

4. 取舍四：集中决策 vs 分散决策

集中决策的优势是资源调配效率高，劣势是信息损耗大、响应慢。分散决策反之。

我观察到的有效模式是”分类集中“：战略探索型和跨事业部项目集中决策，效率改善型和部门内项目分散决策，合规强制型和紧急修复型走专线。这样既保住了关键决策的一致性，又不让小项目堵在决策队列里。

判断标准很简单：如果一个项目的失败不会影响另一个部门的计划，它就不需要集中决策。

5. 取舍五：严格终止 vs 宽容终止

终止机制的严格程度，直接决定组织的试错意愿。终止太严格，没人敢提探索型项目；终止太宽松，僵尸项目泛滥。

我的建议是按类型设定不同的终止容忍度。战略探索型项目的预期失败率可以设在 50%-60%，只要在门禁点按时做了决策、产出了认知，就算”成功失败”；效率改善型项目的容忍度要低得多，因为它的问题是明确的，做不成通常是执行问题。

这个区分很重要，因为很多企业把”项目没做成”一刀切地视为负面评价，结果就是所有人只敢提低风险项目，探索型项目在组织里自然消失。

八、90 天落地路线与自检清单

最后给出可执行的落地路径。这套路线我在三家企业跑过，节奏基本可用，具体时间点按组织情况调整。

1. 第 1-30 天：定义与对齐

1. 拉取过去 12 个月的立项清单，人工分成五类，统计各类的数量与预算占比。
2. 基于真实数据调整五类定义和识别规则，确保每类至少覆盖 5% 的历史项目。
3. 召开一次管理层共识会，重点对齐”不可逆性可以触发决策升级”这一条。
4. 确定 Sponsor 实名制的执行范围（建议先覆盖战略探索型、业务增长型和合规强制型）。

这个阶段最容易失败的地方是跳过第 1 步。我见过直接拿行业模板来套的，结果识别规则和实际项目完全对不上，用两周就废了。

2. 第 31-60 天：工具落地与试点

1. 在管理平台中配置五类工作项类型、对应字段集、审批流和自动化规则。
2. 回填历史项目类型与四维度评分，至少覆盖过去 12 个月。
3. 选 2-3 个部门试点，收集填写时长、审批周期、驳回原因三类数据。
4. 组织一次试点复盘，重点看”类型选择是否正确”和”门禁是否被绕过”。

试点阶段我建议刻意制造一次”终止决策”，哪怕项目本身还可以继续。让组织第一次看到”终止是正常动作”，比任何宣讲都有效。

3. 第 61-90 天：全面推行与数据看板

1. 全员推行，同时上线立项数据看板，按类型、部门、结果三个维度切片。
2. 建立月度立项复盘机制，固定输出三个数字：门禁淘汰率、僵尸立项占比、承诺偏差率。
3. 设置一个”制度反馈通道”，收集识别规则误判的案例，每季度修订一次规则。

4. 自检清单

如果你的立项制度满足以下 6 条中的 5 条以上，说明基本健康；低于 3 条，建议尽早重构。

• 项目类型有明确的识别规则，且规则可以被系统自动判定。
• 决策层级由”金额 + 不可逆性 + 耦合度”共同决定，不只是金额。
• 每个项目的立项材料中包含可证伪的成功标准和明确的终止条件。
• 存在至少一个中期门禁，且该门禁的实际淘汰率在 10% 以上。
• 立项后 30-45 天有资源到位校准动作，未启动项目会被自动标记。
• 每季度做一次”立项承诺 vs 交付实际”的比对分析，并据此修订制度。

5. 一个容易被忽略的收尾动作

最后说一个细节。制度上线三个月后，我建议做一次”逆向走查”：随机抽 10 个已立项项目，让项目组回答一个问题，“如果重新来一次，你会在立项材料里改哪一项？”

这个问题的答案往往直指制度的盲区。我做过三次这样的走查，收到的反馈集中在两点：一是”关键假设当时写得不够具体”，二是”资源承诺没有落实到人”。这两点都不是流程问题，而是制度在引导填写行为时的精度问题。这也说明，立项制度的迭代永远不该停在流程层面。

回到开头那家装备制造企业。他们后来做的事情其实不复杂：把 187 个项目重新分类，发现 63 个僵尸项目里有 41 个属于”效率改善型”，本来就不需要走完整评审。他们做的第一件事不是加流程，而是删流程、加分类、补门禁。三个月后，新立项项目的 90 天启动率从 68% 提升到 91%。

如果你现在正准备修订立项制度，我的建议是：先别动流程，先去把过去一年的项目分成五类，看看每一类的数量、预算和实际结果。这张表做出来之后，你会发现需要修改的流程，可能和你原本想的完全不一样。