项目立项优先级教程：企业管理者风险控制，避坑指南

2023 年冬天，我参加了一家年营收 18 亿的装备制造企业的年度立项复盘会。会上有人把过去三年批过的 62 个项目拉了一张表，结果很刺眼：真正按原始商业论证交付价值的只有 11 个；而这 11 个里面有 9 个，当初的立项评审只花了不到 20 分钟。反倒是被反复争论、拖了三个月才批下来的两个项目，最后全部按期交付、毛利达标。这个反差几乎是我这些年做立项评审最常遇到的规律，在立项环节省下来的时间，后面要用十倍的成本还回去，而且往往还不止十倍。

这篇文章不讲项目管理教科书里的定义，只讲我在企业里真实看到的东西：企业管理者怎么给项目立项排优先级，怎么用优先级做风险控制，以及最容易掉进去的几个坑。全文会给出可以直接拿去用的评分卡、闸门机制、退出条款模板，也会给出一家 600 人规模企业的真实改造数据。

一、先给结论：立项优先级不是排序题，而是风险定价题

大多数管理者对”立项优先级”的理解是排序：把候选项目列出来，按重要程度从高到低排，资源从上往下分。这个理解不能算错，但它漏掉了最关键的一层，排序只解决了”先做谁”，没有解决”该不该做”和”做错了什么时候停”。

我更愿意把立项优先级定义成一道风险定价题：在资源有限、信息不完整、时间窗口会关闭的前提下，哪个项目组合的”风险调整后回报”最高。注意是组合，不是单个项目。下面三条是我反复验证过的核心结论。

1. 优先级是组合问题，不是单项目问题

一个项目单看很赚钱，但如果它占用了唯一能啃硬骨头的架构师，导致另外三个项目整体延期半年，那它对组合的贡献可能是负的。我在评审时最常问的一句话不是”这个项目值不值得做”，而是”如果做了它，我们必须放弃什么“。

没有回答第二个问题的立项申请，我一律退回。因为不回答放弃项，就等于默认其他所有项目的资源都不变，这在现实里从来不成立。

2. 风险不该是减分项，而该是被定价的变量

很多评分卡把”风险”做成扣分：风险高就减 2 分。这个做法的问题是，它把风险和收益割裂了。正确的做法是把风险折算成期望损失，再和收益放在同一把尺子上比。

我通常用这个公式做初筛：期望风险暴露值 = 失败概率 × 失败影响金额 × 暴露时长（月）÷ 12。同样是一亿的潜在损失，如果暴露时长是 3 个月还是 36 个月，对企业的实际杀伤力完全不同。硬件研发和基建类项目特别容易被这一点坑到。

3. 立项决策的价值，取决于它卡在”不可逆点”之前还是之后

每个项目都有一个不可逆点：合同签了、模具开了、产线排了、数据迁移动了、对外承诺发了。过了这个点，砍项目的成本会指数级上升。立项机制存在的全部意义，就是在不可逆点之前把不确定性降到可接受水平。

所以判断一个企业的立项机制好不好，我只看一个指标：它有没有能力在花钱之前说”不”。如果一家公司的立项评审从来没否决过项目，那不是机制好，是机制不存在。

下面这张图是我在多个行业里复盘的”缺陷与风险修复成本放大系数”。它解释了为什么立项阶段多花三天，长期看是划算的。

二、背景和真实场景：为什么大部分企业的立项管理在空转

我先描述三种我见过最多的立项现场。你对号入座一下，大概率能认出自己公司的影子。

1. 三种典型的立项现场

（1）老板拍板型

老板在行业会议上听到一个方向，回来说”这个我们要做”。于是立项申请在一周内补出来，数据漂亮，论证完整，逻辑闭环。评审会开 40 分钟，主要时间花在讨论怎么排资源，没有人讨论要不要做。

这类项目的风险不在方向本身，而在于论证是为了证明决策正确，而不是为了发现决策错误。我见过一个典型案例：某企业为了进入一个新渠道，立项时预估首年营收 4000 万，实际做了 600 万，团队 14 个人耗了 11 个月。

（2）部门抢资源型

每个季度末，各部门集中提交立项申请，理由高度相似：不投入就会落后、竞品已经做了、客户在问。真实动机往往是为了锁定明年的编制和预算。

这类场景的最大问题是立项数量与业务需要脱钩，与部门博弈强度挂钩。我见过一家 400 人的企业，一个财年批了 78 个立项，平均每个项目 5 个人，等于把整个公司拆成了 78 份。

（3）KPI 摊派型

公司定了数字化转型目标，于是每个业务线都被摊派了几个”数字化项目”。这类项目的立项文档通常是模板套的，风险登记册是空的，里程碑是拍的，验收标准是”系统上线即完成”。

它的隐性成本最高，因为没人真正为结果负责，项目上线那天就是它结束的那天。

2. 一年 128 个需求，最后交付了 7 个

2022 年我帮一家零售企业做研发投入复盘，把全年从各渠道进来的 128 个立项需求完整回溯了一遍。结果是我做复盘以来见过最典型的漏斗。

128 个需求经过需求初筛剩 61 个，走完商业论证剩 34 个，正式立项 26 个，进入开发 21 个，按期交付 12 个，交付后被业务方真正使用并产生可量化收益的只有 7 个。从 128 到 7，转化率 5.5%。

关键不是这个数字低，而是流失集中发生在了错误的环节。34 到 26 这一步流失了 8 个，原因全部是”资源排不开”，而这个因素在更早的环节本可以被评估出来。

3. 立项动机的分布，决定了后面所有的风险

我后来养成一个习惯：在评审会上先问一句”这个项目是谁提出来的、提出来的原因是什么”。因为立项动机基本决定了这个项目后面会以什么方式失败。

战略驱动的项目，失败通常是执行不到位；竞品驱动的项目，失败通常是需求判断错误；客户驱动的项目，失败通常是范围失控；KPI 驱动的项目，失败通常是无人使用。把这四类动机的分布画出来，一家公司的项目风险画像基本就出来了。

我跟踪过的一家中型软件企业，其立项动机中”竞品已做”占比高达 38%，那一年他们的项目中止率也是过去五年最高的。

三、拆解常见误区：立项优先级最容易踩的六个坑

下面六个误区，我几乎在每一家企业都能见到至少三个。它们的共同特征是：看起来是在做严谨管理，实际上是在制造虚假确定性。

1. 误区一：把 ROI 算成一个确定数字

“投资回收期 14 个月，内部收益率 32%。”这句话在立项文档里出现的频率极高，但它通常建立在一个单点预测上。单点预测的本质是把不确定性藏起来了。

我的做法是强制要求三种情景：悲观、中性、乐观，并且规定只有悲观情景下不亏掉公司可承受额度上限的项目，才允许进入下一轮。这个规则一加，很多”看起来很赚”的项目会自动退出。

2. 误区二：把战略重要性当成免死金牌

只要写上”符合公司三年战略”，评分就会自动拉高。问题是几乎所有项目都能和战略扯上关系。战略契合度必须被拆成可验证的条目，比如”直接支撑今年必须完成的哪一条战略举措”、”如果不做，哪条战略指标会不达标”。

回答不了这两个问题的，战略契合度应当给低分，而不是给平均分。

3. 误区三：资源可得性放到最后才评估

这是我在复盘数据里看到最致命的误区，前面那个 128 到 7 的漏斗已经证明了。大多数企业的立项流程是”先论证价值，再排资源”，结果是价值论证花了两周，最后因为没人而搁置，或者更糟，硬塞给一个已经满负荷的团队。

我现在的标准做法是：资源可得性与价值论证同步进行，且资源不可得的项目不进立项池，进候选池。候选池每季度重排一次，有人空出来就捞上来。

4. 误区四：用一个总分掩盖维度失衡

总分 78 分的项目不一定比 72 分的更该做。如果 78 分是靠战略契合 10 分拉起来的，而资源可得性只有 3 分，那这个项目大概率会在执行期出事。

所以除了总分，我会强制看两个东西：最低维度分和维度极差。任何单维度低于 4 分（10 分制）的项目，必须给出补足措施和时间点，否则不予立项。

5. 误区五：只批进不批出

立项机制如果只管”批准”，不管”终止”，就会变成单向阀。项目一旦立了，就自动获得永久生存权，直到把预算烧完。

我在每份立项文档里都要求写一段”终止条款”：出现什么信号、由谁判断、在多少天内做出停止决定。这一段往往比收益预测更值钱。

6. 误区六：把”不做”当成保守

很多管理者的潜意识里，”砍项目”等于”没能力”，”多做几个”等于”有进取心”。但从组合角度看，及时终止一个错误项目，和成功交付一个正确项目的价值是同一量级的。

我推动过的一家企业，把”主动终止项目数”写进了研发负责人的考核指标，一年后他们的项目按期交付率从 54% 提升到 79%。减少数量本身就在提升质量。

下面这张帕累托图是我在某企业 41 个失败项目复盘时统计的根因分布。可以看到，前两类原因就贡献了超过六成的失败。

四、专业判断逻辑：四维评分 + 四道闸门 + 一票否决

前面讲了结论和误区，这一节是我实际在用的判断逻辑。它由三部分组成：评分维度、闸门机制、否决与退出条款。三者缺一不可，只用评分卡而不设闸门，等于只做体检不做手术。

1. 四维评分：战略契合、价值确定性、风险可控性、资源可得性

我用的维度只有四个，不是因为它简单，而是因为更多维度会导致权重被稀释，评审会变成一场关于数字的辩论。四个维度的权重我一般这样分配：价值确定性 35%、战略契合 25%、风险可控性 25%、资源可得性 15%。

注意价值确定性的权重最高，而不是战略契合。原因很直接：战略契合是方向问题，价值确定性是生死问题。方向上稍有偏差可以调整，价值假设错了则项目必然失败。

表格里第五列是我最看重的。评审时我不看分数，先看数据来源那一列。来源缺失的分，一律按最低档处理，这比事后追责有效得多。

2. 四道闸门：G0 机会筛选、G1 商业论证、G2 立项评审、G3 启动就绪

只有评分卡是不够的，因为分数只在评审那一刻有效。闸门的作用是把决策切成四段，每一段只解决一个问题，并且明确谁能拍板、产出什么、多长时间内必须出结论。

1. G0 机会筛选（3 个工作日）：只回答”这个方向和公司战略/客户需求是否相关”。产出：一句话机会描述 + 业务负责人实名。不通过的直接回需求池，不做详细论证。
2. G1 商业论证（10 个工作日）：回答”值不值得投入”。产出：三情景财务测算、关键假设清单、初步风险清单。此阶段允许使用纸面推演，不需要完整方案。
3. G2 立项评审（5 个工作日）：回答”能不能做、什么时候做”。产出：四维评分卡、资源排期确认书、终止条款。这是唯一能批预算的闸门。
4. G3 启动就绪（3 个工作日）：回答”准备好的没有”。产出：范围红线、里程碑基线、风险责任人、度量口径。G3 不通过的，项目不得开工，但预算保留 30 天。

四道闸门的总耗时控制在 21 个工作日以内。这个数字很重要，超过三周，业务窗口可能就关闭了，团队也会开始绕过流程。我见过太多企业把流程设计得很完美，结果因为太慢被业务方用”特批”绕过去，最后流程形同虚设。

3. 一票否决清单：这几条不参与打分

有些东西不该和别的维度一起算加权平均分，因为它们是不可交易的。我的清单通常包含五条：

• 合规红线：涉及数据合规、行业准入、安全资质等硬性要求未落实。
• 现金流底线：悲观情景下所需现金超过公司可承受额度，且无分批投入方案。
• 关键人单点依赖：项目成功依赖某一个不可替代的人，且没有备份或知识交接计划。
• 无实名业务负责人：找不到一个对结果负责的业务方，只有 IT 或研发方。
• 无终止条款：立项文档里没有任何”什么情况下停止”的描述。

五条中任何一条触发，项目直接退回，分数再高也不进入讨论。这条规则我坚持了很多年，它的价值在于把评审会从”讨价还价”变成”检查清单”，时间成本大幅下降。

4. 用代码把评分逻辑固定下来

为了避免每次评审都重新争论权重和口径，我建议把评分逻辑写成可复算的脚本，放进项目管理平台的立项模板里。下面是我常用的一个简化实现，用来说明逻辑，不需要照抄。

# 立项优先级指数计算（示意实现，非生产代码）
WEIGHTS = {

"战略契合":   0.25,

"价值确定性": 0.35,

"风险可控性": 0.25,

"资源可得性": 0.15,

}

VETO_TAGS = [

"合规红线",

"现金流底线",

"关键人单点依赖",

"无实名业务负责人",

"无终止条款",

]

MIN_DIMENSION_SCORE = 4.0   # 任一维度低于此值必须给出补足措施

def evaluate(project: dict) -> dict:

1) 一票否决优先于打分

for tag in project.get("tags", []):

if tag in VETO_TAGS:

return {"结论": "退回", "原因": f"触发一票否决：{tag}", "指数": 0}

scores = {k: project[k] for k in WEIGHTS}

2) 维度下限检查

weak = [k for k, v in scores.items() if v 3) 加权指数

index = round(sum(scores[k] * w for k, w in WEIGHTS.items()), 2)

4) 期望风险暴露值（万元）

risk_exposure = round(

project["失败概率"] * project["失败影响_万元"] * project["暴露月数"] / 12, 1

)

return {

"结论": "进入 G2 评审" if not weak else "有条件进入（需补足短板）",

"指数": index,

"短板维度": weak or "无",

"期望风险暴露值_万元": risk_exposure,

}

示例：两个候选项目对比

a = {"tags": [], "战略契合": 9, "价值确定性": 8, "风险可控性": 6, "资源可得性": 5,

"失败概率": 0.3, "失败影响_万元": 800, "暴露月数": 12}

b = {"tags": [], "战略契合": 7, "价值确定性": 9, "风险可控性": 8, "资源可得性": 3,

"失败概率": 0.2, "失败影响_万元": 300, "暴露月数": 18}

print(evaluate(a))

print(evaluate(b))

这段代码最关键的价值不是算分，而是把”短板维度”和”期望风险暴露值”变成评审会上的两个固定议题。前者决定要不要设限期补足条件，后者决定这个项目在组合里要不要分批投入。

下面这张雷达图是我在真实评审中用过的三项目对比，它比一张总分表更能暴露问题。

五、真实案例与数据观察：一家 600 人企业的立项流程改造

这一节讲一个具体案例。它不是我听来的，是我从 2023 年底到 2024 年中实际参与的一段过程，数据也是我从系统里导出来逐月核对的。

1. 改造前的状态：立项靠邮件，状态靠问人

这家公司是做 To B 软件的，600 人左右，研发 280 人，同时有 4 条产品线。改造前他们的立项流程是：业务方发邮件给产品委员会 → 委员会月度开会讨论 → 用 Excel 维护立项清单 → 通过后由 IT 部门分派到各研发小组。

问题非常典型：立项评审平均周期 23 天；立项清单有 5 个版本在不同人手里流转，最新版本靠问；项目状态更新滞后平均 14 天；没有任何跨项目的依赖关系视图，两个项目抢同一个架构师，直到撞车才发现。

他们自己做过一次内部统计，当年超期未预警的项目占 37%，也就是说三分之一的延期是”到期了才知道”。

2. 改造动作：把闸门和评分卡搬进项目管理平台

我们做的事情分三块。第一块是把四道闸门做成平台里的固定工作流，每一道闸门有明确的产出物清单，缺一项无法流转到下一道。

第二块是把四维评分卡做成结构化字段，评分必须填写数据来源，没有来源的分值系统直接标红，评审时优先看红项。

第三块是建立跨项目组合视图，把关键角色的排期、里程碑冲突、风险登记册放在同一个看板上。这一块是他们改造后最满意的地方。

技术选型上，他们最终选择了 PingCode。原因有三个：一是设计上就是面向中大型企业及 100 人以上组织的，多产品线、多项目的组合视图是原生能力，不需要自己二次开发；二是支持私有化部署，这家公司的客户里有不少对数据出内网敏感，这一点是硬门槛；三是支持从 Jira 平滑迁移，他们过去几年在 Jira 上积累的 3000 多条 issue、自定义字段和工作流需要尽量保留。

这里我想多说一句关于迁移的判断。很多企业做国产替代时最担心的是”迁移会不会把历史数据搞乱”。我的经验是：迁移最大的风险不是数据丢失，而是把旧流程里的坏习惯一起搬过去。所以这次我们做了一件事，迁移前先清理，把已经关闭两年以上、没有关联的 issue 归档不迁移，只迁移活跃项目和近两年的交付记录。迁移后项目结构反而比原来清晰。

3. 改造后的数据变化（半年对比）

下面这些数据是改造前 6 个月和改造后 6 个月的对比，来自他们平台内的统计报表和财务侧的年度预算执行表，我做了交叉核对。

这张表里我最想让你注意的是最后两行。立项数量下降 35%，按期交付率提升 25 个百分点。很多人会误以为这是”少做几个就做得好”，其实因果关系是反的：是因为资源可得性被前置评估了，那些注定排不开的项目根本没进池子。

4. 一个反常识的观察：立项通过率下降，年度成功率上升

改造后第一个完整财年，他们的立项通过率从 78% 降到 51%，但年度项目成功率（按原定范围、预算、时间交付并产生预期收益）从 46% 升到 68%。

这个组合变化说明一件事：立项评审的”把关”能力比”通过”能力更重要。一个从来不说”不”的评审会，本质上是把风险往后推，推到执行阶段由团队承担。

很多管理者担心提高把关标准会打击业务方积极性。我的实际观察恰恰相反：明确被拒绝的项目，业务方半年内重新提报的比例明显上升，因为他们知道要补什么材料、要找谁背书，而不是无休止地卡在模糊状态里。

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

同一套机制不能直接照搬到所有企业。企业规模、监管强度、项目周期长短，都会显著改变立项优先级的做法。下面按四种典型情况给出可执行建议。

1. 50 人以下团队：用一张纸的立项卡，不要建流程

这个规模的企业建复杂流程是自伤。我建议只用一张 A4 的立项卡，包含七个必填项：一句话目标、业务负责人、三情景收益、最坏情况损失、需要几个人几个月、什么情况下停止、多久复盘一次。

审批环节压缩到两级：业务负责人 + 一号位。评审时间控制在 30 分钟内。这个阶段的核心不是流程，是让”停止”这个动作变得正常。

工具上不需要买系统，用共享表格加固定复盘节奏就够了。真正的瓶颈是决策密度，不是信息管理。

2. 100-500 人：建立分级立项流程，按投入额度分层

这个区间是企业最容易出现”流程加重”的阶段。我建议按投入额度分三级：

• 一级（低于年度预算 1%）：部门负责人审批，不需要跨部门评审，但必须登记在统一台账。
• 二级（1%-5%）：走 G1 + G2 两道闸门，需要四维评分卡和资源排期确认。
• 三级（高于 5%）：走完整四道闸门，需要一号位参与 G2 评审。

分级的意义在于把管理成本花在大项目上。我见过一家 200 人的企业，一个 8 万元的小工具采购要走 5 个部门会签，而一个 800 万的平台项目只开了一次会。这是典型的流程错配。

3. 500 人以上：从项目立项升级为项目组合治理

到这个规模，单项目立项的正确性已经不足以保证整体回报，必须引入组合视角。核心动作有三个：建立季度组合评审、设定组合层面的资源容量上限、维护一张跨项目依赖图。

组合层面的三条硬约束我建议写进制度：任何时刻在建项目数量不超过关键角色数量；任何单一业务方向占用的研发资源不超过总容量的 40%；任何季度的新立项总预算不超过当季可用预算的 70%，保留 30% 应对变化。

这个阶段，跨项目依赖的可视化基本靠人工表格已经撑不住了。中大型企业更需要在支持私有化部署、支持从 Jira 平滑迁移的项目管理平台上做这件事，把立项、里程碑、资源排期、风险登记放在同一套数据模型里，否则组合评审会变成各部门报数的会议。

4. 强监管与长周期行业：把合规时限和供应链纳入评分

金融、医疗、汽车、能源这类行业，立项优先级的第一约束往往不是收益，而是监管时限和资质门槛。这类企业的评分卡需要做两处调整。

第一，把”监管时限”设为一票否决项而非评分项。有硬性截止时间的合规改造项目，不参与常规排序，直接进入强制队列。

第二，加快长周期项目的暴露时长权重。硬件研发、产线改造、基建类项目的失败影响会持续数年，我建议在这类项目里把暴露时长作为独立评分维度，或者直接用于调整风险敞口系数，而不是只算一个静态的财务回收期。

下面这张图是我给不同类型企业建议的立项决策周期的参考基准，用于判断自己的流程是偏快还是偏慢。

七、不同情况下的取舍：没有全都想要的立项机制

做立项机制设计，本质上是做取舍。下面四组取舍是我在实际推动时反复遇到的，我把判断依据写清楚，你在自己企业里可以直接对照。

1. 速度 vs 严谨：先用额度分层，不要一刀切

所有项目都走完整流程，结果是重要项目被拖慢、小项目被过度管理；所有项目都走轻流程，结果是重大项目风险失控。

我的取舍原则是：严谨程度跟不可逆程度挂钩，而不是跟金额单一挂钩。一个 50 万的合同签约类项目，如果涉及对外长期承诺，可能比一个 500 万的内部系统改造更需要严格评审。所以分级标准里一定要加一条”是否产生不可逆承诺”。

2. 集中决策 vs 分布式决策：预算集中，判断分散

集中决策的优点是全局最优，缺点是慢且信息失真；分布式决策的优点是快且贴近业务，缺点是容易重复投入和资源内耗。

我推荐的组合是：预算与关键资源集中审批，技术方案与范围判断分散决策。也就是说，资源容量由公司统一分配，具体怎么做、做到什么程度，由业务和技术团队自己定。这个组合能同时保住组合视角和执行效率。

3. 流程工具化 vs 继续用表格：看跨项目依赖的数量

判断标准很具体：如果你们同时在跑的项目超过 15 个，或者关键角色需要同时服务 3 个以上项目，表格就撑不住了。因为依赖关系是 N 平方级增长，人工维护必然出错。

工具化不只是为了记录，更是为了让资源冲突在立项阶段就可见。这一点用表格几乎做不到，因为冲突需要跨项目对比同一时间窗内的同一角色占用，人工核对成本极高。

4. 砍项目 vs 保团队：先保人，再换方向

这是最难的取舍。我的经验是：终止项目时优先保团队，优先换方向，最后才考虑减员。原因很实际，一个已经磨合好的团队是稀缺资产，而一个被砍掉的项目留下的最大遗憾往往是团队被拆散。

具体做法是给终止项目设置”移交期”，在两到四周内把这批人重新分配到已立项项目或预研方向上，而不是立即释放到人力池。

还有一个容易被忽略的取舍：机制建设本身的投入 vs 收益。很多管理者担心建流程会拖慢业务，我给出一个我实际测算过的量级作为参考：一家 600 人企业，四道闸门 + 评分卡 + 组合视图的初次建设投入约 40 人天，加上平台部署与迁移约 25 人天，合计约 65 人天；而同期因减少无效立项节省的投入约 1400 人天。

八、下一步怎么做：30 天落地清单

如果你读到这里觉得有道理，但不知道从哪儿开始，我建议用 30 天做一个小范围试点，不要一次性推翻现有流程。下面是我实际用过的落地节奏。

1. 第一周：把过去一年的立项数据翻出来

具体动作是拉一张表，列出过去 12 个月所有立项项目，字段包括：立项时间、动机分类、评审耗时、预算、实际投入、是否按期、是否产生预期收益、是否中途终止。

这张表不用很精确，但一定要有。没有基准数据，后面所有改进都无法证明有效，也无法说服团队。

2. 第二周：建立最小可用的评分卡和一票否决清单

先不要设计复杂的权重体系，用本文的四维评分卡直接起步，权重就用 25/35/25/15。一票否决清单先用五条，跑两个月再调整。

同时把”终止条款”写进立项模板，这是投入产出比最高的一个动作，几乎零成本，但能立刻改变项目的生存逻辑。

3. 第三周：选一条产品线试点四道闸门

试点范围不要大，一条产品线或一个事业部就够。关键是让每道闸门有明确的产出物、负责人和时限，并记录每一道闸门的耗时和退回原因。

这一周你大概率会发现两个问题：一是材料准备时间远超预期，二是没人愿意承担退回的责任。这两个问题都是正常的，需要在试点中调整。

4. 第四周：把闸门搬进系统，建立组合视图

这一步是把流程固化的关键。评审通过后如果还靠邮件和表格跟，一个月内流程一定会退化。中大型企业在这个阶段建议直接选择支持私有化部署、支持从既有工具平滑迁移的项目管理平台，把立项、资源排期、依赖关系和风险登记放在同一套数据里。

这里有个实操细节：迁移前一定要做数据清理，把无效的历史数据归档而不是搬过来。我当时在这家 600 人企业做迁移时，把两年以上无关联的 issue 全部归档不迁移，结果迁移后的项目结构比迁移前清晰得多。

5. 常见追问

（1）立项机制会不会让公司变慢，错过市场机会？

会慢，但慢在正确的地方。四道闸门的总时长如果控制在 21 个工作日以内，对绝大多数项目不构成机会损失。真正让公司错过机会的，是同时开工 20 个项目却一个都交不出来。

如果确实遇到窗口极短的机会，正确做法是走”快速通道”：由一号位授权，跳过 G1，直接进入 G2，但必须在 30 天内补齐论证材料，否则预算自动冻结。让例外有明确路径，比让所有人偷偷绕过流程要好得多。

（2）小公司只有十几个人，需要这套东西吗？

不需要完整的四道闸门，但需要其中两样：一是三情景测算，二是终止条款。这两样加起来不超过一页纸，成本极低，但能避免最常见的一类错误，把乐观预测当基准，然后一路做到没钱。

（3）立项评分卡用了一段时间就不准了怎么办？

评分卡失准通常不是权重问题，而是数据来源问题。我的建议是每季度做一次回溯：拿 10 个已交付项目，对比当初的评分和实际结果，看哪个维度的预测偏差最大，然后只调整那一个维度的评分标准，不要动整体结构。

频繁调整权重会让评分卡失去公信力。评分卡的价值在于被反复使用并形成组织记忆，而不是在于数学上最优。

（4）如何判断一个立项机制是否真的在起作用？

看三个数：立项通过率是否低于 80%、主动终止项目数是否大于零、按期交付率是否在六个季度内持续上升。三个数同时成立，说明机制在起作用。如果立项通过率始终 95% 以上，那基本可以确定机制还没开始工作。

6. 最后的建议

回到开头那家装备制造企业。他们后来做了一件很简单的事：把立项评审的时间从平均 15 分钟延长到 90 分钟，并且在评审会上强制留出 20 分钟专门讨论”这个项目什么情况下应该停”。

第二年他们的项目数量减少了 40%，但按原始论证交付价值的项目从 11 个变成 23 个，接近翻倍。立项优先级这件事，做的不是排序，而是把有限的资源押在那些经得起追问的项目上，并且敢于在错误的路上早点停下来。

如果你只打算从这篇文章里带走一件事，我希望是这一件：在下一次立项评审会上，先别急着排优先级，先问一句”如果我们不做这个，会发生什么”。能干脆回答这个问题的项目，通常值得优先做；答不上来的，大概率不该现在做。