 |
朋友：「就很多新功能都沒做過，風險當然很高啊！」
我：「那你們是怎麼描寫這些風險項目的？舉個例子來聽聽…」
朋友：「大概就是依據經驗，判斷每個新功能的複雜度，再分別給它們高、中、低的風險等級啊…」
「這樣的風險描述，聽起來好像只是依據功能複雜度來評量風險，功能複雜其實未必會是風險的成因。有沒有可能是因為風險的描述，沒有抓到要點，才會造成你所謂的風險，其實根本就不是真的風險，只是一種無關緊要的不確定，而相關的資源和行動也根本就用在錯的地方，所以現在才會被迫救那些到處冒出來的火？而這些火，就是當初那些沒被好好照顧到的風險，所衍生出來的？」
這個世界上很多事情都存在著一些不確定性，只是，當中有些不確定性很高，有些則較低，有些跟我們的專案有關，有些則無關。對一位專案經理而言，他／她只需要關注那些和專案目標有關的不確定即可。那麼，什麼又叫做「跟專案目標有關的不確定」呢？
舉個例子來說，每個專案都會有個最後期限，它也就是所謂的「專案時程目標」，是專案的諸多目標之一。任何有可能（Probability）會對專案完工日期（Objective）造成延遲影響（Impact or Effect）的事件（Event），就是「風險」之所在。
於是，我們就可以把風險定義為「可能會對專案目標造成影響（Impact or Effect）的不確定事件（Uncertain Event）以及其原始原因（Cause）」，而這個「原始原因」則必須是個「事實（Fact）」。
一個原始原因（Cause）可能會造成許多個不確定事件（Uncertain Events），而這些不確定事件，卻不一定每個都會對專案目標造成影響（Impact or Effect）。可能會對專案目標造成影響的不確定事件，才是「風險」！
所以，風險不是「已知」的問題或議題（problem, bug or issue），風險是一種「會對專案目標造成影響」的「不確定」。
掌握了這幾個要點來做風險的結構化描述，才能夠讓風險的溝通和管理事半功倍！
風險無所不在
您也許會想問，那我們做專案為什麼要一直冒風險呢？難道不能做個沒有風險的專案嗎？
我們來看一個生活上的經典案例：換手機。除了因為故障或者是遺失的原因之外，我們為什麼會一直想要換新手機？理由很簡單，就是我們想要的新手機，可以提供新的「價值」給我們，不管這個價值是種無形的虛榮感，可以拿來向朋友炫耀某種品味，還是這個價值是個有形的、實實在在的好功能。
既然如此，手機廠商也就會不斷地想辦法，提供新的價值給用戶，同時也為自己創造新的盈餘。於是，以改善舊功能、舊外觀，或是增加新功能、新色彩，來產出新產品，就變成是專案的一個常態。
然而，不論是哪一種作法，對新專案來說，即使是已經用某個舊專案做為參考基準，這些新東西就一種「變異」。而變異，就會產生一些不確定；而不確定，就可能對專案目標造成影響，這種不確定就是專案的風險！
所以，風險是資本主義下，求新求變的經濟活動，所無可避免的產物啊！
風險只能被好好管理
既然專案風險是無可避免的，那我們也只能好好地去管理它們。怎麼管呢？第一步當然就是「盡可能地」把所有的風險都辨識出來囉。
之所以會用「盡可能」這個詞，其實是因為，在實務上，我們根本就不可能一次就把「所有」的潛在風險都全部辨識出來。況且，很多東西是需要實際動手做了之後才會發現，原來不是當初規劃想像的那回事兒！就算是諸葛亮也有百密一疏，讓自己和團隊身陷險境的時候（空城計就是一例）。風險常常會像程咬金那樣，突然從半途中殺出來！
好，那既然不能一次就把所有的風險全都辨識出來，那麼，我們就必須定期地、持續地做「風險辨識」的動作。不僅要把過去這段期間，專案進行的過程和狀態都再全部審視一遍，看看有沒有什麼新的風險突然冒出來，同時也要看看，先前列管的舊風險有沒有什麼變化，是消失不見了，還是機率變高了，後果會不會變得更嚴重了。
例如，對於那些已經完工並且已經驗證完成的工作成果，它們的相關風險項目，就可以不用再繼續追蹤下去，當初為這些風險所預留的相關緩衝時間（buffer）和預算等「準備（Reserve）」，也都應歸還給專案和組織。而對於那些新開工的工作，我們就得留意可能衍生出來的新風險！
接下來，我們就來看看，一個新手機專案，在實務上是如何做風險管理的。（下篇）
舉個例子來說，每個專案都會有個最後期限，它也就是所謂的「專案時程目標」，是專案的諸多目標之一。任何有可能（Probability）會對專案完工日期（Objective）造成延遲影響（Impact or Effect）的事件（Event），就是「風險」之所在。
於是，我們就可以把風險定義為「可能會對專案目標造成影響（Impact or Effect）的不確定事件（Uncertain Event）以及其原始原因（Cause）」，而這個「原始原因」則必須是個「事實（Fact）」。
一個原始原因（Cause）可能會造成許多個不確定事件（Uncertain Events），而這些不確定事件，卻不一定每個都會對專案目標造成影響（Impact or Effect）。可能會對專案目標造成影響的不確定事件，才是「風險」！
所以，風險不是「已知」的問題或議題（problem, bug or issue），風險是一種「會對專案目標造成影響」的「不確定」。
掌握了這幾個要點來做風險的結構化描述，才能夠讓風險的溝通和管理事半功倍！
風險無所不在
您也許會想問，那我們做專案為什麼要一直冒風險呢？難道不能做個沒有風險的專案嗎？
我們來看一個生活上的經典案例：換手機。除了因為故障或者是遺失的原因之外，我們為什麼會一直想要換新手機？理由很簡單，就是我們想要的新手機，可以提供新的「價值」給我們，不管這個價值是種無形的虛榮感，可以拿來向朋友炫耀某種品味，還是這個價值是個有形的、實實在在的好功能。
既然如此，手機廠商也就會不斷地想辦法，提供新的價值給用戶，同時也為自己創造新的盈餘。於是，以改善舊功能、舊外觀，或是增加新功能、新色彩，來產出新產品，就變成是專案的一個常態。
然而，不論是哪一種作法，對新專案來說，即使是已經用某個舊專案做為參考基準，這些新東西就一種「變異」。而變異，就會產生一些不確定；而不確定，就可能對專案目標造成影響，這種不確定就是專案的風險！
所以，風險是資本主義下，求新求變的經濟活動，所無可避免的產物啊！
風險只能被好好管理
既然專案風險是無可避免的，那我們也只能好好地去管理它們。怎麼管呢？第一步當然就是「盡可能地」把所有的風險都辨識出來囉。
之所以會用「盡可能」這個詞，其實是因為，在實務上，我們根本就不可能一次就把「所有」的潛在風險都全部辨識出來。況且，很多東西是需要實際動手做了之後才會發現，原來不是當初規劃想像的那回事兒！就算是諸葛亮也有百密一疏，讓自己和團隊身陷險境的時候（空城計就是一例）。風險常常會像程咬金那樣，突然從半途中殺出來！
好，那既然不能一次就把所有的風險全都辨識出來，那麼，我們就必須定期地、持續地做「風險辨識」的動作。不僅要把過去這段期間，專案進行的過程和狀態都再全部審視一遍，看看有沒有什麼新的風險突然冒出來，同時也要看看，先前列管的舊風險有沒有什麼變化，是消失不見了，還是機率變高了，後果會不會變得更嚴重了。
例如，對於那些已經完工並且已經驗證完成的工作成果，它們的相關風險項目，就可以不用再繼續追蹤下去，當初為這些風險所預留的相關緩衝時間（buffer）和預算等「準備（Reserve）」，也都應歸還給專案和組織。而對於那些新開工的工作，我們就得留意可能衍生出來的新風險！
接下來，我們就來看看，一個新手機專案，在實務上是如何做風險管理的。（下篇）
圖片來源：twoicefloes.com
|