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

去年第四季度，我参与了一家年营收 30 多亿元装备制造企业的项目组合复盘。他们全年正式立项 218 个项目，可到了 12 月的复盘会上，PMO 负责人只用了 40 分钟就把 218 个项目分成了三堆：61 个能说清楚业务收益的、94 个只能说清楚”做完了”的、63 个连当初为什么立项都得翻聊天记录才能想起来。更扎心的是，那 63 个”说不清”的项目，平均消耗了 11.6 个人月，加起来约占全年研发与 IT 总投入的 18%。

这不是个案。过去三年，我以外部顾问身份参与过 40 多家企业的 PMO 建设和立项流程改造，从 300 人的专精特新企业到 2 万人的集团总部都有。我发现一个高度一致的规律：立项失控的根因，几乎都不是审批不严，而是没有按项目类型做分类治理。

同一套模板、同一张评审表、同一个审批层级，去审一个必须拿下的战略级平台项目、一个合同已经签了的客户交付项目、一个内部报表自动化项目，结果必然是，重要的项目嫌流程啰嗦，紧急的项目绕过流程，普通项目在流程里躺平。这篇文章我会把自己反复验证过的立项方法拆开讲：怎么分类、每一类该看什么证据、评审会上该问哪几个问题、什么情况下流程要加重、什么情况下必须砍到极致，以及这些判断怎么落到系统里而不是停在 PPT 上。

一、先给结论：立项是投资决策，不是行政审批

很多人把立项理解成”走个流程把钱批下来”。我不同意。立项的本质是一次信息不对称条件下的投资决策：用有限的信息，决定是否把稀缺的人、钱、时间押在一件尚未发生的事情上。既然是投资决策，它的方法就必须随投资类型变化。

下面四条结论，是我在几十次流程改造中反复验证后固化下来的核心判断。如果时间有限，只看这四条也够用。

1. 结论一：项目类型不同，立项的”证据标准”必须不同

战略型项目需要的是”战略一致性和不可替代性”的证据；交付型项目需要的是”合同边界与交付可行性”的证据；内部效率型项目需要的是”现状痛点的量化基线和投入产出比”的证据；合规型项目需要的是”不做的后果”的证据。用同一张评分卡去衡量这四类，评分一定失真。

我见过一家企业给所有项目套用”投资回收期必须小于 18 个月”的硬指标，结果安全合规类项目集体被打低分，拖了两年后因为一次监管检查被罚了七位数。指标没错，错在拿错了尺子。

2. 结论二：立项要分两次决策，而不是一次审批

第一次决策回答”该不该做”（投资决策，由业务出资方和战略层判断）；第二次决策回答”怎么做才划算”（方案决策，由技术负责人和交付负责人判断）。这两件事需要的参会人、材料、时间长度完全不同，混在一个会上开，结果就是业务方听不懂技术方案，技术方不关心业务收益，会议变成汇报表演。

3. 结论三：立项最大的价值，是提前写清楚”放弃条件”

这是我最坚持的一条，也是最常被忽略的一条。一份没有退出条件的立项书，等于一张无限期通行证。退出门槛应该在立项时由业务方主动承诺，比如”若 3 个月内首批 2 个业务单元的实际使用率低于 40%，项目自动降级为维护状态”。写下来，比事后砍项目容易十倍。

4. 结论四：流程再漂亮，落不到系统里就是一次性的

立项模板做得再精致，如果它是一份 Word 文档，三个月后必然退化成”填空游戏”。真正有效的做法是把立项表单、评分卡、审批流、项目组合视图放在同一套对象模型上：立项通过后自动生成项目空间、里程碑和责任人，评审数据自动沉淀为可对比的历史基线。这一点决定了立项流程是”制度”还是”形式”。

二、背景与真实场景：立项为什么会一步步失控

要理解立项为什么难，得先看清它在企业里真实的样子。我总结了三类最典型的失控场景，几乎覆盖了我见过的 80% 以上的问题企业。

1. 场景一：战略项目被当成普通 IT 需求走流程

某家电企业的数字化中台项目，战略层在年度经营会上明确列为”一把手工程”，但到了执行层面，它被拆成 14 个 IT 需求单，走的是普通需求评审流程，审批层级只到 IT 经理。结果是：战略层以为项目在推进，IT 部门以为只是接了十几个需求，半年后战略层问进度，发现最关键的三个数据治理模块根本没人排期。

这类问题的本质是治理层级与项目重要性错配。项目越战略，审批层级反而越不能只看金额。

2. 场景二：交付型项目”先立项后补材料”

合同已经签了、交付日期写死了，立项才刚开始走。这时候的立项评审就没有任何决策价值了，因为不做的选项已经被消灭。我统计过一家工程服务企业的 76 个交付型项目，其中 61 个的立项评审会发生在合同签订之后，平均滞后 9.4 天。

这类立项会议通常 20 分钟结束，唯一产出是”确认预算”。真正的风险，资源是否够、关键设备交期是否匹配、验收标准是否有歧义，全都留到了执行阶段爆炸。

3. 场景三：效率类项目堆成”影子项目池”

更麻烦的是那些”没走立项但已经在做”的项目。我在一家零售企业盘点时发现，各部门自行启动的报表优化、流程自动化、小工具开发类项目共有 43 个，PMO 台账上一个都没有。这些项目单个投入不大，但合计占用了 6 名数据工程师 70% 的工时，导致真正的重点项目长期缺人。

影子项目池的危险不在浪费，而在它吸走了你最稀缺的那部分资源，却不进入任何决策视野。

三、按项目类型定制立项标准

接下来是这篇文章最核心的部分。我会把企业里常见的项目分成四类，分别说明它们的立项逻辑、必备证据、审批层级和退出条件。这个分类不是理论推导，而是从实际台账里归纳出来的，如果你的项目分类超过六种，多半是分类过细，反而无法指导决策。

1. 战略/增长型项目

特征：结果高度不确定、投入周期长、与公司战略直接相关、往往没有现成对标。这类项目的立项核心不是算 ROI，而是回答三个问题：不做会怎样？为什么是我们？如果只做一半，先做哪一半？

必备证据包括：战略关联说明（明确指向哪一条年度战略）、不可替代性分析（为什么不能买、不能等）、分阶段价值验证点（第一个可验证的成果点必须在 3 个月内）。审批层级建议到经营层或战略委员会，且必须有 C 级发起人。

退出条件必须写得比其它类型更狠：战略型项目的止损点应该绑定”阶段性验证点”而不是”时间点”。比如”若第一个验证点未达到预设的最低可用标准，且差距超过 30%，则项目降级或重构”。

2. 客户交付型/合同型项目

特征：范围由合同界定、时间由客户决定、失败成本高。这类项目的立项核心是可行性，不是必要性，必要性已经在投标阶段解决了。

必备证据包括：合同关键条款摘要（交付物清单、验收标准、付款节点、违约条款）、交付可行性评估（资源、技术、供应链）、明确的验收标准逐条对应表、以及风险敞口估算。审批层级可以低（业务线负责人即可），但审批前置必须在合同签订之前，至少是”合同评审与立项评审同步”。这一条我在多个企业推动过，是最难改但收益最大的一条。

退出条件比较特殊，通常不是”放弃”，而是”变更”：比如”若客户在 30 天内未确认需求基线，则启动合同变更流程，触发价格与工期重谈”。

3. 内部效率型/数字化项目

特征：收益是可量化的但分散，容易夸大，也容易被低估。这类项目最常见的失败不是做不出来，而是做出来没人用。

必备证据的核心是现状基线：目前这个流程每周消耗多少人时、错误率多少、平均处理时长多少。没有基线的效率类项目，3 个月后无法证明价值，就会在预算削减时第一个被砍。同时要给出目标基线和验收口径，比如”审批平均时长从 3.5 天降到 1 天”。

审批层级可以到部门负责人加 IT 负责人联签，但建议设置单项目投入上限（如不超过年度 IT 预算的 5%），超过则升级到组合层统一排序。因为效率类项目的真正问题从来不是单个值不值得做，而是做得太多导致整体资源碎片化。

4. 合规/风险驱动型项目

特征：收益是”避免损失”，因此无法用常规 ROI 衡量，也最容易在预算紧张时被无限期推迟。

这类项目的立项证据应该直接写”不做的后果”：适用的法规条款、可能面临的处罚区间、外部审计或客户审核的时间节点、以及不做的机会成本。审批层级到合规负责人与经营层联签，且建议设为不可裁减项目，在项目组合排序中单列一档。

退出条件很少适用，但可以设置”范围最小化”条件：若预算受限，允许缩减到仅满足最低合规要求的方案。

四、立项环节最常见的八类误区

说完方法，说坑。下面这八条是我在评审现场亲眼见过、并且反复复发的误区。我把它们分成论证类、流程类、组织类三组，方便你对照自查。

1. 论证类误区

（1）把 ROI 算成一道数学题。最常见的做法是把”预计节省人力 × 人均成本 × 5 年”当作收益，得出一个漂亮的数字。问题是这个乘法里的每个变量都可能是拍脑袋的。我见过一个项目算出 5 年节省 2400 万元，实际上线后每年节省约 60 万元，差了 8 倍。更可靠的做法是只承诺 12 个月内的保守收益，并注明推导链条和关键假设。

（2）用”提升效率”代替量化指标。“提升协同效率””优化管理流程”这类表述在立项书里等于零信息。有效的表述必须包含对象、基线、目标、口径四要素，例如”采购对账环节，人均每周处理 40 张单据，目标降到 15 张，口径为ERP系统导出数据”。

（3）把假设当结论写。立项书里最值钱的不是结论，而是被明确标注出来的假设。我建议单列一节”关键假设与验证方式”，把”假设用户愿意从邮件迁移到系统”这种致命假设摆到台面上，并配上验证时间和验证方法。

2. 流程类误区

（4）把”预算审批”当成”项目立项”。这两件事在财务口径上可能重合，在管理口径上完全不同。预算解决的是”钱能不能花”，立项解决的是”这件事该不该做、由谁做、做到什么程度算完成”。我见过企业预算批复了，但项目范围、责任人、验收标准全是空白，结果执行三个月后无人能说清项目到底是什么。

（5）里程碑写成愿望清单。“6 月完成需求调研、8 月完成开发、10 月上线”，这不是里程碑，这是日历。真正的里程碑必须有可验证的产出物和验收人，例如”6 月 15 日前输出经 3 个业务单元确认的需求基线文档，验收人：业务总监张 XX”。

（6）没有退出机制，只进不出。项目组合里最危险的状态不是失败，而是”半死不活地拖着”。我建议在立项阶段就约定”僵尸项目”的判定标准：连续两个里程碑延期超过 30%、或负责人连续两次缺席评审、或连续 60 天无实质进展，自动触发复核。

3. 组织类误区

（7）没有单一责任人，只有”项目组”。项目组是执行单元，不是责任单元。立项时必须指定一个对结果负责的人，并且这个人要有调动资源的权限。如果立项书上写的是”由数字化转型办公室牵头，各部门配合”，那基本可以判断这个项目会在跨部门协调中消耗掉一半的预算。

（8）评审会开成汇报会，没有决策动作。我参加过太多这样的会：项目经理讲 40 分钟，领导点评 10 分钟，最后说”再研究研究”。有效的立项评审必须当场产出四种结果之一，通过、通过但附加条件、退回补充材料、不予立项。“再研究”不是一种决策，它是决策的缺席。

五、专业判断逻辑：七个必答问题与一张评分卡

方法再好，落到评审现场还是需要一个可操作的工具。我通常给客户两样东西：七个必答问题（用于对话），和一张加权评分卡（用于排序）。前者防止评审变成闲聊，后者防止排序变成领导拍板。

1. 七个必答问题

1. 不做的后果是什么？如果答案是”也没什么”，这个项目大概率不该现在做。
2. 谁对最终结果负责？必须是具体的人名，不是部门。
3. 12 个月内能看到的最小可验证成果是什么？说不出具体成果的项目，属于愿景而非项目。
4. 关键假设有哪些？怎么验证？列出不超过 3 条最致命的假设。
5. 需要占用哪些稀缺资源？和哪些项目冲突？这一条能筛掉大量重复建设。
6. 什么情况下我们会停？没有答案就不通过。
7. 同类的事我们是不是已经做过一次？用于识别重复建设和历史失败模式。

2. 加权评分卡的设计

评分卡的关键不是维度多，而是权重合理、口径统一。我给中大型企业客户的默认权重如下表所示。注意这份评分卡针对的是内部效率型项目，战略型项目要把”战略一致性”权重提高到 35% 以上，交付型项目则应把”交付可行性”提到首位。

3. 一页纸立项模板

我反对动辄 40 页的立项书。80% 的立项决策只需要一页纸的信息量。下面是我在多个客户处固化下来的模板结构，用 YAML 表示便于进入系统字段化管理，实际使用时可以做成表单。

project_charter:
name: 采购对账自动化

type: 内部效率型 # 战略型 / 交付型 / 效率型 / 合规型

sponsor: 财务总监 李某 # 必须是一个人

owner: 财务共享中心 王某

problem_baseline: # 现状基线，必须有数字

weekly_man_hours: 62

error_rate: 8.5%

avg_cycle_days: 3.5

target_baseline:

weekly_man_hours: 24

error_rate: 2.0%

avg_cycle_days: 1.0

measurable_outcome_12m: 年节省约 1900 人时，差错损失下降约 70%

critical_assumptions:

供应商电子发票覆盖率 6 月底前达到 85% # 验证方式：月度抽样

三个业务单元愿意统一对账口径 # 验证方式：5 月前签署口径确认单

resource_conflict:

需要数据工程师 0.5 人月，与数据中台项目冲突

milestones:

date: 2025-06-15

deliverable: 需求基线与口径确认单

acceptor: 财务总监 李某

date: 2025-08-30

deliverable: 试点单元上线并跑通一个月

acceptor: 财务共享中心负责人

exit_conditions:

上线 60 天内活跃使用率低于 40%，转维护状态

连续两个里程碑延期超过 30 天，自动进入复核

decision: 通过（附加条件：9 月前完成口径统一）

4. 评审会怎么开才有效

我们在一家企业把立项评审会从 90 分钟压缩到 25 分钟，通过率反而下降了 9 个百分点，因为决策变认真了。做法很简单：材料提前 48 小时发出，会上不允许逐页念稿，只回答七个必答问题；每个项目固定 15 分钟问答；结束时当场给出四选一的结论。

关键角色只有三个：业务出资方（判断值不值得）、技术负责人（判断做不做得到）、PMO（判断和现有组合冲不冲突）。其他人旁听即可。参会人越多，决策越慢，责任越模糊。

六、真实案例：一家 1200 人企业的立项改造

讲一个具体案例。2024 年上半年，一家 1200 人规模的智能硬件企业找到我。他们的情况很有代表性：研发人员约 480 人，同时在跑 63 个项目，交付准时率 58%，研发骨干流失率连续两个季度超过 12%。访谈中听到最多的一句话是”我不知道自己同时在几个项目上”。

1. 诊断：问题不在执行，在立项

我们先做了一件事：把 63 个项目的立项材料全部翻出来。结果显示，其中 41 个没有明确的责任人，38 个没有量化目标，29 个没有验收标准，全部 63 个都没有退出条件。更严重的是，有 14 个项目在做功能高度重叠的事，分别由三个不同的部门立项。

然后我们做了关键资源映射：把 480 名研发人员中 92 名关键角色（架构师、核心模块负责人、测试专家）与项目做了对应，发现这 92 人平均同时出现在 4.7 个项目上，最高的一位出现在 9 个项目上。这就是准时率 58% 的真正原因，不是大家不努力，是资源在立项阶段就被过度承诺了。

2. 改造：三阶段落地

第一阶段（1-2 月）：分类与瘦身。把 63 个项目按四类重新归类，砍掉 11 个重复建设，合并 9 个，暂缓 7 个。同时发布分类立项标准，明确每类项目的必备证据和审批层级。

第二阶段（3-4 月）：流程上系统。这一步是成败关键。立项表单如果还是 Word 加邮件，前面所有努力会在两个月内归零。我们在 PingCode 上把立项一页纸做成了结构化表单，项目类型、发起人、责任人、现状基线、目标基线、关键假设、里程碑与验收人、退出条件全部是必填字段，缺一项无法提交。

更重要的是，立项通过后自动生成项目空间、里程碑和责任人，评审时填写的资源需求直接进入组合视图。作为服务中大型企业和 100 人以上组织的平台，PingCode 在这类场景里的优势是对象模型比较统一：需求、任务、迭代、测试、发布和项目组合在同一套数据上，PMO 不需要再从三个系统里导数据对齐口径。这个客户因为早期用过海外工具，还有历史数据迁移需求，最终是走 Jira 平滑迁移路径落地的，支持私有化部署这一点也满足了他们对研发数据不出内网的要求。

第三阶段（5-6 月）：机制固化。设立月度组合评审，用评分卡对所有在跑项目排序；启用”僵尸项目”自动预警；把立项数据的完整率纳入部门负责人考核。

3. 结果：六个月后的数据

经过两个季度运行，几个关键指标的变化超出预期。我把改造前后的对比整理如下，同时标注了数据来源：项目台账系统导出 + PMO 月度统计报表。

4. 一个被忽略的副作用

改造后最有意思的变化不在数据里。以前立项评审会上，业务方会尽量把项目说大，因为”说得越大越容易批”。分类标准明确之后，业务方开始主动把项目说小，他们会说”我先按效率型项目提，验证点过了再升级成战略型”。这是一个非常健康的转向：立项从”一次性争取资源”变成了”分阶段证明价值”。

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

同一套方法，在不同规模、不同成熟度的企业里落地路径差别很大。我按规模和阶段给出四组建议，你可以直接对号入座。

1. 100 人以下企业：只做两件事

不要搭体系。这个阶段只需要两样东西：一是”每个项目必须有一个责任人和一个可验证成果”，二是”每个项目必须写一句什么情况下停”。用一页纸甚至一个共享表格就够了。这个阶段引入多级审批、评分卡、组合管理，只会让团队把流程当敌人。

2. 100，500 人企业：建立分类标准与最小评分卡

这个规模开始出现”资源冲突但看不清楚”的问题。建议做三件事：明确四类项目定义与各自的必备材料；建立一张不超过 5 个维度的评分卡；每月开一次 60 分钟的组合评审。工具层面就应该开始上系统了，哪怕是轻量的。

PingCode 的服务边界通常从 100 人以上组织开始，这个阶段正好是它比较容易见效的区间：立项表单、审批流、项目空间、里程碑可以在一条链路上跑通，而且后面规模扩大时不用换平台。

3. 500，2000 人企业：立项与组合必须联动

这个规模的核心矛盾是资源。立项评审必须带资源容量校验，否则立项越多、交付越差。建议：立项表单强制填写资源需求；建立关键角色台账；组合视图按资源占用排序而不是按项目金额排序；引入”僵尸项目”自动预警。这也是我在前面案例里用到的完整做法。

4. 2000 人以上企业：分层治理，允许差异化流程

大集团不要追求全公司一套流程。合理的做法是”总部定标准、事业部定细则”：总部只规定四类项目的分类定义、必备证据清单、退出条件框架和汇报口径；具体审批层级、表单字段、评审频率由事业部根据自身业务特点细化。

同时，总部必须掌握统一的项目组合视图。否则你会发现，每个事业部都说自己资源紧张，但全集团看过去有一批项目在做重复的事。像 PingCode 这类支持私有化部署、支持 Jira 平滑迁移的国产平台，在集团场景里比较常见的用法是先在 1，2 个事业部试点，验证流程后再横向推广，避免一次性全集团切换带来的震荡。

八、取舍：什么时候该重，什么时候必须轻

关于立项，最常见的争论是”流程太重影响效率”。我的观点是：立项流程的重量，应该由”做错的代价”决定，而不是由”审批人的习惯”决定。

1. 决策延迟成本 vs 立项不充分成本

这是两条方向相反的曲线。立项流程越重，决策延迟成本越高（机会窗口错失、团队等待、士气损耗）；立项流程越轻，立项不充分成本越高（方向错误、返工、资源错配）。两者相加存在一个最低点，而这个最低点在不同项目类型上位置完全不同。

根据我在多家企业的测算，战略型项目的最优决策周期大致在 10，15 天，交付型在 1，3 天，效率型在 3，7 天，合规型在 3，5 天。偏离这个区间太远，总成本都会上升。

2. 三个必须”重”的信号

第一，项目一旦失败会影响主营收入或核心客户关系；第二，项目需要占用 3 个以上关键角色超过 3 个月；第三，项目涉及跨 2 个以上事业部的资源与口径。满足任意一条，立项流程就应该加重：加业务论证、加资源校验、加高层评审。

3. 三个必须”轻”的信号

第一，可逆性高、失败成本低于 10 万元的项目；第二，有现成对标方案、技术路径成熟的项目；第三，能在 4 周内看到结果的试验型项目。这三类应该走快速通道，甚至允许”先做后备案”，但必须约定复盘时间。

我最反对的是一种做法：对可逆的小事走重流程，对不可逆的大事走快流程。前者消耗组织耐心，后者埋下重大隐患。判断标准只有一个，如果这件事做错了，我们多久能发现、花多大代价能撤回。

九、关于项目立项的八个高频追问

1. 小项目也要走立项吗？

要，但形态可以完全不同。10 万元以下、4 周内可完成的项目，建议用”轻立项”：一段话说明目标、责任人、验收方式，登记到统一台账即可。核心不是审批，而是”纳入台账”，避免形成影子项目池。我见过最有效的做法是给每个部门一个季度轻立项额度，用完就得走正式流程。

2. 立项通过后，需求还能改吗？

能改，但要区分”基线变更”和”范围新增”。范围内的小调整属于正常执行，不需要重新立项；超出原立项范围、影响工期或预算超过 15% 的，应该走变更评审。关键是立项时就要把”什么算变更”写清楚，否则后期一定扯皮。

3. 业务方不愿写量化目标怎么办？

这是最常见也最真实的阻力。我的经验是不要一次要求写完整，而是要求回答一个问题：”如果这个项目做完了，你会用什么来判断它有没有用？”把这个答案记录下来，哪怕只是定性描述，也比空白强。下一轮再把它变成数字。强迫一次到位，通常换来的是敷衍的假数字，反而更糟。

4. 立项评审该由谁拍板？

按项目类型分：战略型由经营层或战略委员会拍板；交付型由业务线负责人拍板；效率型由部门负责人与 IT 负责人联签；合规型由合规负责人与经营层联签。共同原则是：拍板的人必须是承担后果的人。让不承担后果的人否决项目，是立项机制里最大的效率杀手。

5. 多项目资源冲突怎么在立项阶段识别？

靠人工会议很难，必须靠系统。做法是把关键角色（架构师、核心模块负责人、领域专家）建成资源台账，立项时填写资源需求，系统自动比对现有承诺。当某个角色的承诺占用超过 80% 时自动预警。前面案例中那家企业正是靠这一步把关键角色并发数从 4.7 降到 2.1。

6. 立项材料到底要多少页？

我的建议是：内部效率型 3，5 页，交付型 5，8 页，合规型 6，10 页，战略型 10，15 页。超过 20 页的立项书，通常意味着作者还没想清楚，只是把不确定性用篇幅盖住了。结构化的表单比长篇文档更有效，因为必填字段会逼出关键信息。

7. 已经立项的项目怎么补救？

不要试图给存量项目补全部材料，性价比极低。建议只补三样：责任人、12 个月可验证成果、退出条件。这三样补齐，80% 的管理问题就能被暴露出来。剩下的材料等下一次重大变更或里程碑复盘时再补。

8. 立项数据和项目管理系统必须打通吗？

我的判断是：项目数超过 20 个、参与人数超过 80 人，就必须打通。低于这个量级，手工台账还能撑住。超过之后，立项数据与执行数据的脱节会导致组合视图失真，PMO 会把越来越多时间花在”对齐口径”而不是”支持决策”上。前面案例中，PMO 月度数据整理耗时从 42 小时降到 8 小时，主要就是靠这一步。

十、结语：把立项当成一次可证伪的投资假设

回到开头那家装备制造企业。后来我们做的最重要的改变，不是加了几个审批节点，而是把立项书的标题从”XX 项目立项申请”改成了”XX 项目投资假设与验证计划”。这个改动听起来很小，但它改变了所有人的心理定位，不再是在申请资源，而是在提交一个可以被验证、也应该被质疑的假设。

我的核心观点可以浓缩成三句话。第一，项目类型决定立项标准，一套流程打天下必然系统性失真。第二，立项的最大价值是提前写清楚放弃条件，而不是把预算批下来。第三，流程只有落到系统里、变成必填字段和自动预警，才会从制度变成习惯。

如果你现在就要动手，我建议按这个顺序来，一周内就能看到变化。第一步，把手上在跑的项目按四类重新归类，只做分类，不做评价。第二步，给每个项目补上三样东西：责任人、12 个月可验证成果、退出条件，缺哪样补哪样。第三步，挑一个类型（通常是内部效率型）做试点，把立项一页纸做成结构化表单，跑一个完整季度。第四步，等试点验证有效后，再考虑引入评分卡和组合评审。

不要试图一次性把立项体系建完。我见过太多企业花三个月设计出完美的流程文档，最后因为太重而被绕过。能跑起来的不完美流程，永远优于躺在文件夹里的完美流程。