优先级实操方法：PMO提升项目立项效率的制度设计方法与模板

我做 PMO 的第 4 年，才真正承认一件事：立项效率低，几乎从来不是缺一张评分表。2021 年我接手一家 200 人规模的 B 端软件公司 PMO，那一年他们提了 386 个立项申请，开了 47 次立项评审会，最终立项 118 个，真正交付上线的 61 个，其中 23 个在半年内被业务方自己叫停。会后我复盘了一次，47 次评审会累计占用约 141 小时，按参会管理层的平均人力成本折算，接近 26 万元，而真正决定这 118 个项目排序的，其实只是其中 11 次会里反复出现的那几句话。

第二年，我们把”优先级”从会议室搬进了制度文件。立项申请数量没有下降，评审会降到 9 次，立项 74 个，交付 68 个，半年内被叫停的只有 4 个。这篇文章讲的就是这中间到底改了什么：一套 PMO 可以直接改名使用的优先级制度设计方法，以及配套的评分卡、授权矩阵、评审纪要和退出复盘模板。

（说明：文中涉及的比值、耗时、成本为脱敏后的样本推演数据，用于说明量级差异，不作为行业统计口径。）

一、核心结论：优先级不是排序技巧，而是立项决策制度

先把结论放在最前面，方便你判断这篇文章值不值得往下读。我的核心判断有三条，每一条都和主流做法有偏差。

第一，立项效率的瓶颈在”入口”和”出口”，不在”排序”。大多数 PMO 把精力花在中间的排序算法上，权重怎么设、阈值怎么定、打分要不要去极值。但只要入口没有准入标准，什么需求都能进池子；出口没有退出机制，什么项目都不能停，排序再精确也只是在给一条注定拥堵的管道做美容。

第二，”优先级”必须是一份制度文件，而不是一次会议共识。会议共识的特点是只在会议室内有效，散会后自动失效，换个人主持就换一套逻辑。制度文件的特点是写清算什么、谁算、算到什么程度触发什么动作，且不依赖任何特定个人在场。

第三，制度设计的最小可用集只有四个组件：准入闸门、分级授权、动态排序、退出复盘。缺任何一个，这套制度都会在半年内退化回”领导拍板”。这四个组件不是并列关系，而是串联关系，顺序错了效果会打对折。

1. 为什么”打分模型”单独存在时一定会失效

我把打分模型失效的原因归结为三个结构性缺陷，它们和权重设得好不好无关。

• 打分的输入不可验证。业务方填”预计年收益 800 万”，PMO 没有能力也没有立场去核验这个数。当输入是自证式的时候，打分就变成了比谁更会写材料。
• 打分没有对应的资源约束。如果池子里有 40 个项目都打了 4 分以上，而季度只能做 6 个，那么分数只完成了”分类”，没有完成”排序”。分类和排序是两件事。
• 打分结果没有动作绑定。如果打完分之后不立项、不排期、不拒绝都没有后果，那么被低分评价的项目会一直躺在池子里，池子只进不出。

2. 四个组件分别解决什么问题

下面这张表是我在做 PMO 诊断时最常用的对照表。你可以拿它对着自己组织的现状打勾，缺哪一项，后面的整改优先级就最高。

3. 一句话判断你的组织是否已经具备”制度”

我常用的判断句是：如果你请假两周，立项决策会不会停摆？如果答案是”会”，那你拥有的是会议机制，不是制度。制度的标准是：一个完全不了解历史背景的新人，拿着文件也能做出与前任 80% 一致的决定。

二、真实场景：三种立项现场，对应三种失效模式

我做过的 PMO 诊断里，立项失效几乎都能归到三种典型现场。它们的表象不同，但根因都是某一个组件缺失，误判现场类型会导致开错药。

1. 评审会依赖型：所有判断都发生在会议室里

典型画面：每两周一次立项评审会，议程 12 项，每项 8 分钟。前 3 项认真讨论，第 4 项开始有人低头看手机，第 8 项之后基本是”你们业务线先定，我们没意见”。会议结束时主持人问”还有没有补充”，没人说话，全部通过。

根因：缺少准入闸门和分级授权。因为所有项目都要上会，所以单项目的可讨论时间被稀释到 8 分钟；因为缺少授权分级，所以低风险项目也得占用高管的注意力。

我实际观察到的代价：这类组织的决策返工率极高。所谓返工，是指上一次会通过的项目，在下一次会上被要求”再补一下材料”或者”先放一放”。在我统计过的 5 个类似组织里，返工率普遍在 35%-55% 之间。

2. 打分模型装饰型：表格很漂亮，没人看结论

典型画面：PMO 有一份 12 个维度的评分表，Excel 里带着复杂的公式和条件格式。项目提交后由 PMO 打分，生成一张雷达图，附在立项报告最后一页。但最终决定立项与否的，是报告第一页的”项目背景”和汇报人是谁。

根因：打分结果没有和授权、配额、排期绑定。分数只是信息装饰，不构成决策依据。业务方很快学会了这个规则，于是打分材料越写越好，实质判断越来越依赖会议现场。

识别信号：如果你问 PMO”上个季度有多少项目因为分数低于阈值被拒绝”，对方答不上来，基本就是这个模式。

3. 领导点名型：优先级随组织架构波动

典型画面：季度初确定好的路线图，在季度第 3 周被插入一个”老板关注”的项目，原本排在第 4 位的项目顺延。执行团队加班两周，第 8 周又来一个。到季度末，路线图完成率 40%。

根因：缺少”插队成本显性化”的机制。领导点名本身不是问题，问题在于插队不显示代价。当插队的成本被队伍默默吸收时，插队就会持续发生。

我处理这类问题的方法：不阻止插队，但强制要求插队时同步给出”被挤掉的项目名”。这个动作把隐性成本变成显性选择，插队频次通常会自然下降一半以上。

三、常见误区拆解：五个我踩过或看别人踩过的坑

下面五个误区，前两个我亲自踩过，后三个是我在诊断其他组织时反复见到的。它们的共同点是：看上去都在”优化优先级”，实际上都在加固原有的失效结构。

1. 误区一：以为权重调对了，优先级就准了

我 2020 年花了整整两个月调权重。第一版战略权重给 30%，结果所有项目都写”符合公司战略”；改成 20%，业务方又抱怨短平快的项目上不来。最后我意识到：权重的稳定性比准确性重要得多。一套权重连用 4 个季度不改，团队才能学会怎么填；每季度改一次，团队只学会怎么猜。

我现在的做法是：权重一年只调一次，调整依据是过去一年 A 档项目的实际交付价值与预期价值的偏差，而不是业务方的抱怨。

2. 误区二：把 ROI 当成唯一标准

ROI 在小额、短周期、收益可量化的项目上很好用，但它有三个系统性盲区。

• 基础设施类项目永远算不出正 ROI。技术债治理、监控体系、CI 流水线重构，它们的收益是”避免未来的损失”，而不是”产生增量收入”。用 ROI 排序，这类项目永远排最后，直到某天线上事故教会所有人。
• 合规与监管类项目没有选择权。它们不是”要不要做”的问题，是”什么时候必须做完”的问题。把它们放进 ROI 排序，等于给一个没有选项的事做选择题。
• ROI 会随组织政治被美化。一旦 ROI 直接决定资源分配，测算表就会被打扮。我见过最夸张的一个案例，同一个项目在两次评审里的 ROI 相差 4 倍，唯一的变化是换了个汇报人。

3. 误区三：把优先级当成一次性排序

很多 PMO 年初排一次优先级，然后全年不碰。但优先级本质上是资源与机会的匹配状态，两边都在变：资源可能因为人员流动减少，机会可能因为市场变化放大。

我采用的做法是”双周期”：年度定档位（A/B/C/D），季度定顺序。档位一年只调一次，顺序每季度重排一次。这样既保持了稳定性，又保留了响应能力。

4. 误区四：不设”不立项”通道

这是我最想强调的一条。如果一个制度只有”通过”，没有”不通过”，它就不是决策制度，是登记制度。业务方会迅速识别这一点，然后提高提交量、降低提交质量，因为提交成本低而预期收益不为零。

我给每个 PMO 客户的硬性建议是：把”不予立项”写进制度，并配套一份书面反馈模板，说明不立项的理由和复评条件。第一年你会发现不通过率在 30%-45% 之间，这个数字本身就是制度生效的证据。

5. 误区五：评审通过就等于流程结束

立项评审通过只是开始。真正决定一个项目最终价值的，是中期的退出判断。我见过太多项目在”沉没成本”的驱动下被一路推到最后，原因不是没人发现问题，而是没有人被授权叫停。

所以我把”退出复盘”作为四层模型的最后一层，也是建设难度最高的一层。它的难点不在流程设计，而在组织心理：承认一个已经投入 3 个月的项目应该停止，比决定要不要开始一个项目难得多。

四、专业判断逻辑：立项优先级制度的四层模型

这是我目前在用的框架，四个层级按顺序建设，跳层会失败。比如很多组织想直接上第三层的动态排序，但因为第一层准入闸门没建，池子里全是未经验证的需求，排序出来也没人认。

1. 第一层：准入闸门（Gate），决定什么能进池子

闸门的核心不是”打分”，而是”字段完整性校验”。我给闸门设计的规则很简单：申请单中缺少任一项必填字段，系统直接拒收，不进入 PMO 视野。

必填字段我建议控制在 7 项以内，多了团队会造假填充。我实际使用的清单是：业务问题描述、目标用户与影响范围、期望收益及其测算口径、不做的后果、期望上线时间窗口、拟投入资源量级、业务方责任人。注意第 4 项”不做的后果”，这一项能过滤掉相当比例的伪需求。

闸门还需要两个保护规则：（1）一票否决项，例如涉及未脱敏生产数据出境、无法通过合规评审；（2）战略强制通道，例如监管硬性要求、年度战略主题内的必做项，它们跳过排序但必须占用配额，且每季度设上限（我一般设为 2 个）。

2. 第二层：分级授权（Delegation），决定谁有权决定什么

分级授权的判断依据有两个维度：资源量级和不确定性。大多数组织只用第一个维度，结果是把高风险小项目放给了低层级决策者。我的做法是以资源量级为主、不确定性为修正项。

下面的授权矩阵是我在某 200 人组织实际落地并跑通了 6 个季度的版本，你可以直接改数字使用。

两个修正规则很重要：（1）涉及新增外部依赖、跨境数据、核心系统架构变更的项目，无论资源量级，上浮一级决策；（2）复用已有组件、有同类项目历史数据可参照的项目，可下沉一级决策。

3. 第三层：动态排序（Ranking），决定同一层级内谁先做

排序只在同一档位内进行，跨档位不排序。这一点很关键：如果 A 档项目和 C 档项目放在一起排序，A 档永远优先，C 档永远排不上，档位就失去了意义。

排序的实际操作是按”资源余额”滚动：每季度初，各资源池（前端、后端、数据、测试）先扣除已承诺项目占用，剩余额度按档次内部顺序分配。当某个资源池余额不足时，项目顺延到下季度重新参与排序，而不是插队占用别人额度。

4. 第四层：退出复盘（Exit），决定什么必须停

退出机制我用”三个触发点”来设计，避免变成主观判断。

1. 进度触发：项目实际进度落后计划 40% 以上，且原因不是外部依赖，触发退出评估。
2. 价值触发：项目预期的核心收益指标在中期检查中被证伪（例如目标用户不接受、替代方案出现），触发退出评估。
3. 成本触发：累计投入超过初始预算 60%，但完成度不足 40%，触发退出评估。

触发之后不等于立即停止，而是进入一次 30 分钟的退出评估会，输出三个结论之一：继续（并说明为什么原判断仍然成立）、缩减（砍掉部分范围）、停止（并说明资源回收去向）。关键是”继续”必须有理由，”停止”必须有资源去向，这两个要求能显著减少走过场的评估。

5. 五维评分卡：我实际用过的字段与权重

下面是我最终稳定下来的五维模型。它和市面上常见的”战略，价值，成本，风险”四维模型的差别在于：我把”价值可量化度”从”价值”里拆了出来，因为一个价值大但算不清的项目，和一个价值中等但算得清的项目，决策逻辑完全不同。

四档划分：A 档 ≥ 4.0 分进入年度规划池，季度必排；B 档 3.2-3.9 分进入候选池，按季度资源余额排序；C 档 2.5-3.1 分进入观察池，需补齐数据后复评；D 档 < 2.5 分不予立项，书面反馈并记录，进入季度复评名单。

下面这段配置是我在某中大型研发组织的项目管理平台里实际配置过的规则结构，用 YAML 表达，你可以直接改字段名移植到任何支持自定义字段和分级审批的工具里。

# 立项优先级评分卡配置（示例，可直接改字段名）
scoring:

dimensions:

key: strategy_fit

name: 战略契合度

weight: 0.25

scale: [1, 5]

source: 年度战略解码表 / 战略主题编号

key: value_quantifiability

name: 价值可量化度

weight: 0.25

scale: [1, 5]

source: 业务收益测算表（含口径与假设）

key: delivery_certainty

name: 交付确定性

weight: 0.20

scale: [1, 5]

source: 架构评审结论 + 历史同类项目交付偏差

key: resource_availability

name: 资源可得性

weight: 0.15

scale: [1, 5]

source: 资源池排期表 / 可复用组件清单

key: risk_exposure

name: 风险敞口

weight: 0.15

scale: [1, 5]

reverse: true

source: 合规清单 / 数据安全 / 外部依赖表

bands:

grade: A

min_score: 4.0

action: 进入年度规划池，季度必排

grade: B

min_score: 3.2

action: 进入候选池，按季度资源余额排序

grade: C

min_score: 2.5

action: 进入观察池，补齐数据后复评

grade: D

min_score: 0.0

action: 不予立项，书面反馈并记录复评条件

guards:

name: 一票否决

rule: 涉及未脱敏生产数据出境，或无法通过合规评审

effect: 直接置为 D 档，不参与加权计算

name: 战略强制通道

rule: 年度战略主题内必做项，或监管硬性要求

effect: 跳过排序直接进入 A 档配额，每季度上限 2 个

五、案例与数据观察：一套制度在某中大型研发组织的落地过程

这一节我讲一个完整案例，是一家 400 人规模的研发组织（研发人员约 280 人，横跨 6 条产品线），他们的项目管理平台用的是 PingCode。我作为外部顾问参与了从制度设计到工具配置的全过程，时间跨度 12 个月。

1. 背景与约束

这家组织的核心约束有三个：第一，历史数据必须保留，他们此前用 Jira，积累了 5 年以上的需求与缺陷数据，迁移不能丢历史关联；第二，数据不能出内网，因此只能考虑支持私有化部署的方案；第三，立项决策链涉及 4 个层级，需要工具层面支持分级审批，而不是靠邮件和群聊串联。

这三个约束直接决定了工具选型的边界：通用表格工具无法承载分级审批链和历史数据继承，轻量协作工具无法满足私有化部署要求。他们最终选择 PingCode，主要原因是它面向中大型企业及 100 人以上组织设计，支持私有化部署，且支持从 Jira 平滑迁移，对于已经深度使用过海外项目管理平台、又不希望重来一遍数据资产的团队来说，这是国产替代路径里比较省事的一个选择。

2. 制度落地前的三个数据基线

我在启动前做了一次基线测量，用三个指标锚定改进目标。

• 决策周期：从需求提交到给出立项结论的平均耗时 27.5 天，P90 为 51 天。
• 评审会吞吐：双周评审会平均议程 14 项，单项目可讨论时间约 7 分钟。
• 返工率：已通过项目在后续会议中被要求”再补材料”或”先放一放”的比例为 41%。

3. 落地动作：把规则写进工具，而不是写进文档

这是我在这类项目里最坚持的一点：制度只有落到工具里才算生效。放在共享盘里的制度文件，三个月后会变成”我们好像有这么个东西”。

具体做法分四步：

1. 用自定义字段实现评分卡。把五个维度的评分做成必填字段，权重写在自动化规则里，总分由系统计算，业务方看不到自己在哪一维度偏低，避免针对性美化。
2. 用工作流实现分级授权。按资源量级设置审批分支，≤5 人月的申请自动路由到业务线负责人，超过阈值的逐级上报。SLA 到期自动升级提醒。
3. 用自动化规则实现退出触发。每周扫描一次进度偏差、预算消耗和完成度，任一触发条件命中就自动生成一条退出评估任务，指派给项目经理和 PMO。
4. 用路线图视图实现跨档位可视。A 档项目在路线图上以固定色块呈现，B 档以半透明呈现，业务方能直观看到”自己的项目在哪一档、前面还有多少名额”。

4. 12 个月后的指标变化

下面是第 1、3、6、12 个月的四个关键指标。需要说明的是，第 3 个月出现了明显的指标反弹，原因是团队刚开始使用评分卡，业务方普遍按最低标准填写导致大量项目落入 C 档，引发了集中复评。这个反弹在制度落地中非常常见，如果你遇到，不要急着改规则。

5. 工具选型的现实考量

我在这类项目里通常不直接推某个工具，而是先明确三条硬约束，再看谁满足。这家组织的三条硬约束是私有化部署、历史数据继承、分级审批链。把这三条列出来之后，候选范围自然就缩小了。

下面这张对比表是我常用的评估结构，评分维度按中大型组织的实际痛点设置。评分是 1-5 分，5 分为完全满足。

六、可直接落地的模板：五张表 + 一份制度骨架

这一节是全文最实务的部分。下面五张表是我在多个组织里反复迭代后的版本，你可以直接复制改名使用。每张表我都标注了实际使用中的注意事项。

1. 模板一：立项申请单字段清单

注意事项：“不做的后果”这一项是整套闸门里性价比最高的字段。我在多个组织测过，加上这个字段后，申请量平均下降 18%-25%，下降的部分基本是重复提交和随手下单。

2. 模板二：五维评分卡

评分卡使用 1-5 分制，每一项都要给出评分依据的一句话说明。没有依据说明的打分视为无效，这一条我是写进制度里的。

3. 模板三：分级授权矩阵

授权矩阵的关键不是数值，而是每个层级必须有明确的决策 SLA。没有 SLA 的分级授权，等于把等待时间从高层转移到中层，总周期不会缩短。SLA 到期未决策的，制度上默认视为通过在下一层级执行，这条”沉默即通过”规则能有效抑制拖延。

4. 模板四：立项评审纪要模板

评审纪要我只保留六项内容，多了没人写。下面是模板骨架。

立项评审纪要（模板）
──────────────────────────────

会议时间 / 参会人 / 缺席人：

评审项目（按序）：

1) 项目名称 | 申请档位 | 系统评分 | 本次结论

2) …

【结论一：通过】

决策层级：

资源来源（哪个池子、哪个季度）：

前置条件（如需先完成架构评审）：

【结论二：补充后复评】

缺失信息项：

复评时间：

责任人：

【结论三：不予立项】

不立项理由（必须有书面依据）：

复评触发条件（如"当 X 指标低于 Y 时可重新提交"）：

资源回收去向：

【插队记录】

插入项目：

被挤掉项目：

影响季度：

──────────────────────────────

“插队记录”是这份模板里最容易被省略、但作用最大的一栏。它把插队的代价显性化，而且会形成一条可追溯的记录。我在两个组织里推行这一栏之后，插队频次在 3 个月内分别下降了 54% 和 61%。

5. 模板五：季度退出复盘表

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

同样的制度，在不同规模、不同行业的组织里，落地顺序完全不同。下面按三个维度给出建议，你可以找到最接近自己的那一行。

1. 按组织规模

• 100 人以下：不要建四层模型，只建闸门和轻量排序。这个规模下沟通成本低，会议效率高，过度制度化反而增加负担。建议只做两件事：必填字段清单 + 双档划分（做 / 不做）。
• 100-500 人：四层模型全部建设，但分级授权只设三级。这个区间是制度化收益最大的区间，因为跨部门协调成本开始超过个人记忆能力。
• 500-2000 人：必须上工具。分级授权超过三级之后，靠邮件和群聊串联会出现大量信息丢失。同时要建立”制度版本管理”，制度变更需要有版本号和生效日期。
• 2000 人以上：四层模型之外，还需要一层”跨组合协调”，处理多个产品线之间的资源争抢。这一层的核心不是排序，而是配额谈判。

2. 按行业

To B 软件与解决方案类组织：最大挑战是定制化需求占比高。建议在评分卡里为”可产品化程度”单独设一个修正项，避免项目型需求挤压产品投入。

制造业数字化：最大挑战是收益难以在短期内量化，且合规事项多。建议提高”风险敞口”权重至 20%，并为合规类项目单独设置强制通道。

互联网与在线业务：最大挑战是机会窗口短。建议把档位排序改为”月度重排 + 快速通道”，快速通道每季度配额 1-2 个，允许跳过部分字段但必须事后补录。

3. 按 PMO 成熟度

1. 刚成立的 PMO：先做数据基线，不要急着上制度。花两个月记录现有的决策周期、返工率、资源错配率，用数据说服管理层。
2. 有流程但执行不稳定的 PMO：重点在工具化。把已有流程搬到系统里，用必填字段和审批分支把流程固化。
3. 流程稳定但缺少反馈的 PMO：重点在退出复盘。这一阶段最容易陷入”制度运转良好但项目依然不产生价值”的状态。
4. 成熟 PMO：重点在权重校准。用过去一年的实际交付价值与预期价值偏差，反向调整评分卡权重，每年一次。

八、不同情况下的取舍：四组绕不开的矛盾

制度设计的本质是取舍，不是找最优解。下面四组矛盾，我不给”都重要”这种答案，而是给出我的明确倾向和适用边界。

1. 速度 vs 严谨

我的倾向：在入口严格，在中间宽松。入口的字段完整性和合规校验必须严格执行，因为这是最容易标准化的部分；中间环节的讨论深度可以放宽，允许在 80% 信息下做决定。

但有一个例外：涉及不可逆投入的项目（如硬件采购、外部合同），中间环节必须严谨，因为这些决策一旦做出，退出成本极高。

2. 统一 vs 灵活

我的倾向：评分卡统一，阈值灵活。五个维度和权重全组织统一，避免各部门自建评分卡导致横向不可比。但档位阈值可以按产品线差异化，例如创新业务的 A 档阈值可以降到 3.6 分。

这个取舍的风险是”阈值通胀”：每个部门都要求降低自己阈值。控制方法是每年只允许调整一次，且需要说明上一年度的实际交付数据。

3. 中心化 vs 联邦制

我的倾向：中心化管规则，联邦制管执行。PMO 负责规则设计、阈值设定、跨线协调和复盘；业务线负责在规则内做具体决策。这样既保证了横向可比，又避免了 PMO 成为决策瓶颈。

如果 PMO 既设计规则又做决策，会迅速变成”所有事情都要 PMO 拍板”，这是 PMO 最常见的失控方式。我见过的一个极端案例是，PMO 团队 6 个人，要处理全公司 300 多个项目的立项审批。

4. 工具化 vs 表格化

我的倾向：100 人以上必须工具化，100 人以下可以表格化。分界线不在预算，而在”决策链长度”：如果决策链超过两级，或者需要 SLA 提醒，表格化就会失效，因为表格无法自动升级、无法做权限隔离、无法保留审计轨迹。

九、30 天落地路线图与下一步

制度设计最怕憋大招。我用的一贯做法是 30 天跑通一个最小闭环，然后迭代。下面是我想推荐给你的落地节奏。

1. 第 1 周：做基线，不动流程

只做三件事：统计过去 12 个月的立项申请数、平均决策周期、返工率；抽取 20 个项目做资源占用分布，画出帕累托结构；找 5 位业务方做 30 分钟访谈，问同一个问题，”你上次提交的立项申请，卡在哪一步”。

这一周不要发布任何新流程，否则你会在没有数据的情况下引发抵抗。

2. 第 2 周：设计闸门与评分卡

产出两份文件：7 项必填字段清单、五维评分卡及四档阈值。找 3 个历史项目做回测，用新评分卡重新打分，看结果是否与管理层当时的判断一致。如果偏差超过 30%，说明权重需要调整。

3. 第 3 周：设计授权矩阵与退出触发

授权矩阵按资源量级分四级，每级写明决策人、评审形式和 SLA。退出触发设计三个条件，先只启用”进度触发”，因为它的数据最容易拿到且争议最小。

4. 第 4 周：工具配置与试点

选一个业务线做试点，把闸门字段、评分卡、审批分支配置到项目管理工具里。试点的目标不是效率提升，而是验证流程能否跑通、数据能否自动留痕。

如果你的组织规模在 100 人以上、有私有化部署要求、或者正在从海外项目管理平台迁移，那么工具层面的配置成本会明显高于制度设计本身。这种情况下，选择一款原生支持自定义评分字段、分级审批分支、自动化规则和数据迁移的项目管理平台，会比用通用工具拼装省下大量隐性成本。

5. 常见追问

问：制度上线后业务方集体抵触怎么办？答：抵触通常出现在第 2-4 周和第 2-3 个月两个节点。第一个节点是因为填报成本增加，解决方法是压缩必填字段到 7 项以内；第二个节点是因为大量项目落入 C 档需要复评，解决方法是提前培训填写标准，而不是放宽阈值。

问：管理层要求所有项目都要上会怎么处理？答：不要正面反对，而是给出数据。把过去一年所有上会项目按资源量级分组，统计每组的平均讨论时长和被质疑次数。通常你会发现，资源量级最低的那一组，讨论时长最短、质疑次数最少，用这组数据去申请异步审批，成功率比讲道理高得多。

问：小组织（50 人以内）需要这套东西吗？答：需要闸门，不需要完整四层。50 人以内的组织，沟通成本极低，真正的痛点是”需求随口提、没人记录”。你只需要一个必填字段清单和一个公开的项目池，就能解决大部分问题。

6. 最后一句

我做了这些年 PMO，最深的一个体会是：优先级制度的价值不在于选出最正确的项目，而在于让”不做什么”这件事变得可以公开讨论。一个组织如果在立项时可以坦然地写下”这个项目我们不做，理由是什么、什么条件下可以重新提”，那它的立项效率就已经超过了大多数同行。

下一步建议你做的，不是去调权重，而是拿一张纸，写下最近 10 个被否决或被搁置的项目，然后逐个问：当时的否决理由是什么？有没有书面记录？如果没有记录，那就是你制度里最该补的第一个洞。