Project Risk Management

2018/12/17
2020/09/24 (增加連結)
2021/02/17 (增加內容)

概念

簡單的說就是在專案計畫中進行風險管理計畫及在監督與控制中進行風險控管

• 風險管理計畫: 辨識風險、進行質化或量化的風險分析、計畫風險的因應方式

  • 風險分析:主要是針對風險分析發生機率及影響，針對發生機率及影響去評估哪些風險應該要注意

• 風險控管: 了解風險是否已經發生，若已發生，就依計畫的因應方式執行，執行時，必須了解風險是否被有效處理，另外，也要注意是否環境有所改變(如:主管異動)，是否有未被辨識的風險因為環境改變而產生

• 專案風險管理

  • 風險識別

  • 風險量化

  • 風險對策

討論

• 歷經了這次的疫情衝擊，請大家分享各專案(公司)的風險管理機制。

  • 事先的風險識別、風險分析、風險計畫的擬定

  • 風險監控

  • 風險因應

  • 為什麼明知有風險，但是還是有人不處理?

• 軟體專案有哪些風險? 大家有甚麼有趣或印象深刻的經驗?

PMBOK

• Project Risk Management

  • 11-01 專案風險管理-PMBOK®6th (6:09)

  • 11-02 建立風險管理計畫-PMBOK®6th (6:01)

  • 11-03 識別專案風險-PMBOK®6th (4:44)

    • 利用專案風險分解結構識別風險

  • 11-04 實施風險定性分析-PMBOK®6th (7:44)

    • 利用風險影響程度定義表

  • 11-05 實施風險定量分析-PMBOK®6th (6:56)

    • 利用期望貨幣值

      • 將影片裡的舉例的投資案想成不同的風險

  • 11-06 建立風險回應策略-PMBOK®6th (8:18)

    • Escalate、Avoid、Transfer、Mitigate、Accept

  • 11-07 執行風險回應-PMBOK®6th (3:01)

  • 11-08 監控專案風險-PMBOK®6th (6:14)

  • Risk Management Overview

  • 專案風險管理

  • 在專案計畫書中描述如何進行風險管理 (Plan Risk Management)

    • Outputs: Risk management plan

    • Risk Management Plan

    • 規劃風險管理

    • 如果公司/組織會有一套風險管理的標準程序，就遵循標準程序，如果標準程序允許一些變動(如:採用質化風險分析或量化風險分析的時機)，就在計畫書中本專案採用哪個選項及其原因。

    • 在專案計畫書中會包括風險管理計畫，計畫中會先辨識風險、進行質化或量化風險分析、計畫風險的回應方式

  • 辨識風險 (Identify risks)

    • Outputs: Risk register、Risk report、Project documents updates

    • 辨識風險

    • Risk Identification and Analysis

      • 如果公司/組織已經有可參考的風險項目及因應策略，可以直接參考。一般而言，在專案結束後，會檢討這些風險項目及因應策略是否更新。

      • 如果沒有可參考的風險項目，可以參考:

        • 130 Project Risks，風險類別為

          • Executive support

          • Scope

          • Cost Management

          • Change Management

          • Stakeholders

          • Communication

          • Resources & Team

          • Architecture

          • Design

          • Technical

          • Integration

          • Requirements

          • Decision & Issue Resolution

          • Procurement

          • Authority

          • Approvals & Red Tape

          • Organizational

          • External

          • Project Management

          • Secondary Risks

          • User Acceptance

          • Commercial

        • Project Risk Identification For New Project Manager，風險類別為

          • Schedule

          • Requirement

          • Project Management

          • Product/Technology

          • Customer

          • Human Resources / Contractor

        • Common Software Risks that every developer Should Know

  • Perform Qualitative Risk Analysis

    • Outputs: Project documents updates

    • 實施定性風險分析 (台灣通常翻譯為質化)

    • 風險分析: 風險是影響程度*發生機率，所以，風險分析就是評估影響程度及發生機率

      • 進行質化風險分析 (Perform qualitative risk analysis)

        • 基本上當公司/專案無法進行量化風險分析時，會將風險影響程度及發生機率分等級(如:高、中、低)，比較簡單。但是無法跟風險回應方式的成本進行比較。

  • Perform Quantitative Risk Analysis

    • Outputs: Project documents updates

    • 實施定量風險分析 (台灣通常翻譯為量化)

    • 風險分析: 風險是影響程度*發生機率，所以，風險分析就是評估影響程度及發生機率

      • 進行量化風險分析 (Perform quantitative risk analysis)

        • 將影響程度以金錢上的損失來評估，並利用歷史資料(或產業的資料)計算發生機率，(如: 風險發生時，會損失1,000,000，發生的機率是1/1000)，這樣做的好處是，可以估算風險的期望值(1,000,000 * 1/1000 = 1,000)，可以跟風險回應方式的成本進行比較。

  • 計畫風險的回應方式 (Plan risk responses)

    • Output: Change requests、Project management plan updates、Project documents updates

    • Plan Risk Responses

    • 規劃風險回應

    • 如果公司/組織已經有可參考風險項目的及因應策略，可以直接參考。一般而言，在專案結束後，會檢討這些風險項目及因應策略是否更新。

  • Implement Risk Responses

    • Output: Change requests、Project documents updates

    • Implement and Monitor Risks

    • 風險控管: 了解風險是否已經發生，若已發生，就依計畫的因應方式執行，執行時，必須了解風險是否被有效處理，另外，也要注意是否環境有所改變(如:主管異動)，是否有未被辨識的風險因為環境改變而產生。

  • Monitor Risk

    • Output: Work performance information、Change requests、Project management plan updates、Project documents updates、Organizational process assets updates

    • 控制風險

    • 風險控管: 了解風險是否已經發生，若已發生，就依計畫的因應方式執行，執行時，必須了解風險是否被有效處理，另外，也要注意是否環境有所改變(如:主管異動)，是否有未被辨識的風險因為環境改變而產生。

CMMI

• Level 1

  • RSK 1.1 Identify and record risks or opportunities and keep them updated.

• Level 2

  • RSK 2.1 Analyze identified risks or opportunities.

  • RSK 2.2 Monitor identified risks or opportunities and communicate status to affected stakeholders.

• Level 3

  • RSK 3.1 Identify and use risk or opportunity categories.

  • RSK 3.2 Define and use parameters for risk or opportunity analysis and handling.

  • RSK 3.3 Develop and keep updated a risk or opportunity management strategy.

  • RSK 3.4 Develop and keep updated risk or opportunity management plans.

  • RSK 3.5 Manage risks or opportunities by implementing planned risk

與熊共舞

• 到底什麼是風險?

  • 我們是否常覺得只要是我們沒辦法(或根本是不想)控制的就是風險?

  • 或者我們常忽略我們沒辦法(或根本是不想)控制的風險?

• 為什麼不做(或不重視)風險管理?

• 風險辨識與因應

  • 風險辨識

    • 核心風險: (p.139)

      • 先天性的時程錯誤

      • 需求膨脹

      • 人力流失

      • 規格崩潰

      • 低生產力

  • 對應方式: (p.93)

    • 迴避(avoid):不做有風險的部分

    • 抑制(contain):當風險成形時，投入資源

    • 紓緩(mitigate):當風險成形前，就採取一些措施

    • 逃避(evade):不採取任何措施

  • 風險探索既定流程(defined process) (p.156-160)

    • 災難腦力激盪

    • 情境建立

    • 根源分析

• 風險動態追蹤 (p.163-170)

  • 完工量測指標

    • 邊界元素完工(boundary elements closure)

      • 對付規格崩潰的問題，當邊界元素果沒辦法確定，表示可能會有規格崩潰的問題

    • 實獲率 (Earned Value Running, EVR)

      • 對付其他的核心風險

  • 漸進式交付 (p.171-182)

    • 主動式漸進交付

      • 提早交付原則

        • 交付給利害關係人的價值

        • 風險假設的證實 (如:技術上最大障礙)

參考資料

• 讀書筆記 – 與熊共舞

• 軟體專案管理第十五週課程心得_風險值多少

• 《與熊共舞：軟體專案的風險管理》筆記

• 資深專案經理的建議-"與熊共舞(Waltzing with Bears)"

• 八仙樂園爆炸事件 看風險管理的「道德問題」

• [ 閱讀心得 ] 與熊共舞 --- 軟體專案的風險管理

• 資訊人一生必讀的三十本經典書籍（5/30）與熊共舞：軟體專案的風險管理

• 與熊共舞：軟體專案的風險管理

• 讀書心得~~與熊共舞(Waltzing with Bears)

風險管理工具

通常一般的專案管理工具都有簡單的風險管理功能，以Gantter為例:

• 風險 (Risk)

  • 可以設定類型 (Category)、負責人(Owner), 影響 (Affect), 相關的任務 (Related tasks)

• 風險因應方式 (Response)或 因應計畫 (Contingency plan/fallback plan)

• 原因 (Cause)

• 機率 (Probability) (採質性)

  • 不太可能 (Improbable) / 很少 (Remote) / 偶而 (Occasional) / 可能 (Probable) / 經常 (Frequent)

• 嚴重性 (Severity)或影響 (Impact) (採質性)

  • 可忽略 (Negligible) / 低 (Low) / 中 (Moderate) / 重大的 (Significant) / 災難性的 (Catastrophic)

• 優先順序 (Priority) (with risk matrix) 可根據風險矩陣(機率及嚴重性)自動對應

  • 不處理 (No Action) / 監控 (Monitor) / 處理 (Action) / 緊急處理 (Urgent Action) / 停止 (Stop)

• How to use a Trello Kanban board for Project Issues, Decisions & Action items

參考資料

• Managing overall project risk

• Project Risk Management

• Department of Defense Risk, Issue, and Opportunity Management Guide for Defense Acquisition Programs

• Project Risk Assessment (Ultimate Guide to Project Risk, Part 1)

• Project Risk Management Tools (Ultimate Guide to Project Risk, Part 2)

• The Art of the Strategic Product Roadmap

  • Step 1: Define the Problems

  • Step 2: Determine The Risks

  • Step 3: Solutions and Prototypes

  • Step 4: Build Your Roadmap

    • Guidelines for how to handle the problem categories:

      • High-value / low risk: Build it. Add to the roadmap, this is low hanging fruit.

      • High-value / high-risk: Test it. Items should be considered for the roadmap based on the appetite for risk. These items should be limited, as the more risk that is taken on, the higher chance of failure.

      • Low Value / low risk: These problems aren’t important. They will be the items that are constantly pushed back to later sprints. Leave them in consideration, but off the roadmap.

      • Low Value / high risk: Scrap it. These items lead you down rabbit holes, and often lead to a product plan being derailed.