Traditional qualitative evaluations do not identify project areas in need of more attention, expose recurring themes, or illustrate concentrations of risks, whereas, Risk Breakdown Structures can. David Bustin

1. Risk Breakdown Structure
Risks are present in nearly every aspect of decision-making. The manner in which a
business handles risk can result with insignificant consequences, their ultimate failure, or
anywhere in between. Identifying risks and listing them in priority fails to provide insight into
the risk structure, especially given the volumes of data accompanying risks. “Traditional
qualitative assessment cannot indicate those areas of the project which require special attention,
or expose recurring themes, concentrations of risk, or ‘hot‐ spots’ of risk exposure. The best way
to deal with a large amount of data is to structure the information to aid comprehension”
(Hillson, 2003). Qualitative assessments assist in prioritization of risks individually and do not
account for exposure patterns of risk. The key to minimizing the negative impact, avoid a
particular risk, or maximize the opportunity of risk is learning to identify, understand, and then
categorize a risk into an organized, systematic framework. One such framework, risk breakdown
structure (RBS), was initially developed by The Software Engineering Institute’s Taxonomy-
Based Risk Identification in 1994 before refinement in 2002 by Dr. David Hillson. He
referenced the work breakdown structure (WBS) as a model for the RBS. His description of the
RBS is, “A source-oriented grouping of project risks that organizes and defines the total risk
exposure of the project. Each descending level represents an increasingly detailed definition of
sources of risk to the project” (Hillson, 2002). The remainder of this paper will provide more
depth and description of the RBS.
According to Pritchard, “The use of the RBS actually comprises two stages, first in
development and later in application.” Generic versions of RBS’s are frequently used as starting
points and evolve over the life of a project. Pritchard also points out that inputs for the
development stage include a list of risks sources and inputs for the application stage include the

2. list of project risks, the RBS itself, and an objective for the application. Outputs from the
development stage include a hierarchy of risk sources for a project or an organization. Outputs
for the application stage entail wide-ranging list of risk or list of risk categories. These inputs
and outputs are unique to each project and organization. Many types of RBSs are used by
companies and the type depends on their industry and the way they manage risks (organizational
framework). A common structure displays a two-level RBS containing a few categories at the
top. “Up to two dozen (sometimes more) categories could be used at the second level of RBS
grouped under the top categories. The level of RBS granularity should be explained in the project
risk management plan” (Raydugin, 2013). Raydugin includes operations as one level and
explains although operations are not part of a project, the project development and execution
activities are typically sources of risks in operations. An important point Raydugin mentions is
the risks brought about by change management and the way it is handled. Specifically, the
impacts of uncertain events incurred on the remainder of the project as a result of changes in the
project. To mitigate the uncertainty, reference to a RBS that is applicable across other relevant
projects proves useful. Other RBSs are project-specific and less likely to be helpful. Dr. Hillson
list the main uses and benefits of the RBS. They include risk identification aid, risk assessment,
comparison of projects or tenders, risk reporting, and lessons learned for future projects. Risk
identification can be accomplished through brainstorming and a list of identified risks can be
developed. Using this list to map to risk identified in other methods exposes gaps in risk
identification. It is critical to not forget the severity of risks when assessing them for
prioritization. In risk reporting, information on the risk is distributed to senior management by
detailing project team actions. A risk score or total number of risk is entailed within the report.
Surprisingly, lessons learned is one of the more challenging tasks usually because it is not

3. usually stored in an accessible location. Lessons learned is an important benefit that can
alleviate repeating the same mistakes. Below in Figure 1 is a simple example of a risk
breakdown structure.
Figure 1 Risk Breakdown Structure
Risk breakdown structures provide many benefits and drastically increase efficiency of
project completion. Similar to many other risk management tools, they prove to be a great asset
if they are accessible and void of uncommon jargon.

4. References
Hillson, D. (2003) "Using a Risk Breakdown Structure in project management", Journal
of Facilities Management, Vol. 2 Issue: 1, pp.85-97. Retrieved June 29, 2017
from http://www.emeraldinsight.com/doi/abs/10.1108/14725960410808131
Hillson, D. (2002). Use a Risk Breakdown Structure (RBS) to Understand Your Risk.
Retrieved June 29, 2017 from http://www.risk-doctor.com/pdf-files/rbs1002.pdf
Pritchard, C. (2014). Risk Management Concepts and Guidance, Fifth Edition. Hoboken:
CRC Press.
Raydugin, Y. (2013). Project risk management: essential methods for project teams and
decision makers. Hoboken, NJ: John Wiley & Sons.