Risks can be identified and described at different levels of detail, and there can be considerable variation between different projects or organisations. Some projects identify just a small number of high-level risks, while others have many hundreds or even thousands of detailed risks. A generalised or high-level description of risk can make it difficult to develop responses and assign ownership, while describing risks in a lot of detail can create a great deal of work. How can we determine the correct level of detail? There are three components to consider : management, ownership, and reporting.
風險可以以不同的細節層次辨識及描述之，而且在不同的專案與組織間也有相當的差異。有些專案僅辨識少數 的高層次風險，有些專案則可能有數百甚至數千個細部的風險，一個一般化或高層次的風險描述，可能導致很難發 展其風險回應及指派負責人；然而描述太多風險的細節又會產生大量的工作。我們該如何決定風險的細節層次呢？ 有三個考慮的因素：管理、負責人、以及報告。

1. Firstly, risks should be described at the level to which they are going to be managed. A high-level description such as“Something unexpected might happen during the project” is quite useless as no management action is possible at this level. Too much detail is also pointless, for example “George Smith the junior system architect may break his right leg at the football match next Tuesday night and not be able to finish the Phase 2.4.2 detailed design drawings.” The risk might be better stated as “Key staff may not be available when required to complete the system design.” At this level the risk can be managed proactively, with careful resource planning, use of shadowing or deputies, and ensuring that key tasks are not assigned to one person. Of course it is true that some risks will need to be managed at a detailed level while others can be addressed at a higher level.
1. 首先，風險應該在其將要被管理的層次上描述，太高層次的描述如「在專案執行過程中有某種不預期的事會發 生」是一種相當無意義的描述，因為在此一層次上是不可能採取任何管理行動的；然而太多的細節也沒有意義 ，例如「初級系統設計師史喬治可能會在下週二晚上的足球賽中摔斷他的右腿，因此而無法完成第2.4.2階段 之細部設計圖」，這個風險的較佳描述方式為「關鍵成員無法在有需要時可用以完成系統設計」，在這個層次 上，風險可以用謹慎的資源規劃、使用替代者或副手、以及確保某項關鍵工作不要被指派給某個人等方式積極 地管理。當然有些風險需要在較細節的層次上被管理，然而有些卻可以在較高的層次上應付。

2. Secondly, each risk should be described at a level of detail where it can be assigned to a single owner, with clear responsibility and accountability for addressing the risk. However this also allows for some variation in the level of risk description, as risk owners can range from junior team members who might be responsible for detailed risks, through to the project sponsor or senior managers who are only interested in the higher level.
2. 其次，每個風險都應該在一個細到足以指定單一負責人的層次上描述，並賦予其清楚的權責以應付該風險。然而由於風險負責人的範圍，可以從負責細部風險的初級團隊成員，到只對高層次風險有興趣的專案贊助者或資深經理，因此風險描述上也允許有一些層次上的差異。

3. Thirdly, the level of risk description should match the reporting needs of the person receiving the risk report. Project team members need detailed risk descriptions for those risks which they are responsible for managing. The project sponsor or client needs less detail, perhaps with groups of risks being summarised into high-level descriptions.
3. 第三，風險描述的層次應該配合接受風險報告者的報告需求。專案團隊成員在那些他們負責管理的風險上，需 要細部的風險描述；專案贊助者或顧客則需要少一點細節，也許是將一群風險彙總成較高層次的描述。

Each of these three answers suggests that risk descriptions can be useful at various levels for different purposes. There is no one right level that meets all needs. So what can be done?
以上的三個答案建議風險描述對不同的目的而言要有不同的層次才有用，並沒有一個正確的層次可以符合所有需求，那麼，可以怎麼做呢？

One useful tool addressing this issue is the Risk Breakdown Structure (RBS), which is a hierarchical structure describing sources of risk to the project. This allows risks to be described at increasing levels of detail throughout the project. At the top level (Level 0), all risks are simply “Project Risks”. But this can be broken down into major sources of risk at Level 1, such as Technical Risk, Commercial Risk, Management Risk, External Risk. Each of these major areas can be further detailed at Level 2 (for example Technical Risk could be subdivided into Technology, Performance, Reliability, Interfaces etc). At the lowest level individual risks are described under each specific source.
應付這個問題的一個工具是風險分解結構（RBS），它是一個對專案風險來源階層結構化的描述，這允許風險可以在整個專案中，以細節層次漸增的方式被描述。在最高層次上（第0層），所有風險僅僅是「專案風險」，但是這可以向下分解到第一層風險的主要來源，如技術風險、商業風險、管理風險、外部風險等，每一個主要領域都可以在第二層進一步細節化（例如技術風險可以細分為技術、性能、可靠度、界面等）。在最低層的個別風險則是在每一個特定的來源之下被描述。

Different RBS levels can then be used for different purposes. Detailed risk reporting, ownership and management can take place at the lowest level. Higher RBS levels allow groups of risks to be rolled-up and summarised for reporting, ownership and management further up the organisation. So the project safety engineer may need to know about a specific risk affecting a particular product trial (RBS Level 4), whereas the company's Chief Technical Officer may be interested in the overall level of technical risk on the project (RBS Level 1).
於是，不同的風險分解結構層級可以在不同的目的下使用，細部的風險報告、負責人、以及管理可以在最低層發生，較高的風險分解結構層級使得一群風險可以在組織的較高層級中，被組合並彙總起來報告、指派負責人、以及管理。所以，專案安全工程師可能需要知道會影響一個特別產品試用的某特定風險（RBS第四層），然而，公司的首席技術經理卻可能對專案技術風險的整體水準有興趣（RBS第一層）。

Risk descriptions at different levels of detail are useful in different ways. Instead of insisting that all risks are described at a single level which may not suit all needs, using a hierarchical RBS can provide the necessary flexibility with both high-level and more detail as appropriate.
不同細節層次的風險描述可用在許多不同方面，除了堅持所有風險要在單一層次上描述可能無法適合所有需要外，使用階層化的風險分解結構可以因為同時有高層次以及適當的細節之下，提供必要的彈性。