去年年底我参加一家约 1400 人规模企业的年度立项复盘会，屏幕上打出的数字很漂亮：全年申报立项 137 个，通过 133 个，立项通过率 97%。管理层当场表示满意。但同一个会议室，三个月后开的是”项目中止会”，41 个项目在 Q1 被叫停、挂起或无限期冻结，真正完成结项验收的只有 51 个。通过率 97%、全链路转化率 37.2%，这 60 个百分点的缺口，就是立项风控失效的全部代价。
更麻烦的是，这笔代价在立项当天完全不可见：它不会被记入任何一张审批表，只会以资源冲突、加班、外包溢价和骨干离职的形式，在随后的三个季度里陆续出现。
一、核心结论：立项风控不是审批仪式，而是一次风险定价
我做过八年研发管理相关的咨询和落地，看过接近 300 家企业的立项材料。一个非常稳定的观察是：大多数公司的立项流程，本质上是一套”证明自己想干”的仪式，而不是一套”筛掉不该干”的过滤器。表现就是通过率常年 90% 以上，评审会开得很热闹，但没有一个项目因为指标不达标被真正拦下来。
1. 立项风控的本质，是把管理层的直觉换成可复核的指标
管理层并不是不关心风险，而是缺少把风险说清楚的语言。当有人问”这个项目能不能做”，得到的回答通常是”战略上很重要””客户催得急””技术团队说能做”。这三句话都无法被校验，也就无法被追踪。
指标的作用不是让决策变复杂，恰恰相反：它让”我觉得有风险”变成”资源容量占用率已经到 118%，超出产能 18 个百分点”。前者只能靠职级压制，后者可以讨论、可以量化、可以设阈值。
2. 六个必须在立项阶段就盯住的关键指标
下面这张表是我在多个项目里反复收敛后留下来的一套核心口径。注意它只有六项，不是二十项，超过八项的立项评分表，在实践中几乎必然退化成”全部打 4 分”。
| 关键指标 | 计算口径 | 建议阈值 | 失控信号 |
|---|---|---|---|
| 战略一致性得分 | 项目目标映射到年度战略主题的匹配度，1-10 分 | ≥ 6 分 | 大量项目打 7 分，无法区分优先级 |
| 资源容量占用率 | （已立项项目所需人天 + 本项目人天）/ 期间可用人天 | ≤ 95% | 长期高于 110%，冲突成为常态 |
| 立项材料完备率 | 必填字段完整且可追溯的条目占比 | 100% | 靠评审会现场补答，材料质量参差 |
| 依赖项闭环率 | 已获得书面承诺与时间点的外部依赖 / 全部依赖 | ≥ 90% | 关键路径依赖停留在”口头确认” |
| 退出条件明确率 | 写明中止触发条件的项目占比 | 100% | 立项只写目标，不写止损线 |
| 成本基线偏差率 | 实际发生成本与立项基线的偏差比例 | ≤ 15% | 立项成本只报人力，不含外采与机会成本 |
其中我最看重的是资源容量占用率和退出条件明确率。前者决定了项目组合是否可持续，后者决定了项目出问题时的止损速度。这两个指标恰恰是绝大多数企业立项表上完全没有的。
3. 好指标和坏指标的分界线
我判断一个立项指标是否合格，只看三条标准。第一，它必须可复核，换一个人拿同样数据能算出同样结果；第二，它必须可跨期比较，本季度和上季度口径一致；第三，也是最关键的，它必须有能力反向否决一个项目。
很多企业的立项表上写着”团队士气””客户满意度””技术先进性”这类指标。它们听起来很全面，但没有任何阈值能让评审组据此说”不”。这类指标在风控意义上等于不存在。
二、背景与真实场景：三个我亲历的立项失控现场
指标设计不是从教科书里抄来的，是从事故里反推出来的。下面三个场景，分别对应准入层、可行性层和可控性层的失效。
1. 场景一：战略项目批量立项，资源池被击穿
这家企业做年度规划时，把战略拆成 9 个主题，每个主题下设 3-5 个项目，一次上报 31 个。评审会开了两天，全部通过，理由是”都是战略项目，不能不批”。
问题出在第二个季度。研发资源占用率从 Q1 的 78% 冲到 Q2 的 118%、Q3 的 143%。一名核心架构师同时被安排进 4 个项目，他在第三个月提出离职。立项时没有人问过一句：这些项目加起来需要多少人天，我们有几个人天？
2. 场景二：预算批了，产能没批
第二个案例更隐蔽。公司当年有 41 个项目拿到了预算，但只有 24 个真正进入研发排期，剩下 17 个因为”没有研发资源接”被无限期挂起。财务口径上，它们是已立项项目；执行口径上，它们是僵尸项目。
这类项目最消耗管理成本。负责人每隔两周要汇报一次”暂无进展”，PMO 每月要重新统计一次排期，季度复盘时还要解释为什么没有产出。立项决策如果只审钱、不审人，就等于把资源冲突的风险推迟到执行阶段引爆。
我后来给这家企业的建议是：立项通过的前提不是”预算有额度”，而是”资源有占位”。项目一旦批准，就在资源视图里锁定人天，其他项目不能再抢。
3. 场景三：立项材料全绿，交割时全红
某战略项目的立项材料写得非常漂亮：预期收益 2400 万元，工期 9 个月，技术方案成熟。九个月后实际结算收益 1190 万元，工期延后 5 个月。
复盘时发现，衰减是逐级发生的：关键依赖未闭环导致延期损失约 620 万元；范围未冻结，中途插入三个模块追加成本约 380 万元；共享资源被其他项目抢占后被迫外包，溢价约 210 万元。这三项损失在立项阶段全部可以预判，但没有一项进入立项评审。
三、拆解五个最常见的立项误区
这三个场景不是个案。我把它们背后的共性总结成五个误区，基本覆盖了我在企业里见到的大部分立项失效模式。
1. 误区一：把立项通过率当成管理效率
很多管理层把”通过率下降”视为流程变复杂、效率变低的信号，于是不断要求评审提速。但立项评审的产出本来就应该是”筛掉一部分项目”。一个通过率 100% 的评审会，等价于一个没有开过的评审会。
我的经验值是：成熟运作的立项门禁，通过率通常在 70%-85% 之间。低于 60% 说明门槛失真或材料太差，高于 90% 说明筛选功能失效。
2. 误区二：用单一财务指标做二值决策
ROI 高于某个数就批，低于就不批，这种规则看起来客观，实际上非常危险。财务指标只刻画收益，不刻画可行性和可控性。
我见过一个 ROI 高达 3.2 的项目被叫停，原因不是收益不行，而是它依赖一个尚未完成的外部系统对接，而该对接方在半年内不会排期。这类风险不会出现在 ROI 公式里。
3. 误区三：立项评审与资源容量脱钩
这是最普遍、也最致命的一条。立项评审看的是”这个项目值不值得做”，资源分配看的是”谁有空做”，两件事在两个不同的会上决定，中间没有任何联动。
结果是：有价值但没资源的项目被批准，然后在执行阶段和其他同样被批准的项目互相踩踏。我建议的做法是让资源容量成为立项的否决项，而不是执行阶段的调度问题。
4. 误区四：只审”做不做”，不审”谁做、多久、怎么退”
完整的立项决策应该回答四个问题：要不要做、谁来做、多长周期、什么条件下停止。绝大多数企业的立项表只覆盖第一个。
第四问尤其被忽视。一个没有退出条件的项目，在出现问题时只有两条路：继续追加投入，或者被最高层强行叫停。这两条路的代价都远高于在立项阶段预先设定止损线。
5. 误区五：口径月月变，数据无法跨期比较
“投入人天”这个字段，有的部门填全职人力，有的部门填参与人次，有的部门按日历天数算。数据一旦无法跨期比较，立项指标就失去了趋势判断能力，只能做单点快照。
我通常建议对每个立项字段写清楚三件事：定义、单位、取值时点。这三句话写在模板里，比任何流程文件都管用。
四、专业判断逻辑：三层立项风控指标体系
把指标堆在一起没有意义，关键是分层。我通常把立项风控拆成准入层、可行性层、可控性层三层，每一层解决一类问题，每一层都有自己的否决权。
1. 准入层：决定”该不该进入评审”
准入层回答的是方向问题：项目与战略主题是否对齐、是否满足合规与安全要求、是否与已有项目重复。这一层的特点是可以用清单快速判断，不需要开评审会。
准入层的常见配置包括：战略主题映射、合规与数据安全确认、重复项目查重、预算归属确认。四项全部满足才进入下一层。我在实践中发现，仅靠准入层的自动校验，就能挡下约 10%-15% 的申报项目。
2. 可行性层：决定”现在能不能做”
可行性层回答的是能力问题：技术方案是否成熟、关键依赖是否闭环、资源容量是否允许。这一层最容易做形式化，写一段”技术可行”就算通过。
我的建议是引入技术成熟度分级（例如 1-9 级），并要求引用预研结论或类似项目的实际数据。同时把资源容量做成硬性门禁：占用率超过阈值，项目自动进入排队池，而不是带着”待协调”状态被批准。
3. 可控性层：决定”做完之后怎么管、什么时候停”
可控性层回答的是执行问题：里程碑是否可验证、成本基线是否拆得清、退出条件是否明确。这一层最容易被跳过，但它直接决定项目出问题的止损速度。
我要求每个立项必须写明三件事：成本按”人天 + 外采 + 机会成本”三项拆解；里程碑必须有可交付物，而不是”完成 60%”这种无法验证的表述；至少写明一条中止触发条件，例如”连续两个月进度偏差超过 30% 则启动复评”。
4. 权重与打分模型：给出一个可落地的配置
三层指标加总后，我通常给一个百分制评分。准入层是否决制，不计分；可行性层占 40 分；可控性层占 35 分；战略价值占 25 分。总分低于 60 分不立项，60-75 分进入排队池，75 分以上进入资源排序。
下面是我在某企业实际使用过的一份门禁配置片段，可以直接作为模板起点：
gate:
name: 项目立项门禁
stages:
stage: 准入层
mode: veto # 否决制，不计分
checks:
战略主题映射: required
合规与数据安全确认: required
重复项目查重: required
预算归属确认: required
stage: 可行性层
weight: 40
checks:
技术成熟度等级: {threshold: 5, max: 9}
关键依赖闭环率: {threshold: 0.9}
资源容量占用率: {threshold: 0.95, mode: hard_block}
stage: 可控性层
weight: 35
checks:
成本基线拆解完整度: required
里程碑可交付物完整度: required
退出条件明确: required
stage: 战略价值
weight: 25
checks:
战略一致性得分: {threshold: 6, max: 10}
decision:
score_below: 60 -> reject
score_between: [60, 75] -> queue
score_above: 75 -> rank_and_allocate
5. 门禁设计的三个动作
配置只是骨架，真正让门禁生效的是三个动作。
- 立项即占位：项目通过的同时，在资源视图里锁定人天，其他项目无法再抢这块容量。
- 数据自动采集：评审所需的字段来自项目模板和审批流，而不是评审前一周靠 Excel 汇总。
- 结果反向回写：项目中止或延期时，把原因回写到立项记录上，用于校准下一轮的指标权重。
第三个动作最难，也最有价值。没有它，指标权重会永远停留在第一版，无法随组织实际情况演进。
五、案例与数据观察：一家 1200 人企业的立项门禁重建
2023 年我参与了一家约 1200 人规模企业的立项流程改造，业务横跨制造与软件，研发人员约 480 人，全年申报立项 137 个。这家企业的情况很有代表性：有立项流程、有评审会、有模板，但没有任何一项指标具备否决能力。
1. 改造前的状态：口径混乱，数据靠人凑
改造前，立项材料通过邮件提交，格式是 Word。PMO 每次评审前要用三到四天把材料汇总成 Excel，字段包括投入人天、预期收益、里程碑、风险。其中”投入人天”至少有三种统计口径，导致横向比较几乎不可能。
更关键的是，评审组的结论只有两种：通过、修改后通过。没有”否决”这个选项，因为没有指标可以支撑否决。137 个项目全部走完流程，真正被拦下的为 0。
2. 改造动作：把门禁做进工具，而不是做进流程文件
这次改造最关键的一个决策是：不写新的流程文件，而是把门禁配置到项目管理平台里。因为流程文件只能约束人，工具可以强制约束字段和状态。
这家企业最终选择了 PingCode 作为承载平台，主要基于三个现实约束。第一，它有超过 1200 名员工、涉及客户数据处理，必须支持私有化部署；第二，原本使用 Jira 多年，历史项目与工作流需要平滑迁移而不是推倒重来；第三，作为国产替代方案，在合规审计和数据主权上更容易通过内部评审。PingCode 主要服务中大型企业及 100 人以上组织，这个规模区间正好匹配。
具体落地上做了四件事，我按优先级列出来：
- 用统一的项目模板替换 Word 材料，必填字段包括战略主题、技术成熟度等级、依赖项清单、退出条件、成本三项拆解。
- 把资源容量做成审批流的硬性校验节点，占用率超过 95% 的申请自动进入排队池，不再进入评审会。
- 审批结果自动回写立项记录，中止或延期时强制填写原因分类，形成可统计的中止原因分布。
- 建立项目组合视图，管理层可以按战略主题、部门、资源占用率三个维度看全部在途项目。
3. 改造后 12 个月的数据对比
最直观的变化是项目漏斗。137 个申报项目中，通过立项评审的从 133 个降到 96 个，真正进入研发排期的从 96 个提升到 89 个（因为资源在立项阶段就完成了占位），完成结项验收的从 51 个提升到 74 个。全链路转化率从 37.2% 提升到 54.0%。
值得说明的是，评审通过率从 97% 降到 70%，一开始管理层是有压力的。但三个月后，当”通过即能排期”成为稳定预期，事业部的申报行为明显变化，申报数量减少，单份材料质量显著提升。
4. 四个反常识结论
这次改造结束后，我总结了四条和直觉相反的结论，它们在我的其他项目里也基本成立。
第一，立项评审变慢，反而让整体交付变快。评审周期从 3.5 天延长到 6.2 天，但因为资源在立项阶段就完成占位，执行阶段的等待和协调时间大幅缩短。全链路交付周期中位数从 7.4 个月降到 6.1 个月。
第二，减少立项数量比提高执行效率更有效。当年立项数量从 133 降到 96，但结项数量从 51 升到 74。在资源受限的组织里，做对减法比做对加法收益更高。
第三，最有价值的指标是”退出条件明确率”。改造后 81 个进入交付中期的项目里有 7 个被主动终止，全部依据的是立项时写明的触发条件。主动终止的平均损失约为延期项目的三分之一。
第四，工具的作用是消除博弈空间，而不是提供报表。当资源占用率是系统自动计算、无法人工调整时，事业部之间的申报博弈就自动消失了。过去需要开三次协调会的事情，变成了一次自动排队。
六、不同情况下的行动建议
立项风控没有通用方案，它必须和组织规模、资源复用度、项目并发数匹配。下面按四种规模给出我的具体建议。
1. 50 人以下：轻量清单，重点是资源容量
这个阶段不要引入评分模型，三层指标体系会让流程变得不可承受。我的建议是只保留三个指标：战略一致性、资源容量占用率、退出条件明确率。
评审周期控制在 1 天以内，评审层级 1 级，由业务负责人和研发负责人共同确认即可。这个阶段最大的风险是”老板想做就做”，所以资源容量必须写下来，哪怕只是一张共享的排期表。
2. 100-500 人：固化模板与口径，开始引入工具
这个规模区间最容易出现口径混乱。建议先做两件事：统一立项模板，明确每个字段的定义、单位和取值时点；建立季度口径复核机制，由 PMO 或运营角色负责。
核心指标建议扩展到 5 个，评审周期 3 天左右，评审层级 2 级。这个阶段也是引入项目管理平台的最佳时间点，再晚，历史项目数据迁移成本会明显上升。
3. 500-2000 人：立项即占位，必须与项目组合视图联动
百人以上、千人左右的组织，资源复用度高，一个骨干同时参与多个项目是常态。此时立项即占位是必须的，而不是可选的。没有资源占位，立项评审的结论在第二天就会失效。
建议核心指标保持 6 个，评审周期 5-7 天，评审层级 3 级。同时必须建立项目组合视图，让管理层能看到全部在途项目对资源的总占用。
4. 2000 人以上 / 集团型：组合层与单项目层双轨评审
这个规模的组织，单项目最优不等于组合最优。建议采用双轨评审：组合层评估战略主题之间的资源配比，单项目层评估可行性、可控性与价值。
核心指标在 6 个单项目指标之外，再增加 3 个组合级指标，战略主题资源占比、组合整体资源占用率、组合内项目重复度。评审周期 8-12 天，评审层级 3-4 级，这是不得不付出的协调成本。
七、不同情况下的取舍
做立项风控最难的从来不是设计指标，而是在冲突目标之间做选择。下面四组取舍是我在项目里被问得最多、也最没有标准答案的。
1. 流程严格度 vs 立项速度
每增加一个必填字段、一个评审节点，立项周期就会延长。我给出的经验值是：立项评审周期每延长 1 天，可以换来执行阶段约 1.5-2 周的协调时间节省，前提是这些时间真的用在了资源校验和依赖确认上。
如果评审只是把材料从 Word 搬到模板里，没有任何实质性校验，那延长的每一天都是纯损耗。判断标准很简单：评审会上被否决的项目占比是否大于 10%。
2. 集中管控 vs 事业部自治
集中管控能让资源容量指标生效，但会降低事业部的响应速度；自治能提高响应速度，但资源冲突会转移到执行阶段。我的建议是分层：资源容量和合规准入集中管控，业务价值和范围定义交给事业部。
这两者的边界要写清楚。我见过最糟糕的情况是两边都想管：事业部认为资源是集团的事，集团认为价值是事业部的事，最后谁都不为项目的最终结果负责。
3. 指标数量 vs 决策效率
指标超过 8 个之后，评审组的打分质量会急剧下降，出现”全部 4 分”的现象。我的建议是核心指标控制在 5-6 个，其余指标作为必填信息保留但不参与打分。
另一个经验是：每个指标必须有明确的阈值和否决权，否则它就是信息字段，不是风控指标。把这两类东西混在一起，是立项表失效的最常见原因。
4. 自建 vs 采购、SaaS vs 私有化
承载立项流程的方式有三种：本地 Excel 加邮件、通用 SaaS 项目管理平台、私有化部署的项目管理平台。三者的成本结构完全不同。
Excel 方案没有软件成本，但人工汇总成本随项目数线性上升，且无法强制字段口径。SaaS 方案上线快、采购成本可控，但在数据出境、字段深度定制、审批流改造上有明显边界。私有化部署一次性投入最高，但在千人以上规模、合规要求强的场景里，人均成本反而更低。
我的判断标准是：如果企业已经超过 500 人、涉及客户数据处理、且需要深度定制审批流，私有化部署几乎是唯一可行选项。像 PingCode 这类支持私有化部署、同时支持从 Jira 平滑迁移的平台，在这个区间是比较务实的选择，迁移成本低意味着历史项目数据不会变成孤岛，而立项风控恰恰非常依赖历史数据来做权重校准。
八、下一步怎么做：90 天立项风控加固路线
如果你认同前面的判断，但不打算做一次大改造，我建议用 90 天做一轮最小可行加固。下面是我在多个企业验证过的节奏。
1. 第 1-30 天：先统一口径，不动流程
这一个月只做一件事：把立项材料里每个字段的定义、单位、取值时点写清楚，形成一份不超过两页的字段说明。不要改流程，不要换工具，先把”投入人天”这类核心字段的三种口径收敛成一种。
同时统计一次当前在途项目的资源占用率。这个数字往往会让人吃惊，也是推动后续改造最有力的证据。
2. 第 31-60 天：加入两个硬性门禁
不要一次加六个指标。先加两个：资源容量占用率和退出条件明确率。前者限制增量，后者控制损失。两项都必须具备否决能力，也就是能真的把项目拦下来。
这个阶段开始把立项模板从文档迁移到工具里。如果还在用 Excel，至少要把字段校验做进去，让不完整的材料无法提交。
3. 第 61-90 天：建立回写机制与季度复盘
最后一个月最重要的工作是回写。所有中止、延期、范围变更的项目，都必须把原因回写到立项记录上。三个月后你会得到第一份中止原因分布，这份数据是校准指标权重的唯一依据。
我通常建议把这份复盘做成季度固定动作，并且只讨论两件事：哪些指标长期没有拦下任何项目（考虑删除），哪些中止原因反复出现但立项阶段没有对应指标（考虑新增）。
4. 一个容易被忽略的收尾动作
最后补一句我认为最容易被忽略、但效果最明显的建议：把”立项通过但未进入排期”的项目单独拉一个清单，每季度清零一次。
这类僵尸项目在每个组织里都存在，它们不出现在任何风险报告里，却持续消耗管理注意力和预算额度。把它们清零，往往比新增十个风控指标更能改善项目组合的健康度。
立项风控的最终目标不是让流程更严，而是让管理层在批下一个项目时，能清楚说出两句话：这个项目占用的资源从哪里来，以及它在什么条件下应该被停止。能答出这两句，一套立项指标体系就算立住了。
常见问题解答（FAQ）
1. 立项评审时，管理层最少要盯住哪几个风险控制指标？
我们公司开立项会基本是业务负责人讲一遍 PPT，管理层听完点头就过，事后才发现预算超支、收益根本没兑现。我一直想知道，评审桌上到底该看哪几个数，才能既不放跑机会也不放进坑。我自己也做过多指标表，列了二十多项，结果没人看得下去。
建议控制在六到八个核心指标，一页纸能看完，超过十个基本等于没指标。具体是：一，全口径投入，人力按公司统一内部人月单价折算，加上采购和机会成本；二，预期收益与回收期，必须写明收益来源和兑现路径；三，资源占用，看关键岗位饱和度，超过百分之八十就要预警；
四，战略匹配度，是否属于年度重点方向，用一到五分打分；五，交付可行性，里程碑颗粒度到月，并标出关键依赖方；六，风险敞口，把技术、合规、供应商三类风险各给出发生概率和影响程度。判断口径上我有个硬要求：不能量化的收益不进入立项书主指标，只能写在备注里，否则评审会很容易被故事带走。
另外回收期、毛利率提升这类阈值必须按行业和公司阶段调，不要直接抄别人的数字。
2. 立项通过率多少算正常，是不是通过率越高说明组织效率越高？
我们老板一直以立项通过率高为荣，说这证明团队执行力强、想法靠谱，但我总觉得评审根本没起到筛选作用。去年我们立了四十多个项目，年底真正交付并且产生收益的不到三分之一。我想知道通过率到底有没有一个健康区间。
通过率不是越高越好，它衡量的是门槛，不是效率。多数行业的参考区间在百分之四十到六十之间，如果连续两个季度高于百分之八十五，基本可以判定门槛失效了。可执行的做法是分级授权：投入低于某个阈值，比如二十人月以内的小项目，由部门自主立项只做备案，不占用管理层评审时间；
超过阈值才进管理层评审，把精力压在大额投入上。同时要一起统计三个数才有意义：立项通过率、立项后九十天内取消或暂停的比例、交付后收益达成率。通过率高但九十天暂停率也高，说明评审走过场；通过率低但收益达成率高，可能是门槛过严，会压制试错型项目，需要单独给探索类项目留一条通道。
3. 立项书里的收益和成本数据，管理层怎么判断有没有注水？
我审过几份立项书，同一个项目不同部门报上来的收益差了三倍，人力成本有的按工资算、有的按对外报价算，很难判断谁在注水。后来吃过一次亏，一个项目立项时号称一年省两百万，做完只省了三十万。从那以后我就特别在意数据口径这件事。
核验三件事。第一，收益口径必须唯一且可追溯，要求写成“收益等于哪个指标乘以变化幅度再乘以单价”，并且指定一个财务或数据口径的背书人，客户口头意向、表示感兴趣一律不算。第二，成本用公司统一的内部人月单价，避免有的部门按工资、有的按对外报价，否则横向比较完全失效。
第三，强制做敏感性分析，让业务方给出乐观、中性、悲观三档，管理层只认中性档，而且悲观档不能亏到伤筋动骨。实操上我会要求所有立项书的收益栏附一行说明：该数字由谁、在什么时间、用什么数据源确认。
经验值是，如果中性档收益比乐观档低百分之四十以上，说明方案本身不确定性太大，先做小规模验证再正式立项，而不是先立项再找证据。
4. 项目立项之后，怎么设回检机制才不至于立完就不管？
我们立项会开完就结束了，后面没人回头看当初承诺的收益有没有兑现。到年底复盘才发现好几个项目早就跑偏，那时候已经投了几百万进去。我想知道回检应该什么时候做、看什么、触发什么动作。
设阶段门加固定回检节点。通常三个点：立项后三十天，确认资源到位、范围冻结；九十天，看首个小里程碑是否交付、成本偏差多少；项目结束后三到六个月，做收益回检，看真实数据而不是汇报数据。判断依据用偏差率，成本或进度偏差超过百分之二十，或者关键里程碑连续两次延期，就触发重评。
重评只能给出三个结论：继续、缩范围、终止，不允许出现“再观察一个季度”这种模糊结论，否则回检会退化成例行汇报。落地时把回检节点做进项目管理工具的里程碑和风险模块，让偏差自动预警，而不是靠人记；
同时把立项时承诺的收益和回检时的实际收益放进同一张表对管理层汇报，这一条最能抑制立项阶段的数据注水，因为大家知道后面一定会被拿出来对。
文章包含AI辅助创作：立项流程与规范：管理层项目立项风险控制关键指标，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/281603
读者评论
资源容量占用率做成硬性门禁这个方向我认同，但落地时最难的恰恰是数据本身。我们公司项目排期和人力台账是两套系统，人在项目里的实际投入比例靠员工自己填，误差经常在20%以上。指标口径再严谨，喂进去的是估算值，最后还是靠评审组拍脑袋判断。所以我现在更关心的是有没有办法用考勤、代码提交这类旁路数据去校准，而不是继续加字段。
通过率70%到85%这个经验值我觉得不能直接套用。我们是做基础设施运维的，大量项目是监管合规驱动的，本来就没什么可筛的，硬压通过率只会逼团队把一个大项目拆成几个小项目来凑数。我更想问的是，作者观察的样本里有多少是研发型、多少是合规驱动型？不同类型企业的合理区间可能差很多，一刀切反而会造成新的形式主义。
退出条件明确率写到100%容易，真到了该停的时候没人敢按按钮。我们立项时也写了止损线，结果发现项目一旦挂上战略的名头，触发了条件也是先追加资源再观察一个季度。所以我感觉光有指标不够，还得明确谁来判定、判定之后责任怎么算，否则止损线就是写在文档里的一句话，跟没有差不多。