In project management, controlling risk is a critical component of the project plan. A well-thought-out plan considers all the risks that can bring a project to its knees, with the goal of minimizing, if not eliminating, their impact on the project. Failure is costly, in time and money.
That’s a lot of money, considering billions are spent on projects every year.
But not all risks are created equally, and with schedule adherence an integral ingredient to project success, teams must know how to prioritize their risks. This is where the risk breakdown structure comes in handy.
Overview: What is the risk breakdown structure (RBS)?
- Work breakdown structure (WBS): Breaks the project down into small work components
- Organization breakdown structure (OBS): Depicts an organization’s structure and the relationships between the different jobs and positions
- Resource breakdown structure (RBS): Lists the project’s resources — such as people, materials, and equipment — by type and category
- Risk breakdown structure (RBS or RiBS): Organizes risks into categories
The risk breakdown structure is an ordered breakdown list of the risks — internal or external, anticipated or unforeseen — that can impact the project’s scope, schedule, and budget. It’s hierarchical and graphical in nature.
A risk breakdown structure allows you to do the following:
- Organize risk data to facilitate understanding
- Highlight project areas that require special attention
- Pinpoint any recurring risk themes
- Identify areas of the project with a concentration of risks
- Define the project’s total risk exposure, which is a summary of potential losses
- Outline the risk management process
A risk breakdown structure categorizes the project’s risks, which you can further break down into any levels of detail. Project risk categories can include:
- External risks: These are risks that are outside your control. Examples are environmental or regulatory risks, suppliers, and competitors.
- Internal risks: Internal risks happen in-house, such as lack of resources, funding delays, or prioritization mistakes.
- Technical risks: These include ambiguities in the scope or requirements definition and technology obsolescence.
- Project management risks: These risks can impact planning, communication, project control, etc.
Most risks will fall in any one of the above buckets. In some cases, you may have to create additional categories.
Uses of the risk breakdown structure
The risk breakdown structure can be used in several ways, including:
Use #1: Risk identification tool
Risk identification determines, documents, and communicates risks that can hinder a project from realizing its goals and objectives. Questions to ask during this process include:
- What could possibly go wrong in the future?
- What has gone wrong in the past that can possibly happen again?
Tips for identifying risks
- Choose your risk identification method: There are many tools and techniques you can use to identify potential risks, such as:
- Interviews or workshops
- Reviewing project documents
- Root-cause analysis
- SWOT (strengths, weaknesses, opportunities, and threats) analysis
- Delphi technique in which a panel of experts are sent multiple rounds of questionnaires until a consensus is reached
- Create a risk register: Also known as a risk log, a risk register lists the risks you’ve identified, plus relevant information about each risk, such as the nature of the risk and its associated risk management measure. Just like the stakeholder register, it’s a living document that you update throughout the project’s life cycle.
Use #2: Risk analysis
Risk analysis assesses each of the project’s risk events to determine its impact on the project’s objectives or outcome. It follows the risk identification process.
Tips for analyzing risks
- Qualitative vs. quantitative risk analysis: Assess each risk’s probability of occurrence and project impact using quantitative and qualitative risk analysis to expose and prioritize high-impact risks.
- Update your project documents: Once you’ve assessed the risks, update all relevant documents, such as the risk register and the project communication plan that details your risk communication strategies.
Use #3: Risk reporting
Communicating consistently and effectively is a project management basic. Project managers use risk reports to convey risk assessment outcomes to key stakeholders, such as the client or the project owner. The goal is to:
- Help them understand current risks, trade-offs, and opportunities
- Prevent any unpleasant surprises
- Help them make risk-informed decisions
A few things to remember about risk reporting
- A project risk report is not the same as the project risk register: The risk register contains all identified project risks, while risk reports for senior management, typically only include significant risks.
- Risk reporting is a standard reporting requirement: Project risk reports are part of a reporting cycle, usually set weekly, semi-monthly, or monthly.
Use #4: Post-project review
A project post-mortem is a best practice conducted at project conclusion. One of several RBS benefits is the ample information they provide, which you can use to create post-project reports for future projects.
Tips for identifying post-project lessons
- Document lessons learned: Aside from a review of the project’s metrics, your post-project analysis may include an evaluation of the risk management process and its role in the project’s failure or success.
- Analyze post-project reports for common risks: Post-project analysis reports may uncover recurring risks, allowing your organization to establish and implement preventive measures.
Use #5: Project comparisons
If you need to rank two projects, or select only one, an RBS analysis can compare the projects and understand their associated risks.
Tips for comparing projects
- Use the same RBS framework to compare projects: It will be difficult to directly compare two projects that use dissimilar risk structures.
- Apply other risk assessment methodologies: Once you’ve selected your project, use other assessment tools, such as the risk matrix, for a more granular understanding of the project’s risk exposure.
Examples of the risk breakdown structure
Risk breakdown structures differ based on the nature of the project and the organization. Remember to use the appropriate categories and add as much detail as you need.
Here are some risk breakdown structure examples:
Construction projects are generally complex and involve a lot of moving parts, including numerous partners and stakeholders with different expectations and varying levels of understanding of the risks involved.
Construction risks can have dire consequences. And like all types of project risks, they evolve throughout the life of the project. A risk breakdown structure makes it easy to get everyone on the same page.
2. Software development
Your software development RBS can also come in table form.
You start by identifying the categories, with each level to the right breaking them down to add more details.
Generic breakdown structures are a good place to start when identifying and analyzing project risks.
Look at some examples and then modify as necessary to create your own.
Better manage risks with a risk breakdown structure
The future is impossible to predict. But one thing is certain: A project implementation plan can fail in countless ways.
If you understand the risk events that can derail a project, you’ve taken the first step toward managing them.
The risk breakdown structure provides a simple tool to identify project risks, structure them so they’re better understood, prioritize them so your team knows which requires the most attention, and then apply the appropriate prevention or mitigation actions in a timely manner.