肥蝦這幾日可說是心亂如麻，案子的進度也是零進度。記得在專案管理課程或相關的書籍中，對於風險的處理與對應的應變計劃的規劃邏輯，可說已是相當完善。加以肥蝦自己也有十年的專案經驗，不管是內部研發、產品引入或是產品客製化，所能先行設想到的可能風險，雖不敢說百分之百，也能捉個七八十。
想想WMONEY系統的啟動(Kickoff)會議距今也三週了，當初所考慮到的可能主要風險與應對措失，如：

(一)風險項目:1
(二)風險等級:8
(三)風險名稱:缺乏dotNET 3.5完整的瞭解
(四)風險內容:對WPF,WCF,WF缺乏一定的瞭解在建構系統時將無法達成效率性、可擴展性。
(五)風險負責人:肥蝦
(六)風險應變計劃:(1)請協理詢求臺灣微軟的協助。(2)考慮雇請技術顧問。
(七)風險回應/日期:
(八)關聯風險:
(九)風險類型:技術風險
(十)其它:

(一)風險項目:2
(二)風險等級:7
(三)風險名稱:與現有端末元件的整合
(四)風險內容:現有系統中現有的端末元件是否能直接使用或需配合新架構改寫。
(五)風險負責人:韓舊都
(六)風險應變計劃:(1)研究現有端末元件程式碼。(2)詢求外部既有資源。
(七)風險回應/日期:
(八)關聯風險:(風險項目1)
(九)風險類型:技術風險
(十)其它:

(一)風險項目:3
(二)風險等級:4
(三)風險名稱:現有dotNet開發人力資源不足
(四)風險內容:現有人力專長多在Java與VB6.0，且人員不多。
(五)風險負責人:阿強機器人
(六)風險應變計劃:(1)詢求公司其他部門的人力資源。(2)詢求外部人力資源。
(七)風險回應/日期:
(八)關聯風險:
(九)風險類型:技術風險
(十)其它:

等等...。
在PMBOK 2008也提到對Unknown-Unknown風險可以提列管理準備(management reserves)，對Known-Unknown風險可以依據負面、正面、偶然事件的應對策略─負面：避免、轉移、減緩、接受；正面：利用、分享、提高、接受；偶然事件：(Contingency Responses)可能性應變計劃。如果真得不能事先預估，還有一個WORKAROUND(權宜措施)，這個權宜措施就要看專案管理的經驗與專案經理對內外環境的熟悉度而定了。

在這樣的邏輯下，本來肥蝦認為本案雖然先天不足，但仍可靠後天的努力來克服。但、但...
肥蝦千想萬想也沒想到....
韓舊都病了！反正key resource，生病一下、休個假...什麼的，是常有的，還不至影響大局，反正當初就有估些buffer在！

但是、但是，韓舊都是"腦幹出血"！未來還是一片未知！每天大家耳鬢廝磨的同事，一下子肥蝦也無法適應！腦中一片空白！

現在要叫肥蝦一下提出甚麼權宜措施，是真的一下也不知道！沒錯，在工作上可以先行設法切割韓舊都所負責項目的關聯程度、要求補人、或者暫緩進度...。在一些書上都說要有備援人選，但在臺灣的環境中，這談何容易！備援人選對一個專案團隊、甚至公司，都是奢侈品！

真得，在台灣作IT軟體產業本土開發廠商蠻悲哀的！同事們也是求神拜佛的，尋求所有可能的資源來幫助舊都。肥蝦也只能乞求上天開開眼，心中只希望韓舊都能渡過此劫！