作業: 識別和評量風險
這項作業說明如何識別、分析專案風險及設定風險優先順序,確定適當的風險管理策略,以及將它們反映在專案的風險清單中。
規範: 專案管理
目的
  • 識別和分析專案的風險及設定風險的優先順序
  • 確定適當的風險管理策略
  • 更新風險清單來反映現行專案狀態
關係
步驟
識別潛在的風險
目的 建立專案「什麼東西可能出錯」的庫存。 

起始風險清單(初始階段):

請將專案小組聚集在一起(這時專案小組應該很小;如果這時專案小組超過 5-7 人,請將風險評量流程限制於活動負責人)。

當我們識別風險時,我們會考慮「什麼東西可能出錯」。當然,在最寬的層次上,任何東西都可能出錯。不過,重點是不要在專案上強加悲觀的觀點;我們要識別成功之前可能需要面對的障礙,以便減少它們、消除它們。如需詳細資訊,請參閱工作成果準則:風險清單

更明確地說,我們是在尋找某些可能發生的事件,我們可能因為這些事件而難以在預算內,準時交付有正確特性和必要品質層次的專案。

請利用集體研討技術,要求每位成員識別一項專案風險。可以接受說明性的問題,但風險不應由小組來評估或評論。請逐步進行,直到無法識別其他風險為止。

請邀請各關係人加入這個流程,不要太擔心形式或重複;您可以稍後再清理這份清單。請用同類的人(客戶、使用者、技術人員等)。這會簡化收集風險的程序;相較於眾人雜處,人們在同事(專業和階層)前面比較不會羞怯。

請清楚告訴各位參與者,提出風險完全不等於自願處理風險。如果有任何提出風險就必須處理風險的感覺,就不會有人識別任何風險(或只會提出無關緊要的風險)。

為了鼓勵識別風險,請嘗試從一般風險清單開始,如 Capers Jones 的 Assessment and Control of Software Risks [JON94],或 Software Engineering Institute 所建立的 the Taxonomy-Based Risk Identification [CAR93]。請傳閱這份風險清單:看到已識別的風險,通常可以協助人們識別出其他風險。

更新風險清單(稍後的階段):

您可以依照上面所識別的方式來徵求輸入。但一般而言,新風險通常是在現有清單範例的基礎上,由小組成員來識別,放在一般專案的「狀態評量」中。請參閱作業:評量反覆

分析風險和設定風險優先順序
目的 結合類似的風險(縮小風險清單)。
依風險對專案的影響,將風險分級。 

在找不到任何其他風險之後,請將風險清單當作一個群組來看待,看其中是否有任何自然分組(出現相同風險),可能的話,請結合風險來消除重複。有時候,所識別的風險會是某些更根本的風險所表現的症狀;在這個情況下,請將相關的風險分組在更根本的風險之下。

定量風險管理技術建議您根據風險對於專案所代表的整體風險曝露來設定風險的優先順序。如果要確定各項風險的曝露,小組應該預估下列資訊:

風險的影響  如果發生風險,計劃的排程、工作或成本所發生的偏差
發生的可能性  風險實際發生的可能性(通常是用百分比來表示)
風險曝露  影響乘以發生的可能性

每個風險的曝露都應該由小組的共識衍生。重要的不同意見應該進一步討論,以瞭解每個人是否用相同方式來解釋風險。這項資訊通常都會併入風險清單列表格式中,成為其中的一些直欄。

基於本性,人們往往會擔心可能造成最大影響的風險,但如果它們很不可能發生,其實中等風險比較重要,但人們往往會忽略中等風險。這個方法會考量風險的強度和發生的可能性,以協助專案管理人員將他們的風險管理工作焦點放在會嚴重影響專案交付的部分。

在各項風險曝露確定之後,您便可以依照曝露的遞減順序來排列風險,建立您的「前 10 項」風險清單。

由於可能性和費用的預估本身便是高成本且帶有風險,因此,一般只會測量最前面 10 到 20 個風險的影響。較小專案可以考慮較少風險,較大的專案則是較大的「風險目標」,也因此會有較多相關風險。

除了依照曝露遞減次序來排列風險之外,您也可能發現,根據風險影響專案的強度(風險強度),將風險分組成幾個種類會很有幫助。在大部分情況下,五個種類便已足夠:

  1. 重要
  2. 中等
  3. 次要

請寫下各項風險,在專案小組成員之間傳閱。

識別風險迴避策略
目的 重組專案來消除風險

雖然不一定能夠,但您有時可以完全避開風險。風險通常是因系統範圍不好所造成;如果您可以縮減系統範圍(消除不重要的需求),風險清單的許多部分都會因需求取消而被刪除。在這些風險中,資源(包括時間)不足以完成工作,並不是最小的一項風險。

在其他情況中,您也可以獲取技術來降低建置特定功能的風險,這是將一組風險(建置技術)交換為另一組風險(依賴在控制之外的力量)的風險迴避形式。

最後是風險可以移轉到其他組織。

識別風險緩和策略
目的 開發緩和風險的計劃,也就是降低風險的影響。 

對於直接風險,也就是專案在某個程度上能夠加以控制的風險,請識別將採取什麼行動來降低風險的可能性,或降低風險對於專案的影響(緩和策略)。一般而言,風險都是從缺乏資訊衍生而來;緩和策略本身通常便是進一步探索主題來減少不確定性。

有些風險是可以採取行動來使風險具體化或加以排除。在反覆式的開發流程中,請在初期反覆中配置這類行動,以便儘早緩和風險。請儘早面對風險。如果風險的形式是「X 可能無法依照計劃運作?」,請規劃儘快嘗試 X。

範例:

  • 為了降低無法整合 X 和 Y 產品的風險,便建置一個原型來探索整合的困難。將測試下列特性(列舉在清單中)來確保整合會順利完成。
  • 為了降低無法適當執行 A 資料庫的風險,將利用一套測試來建立目標應用程式的工作量模型,以進行它的基準性能測試。
  • 為了降低測試工具 Z 無法有效進行應用程式之退化測試的風險,在即將來臨的反覆中,我們將取得它和使用它。

這些動作應該會降低某些發生風險的可能性,且有可能會接近零。如果風險獲得確認,就用應變計劃來回應風險(請參閱識別應變策略)。

識別應變策略
目的 開發替代計劃

對於各種風險,不論您有沒有積極緩和它的計劃,您都必須決定當(或如果)風險實現了,也就是說,當風險成為問題,成為一項保險術語中的「損失事件」,這時您要採取什麼行動。這通常稱為「'B' 計劃」,或應變計劃。當風險迴避和風險移轉失敗,緩和不很成功,必須正面處理風險時,便需要應變計劃。間接風險(也就是專案無法控制的風險),或當緩和策略成本太高以至於無法實施之時,通常便是如此。

應變計劃應該考慮:

風險

指標

動作

什麼是風險?  您如何知道風險已成為現實? 如何辨識「損失事件」?   處理「損失事件」時,應採取什麼動作(如何停止「損失」?) 

識別風險指標

有些風險可以利用專案測量值,查看趨勢和臨界值來監視;例如:

  • 重做剩餘過高
  • 毀損剩餘過高
  • 實際費用超出計劃太多

有些風險可以根據專案需求和測試結果來監視;例如:

  • 強度在需求之上的指令回應時間。

部分風險會關聯於特定事件;例如:

  • 第三方未及時交付軟體元件。

另外,還有許多其他「較軟」的指標,它們都無法充分診斷問題。例如,永遠都會有士氣低落的風險(事實上,在專案的某些點上,這幾乎是可預期的)。指標有許多:抱怨、黑色幽默、錯過截止時間、品質不好等。這些「測量」都不是可靠的指標;關於特定交付項目沒用的玩笑可能是一種健康的壓力舒解方式,但如果情況不變,可能表示小組逐漸感受到即將來臨的厄運。

請傾聽所有指標,不要判斷。傳遞「壞消息」的人,很容易被貼上標籤,成為態度不好的人;但譏諷言詞的背後,往往藏著真理。「壞消息的信使」通常扮演著「專案良知」的角色。大部分人都希望專案成功,如果專案走向另一方向,他們會感到挫敗。

識別「損失」動作或「B 計劃」

如果是簡單的情況,應變計劃會列舉各個替代解決方案。影響通常在於報廢現行解決方案、實作新方案所帶來的成本和延遲。

至於其他狀況,「較軟」的風險在發生損失狀況時,通常並不是採取單一動作,而是許多動作。例如,當士氣低落時,最好是承認狀況,聚集一個小組來討論普遍的專案態度。請傾聽各項憂慮,找出問題,讓大家發洩情緒。不過,在適當發洩之後,要繼續處理憂慮的原因。請利用風險清單,使討論焦點集中。請將這些憂慮轉換成具體的行動計劃,重設風險的優先順序,再形成反覆計劃來系統地處理最前面的風險。積極行動的效果比正面但空洞的言詞更有力。

雖然一時情緒會不好,但損失的狀況也有正面的價值:它會強迫行動。忽略風險,通常只是將風險延後,在表面的平靜之下,陷入自滿之中。當發生損失事件時,需要採取行動。這時風險已經不是風險,它的存在已經無可置疑。

可是,發生損失也在於風險的迴避或緩和失敗。這時應該強制重新檢查風險清單,以確定專案小組是否有任何系統性的盲點。這與坦白的自我評量一樣困難,但它可以防止後來發生其他問題。

在反覆期間重訪風險
目的 確保在整個專案中,風險清單隨時都保持最新。 

風險評量實際上是一個連續程序,而不是在專案期間,依特定間隔出現。您至少應該:

  • 每週重讀您的清單,看看有了什麼改變。
  • 讓最前面 10 個項目呈現在整個專案面前,堅持對它們採取的動作。您通常會將現行風險清單附加到您的狀態評量報告中。
在反覆結束時重訪風險
目的 確保在整個專案中,風險清單隨時都保持最新。 

反覆結束時,請關聯於風險清單,將焦點重新放在反覆目標上。明確地說,便是:

如果您發現在初始階段和詳述階段,風險清單加長了,請不要太擔心。當專案成員執行這項工作時,他們會瞭解到,他們認為是無關緊要的東西,實際上包含著風險。當您開始整合時,您可能會發現一些隱藏的困難。不過,當專案到了詳述結束時,以及在建構期間,風險應該會穩定地降低。若非如此,可能是您並未適當處理風險,或系統太複雜,或是不可能建置系統性而可預測的樣式。如需詳細資訊,請參閱工作成果準則:風險清單