描述風險：需要多細？－IamAlexKao的部落格

Describing Risk : How much Detail?

描述風險：需要多細？

轉錄自【博鴻PM充電週報第64期】

風險可以以不同的細節層次辨識及描述之，而且在不同的專案與組織間也有相當的差異。有些專案僅辨識少數的高層次風險，有些專案則可能有數百甚至數千個細部的風險，一個一般化或高層次的風險描述，可能導致很難發展其風險回應及指派負責人；然而描述太多風險的細節又會產生大量的工作。我們該如何決定風險的細節層次呢？

有三個考慮的因素：管理、負責人、以及報告。

1. 首先，風險應該在其將要被管理的層次上描述，太高層次的描述如「在專案執行過程中有某種不預期的事會發生」是一種相當無意義的描述，因為在此一層次上是不可能採取任何管理行動的；然而太多的細節也沒有意義，例如「初級系統設計師史喬治可能會在下週二晚上的足球賽中摔斷他的右腿，因此而無法完成第2.4.2 階段之細部設計圖」，這個風險的較佳描述方式為「關鍵成員無法在有需要時可用以完成系統設計」，在這個層次上，風險可以用謹慎的資源規劃、使用替代者或副手、以及確保某項關鍵工作不要被指派給某個人等方式積極地管理。當然有些風險需要在較細節的層次上被管理，然而有些卻可以在較高的層次上應付。

2. 其次，每個風險都應該在一個細到足以指定單一負責人的層次上描述，並賦予其清楚的權責以應付該風險。然而由於風險負責人的範圍，可以從負責細部風險的初級團隊成員，到只對高層次風險有興趣的專案贊助者或資深經理，因此風險描述上也允許有一些層次上的差異。

3. 第三，風險描述的層次應該配合接受風險報告者的報告需求。專案團隊成員在那些他們負責管理的風險上，需要細部的風險描述；專案贊助者或顧客則需要少一點細節，也許是將一群風險彙總成較高層次的描述。

以上的三個答案建議風險描述對不同的目的而言要有不同的層次才有用，並沒有一個正確的層次可以符合所有需求，那麼，可以怎麼做呢？

應付這個問題的一個工具是風險分解結構（RBS），它是一個對專案風險來源階層結構化的描述，這允許風險可以在整個專案中，以細節層次漸增的方式被描述。在最高層次上（第0層），所有風險僅僅是「專案風險」，但是這可以向下分解到第一層風險的主要來源，如技術風險、商業風險、管理風險、外部風險等，每一個主要領域都可以在第二層進一步細節化（例如技術風險可以細分為技術、性能、可靠度、界面等）。在最低層的個別風險則是在每一個特定的來源之下被描述。

於是，不同的風險分解結構層級可以在不同的目的下使用，細部的風險報告、負責人、以及管理可以在最低層發生，較高的風險分解結構層級使得一群風險可以在組織的較高層級中，被組合並彙總起來報告、指派負責人、以及管理。所以，專案安全工程師可能需要知道會影響一個特別產品試用的某特定風險（RBS第四層），然而，公司的首席技術經理卻可能對專案技術風險的整體水準有興趣（RBS第一層）。

不同細節層次的風險描述可用在許多不同方面，除了堅持所有風險要在單一層次上描述可能無法適合所有需要外，使用階層化的風險分解結構可以因為同時有高層次以及適當的細節之下，提供必要的彈性。

『更詳細的風險分解結構概念及其使用，參閱www.risk-doctor.com/pdf-files/rbs1002.pdf』