Describing risk: How much detail?

 

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 will 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.
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.
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.

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.

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).

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.

[For details of the RBS concept and use, take a look at the paper where this idea was first described, available online at www.risk-doctor.com/pdf-files/rbs1002.pdf.]