PMP沒講的是...

軟體專案風險管理

一位PM對於所負責之專案的規劃安排，若是沒有考量風險，沒有預留必要的準備(reserve)，無法因應專案的不確定，那肯定不是一個好的規劃。專案一旦發生了風險，PM只能束手無策，那也肯定不是一位好的PM。

風險管理是做預防

在現實的環境中，對於軟體專案來說，在接案初期欠缺對專案的可行性評估，已使得專案曝露在極大的風險下。對於不熟悉的應用領域，卻想將該領域的營運流程做自動化處理；對於不熟悉的技術，卻期望能在短期內交付滿意的成果…。欠缺對專案的合理判斷，再加上不用功的甲方與不專業的乙方，這些因素足以讓專案一開始就陷入極大的風險。

但不完美的現實，也還是要想辦法去突破困境。之前有二篇文章（請參閱：“『風險管理』從來就不是額外的事！＂以及“其實 ~ 它不是『風險』！＂）中曾提及一個觀念，軟體專案中其實有許多事件是必然會發生的（不具機率性），它們是專案的限制，而不是專案的風險。但因為未能於事前正視專案限制、未能給予妥善的因應，只想碰運氣或等事情發生了再說，導致專案走到最後，總是不得不四處調動救火員來處理那救不完的火。

而藉由完善的風險管理流程，是可以讓專案裡這些先天不良的狀況（限制條件）一一現形，進而得到妥善的因應後，來提升專案成功的機率，而不僅是針對狹義的風險進行管理。因此，只要願意做風險管理的組織或PM，就有機會將這些先天的不良抓出來；只要願意做風險管理的組織或PM，就能讓專案成功的機率大大提升；而不做風險管理的組織或PM，那就有做不完的危機處理了。

風險管理流程

對於風險管理的方法，也就是那標準的五個流程：『規劃風險管理』、『辨識風險』、『分析風險』、『回應風險』，以及『監控風險』。而對於軟體專案來說，也一樣適用這個方法論，就是做好這五個風險管理流程步驟。

步驟一：規劃風險管理

PM要事先擬定整個專案的風險管理流程步驟、設計好將來會使用到的風險管理表單工具、排定風險管理會議時間與議程、安排例行性的風險管理活動、指定風險管理活動的負責人…等。

對於軟體專案來說，這個部分主要得視該專案所涉及的應用領域及內外部環境來做合適的安排。例如，若是承接外商銀行的案子，因為外商銀行受總行全球政策的影響大，分行自身的自主權小，那麼專案的風管活動頻率是要比做本土銀行勤快些、規劃的準備也會較多些。若是承接內部應用系統開發專案（ex. OA, MIS），因為所處內部環境的變動相較於外部環境的變化小，那麼專案的風管活動頻率會比做外部應用系統建置（ex. CTI, e-Commerce）的風管活動頻率低些。若承接的是一個不熟悉的新型研發專案、或是在新聞事件點上的企業、或客戶係處於景氣循環波動較大的產業別…等，那也最好在風管活動上要採取較高規格的對待，須亦步亦趨地貼近內外部環境的變化而因應。

也就是說，專案所涉及的環境愈複雜、變動愈頻繁、不確定性愈高的情況下，對於專案的風管活動自然是要求要更高些。反過來說，較為單純的環境、較為穩定的狀態、不確定性較低的條件下，也就不需要做複雜的風險管理流程步驟了。

步驟二：辨識風險

這部分就不宜還是只由PM一人完成，應廣納不同觀點會更好。對於專案中的技術性任務，專案成員們往往是最知道風險有哪些的人，因而邀請成員一同參與、以集思廣益的方式，來收集會影響專案任務無法如期如質如預算完成的風險項目，是很不錯的做法。而對於PM來說，最重要的是頭腦要很清楚的問自己，所負責之專案驗收的重點是什麼、專案成功或失敗的關鍵點是什麼、所交付的應用軟體必須有些什麼功能或資訊，客戶才會驗收，少了些什麼，客戶就必定無法驗收，為了開發出這樣的應用軟體，最關鍵的技術是什麼，掌握住了什麼技術就一定能做出產品，又是什麼地方只要不能百分百掌握住，就一定做不出來…..等。

舉例來說，若是ERP專案，那麼與組織營運流程的切合程度是重要的關鍵；若是資料倉儲專案，那麼資料的整理與呈現是重要的關鍵；若是HR專案，那與組織的人力資源發展策略的支持是重要的關鍵；若是CTI專案，那與客服中心的服務流程配合，以及與同業客戶服務水平的競爭，是重要的關鍵。

『專案獨特性』一直是專案不確定性的主要來源，也是危及專案成功的關鍵點，那正是PM要特別關注的地方。PM針對一個專案的獨特性，必須要能充分掌握，反覆思索與演練，務必做到能很清楚地“知道＂專案為什麼會成功、客戶為什麼會驗收、專案又為什麼會失敗…那才夠好。

步驟三：分析風險

針對每一項辨識出來的風險，一一給予仔細的評估，分析它發生的機率高低與發生後對專案所帶來的衝擊影響大小，並將風險項目排出重要性或優先順序。完成了這個動作，也才知道下一步要怎麼處理更好。高度風險當然是要獲得較多的關注處理，而低度風險也就放著即可，日後也只需觀察其變化，而無須給予太多的付出。

於此階段，PM最要注意的倒不只是各個風險項目的評估結果，而是成員如何做評估的，是否有遵循風險管理規劃時所訂定的評估準則，或者此評估準則是否需要任何的調整。評估時若帶有過度主觀意識，那可能會影響風險評等的結果，必須確保風險的分析是客觀地依據所設定的風險評估準則一致評價的。

另外，PM還要掌握住專案客戶（主要利害關係人）最在意、最無法忍受的地方是什麼，要懂得依據客戶的風險容忍度來做調整。常常是，涉及交易的軟體，會在時間上較無容忍度，要求能準時交付（Time to Market）；而只是內部流程改善的軟體，則在預算上較無容忍度，必須能控制在預算內完成。

步驟四：回應風險

做了分析後的風險項目，接著就是依風險的重要度及優先順序來擬定適當的回應行動，以便將風險的發生機率降下來，或將風險對專案的衝擊影響降下來。要辨識風險，不是太困難，而要能回應風險，尤其是有效的回應，就不是簡單的事了，這個部分就嚴苛地考驗了組織與PM以及專案成員們解決問題的能力。

對於交付標的未能通過驗收的風險、對於造成專案時程延遲的風險、對於會增加專案預算的風險…等，其因應方式大多就是朝『管理面』來下手，這個部分又再次考驗了PM對於專案管理知識的理解與運用能力。

將所探索出來的解決方案（即風險回應行動）納入專案規劃中，此刻的專案計畫已是一份更為完整的規劃考量。

步驟五：監控風險

一份已妥善考量了風險的專案計劃書，也就是一份已將專案不確定事件做了妥善預防的安排，依著這樣的計劃來執行，已是十分的妥當。然而，因為環境是動態的、管理也是動態的。所以，在整個專案進行期間，仍需要持續地做風險的監督與控制，包括注意專案內外部環境條件的改變、監督已識別風險的變化、檢視風險回應行動的有效性…等。

做一位PM幾乎得時時想著，是否未來會有什麼不確定事件即將發生，而將衝擊專案無法順利達成目標，對於這些可能事件，PM的因應又是什麼！對待專案總是多想一步、提早一步！重覆上述的風險管理流程步驟，能有效預防這樣的不確定事件的發生，或至少能在事件發生時有所因應準備（而非束手無策）。

風險管理是最後一道防線
 

即便你已完成了專案的初步規劃，你仍然要這樣做，把自己抽離專案，更客觀地看待自己的專案條件(condition)，你會察覺到專案隱藏的潛在威脅。而藉由開放又審慎的風險管理態度與風險管理技術的應用，能讓PM對自己的專案有更周全的規劃、更好的準備，讓你的專案不成功也難。