Day 29晚上-1：项目风险管理 - 在危机爆发前就扼杀它

一个没有风险管理的项目如何损失3000万

2019年，某传统车企启动"智能售后平台"项目，预算1500万，计划18个月上线。项目经理老刘是技术专家，他觉得"风险管理是多余的"，团队应该专注执行。

第6个月，核心供应商突然倒闭，系统架构需要重新设计。

第10个月，政策调整，原计划的数据接口方案违规，必须推倒重来。

第14个月，竞争对手提前上线类似产品，市场窗口期丢失。

第20个月，项目终于上线，但已经花费3200万，延期10个月，市场份额被抢走30%。

复盘时，咨询顾问指出：这些"意外"其实在项目启动时就有征兆，只是没人系统性地识别和应对。

对比另一家新势力的类似项目：

• 启动时就建立了风险登记册，识别出47项潜在风险
• 其中3项被评估为"高概率高影响"，提前制定了应对预案
• 当供应商出现财务危机（他们提前3个月发现了信号），立即启动备选方案
• 最终按时上线，预算控制在110%以内

风险的本质：不确定性事件

什么是项目风险？

风险（Risk）= 不确定的未来事件 + 对项目目标的影响

关键特征：

1. 未发生性：风险是"可能发生"的事，不是"已经发生"的问题
2. 不确定性：不知道会不会发生、何时发生、影响多大
3. 双面性：风险可以是负面威胁，也可以是正面机会

风险 vs 问题 vs 制约因素

常见误区：很多团队把"已知的限制"当成风险来管理，浪费精力。

例如：

• ❌ 错误："预算有限"是风险 → 这是制约因素，不是风险
• ✅ 正确："预算可能被削减20%"才是风险

风险管理的四大步骤

Step 1：识别风险 - 把"暗雷"挖出来

识别方法1：头脑风暴会议

最佳实践：召集跨职能团队（运营、IT、财务、门店代表），用结构化问题引导：

1. 项目目标风险：
   • 目标是否清晰？是否存在理解偏差？
   • 成功标准是否现实？
2. 范围风险：
   • 需求是否完整？会不会漏掉关键功能？
   • 是否存在范围蔓延的可能？
3. 进度风险：
   • 哪些任务的工期估算不确定？
   • 哪些依赖关系可能断裂？
4. 资源风险：
   • 关键人员是否稳定？
   • 预算是否可能被削减？
5. 技术风险：
   • 是否使用未验证的新技术？
   • 系统集成是否复杂？
6. 外部风险：
   • 供应商是否可靠？
   • 政策是否可能变化？
   • 竞争对手是否会有动作？

真实案例：某新势力在头脑风暴中识别出一个"隐形风险"：

• 风险描述：门店网络建设依赖某地产商，该地产商正在被监管部门调查
• 如果发生：20%的门店无法按期开业，影响售后网络覆盖
• 应对措施：立即启动备选地产商接洽，虽然增加谈判成本，但避免了更大损失
• 结果：3个月后地产商暴雷，但项目因提前准备未受影响

识别方法2：专家访谈

找行业老兵、技术专家、供应商伙伴，问一个核心问题："如果你是我，最担心什么？"

某项目经理的访谈记录：

• 访谈IT总监："最担心现有系统的数据质量，80%的门店数据不规范"
• 访谈财务总监："最担心汇率波动，进口设备成本可能上涨15%"
• 访谈门店店长："最担心培训不到位，一线员工抵触新系统"

这三个担忧都成为了风险登记册中的重点关注项。

识别方法3：历史数据挖掘

翻看公司过去的项目复盘报告，看看"踩过哪些坑"。

识别方法4：SWOT分析

• 高层支持力度大
• 预算充足 | - 门店执行力参差不齐
• 技术团队人手紧张
• 缺乏类似项目经验 |
  | 机会（Opportunity） | 威胁（Threat） |
  | - 行业政策支持
• 竞争对手尚未行动
• 可借鉴同行案例 | - 供应商选择有限
• 用户接受度不确定
• 经济环境下行 |

从SWOT到风险：

• 劣势 → 内部风险（如："技术团队人手紧张可能导致延期"）
• 威胁 → 外部风险（如："经济下行可能导致预算削减"）
• 机会 → 正面风险（如："政策红利可能加速审批流程"）

Step 2：评估风险 - 抓大放小

识别出50个风险后，不可能每个都重点关注。风险评估的目的是排优先级。

风险评估矩阵：概率 × 影响

概率等级：

• 高（>50%）：很可能发生
• 中（20-50%）：有可能发生
• 低（<20%）：不太可能发生

影响等级：

• 高：严重影响项目成败（延期>1个月，超支>20%，核心功能无法实现）
• 中：有影响但可接受（延期1-2周，超支5-10%）
• 低：影响微小（几天延误，小额超支）

风险矩阵：

影响程度
  高  |  中风险  |  高风险  |  高风险
      |----------|----------|----------
  中  |  低风险  |  中风险  |  高风险  
      |----------|----------|----------
  低  |  低风险  |  低风险  |  中风险
      |----------|----------|----------
          低        中        高
                发生概率

真实案例：某售后系统项目的风险评估

优先处理原则：

• 🔴 高风险：必须制定详细应对预案，持续监控
• 🟡 中风险：制定基本应对措施，定期检查
• 🟢 低风险：记录在册，不投入太多精力

Step 3：制定应对策略 - 四大武器

风险应对有四种基本策略，对应不同的风险特征。

策略1：规避（Avoid）- 改变计划，消除风险

定义：调整项目计划，使风险根本不会发生。

适用：高概率+高影响的风险，且可以通过改变做法来规避。

案例1：

• 原风险："使用未验证的新技术可能导致系统不稳定（概率60%，影响高）"
• 规避策略：改用成熟技术方案，虽然功能稍弱但稳定性有保障
• 结果：风险消除，项目按时交付

案例2：

• 原风险："依赖单一供应商，如果其出问题项目无法继续"
• 规避策略：从项目设计之初就采用"双供应商"架构
• 成本：前期集成成本增加15%
• 收益：6个月后主供应商暴雷，备用供应商立即顶上，项目未受影响

何时不应规避：

• 如果规避成本>风险损失，不值得
• 如果规避会牺牲核心目标（如：为了规避技术风险而砍掉核心功能）

策略2：减轻（Mitigate）- 降低概率或影响

定义：采取行动降低风险发生的可能性，或减少其影响程度。

适用：无法完全规避，但可以通过努力降低风险等级。

降低概率的案例：

风险：核心开发可能离职（概率30%）

减轻措施（降低概率）：
- 与核心开发深度沟通，了解诉求
- 提供项目奖金+职业发展机会
- 改善工作环境，减少加班

结果：离职概率降至10%

降低影响的案例：

风险：供应商可能延期交付（概率60%，影响：延期2个月）

减轻措施（降低影响）：
- 签订合同时明确延期罚则
- 提前3个月下单（原本提前1个月）
- 要求供应商每周汇报进度
- 准备备选供应商联系方式

结果：
- 概率仍是60%，但影响降至延期2周（提前下单的缓冲）
- 风险等级从"高"降至"中"

真实案例：某项目的"门店培训参与率低"风险

原风险评估：
- 概率：70%（历史项目培训参与率只有40%）
- 影响：高（培训不足导致系统使用率低）

减轻措施：
1. 降低概率：
   - 培训时间改为门店淡季
   - 培训内容精简至2小时（原4小时）
   - 设置"完成培训才能领取奖金"机制

2. 降低影响：
   - 开发在线补课系统，错过现场培训的可以自学
   - 安排"种子用户"先培训，再由他们带动其他人
   - 系统设计更直观的引导界面

结果：
- 参与率提升至85%
- 未参与的15%通过在线补课也掌握了基本操作
- 系统上线首周使用率达92%（远超预期）

策略3：转移（Transfer）- 让别人承担风险

定义：将风险的财务后果转移给第三方（但风险本身仍存在）。

常见方式：

• 保险：购买项目保险、设备保险
• 合同条款：固定价格合同（供应商承担成本超支风险）
• 外包：将高风险工作外包给专业公司
• 担保/保证金：要求供应商缴纳履约保证金

案例1：固定价格合同

风险：系统开发工作量可能超预期50%

转移策略：
- 与外包公司签订"固定总价合同"
- 价格：200万，不论实际工作量多少
- 如果超工作量，外包公司自己承担

结果：
- 实际工作量确实超了40%
- 但项目方只支付200万，风险被成功转移

案例2：延期罚则

风险：供应商延期交付硬件

转移策略：
- 合同约定：每延期1天，罚款5万
- 最高罚款不超过合同金额的20%

实际发生：
- 供应商延期10天
- 赔偿50万
- 虽然项目仍延期，但财务损失部分被转移

注意：转移策略的局限性

• ❌ 不能转移声誉风险（项目失败，客户不会在乎"是供应商的锅"）
• ❌ 不能转移关键路径风险（供应商赔钱了，但项目还是延期了）
• ✅ 适合转移财务风险、次要风险

策略4：接受（Accept）- 认了，但要准备Plan B

定义：主动决定不采取任何措施，或仅准备应急预案。

适用：

• 低风险（概率低且影响小），应对成本大于风险损失
• 无法规避或减轻的客观风险

被动接受 vs 主动接受：

真实案例：天气风险的接受策略

项目：全国50城门店开业活动

风险：某些城市可能遇到极端天气（台风、暴雪）

评估：
- 概率：20%（根据历史气象数据）
- 影响：中（部分城市活动延期）

策略选择：主动接受
- 不做预防（无法控制天气）
- 但准备应急预案：
  - 预留"弹性开业日期"窗口期（前后各3天）
  - 准备室内备选场地方案
  - 设立5万元/城市的应急预算

实际发生：
- 3个城市遇到恶劣天气
- 启动应急预案，改为室内活动或延期2天
- 整体项目未受重大影响

Step 4：监控风险 - 让风险管理"活"起来

风险管理不是"做一次就完"，而是持续的动态过程。

风险登记册：项目的"健康档案"

必备字段：

关键实践：

• 📅 每周更新：项目例会上必须过一遍风险登记册
• 🚨 触发器：设定风险"从黄灯变红灯"的触发条件
• 🔄 动态调整：新风险加入，已消除风险移除，概率/影响变化更新

风险触发器：提前预警的"烟雾报警器"

触发器（Risk Trigger）是风险即将发生的早期信号。

案例：

风险：核心开发可能离职

触发器（预警信号）：
- ⚠️ 该员工开始频繁请假
- ⚠️ LinkedIn资料更新为"开放机会"
- ⚠️ 工作产出质量下降
- ⚠️ 团队聚餐时沉默寡言

监控机制：
- HR每月与核心员工一对一沟通
- PM观察日常工作状态
- 发现2个以上触发器 → 立即启动应对预案

真实故事：某项目经理通过"触发器"挽救了项目

背景：项目进行到第5个月，进度正常

观察到的触发器：
- 供应商最近3次周会都派副手参加（以前都是老板亲自来）
- 供应商交付的文档质量明显下降
- 供应商开始频繁提出"增加预算"的暗示

项目经理的判断：供应商可能遇到财务困难

行动：
- 立即安排高层拜访供应商，侧面了解情况
- 通过行业人脉打听，发现供应商确实在裁员
- 果断启动备选供应商接洽

结果：
- 2个月后原供应商宣布破产
- 但项目因提前准备，平滑切换到备选供应商
- 仅延期1周，远好于同行业其他项目（平均延期3个月）

风险审查会议：不要让它变成"走过场"

会议频率：

• 小型项目：每2周1次
• 中大型项目：每周1次
• 关键阶段：每天早会快速过一遍高风险项

会议议程（30分钟）：

1. 新风险识别（10分钟）
   • 有没有新的风险冒出来？
2. 现有风险更新（15分钟）
   • 概率/影响有变化吗？
   • 触发器有异常吗？
   • 应对措施执行情况如何？
3. 风险转化为问题（5分钟）
   • 哪些风险已经发生？
   • 启动哪个应急预案？

避免的陷阱：

• ❌ 把风险评审变成"进度汇报会"
• ❌ 只关注已知风险，不讨论新风险
• ❌ 只汇报"一切正常"，不敢说真话
• ✅ 营造"说出风险是负责任"的氛围

实战练习：为你的项目建立风险管理体系

Step 1：召开风险识别会议

邀请：项目组核心成员+关键干系人

时长：2小时

产出：识别至少20个风险

Step 2：填写风险登记册

Step 3：制定TOP 3高风险的详细应对计划

选出等级最高的3个风险，为每个风险制定：

• 主要应对措施（3-5条）
• 触发器（2-3个预警信号）
• 应急预案（如果风险发生，Plan B是什么）
• 责任人和检查频率

Step 4：设置周例会议程

在每周项目例会中增加15分钟"风险review"环节。

下一页，我们将学习干系人管理，掌握如何"搞定人"比"搞定事"更重要的智慧。