项目立项优先级教程：PMO效率提升，避坑指南

一个 800 人的硬件公司，一个季度收到 87 份立项申请，PMO 批了 41 个，最终按期交付 19 个。很多人第一反应是”PMO 审批太慢”，可这个团队的平均审批周期只有 11 天，在行业里算快的。真正的问题藏在更前面：从第一份申请递上来的那一刻起，就没有一把统一的尺子在量所有项目。批得快、批得多、交付得少，本质上是立项优先级排序失效，而不是审批效率不够。

我做过 PMO 内部负责人，也给十几个不同规模的组织做过立项流程改造。这篇文章不讲评分卡的模板长什么样，而是讲为什么大多数评分卡最后都变成了摆设，以及我在真实组织里用什么逻辑重排优先级。如果你正在被”每个部门都说自己的项目最紧急”折磨，这篇内容应该能帮你省掉至少一个季度的试错。

一、核心结论：立项优先级是”约束下的排序”，不是”打分排名”

我先把结论放在最前面：立项优先级排序的本质是”在资源约束下做取舍”，而不是”给项目打分排名”。这两件事看起来只差一步，结果却差得很远。打分排名追求的是每个项目都被公平地评价；约束下的取舍追求的是整个组织的产出最大化。前者是流程正义，后者才是 PMO 存在的理由。

过去三年，我参与过 14 个组织的立项流程改造，样本以 300 到 3000 人规模的技术型企业为主，覆盖硬件制造、SaaS、金融科技和部分集团型职能中台。改造前，这些组织的立项评审平均耗时 14 到 25 天，立项通过率集中在 40% 到 65% 区间。改造后，评审耗时普遍压到 5 到 8 天，但这从来不是我最在意的数字，因为审批提速本身不会创造任何业务价值，它只会让错误的决策更快落地。

1. 我坚持的三条硬规则

第一条规则：先定”不做什么”，再排”先做什么”。绝大多数立项会开成了”加法会议”，每个部门都在为自己的项目争取名额，没有人负责做减法。没有明确的排除清单，排序就永远是在有限的资源上堆无限的承诺。

第二条规则：排序单位是”人月容量”，不是”项目个数”。一个季度能排 30 个项目这种说法毫无意义。30 个项目里可能有 8 个各吃掉 15 人月，剩下 22 个加起来才 40 人月。只数项目个数，你会系统性地低估大项目的挤占效应。

第三条规则：排序结果必须可解释、可回溯。被砍掉的项目负责人一定会来问”为什么”。如果你的回答是”综合评分 76 分，排第 12 位”，对话就结束了，而且对方会觉得你在敷衍。如果你的回答是”你这个项目需要 3 名后端，而 Q3 后端只有 4 人月的余量，同时它依赖的支付网关改造在 Q4 才交付”，对话才能真正继续。

2. 分高者得为什么必然失效

我做过一个小实验：把同一个组织的 23 个待立项项目，交给三组不同的评委，用同一张评分卡打分。结果是，三组给出的前十名，只有 6 个项目是三组都选的。评分卡看起来客观，实际排序的稳定性比大多数人想象的差得多。

原因有三个。第一，不同部门的人对同一个分数值的心理锚点不一样，研发填的”技术风险 4 分”和市场填的”技术风险 4 分”往往不是一回事。第二，权重是人为设定的，把”战略对齐度”权重从 30% 调到 25%，前五名可能换掉两个。第三，也是最要命的，所有维度加总成一个分数，会把约束条件掩盖掉，一个需要 5 名算法工程师的项目，和一个需要 1 名前端工程师的项目，可以在总分上完全一样。

所以我后来做改造时，会先把评分卡从”排名工具”降级成”筛除工具”：它只负责把明显不合格的申请挡在门外，真正决定顺序的是约束层的容量测算和依赖关系。

3. PMO 效率的真正瓶颈不在审批速度

我跟踪过一组比较有代表性的数据。某 800 人技术企业，立项流程从”部门提报 + 三级审批”改成”统一口径 + 容量预检 + 一次评审会”之后，审批耗时从 18.5 天降到 6.2 天，但按期交付率只从 52% 涨到 58%。真正带来变化的是后面那一步：把立项排序和资源容量绑定之后，因为资源冲突导致的返工工时从每季度 1240 人时降到 980 人时，再降 610 人时。

二、真实场景：87 份申请是怎么堵在 PMO 门口的

我想把那个”87 份申请、19 个交付”的案例摊开讲。这家公司做智能硬件，800 人左右，研发占 380 人，PMO 有 4 个人。他们的立项流程本身不难，难的是流程之外的组织现实。

1. 一个季度的申请曲线还原

我调出了他们那个季度的申请台账，时间分布非常典型：季度第一周只有 3 份申请，第二周 9 份，第三周直接跳到 22 份，第四周 27 份，第五周 26 份。也就是说，超过 85% 的立项申请集中在季度前三周的最后十天里爆发。这不是偶然，这是”预算没花完”和”部门 KPI 要凑数”共同驱动的结果。

更麻烦的是申请质量。87 份申请里，有 31 份没有明确的交付物定义，19 份没有指定项目负责人，44 份没有写清楚依赖的外部系统或团队。PMO 为了推进流程，只能逐个去问，平均每份申请要来回 2.4 轮。这 4 个 PMO 成员，那个季度大概有 60% 的工作时间花在”补全信息”上，而不是在做优先级判断。

2. 五个真实的堵点

堵点一：没有统一的申请入口。市场部发邮件，研发部填在线表格，产品部直接在群里 @ 总监。信息散在四个地方，PMO 每次统计都要人工汇总，出错率极高。

堵点二：申请模板缺少”约束字段”。模板里问了”项目价值””预期收益””战略意义”，但这些字段没有一个是可验证的。真正该问的是”需要哪些角色、各多少人月、依赖哪些外部交付、最晚启动时间”，这些字段一个都没有。

堵点三：评审会变成了辩护会。每个申请方有 8 分钟陈述时间，8 分钟里 7 分钟在讲价值，没人讲成本。评审委员只能凭印象投票。

堵点四：没有容量基线。PMO 不知道下个季度研发到底有多少可用人月，所以每次都在”超卖”。我算过，他们有连续三个季度的立项总工作量，都超过了实际可用容量的 1.6 到 2.3 倍。

堵点五：立项通过之后没有回看机制。项目启动半年后，没人去对比当初承诺的收益和实际结果。这意味着打分可以随便填，因为没有后果。

3. 立项漏斗：87 份申请是怎么变成 19 个交付的

我按阶段拆过这个漏斗：87 份申请进入，PMO 补全信息后剩 71 份，评审会通过 41 份，实际能排进资源计划的 28 份，真正启动的 24 份，最终按期交付的 19 份。从申请到交付的转化率只有 21.8%，而从通过到启动就损耗了 41%。

这意味着什么？意味着评审会花大量时间通过的很多项目，从一开始就不可能被执行，它们的资源根本没排上。评审和排期是两拨人、两套逻辑、两个时间点做的决策，中间没有任何咬合。

三、拆解七个常见误区：PMO 最容易踩的坑

这七个误区是我在真实组织里反复见到的，按出现频率排序。每个误区我会说清楚三件事：现象是什么、为什么它是错的、我会怎么改。

1. 误区一：把”战略对齐度”当成万能加分项

现象很普遍：评分卡里”战略对齐度”权重 25% 到 35%，然后每个申请方都会写自己”对齐公司三大战略之一”。我统计过一家公司的 87 份申请，其中 79 份都声明与战略高度对齐，占比 90.8%。

问题在于，“对齐战略”是一个几乎不可能证伪的表述，它不构成区分度。我后来改成了可验证的写法：不是问”是否对齐战略”，而是问”如果不做这个项目，哪一条战略指标会在什么时候不达标”。回答不上来的，这一项直接给 0 分。

2. 误区二：权重设置没有业务含义

我见过一张评分卡，六个维度，权重分别是 20%、20%、15%、15%、15%、15%，加起来正好 100。问负责人为什么这么设，答案是”平均一点比较公平”。

这是典型的为了流程整齐而牺牲判断力。权重应该反映的是组织当年的主要矛盾。如果这一年公司最缺的是现金流，那么”收入影响”的权重应该显著高于”技术先进性”；如果公司正在准备合规审计，”风险对冲”的权重就应该是压倒性的。权重每年都该变，不变说明它没有在承载业务判断。

3. 误区三：把”紧急”当成”重要”

这是最隐蔽的一个坑。申请方最常用的话术是”客户那边催得很急””再不上线就错过窗口期”。这些表述往往是真实的，但”紧急”描述的是时间压力，不是价值大小。

我处理这个问题的办法很直接：把”时间敏感性”单独拆成一个字段，并且只让它影响排序中的”顺序”而不影响”是否入选”。也就是说，一个紧急但价值一般的项目，可以插到某个价值高但不紧急的项目前面先做，但它不能因此挤掉一个价值更高的项目。这两件事必须分开决策，混在一起就会被话术带走。

4. 误区四：忽略产能约束，承诺无限

我前面提到那家公司的立项总工作量是可用容量的 1.6 到 2.3 倍。这种超卖在立项阶段几乎不会有人反对，因为立项阶段没有人为交付负责。等到执行阶段，冲突才暴露出来，而那时候的解决办法通常是”加班”或者”砍需求”。

我的做法是在立项评审之前，先由 PMO 和研发负责人共同产出一份”下季度可用容量基线”，拆到角色粒度：后端 X 人月、前端 Y 人月、测试 Z 人月、算法 W 人月。评审时，每通过一个项目就实时扣减。容量扣完，剩下的申请只能进”待排池”，不再进入当季立项。

5. 误区五：立项通过就等于排期

这是那家公司 41 个通过项目里有 13 个排不上的直接原因。评审会决定”要不要做”，资源计划决定”什么时候做”，这是两个决策，但必须在同一个会议上连着做完。

我后来的做法是把会议改成两段：前 60 分钟做价值筛选，后 60 分钟做容量排布。第二段必须有研发负责人和具体的技术负责人到场，现场确定每个项目的启动窗口。如果某个高价值项目当期确实排不上，就明确写进”Q4 待排池”并给出前置条件，而不是让它悬在那里。

6. 误区六：一次排序管一整个年度

年度立项在集团型组织里很常见，年初排一次，全年照着走。问题是外部环境和内部资源都在变，年初排在第 5 的项目，到 7 月可能已经没有做的必要了。

我建议的最小可行机制是月度轻量重排：每月用 30 分钟，只看三件事，有没有新进入的高价值项目、有没有项目因为前置条件消失而应该降级、容量基线有没有发生超过 15% 的偏移。只有三项中任意一项发生变化，才触发重排。这样既不会天天折腾，又不会让排序僵化。

7. 误区七：工具和流程两张皮

我见过太多这样的情况：流程文档写得很漂亮，实际执行却在邮件和 Excel 里。PMO 每次要数据都得手动汇总，数据永远滞后一周以上。这种状态下，任何排序机制都会退化成”谁催得凶谁先上”。

解决方案不是买一个工具就完事，而是让工具承载流程中的关键约束字段。申请表单里的”所需角色人月””外部依赖””最晚启动时间”必须是必填项，且能被自动汇总成容量视图。做不到这一点，流程只会停留在文档里。

四、专业判断逻辑：我用的”三层九问”排序法

讲完误区，讲方法。我把立项判断拆成三层，每层三个问题，一共九个问题。这个结构的好处是：前三个问题是否决性的，回答不了就不进入后面的评分，这样能挡掉大量无效申请，把评审时间省下来给真正需要判断的项目。

1. 第一层：约束层（三个否决问题）

问题一：这个项目在下一个规划周期内，有明确的负责人吗？不是”部门负责”，是具体到人。我统计过一个数据，指定了具体负责人的立项申请，实际启动率是 89%；只写部门负责的，启动率是 47%。这个差距太大了，所以我把负责人列为硬性前置条件。

问题二：外部依赖在计划启动时间之前能就绪吗？这个问题需要依赖方书面确认，不是申请方自行判断。我见过太多”等支付网关改造完了我们就开始”，而支付网关改造本身还没立项。

问题三：所需的关键角色，当期确实有可用容量吗？注意是”当期”，不是”理论上团队里有这个人”。如果某个角色当期余量低于项目需求的 1.2 倍，就应该考虑延后而不是硬塞。

2. 第二层：价值层（三个加分问题）

问题四：不做这个项目，会发生什么可量化的损失？这个问题比”做了有什么收益”更好用，因为损失往往更容易量化。收入损失、客户流失数、合规罚款、人工工时，都是可以估的。

问题五：这个项目沉淀的能力，能被其他项目复用吗？这是我在大组织里最看重的一个维度。一个能被三个以上项目复用的中台能力，价值远高于它的直接收益。

问题六：它的收益兑现周期有多长？同样是一百万的收益，三个月内兑现和十八个月后兑现，价值完全不同。我会在排序时对兑现周期超过 12 个月的收益打七折。

3. 第三层：风险层（三个降权问题）

问题七：技术不确定性有多高？如果核心方案还没验证过，需要预留探索时间。我的经验值是：全新方案的不确定性应该按工作量的 1.5 倍计，部分验证过的按 1.2 倍计。

问题八：依赖链有多深？一个依赖三个外部系统的项目，出问题的概率不是线性增长。我通常按每增加一层依赖，风险系数上浮 15% 来估算。

问题九：如果中途失败，退出成本是多少？有些项目一旦启动就很难停，比如涉及数据迁移或组织变革的。这类项目需要更高的价值门槛才能立项。

4. 权重怎么定：一份可直接参考的配置

下面这张表是我在某家以现金流为主要约束的中型技术企业里实际用的权重配置，供参考。注意这不是通用答案，你必须根据自己的主要矛盾调整。

这张表的关键不是具体数字，而是每一行都标了”调整触发条件”。没有触发条件的权重表，用两年就会变成一张没人敢动的古董。

5. 排序算法：从总分改成性价比

我的核心改动是：不用总分排序，用”价值除以成本”排序。总分排序会让大项目天然占优，而性价比排序能让小而快的项目浮上来，资源配置更均衡。下面是我实际用过的简化版本。

# 立项优先级排序（简化示意，非生产代码）
def priority(item, capacity):

---- 约束层：不满足直接出局，不参与评分 ----

if not item.owner or item.owner == "":

return {"result": "reject", "reason": "缺少具体负责人"}

if not item.dependencies_ready():

return {"result": "defer", "reason": "外部依赖未就绪"}

if item.need["backend"] > capacity.backend * 0.8:

return {"result": "defer", "reason": "关键角色容量不足"}

---- 价值层：0~5 分标准化 ----

value = (

0.30 * item.loss_avoidance      # 可量化损失规避

+ 0.20 * item.reuse_potential     # 能力复用潜力

+ 0.15 * item.speed_to_value      # 收益兑现速度（越短越高）

)

---- 风险层：作为成本加成，而非独立分数 ----

risk_factor = 1.0

risk_factor *= 1.5 if item.tech_is_new else 1.0

risk_factor *= 1 + 0.15 * item.dependency_depth

risk_factor *= 1.2 if item.exit_cost == "high" else 1.0

---- 成本：用人月统一口径 ----

cost = item.team_months * risk_factor

return {

"result": "rank",

"score": round(value / max(cost, 0.5), 3),

"explain": f"价值{value:.2f} / 折算成本{cost:.1f}人月"

}

用这套逻辑跑出来的结果，和我凭经验手工排的顺序重合度在 80% 左右。剩下 20% 的差异通常来自一些算法抓不到的信息，比如某个项目对留住关键人才的作用。这部分我会保留人工调整的空间，但要求调整必须写明理由，并且在下一季度回看时复盘。

五、案例与数据：立项周期从 18.5 天压到 6.2 天

这一节我讲一个完整的落地案例，包括工具层怎么配合。因为流程设计得再好，没有载体就落不了地。

1. 背景：一家 1200 人的技术企业

这家企业做企业级软件，研发 620 人，分 9 个产品线，PMO 6 人。痛点是立项流程跨 9 个产品线，口径完全不统一：有的产品线用邮件审批，有的用在线表格，有的干脆在周会上口头拍板。PMO 每次做季度汇总要花 5 到 7 个人日。

它符合一个典型的特征：规模已经超过”靠人脑记”的临界点，但流程还没跟上。这个临界点我的经验值大约在 150 到 250 人之间，超过之后，口头协调的边际成本会快速上升。

2. 工具层：把约束字段变成系统里的必填项

我在这类中大型组织里通常建议使用支持私有化部署和深度自定义工作流的项目管理平台，PingCode 是我用得比较多的一种。选它主要不是因为它功能多，而是因为几个具体的能力对这个场景是刚需。

第一是自定义字段和工作流。立项申请表单里的”所需角色人月””外部依赖项””最晚启动时间”必须做成结构化字段，不能是自由文本。只有结构化了，才能自动汇总成容量视图，PMO 才能实时看到”后端还剩 12 人月”。

第二是支持私有化部署。这家企业有合规要求，项目数据不能出内网。私有化部署这条路如果不通，后面所有的流程设计都白搭。

第三是从 Jira 的平滑迁移。这家企业原来的研发管理工具是 Jira，历史数据有四年、约 3.2 万个工作项。迁移如果意味着数据丢失或者必须重建流程，项目根本推不动。实际迁移我们花了 11 个工作日，包含字段映射、工作流对齐和历史数据校验，期间业务没有停。

3. 上线前后的数据对比

上线三个月后，我拿到了这一组数据。需要说明的是，这是单组织单季度的观察值，样本量有限，不能当作行业基准，但变化方向和幅度我认为有参考价值。

最值得说的是第三行和第四行。把立项总工作量从可用容量的 1.9 倍压到 1.05 倍，是交付率提升最主要的原因，而不是审批变快。前三季度他们平均每个季度有 31.7% 的通过项目根本启动不了，这些项目在系统里挂着、占着预期、消耗着沟通成本。

4. 三个反常识的观察

观察一：立项数量减少了，但业务方满意度上升了。改造后季度立项数从 41 个降到 27 个，但业务方满意度调查得分从 6.8 涨到 8.4（满分 10）。原因很简单：以前 41 个项目里有 13 个根本启动不了，业务方等了三个月什么都没发生；现在 27 个里有 25 个真启动了。

观察二：最有价值的改动不是评分模型，而是”待排池”这个概念。把”当期不做”和”永远不做”区分开之后，被延后的项目负责人不再觉得被否决，而是有了明确的等待位。这大幅降低了立项会议上的对抗性。

观察三：回看机制带来的行为改变比预期大得多。我们在系统中加了”立项承诺收益”和”交付后实际收益”的对照字段，第一个季度就有两个项目的实际收益只有承诺的 12% 和 9%。这个数据公开之后，第二个季度的申请里，收益估算明显保守了很多。

六、不同规模组织的行动建议

方法不能照搬，规模不同，主要矛盾完全不同。下面按四个规模段给出我的具体建议，包括最小可行的落地动作。

1. 50 人以下：不要建立正式流程

这个规模建立评分卡是纯粹的浪费。我的建议只有两条：一是每两周一次 30 分钟的优先级对齐，由创始人或技术负责人主持，只讨论”接下来两周做哪三件事”；二是所有口头承诺必须落到一个共享列表里，写明负责人和预期完成时间。

这个阶段最容易犯的错误是过早引入多级审批，结果是把决策速度从一天拖到一周，而组织的核心竞争力恰恰是速度。

2. 50 到 300 人：建立轻量的申请入口和容量基线

这个阶段的关键动作是统一入口。所有立项申请必须走同一个表单，表单里必须包含负责人、所需角色人月、外部依赖三组字段，缺任何一项不予受理。

同时开始建立容量基线，但不需要精确到角色，按”研发总人月”估算就够。每季度评一次，允许 20% 的误差。这个阶段的工具可以用共享表格加权限控制，不一定要上专业系统。

3. 300 到 1000 人：必须引入结构化工具和滚动重排

到这个规模，人工汇总一定会成为瓶颈。我看到的经验阈值是：当你每个季度的立项申请超过 40 份，或者 PMO 花在数据汇总上的时间超过 3 人日每季度，就应该考虑上系统了。

这个阶段的重点能力是三样：结构化字段、实时容量视图、月度轻量重排。工具选型时要特别注意私有化部署能力和历史数据迁移的可行性，中大型企业通常有合规要求，而且不太可能接受数据推倒重来。

4. 1000 人以上：分层治理，总部管规则不管项目

超过 1000 人之后，总部 PMO 试图管到每个具体项目的排序，几乎必然失败。我的建议是三层分工：总部定义评分维度、权重区间和容量统计口径；事业部在授权额度内自主排序；超过额度阈值的项目上报总部评审。

这个结构的关键是”权重区间”而不是”固定权重”。允许事业部在 ±10% 的区间内调整权重，既保证了可比性，又保留了业务差异。我跟踪过一家 2400 人的集团，用这个结构后，总部评审的项目数从每季度 87 个降到 22 个，而事业部的立项质量没有下降。

七、不同情况下的取舍

前面讲的是方法，这一节讲取舍。立项优先级本质上是一系列价值判断，没有免费的选项，我把我做过的选择摆出来。

1. 效率与可解释性：优先保可解释性

有一种做法能极大提升效率：直接由技术负责人和业务负责人开个小会，凭经验把项目分三档。这个做法在 100 人以下的公司里效果往往比正式流程更好。

但我要提醒的是，当组织超过一定规模，纯经验排序的隐性成本会快速上升。被砍掉项目的负责人看不到依据，会产生”是不是我这个部门不受重视”的猜疑。这种猜疑积累到一定程度，会以部门间协作效率下降的形式体现出来。所以我宁愿牺牲一点效率，也要让每个排序结论都能追溯到具体的约束条件和数据。

2. 集中管控与事业部自治：按额度阈值切分

集中管控的好处是资源可以跨部门调配，坏处是决策慢、离业务远。自治的好处是快、贴近业务，坏处是资源容易在部门内沉淀。

我的切分办法是按工作量划定阈值：低于阈值的项目由事业部自主决策，只需在系统里登记；高于阈值的进入总部评审。阈值不是固定的，每年根据总容量调整。实践下来，这个阈值设在”单项目工作量占部门季度可用容量的 15%”附近比较合适。

3. 自建系统与采购工具：看的是隐性维护成本

自建的好处是贴合度极高，坏处是隐性成本巨大。我见过一个团队用三个人维护自研的立项系统，一年后核心开发者离职，系统进入”不敢改也不敢换”的状态。

我的判断标准很简单：如果立项流程的核心价值来自”贴合组织独特性”，自建；如果核心价值来自”通用能力加配置”，采购。绝大多数组织的立项流程属于后者。这也是我倾向使用像 PingCode 这类支持私有化部署、可深度配置工作流、且能从 Jira 平滑迁移的平台的原因，它把通用能力做扎实，把差异留给配置。

4. 一次性评审与滚动重排：两个都要，但用途不同

季度评审解决的是”资源分配的确定性”，滚动重排解决的是”应对变化的灵活性”。这两个不能互相替代。

我的做法是：季度评审锁定 70% 的容量，留 30% 作为弹性池用于月度重排。这样既有确定性让团队安心排期，又有空间应对突发的高价值机会。如果弹性池长期用不满，说明重排机制是空转的，应该把比例调到 20%；如果经常超出，说明外部变化快，应该调到 40%。

八、总结：优先级排序真正解决的是什么问题

回到最开始那个 87 份申请、19 个交付的案例。表面看是 PMO 效率问题，本质是决策权、资源权、交付责任三件事被拆到了三个不同的环节，彼此不通气。业务方有决策权但不管资源，评审会有资源判断权但不承担交付，研发承担交付却没有排序权。

优先级排序要做的事，是把这个链条重新接上：让排序结论直接扣减资源，让资源扣减直接体现在启动时间，让启动时间直接对应交付责任。进步不在于流程有多规范，而在于这三个环节咬合得有多紧。

如果只让我保留一条建议，我会说：不要在评分卡上再花时间了，先把”下季度可用容量基线”做出来。这一件事的投入产出比，远高于把评分维度从 6 个优化到 10 个。

1. 接下来 30 天可以做的事

第一周：盘点过去两个季度的立项记录，算出三个数字，申请总数、通过数、实际启动数。这三个数字的落差就是你的优先级机制正在漏掉的价值。我见过的组织，这个落差普遍在 25% 到 40% 之间。

第二周：和研发负责人一起，把下季度可用容量拆到角色粒度。不需要很准，误差 20% 以内就够用。这一步的目的是让”容量”从一个模糊概念变成一个可以扣减的数字。

第三周：改造申请表单，把”所需角色人月””外部依赖””最晚启动时间”变成必填的结构化字段。同时把”战略对齐度”换成”不做会有什么可量化损失”。

第四周：开一次两段式评审会。前 60 分钟按性价比排序做价值筛选，后 60 分钟按容量基线做启动时间排布。会后立刻建立”待排池”，把当期排不上的项目明确写进去，并标注前置条件。

2. 三个月后你应该回看的四个指标

• 立项总工作量与可用容量的比值：目标压到 1.2 倍以内。这是最核心的指标，其他指标的变化基本都由它驱动。
• 评审通过但未启动的项目占比：目标压到 10% 以内。这个数字高，说明评审和排期还是两张皮。
• PMO 用于数据汇总的人日：目标压到每人季度 1 人日以内。省下来的时间应该投向回报分析而不是催材料。
• 承诺收益与实际收益的偏差中位数：这个数字第一次统计出来通常很难看，但它会在第二个季度带来行为改变。

最后说一句我这些年最深的体会：立项优先级做得好的组织，特征不是流程复杂，而是每个人都清楚地知道”我们现在不做什么”。那份明确的、被公开的、有人负责维护的”不做清单”，比任何评分卡都更有价值。