全文约 2300 字，阅读约 6 分钟。
重点内容：风险管理九成的功夫不在「识别风险」，在评审节奏、触发信号、具体责任人这三件事上。登记册死掉的前兆，是评分三个月没人动过。
先给结论：风险管不好，多半不是运气差
Standish Group 的 CHAOS 报告 2020 版把项目分成三档：按时、按预算、按约定范围交付的占 31%；延期、超预算或者砍了范围的占 50%；直接取消、或者做完没人用的占 19%。合起来近七成项目没有完全成功。
这个数字三十多年没怎么变过。1994 年第一版调查了 365 位 IT 董事、8360 个应用，成功率只有 16.2%，其中 52.7% 的项目花掉了原预算的 189%。
得说句公道话，CHAOS 的口径一直有争议。Eveleens 和 Verhoef 在 2010 年发过一篇《The Rise and Fall of the Chaos Report Figures》，用统计方法证明里面的数字受预测偏差影响很大。但哪怕把成功率高估一倍，「大多数项目不按原样交付」这个事实，坐过复盘会的人都懂。
CHAOS 2015 还按规模拆过一组数：超大型项目成功率只有 6%，小型项目 61%，差了十倍。报告给的核心建议就一条，把大项目拆小。我的理解是，风险管理的本质是跟规模对着干，项目每大一圈，不确定性就多一圈。
大部分登记册不是输在没做，是输在没人看
我参加过不少项目启动会，流程都差不多：拉一群人头脑风暴，白板贴满便利贴，整理成一张风险清单，附在项目章程后面。然后就没有然后了。
EB Pearls 那篇讲风险登记册的文章里有个观察：登记册通常在第四个冲刺之后被放弃，因为团队开始忙了。这话说得客气，实际一周就够。死因按出现频率排三条：做给审计看，不是做给团队用；评分偏乐观，因为没人愿意当那个向客户报忧的人；只识别不升级，升级感觉像承认失败。
乐观偏差这条我印象很深。他们的解法是让成员先独立打分，再在会上对齐，分歧本身就是信号。我见过一次，同一个供应商交付风险，开发私下评「高」，项目经理当着客户的面评「低」。这种分歧不上称，后面全都会在进度上兑现。
风险写成话题，等于没写
看过太多登记册，条目长这样：「供应链风险」「资源不足」「进度风险」。这种写法没法评估也没法落实，只能躺在那里积灰。
能用的写法是把起因、事件、影响写全。把「供应链」换成「钢材到货晚于框架施工日期」，前者是话题，后者是事件，能评概率、能定责任人、能设触发信号。
ONES 博客里有个案例我记了很久：离上线还有十天，业务在群里说「这个字段必须改，不然合规不过」，研发沉默，测试翻历史用例。复盘时摊开事实，根子是三件事叠在一起：合规审查节点不清晰、需求变更没有触发机制、回滚和灰度方案没提前做。注意这三条，每一条本来都该是登记册里的一行。
还有个常见错误，把「项目延期」直接当成风险。延期是结果，不是风险。得继续追问：是供应商交付、关键路径任务、需求变更，还是资源不足？找不到原因，就没法制定措施。
只评一次分，等于没评
登记册第二大死法是评分停在启动会那天。概率和影响随项目推进一直在变，十月的低风险，到一月可能就是头号威胁。Techademy 那篇讲得直接：评分两个月没复审过，登记册已经死了。
还有一种更隐蔽：所有风险全标成「中风险」。看着谨慎，实际等于没有排序。评分得有依据，影响多少天、增加多少成本、影响多少用户、是否涉及合规或关键客户。团队不敢把风险标成高，往往说明管理氛围有问题，等级是帮决策的，不是给责任人贴标签的。
没有触发信号的应对，都是自我安慰
「密切关注」「必要时上报」，这种应对措施我见过无数遍，也见过它们怎么失效。没有触发条件，团队永远慢半拍，而在风险管理里，慢一拍通常意味着额外的时间和成本。
好用的触发信号长这样：「如果概率从中升到高，七天内升级到指导委员会」。概率、影响、应对失效，三个条件任何一个变动就升级。升级是机械动作，不是政治判断。没有定义触发条件，升级就变成判断题，而压力下的判断题基本都会做错。
还有个细节：应对措施里该有预算。某项应对要花钱花时间，就该现在纳入预算和进度，而不是出事那天慌乱中再说。没留钱的预案叫愿望。
风险要落到人，更要落到决策
「项目组负责」是最常见的责任稀释。每行风险需要一个具体角色名字，去盯触发信号、执行应对、必要时升级。项目经理对登记册的存在和更新负责，单条风险有单条的负责人，这是两回事。
检验登记册是不是活的，有个很实用的标准：任何一次例会上，你应该能说出登记册自上次会议以来促成的至少一个决策，挪了一个日期、给某个供应商加了第二来源、动了一笔应急储备，都算。说不出来，这张表就是装饰。
另外两条纪律。风险发生后要转成问题记录，写明实际影响、解决方案和恢复日期，继续挂在风险台账里会造成状态混乱。登记册别贪多，在用清单保持在十来条，八十条以上没人管得住，低于十五条通常说明漏了类别。
怎么让这套机制真的跑起来
机制归机制，落地就三件事：固定节奏、明确字段、有人提醒。
节奏上，高风险每周看一次，其余每月一次，每次十五分钟就够。坚持每周风险评审的项目，爆炸方式基本都在预料之内；跳过评审的项目，反复被惊讶。
字段上，一张能用的登记册就七列：风险描述（起因加事件加影响）、概率、影响、责任人、触发信号、应对措施、状态。这七列在智序项目管理系统里是默认字段，不用二次开发，拿过来就能填。
提醒上，别指望人脑。我们把风险看板挂在项目系统里，每条风险带负责人和下次复盘日期，到期自动进待办。现在像智序项目管理软件这类工具都带这种能力，风险条目设好概率、影响和触发条件，周会前系统自动把标红的风险推到负责人待办里，比拉群催靠谱。智序项目管理系统我们用了大半年，最大的变化不是表格变漂亮了，是周报里「Top 风险」那一节终于有人认真看了。
当然工具只是容器，智序 ORDR 也好，Excel 也好，容器不产生纪律，节奏才产生纪律。小项目也别过度制度化，周期几周、参与不到十人的项目，一张简化表格加每周十五分钟高风险检查就够，把简单问题复杂化本身就是风险。
明天就能做的一件事：把现有风险清单打开，逐条问三个问题：有没有具体的责任人？触发信号是什么？上次改评分是哪天？三问答不上来的，今天就改掉。选智序项目管理软件的时候，也可以把这三个问题当验收清单问一遍，比看功能列表管用。
更细的落地方法可以看 项目管理方法论专栏，需求、排期、复盘的做法都在里面。
如有侵权请与我们联系