Risk Breakdown Structure
The risk breakdown structure (RBS) is a hierarchical representation of the potential sources of risk in a project. Level 0 gathers all sources. Level 1 splits them into families, for example technical, management, commercial and external. Each further level details the one above it. The team walks through the structure to identify risks without missing a source. It then files each risk in the register under a category. The grouping shows where the exposure concentrates. Read line by line, the register hides that concentration.
Goal
The risk breakdown structure is a tree of categories. Its leaves name sources of risk: requirements definition, legacy data quality, suppliers, regulation. Individual risks stay in the register. Each line there receives the code of the leaf the risk comes from.
Risk identification produces a list. A register of forty lines shows neither where the exposure concentrates nor which themes recur nor which sources nobody has examined. David Hillson proposed the RBS in 2002 to fill that gap. He modelled it on the work breakdown structure (WBS). The WBS breaks down the work to be done. The RBS breaks down the sources of risk.
The team uses the RBS at two points. Before identification, the team reviews its categories so that no source is missed. Afterwards it sorts the identified risks by source.
The deliverable is the structure itself. The risk management plan holds the RBS under the heading "risk categories". The risk register and risk report use it: the register carries a category column, the report breaks the risks down by category.
Usage
When to use it
- A register of several dozen lines: the list no longer shows where the exposure concentrates.
- An identification workshop or interview: levels 1 and 2 set the agenda and cover every source.
- An organisation that runs similar projects: a shared RBS gives the projects one vocabulary and comparable reporting.
- Steering committee: the report aggregates the risks at level 1 and the committee sees where the exposure comes from.
- Bid evaluation: one RBS files the risks of every bidder and the bids compare category by category.
- Project closure: filed by source, the risks that occurred feed the lessons learned and correct the organisation's RBS.
When not to use it
- A small project with about ten risks: the list reads at a glance. A category column in the register is enough.
- A question about which part of the project is affected: file the risks by work package of the work breakdown structure (WBS).
Description
A hierarchy of sources
The PMBOK Guide breaks down the sources of risk, whereas Hillson groups the project's risks by source.
The sample RBS in the PMBOK Guide has three levels. Level 0 is titled "all sources of project risk". Level 1 gathers the families: technical risk, management risk, commercial risk and external risk. Level 2 details each family. The technical family opens with scope definition, requirements definition and "estimates, assumptions, and constraints". The external family opens with legislation, exchange rates and site/facilities. Each element carries a hierarchical code: 1, 1.1, 1.2. Hillson's examples go two or three levels below level 0.
The leaves remain categories. "Suppliers and vendors" is a leaf. "The supplier delivers the billing module two months late" is a risk. It enters the register under that leaf. The PMBOK Guide example codes the leaf 3.3.
The acronym RBS also stands for the resource breakdown structure, which breaks the project's resources down by category and type. The team writes out the full term at its first mention in each document.
Neighbouring structures
The PMBOK Guide lists the WBS, the OBS, the resource breakdown structure and the VBS among the hierarchical charts. It treats the RBS in the risk management plan. The five structures share the tree form. Each one breaks down a different object.
| Structure | What it breaks down | Question it answers |
|---|---|---|
| Risk breakdown structure (RBS) | The sources of risk | Where does the risk come from? |
| Work breakdown structure (WBS) | The scope down to the work packages | What work does the project deliver? |
| Organizational breakdown structure (OBS) | The organisation by unit | Which unit carries the work? |
| Resource breakdown structure | The resources by category and type | Which resources does the project use? |
| Value breakdown structure (VBS) | The deliverables with their estimated value | What value does each deliverable bring? |
The PMBOK Guide suggests filing risks by source with the RBS or by affected part of the project with the WBS. The two classifications intersect. A data migration error comes from a technical source and hits the Migration work package. A register that carries both codes answers both questions.
Choose the starting structure
According to the PMBOK Guide, the organisation keeps a generic RBS for all its projects or one RBS per project type. Otherwise the team builds an RBS specific to the project. A generic RBS defined by the project management office (PMO) standardises identification and reporting in a common language. A project-specific RBS fits the project's needs but loses that standardisation.
A published RBS is a starting point. Each organisation adapts its own to its sector and its projects. A hospital adds a "clinical operations" family. A cantonal administration details "public procurement" under the commercial family. A team that copies the PMBOK Guide example as it stands keeps generic families. None of them names a source specific to the sector. So the team does not look for risks in the sector's own sources.
Each risk must fit exactly one leaf. When two leaves overlap, the team codes the risks of one source under one leaf or the other. Each leaf then shows only part of the exposure. "Resources" and "Skills" are a common case. The PMBOK Guide also allows a simpler structure: a list of categories or a structure based on the project objectives.
Record the RBS in the risk management plan
The risk management plan defines the project's risk categories. The RBS appears there with its codes and a one-line definition per leaf. These definitions settle the borderline cases in advance. The identification workshop then has no classification to debate. During the project the team adds a leaf when needed. Renaming or merging leaves breaks the comparison from one review to the next.
Identify risks with the RBS
In a workshop, the group reviews the elements of the RBS one by one. In an interview, the RBS provides the agenda. The team draws a checklist from the lowest level: generic risks per leaf. The facilitator closes the workshop with a question about the risks that the structure does not cover.
The PMBOK Guide defines a prompt list as a predefined list of categories that guides idea generation during identification. The categories at the lowest level of the RBS provide one for individual risks. For the sources of overall project risk, the PMBOK Guide cites other frameworks: PESTLE analysis, TECOP (technical, environmental, commercial, operational, political) and VUCA (volatility, uncertainty, complexity, ambiguity).
File each risk under a leaf
The team assigns each risk in the register to a leaf at the lowest level. An empty leaf signals a possible blind spot. Nobody found a risk there. The open question is whether anybody looked. Risks found by other techniques also go under the RBS. Two lines under the same leaf then sometimes describe the same risk.
The team holds a short session on an empty leaf before it declares the leaf free of risk. A risk that fits under no leaf signals an incomplete RBS. The team adds the missing leaf. Filing the risk under a neighbouring leaf would distort the distribution.
Some teams number the risks by the RBS. Risk 1.2-03 is then the third risk of leaf 1.2. The code tells where the risk comes from without opening the register. But a reclassified risk changes its identifier. Its history and its traceability break. So the team keeps a stable identifier in the register and carries the RBS code in a separate column.
Measure the concentration
The number of risks per leaf misleads. One leaf can carry ten minor risks. Another carries only two, but major ones. So the team calculates the score per element that Hillson proposes: the sum of the probability × impact scores of the risks attached to it. The risk management plan sets the rating scales. The probability and impact matrix applies them risk by risk. Without ratings the team only counts the lines and treats that count as provisional.
The team then adds up the level 2 scores to obtain the level 1 scores. The score adds up ordinal ratings. It ranks the leaves against each other. It quantifies neither a loss nor a delay.
A sum also rewards volume: ten risks rated 3 exceed one risk rated 25. So the team shows the highest score of each leaf beside the sum. It can also flag separately any risk above the threshold that the risk management plan sets.
The register holds threats and opportunities. The team adds up their scores separately for each leaf. A mixed sum hides an exposure behind an opportunity.
Read the distribution and target the responses
According to the PMBOK Guide, grouping by category makes the responses more effective. The team focuses attention and effort on the most exposed areas. It can also build one generic response for a group of related risks. How to choose a response is covered in risk response strategies.
The distribution also shows the project's type of exposure and its main sources. An affinity map of the risks under one leaf reveals common causes. The PMBOK Guide also groups risks by common root cause. Root cause analysis confirms those causes. Finally the grouping helps to spot dependent risks, which occur together.
Report by level
The RBS sets the level of detail of the risk report. The steering committee reads level 1. The owner of a leaf reads the detail of the risks under it. The organisation names one person responsible for each family.
Feed the risks back at closure
At closure the organisation files the risks recorded in the end-of-project review under its RBS. Risks that recur from one project to the next then show up per leaf. The organisation corrects the RBS and its checklists. The PMO also keeps a catalogue of typical risks. Each completed project adds the risks it ran into. The RBS classifies them.
In HERMES
HERMES 2022 gives the project manager the Manage risks task. In it the project manager identifies the risks, groups them into risk areas, then analyses and evaluates them. The task does not list these areas. HERMES distinguishes two types of risk. Project risks concern how the project runs. Operational risks concern the use of its results. These two types classify risks by what they affect. They add to the RBS. Its level 1 stays the level of sources. An RBS gives the risk areas a structure that stays stable from one project to the next. The project manager documents the risks in the project status report.
AI considerations
A language model proposes a first RBS from a description of the project and its sector. It files the lines of an exported register under the leaves and flags the lines that fit under two leaves or under none. It spots duplicates. It writes the formula or the pivot table that counts the risks and sums the scores per leaf, then per family. The spreadsheet does the calculation. For a checklist, the model drafts generic risks per leaf.
A generated RBS repeats the published examples. It omits public procurement, data protection and the other sources specific to the sector and to the Swiss context. The team checks it against the organisation's lessons learned. The owner of an ambiguous risk classifies it. An empty leaf is a question for the domain experts. A model that fills it with plausible risks inflates the register and masks the blind spot. The register names suppliers and contractual weaknesses. This information is a business secret: the contract and the non-disclosure agreements decide whether the register may go to an external AI service. The register also names the risk owners. Under the Federal Act on Data Protection (FADP), these names are personal data. The team removes or pseudonymises them before sending.
Examples
A regional hospital replaces its billing software. The register holds 23 risks rated from 1 to 5 for probability and for impact. The team files each risk under a leaf and adds up the scores.
RBS tailored to the project. Example values. Score: sum of probability × impact. Scales of 1 to 5.
Leaf 1.1 Requirements carries the most lines: six minor risks for 22 points. Leaf 1.2 Legacy data quality carries two for 32 points. The committee directs the response effort to that data. The technical family gathers 81 of the project's 149 points. Leaf 3.2 Subcontractors stays empty, although a subcontractor runs the data migration.
Visualisations
The RBS is drawn as a tree. Level 0 sits on the left. The families and then the leaves extend to the right. Each element carries its code. The tree serves the identification workshop. The steering committee receives bars per level 1 family. The risk report shows a treemap or a tree coloured by score. The working copy stays an indented list with its codes in the spreadsheet.
Cost
| Phase | Level | Rationale |
|---|---|---|
| Preparation | Medium | Adapt an existing RBS to the project and define each leaf in the risk management plan. High when the organisation has no starting RBS. |
| Execution | Low | Code each risk in the register at identification, then add up the scores per leaf at each review. |
| Documentation | Low | One column in the register and one distribution in the report. The RBS rarely changes during the project. |
Tools
A spreadsheet is enough for most projects. A pivot table counts the risks and sums the scores per leaf and per family. Mind-mapping software (XMind, MindManager) draws the tree during the workshop that builds the RBS. A tracking tool such as Jira holds the RBS code in a fixed-value field that blocks invented categories. A dashboard tool such as Power BI draws the distribution as a treemap from a register export.
Sources
- Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide), 8th ed., PMI: the Perform Risk Analysis process and its risk categorization tool (§2.7.2.3); the definition of the RBS, its three variants and the example in Figure 4-5 (Section 4, entry Risk management plan, heading Risk categories); the distribution by category in the risk report (Section 4, entry Risk report); categorization by source, by affected part and by root cause (Section 5, entry Risk categorization); the RBS as a prompt list, PESTLE, TECOP and VUCA (Section 5, entry Prompt lists).
- David Hillson, "The Risk Breakdown Structure (RBS) as an aid to effective risk management", PMI Europe 2002, Cannes, June 2002: the paper that defines the RBS as a grouping of risks by source; published RBSs as starting points; its uses in identification (workshop, interview, checklist, closing question on unforeseen risks), in classification (empty leaf, duplicates, numbering by the RBS), in assessment by score, in reading the type of exposure, in comparing projects, in reporting and in lessons learned.
- PMI France, Cercle des Entreprises, Optimiser l'utilisation du Registre de Risques, version 2, January 2015, §3.3 and §3.4: the French term, the use of the levels and the person responsible per family, generic RBS and project RBS, the catalogue of typical risks.
- Federal Chancellery, HERMES 2022, Project Management Reference Manual: the Manage risks task (5.4.3.41), grouping of risks into risk areas, project risks and operational risks.