Key message: A Risk Breakdown Structure is the first and critically necessary step to identify risk events. It assists with defining risk events and in risk reporting.
As the title of this article suggests many risk practitioners think the development of a RBS is at worst a total waste of time and at best of little value.I have seen facilitators of the risk assessment process dive straight in and start populating a risk register with individual risk events.Whilst this is a common practice I believe it does not assist in the identification of many potential or otherwise neglected sources of risk.The practice of using a Breakdown Structure (BS) comes from Project Management in the form similar to that of a Work Breakdown Structure (WBS).
Whilst the WBS provides a detailed graphical representation of the project scope of work, the essence of the RBS is to clearly set out the potential areas and categories of risk within the context of the subsequent Risk Assessment.We use Risk Areas and Categories to help dissect the context to a level where the risk event descriptions can be detailed and more clearly defined.How to define a risk event is the subject of a subsequent article.Whilst I am not advocating the need to develop an RBS to the level of detail of the WBS, the two levels are a good starting point.
Risk Areas are the highest and broadest level of the RBS. These represent major or significant known and/or potential areas of risk within the Context of the project/activity/decision. Several tools can be used to assist in defining these Areas including: Input-Process-Output; SIPOC; Project Life Cycle Phases; Organisational Breakdown Structure (OBS); brain storming, mind maps; a combination of tools etc. Risk Areas can then be decomposed into more detail. This level of the RBS is called Risk Categories. Any Risk Area must have more than one Risk Category in order for it to be valid. Risk Categories define the next level of detail in order to assist in the detailing of specific risk events.
Having completed the RBS to this level it can then be used to confirm both the other data within the “Establish the Context” step and as a communication tool to stakeholders to confirm their understanding of the risk map for the project/activity/decision.
Some practitioners who do support the development of an RBS suggest there is a third level and that this level consists of the risk events themselves. I do not support this level as it makes the RBS a cumbersome and complicated document. The risk register in my view is where the risk event descriptions belong and not the RBS.
Using the construct of the RBS to tag specific risk events helps in communicating, monitoring, reviewing and reporting risk data. In terms of communicating and reporting of risk events or groups of risk events by tagging risk events on the risk register with the appropriate prefixes as the risk area and risk category a valuable risk report can me generated. For example a stakeholder may request to view all of the financial risk events. Finance may have been an area or category. Without developing a RBS this may not be possible. A more specific report could be provided.
For example if Finance was the Risk Area and Credit was one of the Risk Categories then a report with all of the financial credit risks could be provided.
Having completed your first RBS this could then be used as a start point for subsequent risk assessments.
Starting with a “Brownfield” rather than a “Greenfield” RBS has some distinct advantages for those involved with, or wanting to facilitate a risk assessment. Whilst every context will be different there maybe some similarities and to reduce the amount of work and discussion need to prepare a new RBS each time a risk assessment is planned a generic or similar RBS assist greatly.
If you have not created a RBS before go off and give it a shot. For those who already use the RBS I hope this article helps justify its value to those who are detractors.
Note: in this article risk can mean both threats and opportunities