Using a Risk Breakdown Structure

The easiest way to understand an RBS is by drawing an analogy to the Work Breakdown Structure (WBS). In a WBS, a structure to the work that needs to be done in a project is created, while in an RBS a structure to the risks impacting your project is created. Carrying on with this analogy, let’s define an RBS. It is a tool through which you can group project risks and organize them in categories. Each category is then broken down into levels. Every level details out the source of risks to your project.

By using the RBS, you can also identify risk dependencies, understand the risk exposure to a project, and determine the root cause of risks. The RBS is a very useful tool for project managers. Let’s look at a visual example.

The following image shows an RBS that can be used for any project. (Click any image for a large view.)

Notice how each risk area is systematically broken down into levels. This is the reason why it is easier to identify, analyze and communicate risks impacting your project. As you go deeper into each level, you can identify potential risk triggers. In turn, this helps you to respond to risks effectively. In addition, the total risk exposure to the project is easier to understand and hence easier to plan for.

Note: There is no such thing as a one-fits-all project RBS. You will need to customize the generic RBS as per your industry, organization, and type of project.

Now that you have a visual of an RBS, have a look at a sample RBS for software development (shown below). This sample goes down to Level 3. However, that doesn't mean there can't be a Level 4 or a Level 5. For example, Level 4 may contain interfaces and testability. You are expected to customize an RBS as per your project's situation. For example, if you have outsourced work then communication barriers, communication technology, and cultural differences are all negative risks and would be a part of the RBS. Cost savings is a positive risk, which you will have to exploit effectively.

Best Practice: Encourage the project stakeholders, such as the core project team and client, to identify risks based on the framework provided by your customized RBS.

Some uses of RBS are:

• Risk Identification: After creating the RBS, your team can identify risks by using risk identification techniques, such as by conducting Brainstorming or SWOT Analysis workshops. As a risk is unearthed, it will be categorized in each topic in the RBS. Sometimes a risk may fall under several topics.
• Risk Analysis: An RBS provides you with the type of risk exposure to the project and the type of dependencies between risks. The RBS may also mislead you to think that a certain category is the most risky. For example, suppose in a project that Technology has more risks than Communication. This would lead you to believe that Technology is the most risky. However, this may not be accurate. You will need to conduct a Probability-Impact analysis of the risks to determine the severity. After all if Technology has a litany of low severity risks and Communication has a couple of high-severity risks, then Technology is not as risky as Communication.
• Project Comparisons: With an RBS you can compare two projects. For example, if you have conducted a SWOT Analysis on two projects, your organization has to pick one. An RBS would enable you to understand the entire project risks associated with each project. You can then use Decision Trees and conduct an Expected Monetary Value (EMV) analysis.