Have you ever considered the risks to your project’s successful completion during the planning stages of your project? If not, I would suggest it is a highly beneficial exercise to help you grow in your project management career.
A Risk Breakdown Structure (RBS) is an organized way of categorizing the risks to a project. According to the Project Management Institute’s Project Management Body of Knowledge, the risks to a project are itemized in a risk register, and then prioritized via qualitative and quantitative analysis. The RBS provides broad risk categories within which to organize the risks.
It is, in fact, much simpler than the unwieldy name suggests. It’s nothing more than a table with risk categories broken down into increasingly specific subject matter.
Purpose
Why would you create risk categories?
- To provide a system of organization. The full risk register can contain 10 – 50 different risks, depending on the project. There are always many risks that have little in common, for example losing project team members, being unable to find software, and experiencing poor vendor performance.
- Assists in identifying risks. It’s remarkably easy to miss entire risk categories when identifying risks. The RBS keeps things organized and helps in brainstorming the potential risks to the project.
- Provides a starting point for the risk management plan.
If you manage many projects that are similar in nature, an RBS would be a great thing to make once and then reference later. Inevitably, when categorizing risks a category list is the logical starting point.
A Recent Addition
The RBS was not included in the PMBOK until two editions ago, and not refined until the present edition. I presume that the reason it was added had to do with the intuitive nature of creating risk categories before brainstorming the risks present in each category. Everybody was doing it informally, so they gave it a name and encoded it in the standard.
Small Projects
It might not be cost effective to have a large and elaborate risk register for small projects. But I would argue that at some consideration of the project risks is always a good idea. Even if you’re doing something around the house, like building a fence, a few minutes to think about the most likely hiccups is probably a good idea. If you have clients and other project stakeholders they might even appreciate the intent to mitigate some of the project risks before they arise.
Standard risk management practice would consist of the following:
- Creating the Risk Breakdown Structure
- Developing the Risk Register (list of risks)
- Risk Analysis, which consists of determining a ranking (1-10 or similar) of the probability and impact of each risk. Usually an overall ranking is also produced.
- Determining the response plans where necessary
- Developing a monitoring and control plan to revisit (strike off or re-analyze) risks throughout the project.
For small projects, you can determine how much is appropriate for you.
Example
A risk breakdown structure for a software project might have the following categories:
- Business: Competitors, suppliers, cash flow
- Technical: Hardware, software, network
- Organizational: Executive support, user support, team support
- Project Management: Estimates, communication, resources
It’s different for every industry. Make sure you use the risk categories that are right for you.
