Please enable JavaScript.

Coggle requires JavaScript to display documents.

管理風險 (Key Terms (Avoiding risk (避免風險 : 改變專案計畫，降低風險發生的可能性), Budget reserve…

- - - - 團隊成員通常用兩個條件評估風險的顯著性
        
        事件的發生機率
        
        事件的衝擊
- - - - 形成一個循環
  - - - 風險管理是主動的
      - 降低負面後果
      - 讓專案經理能化危機為轉機
      - 對未來事項較能加以掌握
      - 在預算內讓專案順利進行
- - - - 列出風險的可能清單
      - 腦力激盪或依據問題的辨識，列出所有已知的風險
      - 依照80/20的理論先探討較重大的風險，再探討特定事件
      - 風險分解結構RBS
        
        技術因素
        
        需求
        
        技術
        
        複雜度與介面
        
        績效與可信度
        
        品質
        
        外部因素
        
        分包商與供應商
        
        法規
        
        市場
        
        顧客
        
        氣候
        
        組織因素
        
        專案相依度
        
        資源
        
        資金
        
        優先順序
        
        專案管理因素
        
        估算
        
        規劃
        
        控制(追蹤管考)
        
        溝通
  - - - 產品開發專案的部分風險剖面
        
        技術需求 :需求是否穩定
        
        品質 : 設計時是否已納入品質考量
        
        設計 : 設計是否不切實際或假設太樂觀
        
        管理 : 成員是否清楚各自權限
        
        測試 : 需要時能不能取得測試設備
        
        工作環境 : 成員能不能跨部門合作
        
        開發 : 是否有合適的開發流程，方法，和工具支援
        
        成員 : 是否缺乏經驗成員是否足夠
        
        時程 : 這個時程是否有賴於其他專案完成
        
        顧客 : 顧客是否了解專案完成所需的代價
        
        預算 : 成本估算可不可靠
        
        承包商 : 承包商的任務定義名明確嗎
    - - 逐條探討每個風險發生機率和影響
      - 形成風險評估矩陣
      - 從風險評估矩陣考慮風險嚴重性矩陣
      - 從風險嚴重性矩陣衍伸出來做進一步機率分析
        
        風險嚴重性矩陣
        
        FMEA 由風險嚴重性矩陣衍伸，可偵測風險程度
        
        衝擊機率偵測 = 風險值
        
        紅色區域主要風險
        
        黃色區域中度風險
        
        綠色區域輕度風險
      - (決策樹，NPV，PERT)
      - 準量化的風險發生分析
  - - - 緩和風險 : 降低風險發生的可能性
      - 避免風險 : 改變專案計畫，降低風險發生的可能性
      - 轉移風險 : 把風險轉給其他單位，如買保險
      - 保留風險 : 當已知有風險但發生機率低時，採取承擔風險
      - 應變計畫
        
        是一個替代計畫，不是初始計畫中的一部分
        
        風險被辨識出之後才生效
        
        當可能的風險實際發生時採取的替代措施
        
        採取一些措施降低負面影響
        
        呈現出能降低並緩和風險所帶來負面衝擊的行動
        
        如果沒有應變計畫，管理者將無法及時因應
        
        且在壓力下所做的決策通常會有問題
        
        及早制定的應變計畫有助於平順轉移或解救專案
    - - 若選擇的技術失敗時，有備用的策略
      - 發展方法以快速診斷技術不確定性是否可以被解決
    - - 使用寬限時間，增加了專案最終完成日期的風險
        
        時間緩衝
        
        避免彌補不是計畫在內的延遲，所造成的專案期程延誤
        
        通常加在
        
        有高風險的活動
        
        因先行活動耽誤進度而使專案可能延誤的合併活動
        
        非要徑上的活動
        
        運用少數資源的活動確保活動能如期展開
      - 設定完成日期，會造成因為這日期，無法如期完成的風險
      - 壓縮專案時在壓縮過程中，造成專案期程無法履行的風險
    - - 當問題發生，需要更長時間解決，便產生預算風險
      - 價格風險應逐一評估
      - 檢視價格時，須避免一整筆資金涵蓋所有價格風險
    - - 原先答應的預算突然短缺影響整個專案完成的可能
      - 預備金/應變資金
        
        應變資金被用來處理專案風險
        
        預算準備金 : 針對已辨識的風險編列的費用
        
        管理預備金 : 針對未經辨識的風險編列的費用
    - - 開拓
        
        透過找出不確定的因素
        確保好的風險發生
      - 分享及轉移
        
        與其他夥伴共同完成，降低風險發生可能
        增加雙贏機會
      - 強化
        
        採取積極作為，讓風險帶來的正面影響發生
      - 接受
        
        承擔風險事件發生
  - - - 執行相關風險回應的策略
      - 監視會造成風險的事件之預兆
      - 當我們知道事件會發生時，啟動預備計畫
      - 不斷監視是否有新風險產生，寫出相對應的應變計畫
    - - 監視並追蹤報告並做相關的應變
      - 醞釀開放的組織架構
      - 允許組織成員勇於跟上級報告事件
      - 不斷地執行風險辨識活動
      - 不能疏忽每個小問題，可能造成大問題
      - 任務的分配，指定風險管理的責任
      - 變革管理
        
        專案範疇改變，或增加額外功能時
        
        因風險事件發生時，執行應變計劃所造成的成本與時程異動
        
        專案團隊建議做改善性變更時
        
        變革管理的步驟
        
        1.確認提議的變更
        
        2.列出變革的相關影響，如期程及預算的變動
        
        3.正式檢視，並評估是否批准或否決變革
        
        4.協商並解決變更限制與成本的衝突
        
        5.讓每個成員都知道變革已經發生
        
        6.設定責任分配與執行者
        
        7.調整時程及預算
        
        8.確認所有變革都已被執行完畢
        
        變更控制流程
        
        變更開始
        
        送出變更要求
        
        檢視變更要求
        
        批准與否
        
        2 more items...
      - 建立變更管理系統的成效
        
        沒有不預期的變革會被採行
        
        因變動造成的費用增加可以被控管
        
        將工作展開圖與工作效益評估整合在一起
        
        追蹤預備金使用情形
        
        釐清變動的責任歸屬
        
        所有成員均了解變動的影響
        
        範疇的變動會很快在預算書上被納管，能監督變更執行
        
        所有變動產生的相關行為都被控管，並很快被反映在基準與績效衡量中