INFO6007 Week 07 Risk Management 讲课总结
INFO6007 Week 07 讲课总结：Risk Management
课程：INFO6007 — Project Management in IT，Semester 2 2026 来源：讲义 PDF + tutorial（无转录稿） -
Lecture - INFO6007 Week 07 - Risk Management Plan.pdf（63 页） -Reading 1 - Standish Group Chaos Report.pdf（1995） -Reading 2 - NHS UK National Programme for IT case study.pdf（Justinia, 2017） -Tutorial sheet INFO6007 Week 07+Answer Sheet Week 07 Tutorial参考：Schwalbe, K. (2018). Information Technology Project Management, pp. 463–503。
本讲的主线是 风险管理六过程，前半部分讲风险的「软」面（沟通、干系人、风险偏好、组织文化），后半部分讲「硬」工具（概率影响矩阵、Monte Carlo、决策树/EMV）。NSW 数字驾照案例继续贯穿。
⚠️ 本周 tutorial 做的是 Week 6 资源管理的练习（见第十一章）；本周的风险内容在 Week 8 tutorial 练。
📝 风险是期末必考区：Practice Exam Q2(c)（识别两项风险 + 应对策略 + 具体行动）、Q3(b)（EMV 计算并判断是否批准测试计划），Question Bank Q25（三项风险 EMV 排序 + 应急储备）、Q6.3（风险偏好 + 治理）。
一、什么是项目风险
「项目风险是一个不确定的事件或条件，一旦发生，会对一个或多个项目目标（范围、进度、成本、质量）产生正面或负面影响。」
- 风险的本质是不确定性——可能发生，也可能不发生
- 已经发生的是 issue（问题），不是风险
- IT 项目尤其动态：技术快速变化、需求不断演进、网络安全、数据隐私
Standish Group CHAOS Report（讲义引用）
讲义引用：超过 60% 的 IT 项目没能达成时间、预算或范围目标，主要原因是风险管理不善。
（Reading 1 的 CHAOS Report 详细数据不在 2026 S2 期末范围，已删除，依据 Ed #88、#99：阅读材料不直接考。）
风险管理的目标
- 尽早识别潜在风险
- 评估概率和影响
- 制定最小化威胁、最大化机会的策略
- 在整个生命周期持续监控
- 在不确定性下做出明智决策
风险管理不是一次性任务，而是贯穿生命周期的持续过程；它与范围、进度、成本、质量管理互补，帮助 PM 摆脱「救火模式」。
二、风险的类型与类别
正风险 vs 负风险
| 方面 | Positive Risks | Negative Risks |
|---|---|---|
| 本质 | 机会（opportunities） | 威胁（threats） |
| 影响 | 对项目有利 | 对项目有害 |
| 应对 | Exploit, enhance, share, accept | Avoid, mitigate, transfer, accept |
例：正风险——云服务商提供促销额度降低基础设施成本；负风险——核心开发者离职。
五类风险
| 类别 | 来源 | IT 例子 |
|---|---|---|
| Market | 外部市场条件变化 | 竞争对手抢先发布、用户采用率不及预期 |
| Financial | 资金、预算、成本超支 | 资金被削减、汇率波动 |
| Technology | 技术的采用、集成或性能 | 遗留系统集成失败、数据泄露 |
| People | 人的因素、资源管理、干系人参与 | 关键人员离职、用户抵制 |
| Structure/Process | 组织流程、治理、项目结构 | 合规不达标、治理不一致 |
风险管理的好处
提高项目成功率、更好的决策、节约成本和时间、增强干系人信心、竞争优势、合规与治理。
三、风险沟通与干系人参与
风险沟通
以清晰、及时、透明的方式与干系人分享风险（威胁和机会）信息。
目标：让干系人理解风险及影响；更新风险状态和应对；在团队、管理层和客户之间建立信任；支持应对决策。
有效风险沟通的五个特征：clear, consistent, timely, transparent, action-oriented。
为什么要让干系人参与风险管理
- 干系人可能识别出团队不知道的风险
- 提高概率/影响评估的准确性
- 建立对风险及应对的共同所有权
- 及早参与能减少变革阻力
案例：英国 NHS National Programme for IT（NPfIT）
| 项目 | 内容 |
|---|---|
| 启动 | 2002 年 |
| 目标 | 全国电子病历系统、改善医疗 IT 基础设施、统一 NHS 系统 |
| 预算 | 讲义写 约 £12bn |
| 结局 | 2011 年被放弃/解散，花费数十亿而大部分目标落空 |
识别出的风险：
| 类别 | 风险 |
|---|---|
| Technology | 多供应商与遗留系统的集成 |
| People | 临床医生抵制新工作流 |
| Financial | 巨额预算超支 |
| Process | 各 NHS 区域治理不一致 |
风险沟通的失败： - 风险只在高层之间沟通，一线人员（医生、护士、行政）被排除在外 - 供应商和 PM 淡化风险以避免政治后果 → 决策延误，风险滚雪球 - 议会和公众没有得到准确的风险信息 → 失败暴露时声誉受损
干系人参与的失败： - 临床医生没有被早期纳入风险识别 → 系统与医疗工作流不匹配 - 供应商激励错位——只关注合同里程碑，不关注长期风险缓解 - 政府/议会介入太晚，只在危机时刻出现
（Reading 2 的 NPfIT 根因分析不在 2026 S2 期末范围，已删除，依据 Ed #88、#99。）
讲义的四条教训： 1. 尽早让所有干系人参与——尤其是要「和系统一起生活」的终端用户 2. 公开、持续地沟通风险——隐藏风险会侵蚀信任 3. 定制风险沟通——高层要摘要，技术团队要详细日志，终端用户要实操指导 4. 透明带来韧性——宁可承受短期批评，也不要长期崩溃
四、风险偏好、组织文化与效用函数
Risk Appetite（风险偏好）
组织为实现目标愿意接受的不确定程度。
影响因素：
| 因素 | 例 |
|---|---|
| 行业背景 | 科技创业公司通常比政府机构风险偏好高 |
| 财务健康 | 储备充足的公司能承受更多风险 |
| 领导心态 | 冒险型 vs 保守型 |
| 干系人期望 | 股东要求高增长 → 风险偏好更高 |
三种风险文化
| 文化 | 特征 |
|---|---|
| Risk-Averse（规避） | 回避不确定性，偏好合规、详细审批，创新慢 |
| Risk-Neutral（中性） | 务实地平衡机会与威胁 |
| Risk-Seeking（追求） | 鼓励实验、创新、快速扩张 |
讲义要点：风险管理必须与组织文化匹配，否则会失效。
风险效用函数
表示一个人/组织在不确定条件下对可能结果赋予多少效用（满意度）。X 轴是货币价值，Y 轴是效用。
| 偏好 | 行为 | 效用曲线形状 |
|---|---|---|
| Risk averse | 宁要确定的低收益，不要有风险的高收益 | 凹（concave）：收益增加，效用增速递减 |
| Risk seeking | 愿意冒险博取更高回报 | 凸（convex）：效用增速递增 |
| Risk neutral | 对风险无所谓，只看 EMV | 直线 |
📝 Question Bank Q6.3（博物馆是否立刻公开含敏感信息/权限未定的照片）：公共文化机构通常风险规避，声誉与法律风险的影响远大于「多吸引游客」的收益 → 建议对受影响照片采取 Avoid（暂不公开）或分批发布，由治理层（赞助人 + 策展人 + 法务）按权限做最终决定，并与相关干系人（权利人、社区）沟通。
五、风险管理六过程
| # | 过程 | 核心输出 |
|---|---|---|
| 1 | Plan Risk Management | 风险管理计划 |
| 2 | Identify Risks | 初始风险登记册、风险分解结构 |
| 3 | Perform Qualitative Risk Analysis | 优先级排序 |
| 4 | Perform Quantitative Risk Analysis | 数值化的整体风险暴露 |
| 5 | Plan & Implement Risk Responses | 应对策略、风险责任人 |
| 6 | Monitor and Control Risks | 更新的登记册、新风险、残余风险 |
PMBOK 第 6 版把「规划应对」和「实施应对」拆成两个过程（共七个）；讲义把它们合并成「5 & 6」，所以说六个过程。
1. 规划风险管理
目的：定义如何进行本项目的风险管理活动。
目标： - 确保风险管理结构化、一致、划算 - 定义角色与职责（谁管理风险，谁批准应对） - 确定方法、工具与技术（头脑风暴、Monte Carlo……） - 分配资源（预算、时间、风险储备） - 设定阈值（多大的风险可以接受）
好处：主动而非被动；对干系人透明；减少意外，节省时间和成本；团队在优先级上达成一致。
NSW 案例的规划要点：规模尺度（概率、影响、紧迫性）、责任人与升级路径、双周评审 + 阶段关口 + 上线准备检查点；示例规则——任何「极端」级别的身份、安全、隐私或可用性风险都需要立即处理并升级。
2. 识别风险
确定哪些风险可能影响项目并记录其特征；主要产出是初始风险登记册。项目早期开始，并在整个生命周期持续。完成后可以画出 Risk Breakdown Structure（风险分解结构）——风险类别的层级表示，帮助系统地想到所有风险来源（例如：项目 → 技术/管理/商业/外部 → 具体子类）。
四种识别技术
| 技术 | 做法 | 优点 | 缺点 |
|---|---|---|---|
| Brainstorming | 团队在不评判的氛围中自由产出大量风险想法 | 快、简单、多元视角；适合高不确定性的早期 | 可能被声音大的人主导；依赖主持人 |
| Delphi technique | 专家小组多轮匿名问卷直至达成共识 | 避免强势人物的影响；适合复杂不确定项目 | 耗时；依赖真正的专家 |
| Interviewing | 对干系人、SME、资深成员做结构化/非结构化访谈 | 深入的洞察和背景；发现不明显的风险 | 主观；访谈者偏差 |
| SWOT | 内部优势/劣势 + 外部机会/威胁 | 简单，内外兼顾，正负风险兼顾 | 可能过度简化 |
Brainstorming vs Delphi 是常考对比：核心区别在于匿名性——Delphi 正是为了解决头脑风暴「被大嗓门主导」的缺点。
NSW 案例的初始风险登记册：
| ID | 风险事件 | 类别 | 触发/证据 | 责任人 |
|---|---|---|---|---|
| R1 | 上线高峰需求 | Technical | 响应慢或超出容量阈值 | 平台负责人 |
| R2 | 记录集成错误 | Technical | 交易失败或数据不匹配 | 集成负责人 |
| R3 | 隐私或安全问题 | Technical / stakeholder | 审查发现或投诉 | 安全负责人 |
| R4 | 试点反馈改善推广（机会） | Opportunity | 积极试点结果或支持趋势 | 产品负责人 |
3. 定性风险分析
基于概率和影响对风险进行主观的优先级排序；在识别之后、定量分析之前；使用专家判断和定性工具。
目标：确定优先级；赋予相对重要性；为应对规划提供输入；让干系人对严重程度达成一致。
概率–影响矩阵（Probability Impact Matrix）
每个风险评估：可能性（低/中/高） 和 影响（对成本、时间、范围、质量），然后放进网格：
| 概率 ↓ / 影响 → | Low | Medium | High |
|---|---|---|---|
| High | 中 | 高 | 最高 |
| Medium | 低 | 中 | 高 |
| Low | 低 | 低 | 中 |
NSW 案例：R1 高概率 × 高影响 → EXTREME，立即处理；R2 中 × 高 → HIGH；R3 低 × 极高 → HIGH；R4 中等概率 × 中等收益 → MODERATE（监控并增强）。
注意 R3：低概率但影响极高的风险（安全/隐私）依然是高优先级——不能只看概率。
4. 定量风险分析
用模型、模拟和统计对风险对整体目标的影响做数值分析。它能回答：按期完成的概率是多少？预期成本超支多少？整体风险暴露有多大？ 并支持应急储备、预算与进度缓冲的决策。
Monte Carlo 模拟
- 使用随机抽样模拟项目的各种可能结果，运行成千上万次迭代
- 产出结果的范围（分布）而非单一估计
- 步骤：① 定义变量（不确定因素 + 概率分布：正态、三角、Beta）→ ② 运行模拟 → ③ 分析结果（例如「80% 把握在 X 天内完成」）
决策树分析与 EMV
决策树结合决策分支（选择）和机会分支（风险/概率），用于计算 Expected Monetary Value（期望货币价值）：
步骤：识别决策点 → 列出备选方案 → 为每个结果附上概率 → 赋予收益/成本 → 计算每个分支的 EMV → 选 EMV 最高的方案。
讲义例题（Schwalbe Figure 11-7）：
| 方案 | 结果 | 计算 |
|---|---|---|
| Project 1 | 20% 赚 |
|
| Project 2 | 20% 亏 |
→ 选 Project 2（EMV 更高）。
💡 注意 Project 1 的最大收益更高（$300k），但 EMV 更低——风险追求者可能会选 Project 1，风险中性者只看 EMV 选 Project 2。这就是效用函数和 EMV 的联系。
NSW 案例的 EMV：
| 情景 | 概率 | 影响 | EMV |
|---|---|---|---|
| 高峰需求应对 | 30% | A$800k 成本 | A$240k |
| 集成返工 | 25% | A$500k 成本 | A$125k |
| 推广延误 | 15% | A$1.2m 成本 | A$180k |
| 试点洞察减少支持（机会） | 40% | A$300k 节约 | −A$120k |
机会的 EMV 记为负成本，从威胁暴露中扣除。
📝 两道考试同型题
Practice Exam Q3(b)：25% 概率需
→ 纯从 EMV 看不应批准（
Question Bank Q25：
| 风险 | 概率 | 影响 | EMV | 排名 |
|---|---|---|---|---|
| 切换时供应商宕机 | 30% | $200,000 | $60,000 | 1 |
| 法规变化 | 10% | $500,000 | $50,000 | 2 |
| 关键工程师流失 | 50% | $40,000 | $20,000 | 3 |
应急储备可按 EMV 合计 $130,000 设定；EMV 的局限：它是平均值，单个风险发生时实际损失是全额影响（例如法规变化一旦发生就是 $500k）；概率和影响本身是估计；忽略风险偏好。
5 & 6. 规划与实施风险应对
在风险发生之前决定做什么——主动步骤。目标：降低威胁、增强机会、指定风险责任人、确保应对划算且现实。
威胁的应对（负风险）
| 策略 | 含义 | 例 |
|---|---|---|
| Avoid（规避） | 彻底消除威胁 | 修改范围，排除高风险功能 |
| Mitigate（减轻） | 降低概率或影响 | 额外测试降低软件故障风险 |
| Transfer（转移） | 把责任转给第三方 | 买保险、外包给有 SLA 保证的供应商 |
| Accept（接受） | 不主动处理，发生后承担后果 | 低优先级风险；可设应急储备（主动接受） |
| Escalate（上报） | 风险超出项目范围 → 上报项目集/组合管理 | 公司级网络安全风险 |
机会的应对（正风险）
| 策略 | 含义 | 例 |
|---|---|---|
| Exploit（开拓） | 确保机会一定发生 | 把最好的资源派给任务，保证提前完成 |
| Enhance（提高） | 增加概率或影响 | 团队培训提升生产率 |
| Share（分享） | 与第三方合作获取收益 | 与另一家公司联合发布产品 |
| Accept（接受） | 机会来了就利用，但不刻意追求 | 有空闲开发工时才用 |
| Escalate（上报） | 机会超出项目范围 → 上报更高权限 | — |
对称记忆：Avoid ↔︎ Exploit（消除 vs 确保）；Mitigate ↔︎ Enhance（降低 vs 提高）；Transfer ↔︎ Share（转出风险 vs 分享收益）；Accept 和 Escalate 两边都有。
Escalation vs Transfer（讲义课后题）：Transfer 是把项目内风险的后果/责任通过合同转给第三方，项目仍需管理它；Escalation 是承认这个风险不属于项目层级，交给项目集/组合/高层负责，上报后项目不再拥有它。
风险登记册（Risk Register）
- 记录所有已识别风险、特征和计划应对的核心文档
- 活文档：整个生命周期持续更新
- 保证风险可见、被监控、有责任人
- 典型字段：ID、描述、类别、根因/触发器、概率、影响、优先级、应对策略、责任人、状态、残余风险
NSW 案例的应对包：选择策略 → 设计行动（负载测试、分阶段发布、保证、回退方案）→ 指定责任人 → 设定触发器（应急、接受、升级点）；实施时被批准的应对要变成有排期、有责任人的工作，而不是停留在登记册里。
6. 监控风险
跟踪已识别风险、监控残余风险、识别新风险、评估风险过程有效性；贯穿整个项目。NSW 案例的五步：复审登记册 → 检查触发器 → 测试应对效果 → 识别新风险和残余风险 → 更新并沟通；数据来源是试点反馈、事件日志、容量数据、审查发现、支持需求。
六、传统 vs 敏捷的风险管理
| 方式 | 做法 |
|---|---|
| Traditional（瀑布） | 在启动和规划阶段预先识别、分析、规划；风险登记册 + 正式评审 |
| Agile | 在短周期（sprint）中迭代处理；嵌入日常活动 |
| Hybrid | 传统的结构化过程（登记册、概率影响矩阵）+ 敏捷实践（日常监控、自适应应对） |
敏捷风险管理实践
| 实践 | 说明 |
|---|---|
| Iterative Risk Reviews | 每个 sprint 末（回顾会）重审风险；持续交付带来早发现 |
| Risk-Based Backlog Prioritization | 高不确定性/高风险的故事先做（fail fast）——例如尽早试用新云服务暴露集成风险 |
| Risk Burn-Down Charts | 像 sprint 燃尽图一样跟踪风险暴露随时间的变化 |
| Collaborative Ownership | 风险不由单个「风险经理」管理，而是团队共担 |
优势：敏捷——发现快、干系人参与好、适应需求变化；混合——兼顾灵活性和正式治理，适合有多干系人、监管方、供应商的大型 IT 项目。
七、课后案例：金融服务公司云迁移
中型金融服务公司把遗留系统迁到云端，涉及多个供应商、内部团队和严格的合规要求。
| # | 风险 | 正/负 | 类别 |
|---|---|---|---|
| 1 | 供应商 A 可能延迟交付迁移工具 | 负 | Structure/Process（或 Technology，供应商交付） |
| 2 | 新的客户数据存储法规可能生效 | 负 | Market（外部环境）/ 合规 |
| 3 | 无备份时 25% 概率迁移中丢数据 | 负 | Technology |
| 4 | 资深开发者考虑离职 | 负 | People |
| 5 | 采用 AI 监控工具可提高可用性、降低迁移后成本 | 正 | Technology / Financial |
Risk 3 的 EMV：
Risk 4 的应急/回退方案：知识转移与文档化、结对编程/交叉培训、预先识别内部替补或承包商；也可用留任激励（降低概率）。
以上分类为参考答案（讲义只给了题目），类别归属有一定弹性，关键是给出理由。
八、Tutorial（Week 7）：资源管理练习
本周 tutorial 内容是 Week 6 资源管理。
Part A：为手机银行 App 画 RBS
| Level 1 | Level 2 |
|---|---|
| Human Resources | 后端开发、前端开发、QA 测试、DevOps 工程师、项目经理 |
| Equipment / Tools | 笔记本/工作站、服务器/云基础设施、网络设备 |
| Software / Materials | 开发 IDE、测试工具、项目管理软件、文档工具 |
想拿满分可以再往下画 Level 3（具体人名/工具版本/云实例/许可证数量），讲义说理想的 RBS 有三层。
Part B：识别过度分配与利用不足，提出资源平衡方案
| 成员 | 分配工时 | 可用工时 | 负荷 | 状态 |
|---|---|---|---|---|
| Dev 1 | 50 | 40 | 125% | 过度分配 10h |
| Dev 2 | 30 | 40 | 75% | 利用不足 10h |
| QA 1 | 35 | 40 | 87.5% | 轻微利用不足 |
| QA 2 | 40 | 40 | 100% | 满负荷 |
平衡后：
| 成员 | 分配 | 可用 | 状态 |
|---|---|---|---|
| Dev 1 | 40 | 40 | 平衡 |
| Dev 2 | 40 | 40 | 平衡 |
| QA 1 | 37.5 | 40 | 轻微利用不足 |
| QA 2 | 37.5 | 40 | 轻微利用不足 |
两种平衡策略： 1. 重新分配（Reallocate）：把 Dev 1 的 10 小时合适工作转给 Dev 2——前提是 Dev 2 有所需技能，且不影响依赖关系 2. 重新排期（Reschedule）：如果这些任务必须由 Dev 1 完成，就把 10 小时推到有空闲的时段；优先推迟有浮动时间的任务；浮动不够时，完工日期可能要后移
QA 之间转移 2.5 小时是可选的——两人都没有过度分配。
易错点：答资源平衡不能只说「转给 Dev 2」，要写出技能/依赖的前提假设，以及推迟任务对关键路径的影响——answer sheet 两条都写了。
Part C：QA 团队士气低落
提升生产力和士气的策略： - 认可与奖励：对达成测试目标进行表彰 - 培训与技能发展：工作坊提升信心与效率 - 工作量管理：公平分配任务，避免倦怠 - 目标设定与反馈：清晰可达的目标 + 定期反馈 - 团队建设活动：促进协作和积极文化 - 赋权：让 QA 团队参与测试策略决策
适用的激励理论： - Herzberg 双因素：管理保健因素（薪资、工作量、工作条件）防止不满；运用激励因素（认可、成就、成长机会）提升绩效和士气 - 或 Maslow：先保证基本需求（薪资、安全的工作环境），再通过认可、培训、职业成长满足尊重和自我实现
答题技巧：把每条策略对应到理论的某个因素/层级，比单独罗列策略更容易拿分。
九、本周考点速记 / 易错点
- 风险定义：不确定的事件或条件，可正可负，影响范围/进度/成本/质量；已发生的是 issue。
- 五类风险：Market / Financial / Technology / People / Structure-Process。
- 威胁四策略（+Escalate）：Avoid / Mitigate / Transfer / Accept；机会四策略（+Escalate）：Exploit / Enhance / Share / Accept。对称记忆。
- Escalate ≠ Transfer：上报是风险不属于项目层级；转移是通过合同把后果转给第三方。
- 定性（主观排序，概率影响矩阵）vs 定量（数值模型：Monte Carlo、决策树/EMV）。
- EMV = Σ 概率 × 影响；机会的 EMV 记为负成本；风险中性者只看 EMV。
- 「是否值得花钱降风险」：比较
- Brainstorming vs Delphi：Delphi 匿名、多轮，避免强势人物主导，但耗时。
- 风险偏好：风险规避（凹）/中性（直线）/追求（凸）；行业、财务、领导、干系人影响偏好。
- 风险登记册是活文档，每个风险必须有责任人。
- NHS NPfIT 教训：终端用户早参与、透明沟通、定制沟通、透明带来韧性。
- Chaos Report（讲义引用）：超过 60% 的 IT 项目没达成时间、预算或范围目标，主因是风险管理不善。（Reading 1 的具体比例已删除，不考。）
- 敏捷风险管理：迭代复审、高风险先做（fail fast）、风险燃尽图、共同所有权。
- 资源平衡答题：写出转移工作的技能/依赖前提，以及推迟对关键路径的影响。
十、本讲与前后的衔接
| Week | 内容 | 关键词 |
|---|---|---|
| 4 | 成本管理 | 应急储备、管理储备 |
| 6 | 资源管理 | RBS、资源平衡（本周 tutorial） |
| 7 | 风险管理 | EMV、概率影响矩阵、风险应对、风险登记册 |
| 8 | 采购管理 | 合同类型 = 风险在买卖双方之间的分配（tutorial 做本周的风险） |
| 9 | 治理 | 风险升级路径、指导委员会 |
三处直接呼应： 1. EMV 决定应急储备——对应 Week 4 的成本基线 + 应急储备 2. Transfer 策略的主要手段就是采购合同——Week 8 会讲 Fixed Price 合同如何把成本风险转给卖方 3. 风险的 Escalate 依赖治理结构——Week 9 的指导委员会、赞助人、升级路径