風險管理的部分大部分科技業會用所謂的NUDD
或是風險矩陣的方式合併Lesson Learnt的方式做處理
但這都是屬於專案前半，執行中發生的任何意外就不是風險，而是危機管理
危機管理的部分通常這類的突發狀況經常性的會連帶到能見度問題
專案管理人員的能見度除了在滅火這件事情外
還有在關鍵時刻比你手頭能處理問題的手法多寡
多寡這回事，不外人事時地
人脈，是否有過往的事件可參考，讓子彈飛，是否別的地方會發生或可以解決
牽扯到的就是整個Solution如何去編織的問題
通常這類問題的報告結構是這樣的
第一頁
開宗明義的先簡略檢視一下問題
問題肇因跟影響範圍
還有可能或是你比較推薦的解法
而至少提出幾種的備案，舉個例子
一種是快，但可能有風險或是費用比較高的
第二種是最慢省錢，但確定是最安全的
通常比較合適的是公司或是部門有Risk Buy而大家都能接受的。
最後才是技術細節，除非老闆是技術控，不然不需要浪費時間
只要跟相關的人等確定沒有問題，有得到背書後在上面提一下就好
通常老闆都會選最快解決問題的方式
但你要把裡面的細節、資源、跟系統風險講清楚
最後在開會的時候如果老闆要求那就以Meeting minutes做總結並核實方案資源
我個人的做法:
通常會有一個樣板，連帶方案跟架構怎麼寫
如果遇到這類Case就把剛剛提到的相對資訊全部填進去就可以
老闆只想知道問題能不能解，至於怎麼拆炸彈
那是要讓老闆買單前你自己得搞定的問題。
不過這種做法，就會讓某些只想抽水的人覺得你很油條難搞就是。