Chapter 3

Risk Definitions
and General
Categories
Definition of Risk

There are two slightly different definitions of

“risk” as it relates to project management—the
traditional definition (which most organizations
have used), and a revised definition per the
Project Management Institute's A Guide to the
Project Management Body of Knowledge
(PMBOK® Guide) – Fifth Edition.

2
Traditional Definition of Risk

According to Wikipedia, risk is defined as “the potential of loss.

Resulting from a given action, activity, and/or inaction” (“Risk,”
n. d.). The two operable words here are potential and loss.
Within In the context of project risk management, the word
potential is typically replaced with the word likelihood or
probability.

Furthermore, the word loss is typically replaced with either the

word consequence or impact, both of which allude to negative
outcomes. It needs to be noted that, while project risk
management seems to focus on minimizing the chances of
negative outcomes (or issues) surfacing, another important
element of the process is attempting to maximize opportunities.
The process is sometimes referred to as the evaluation of risks
and opportunities—distinctly opposite phenomena.
3
PMBOK® Guide Definition of Risk

The PMBOK® Guide defines risk as “an uncertain event or

condition that, if it occurs, has a positive or a negative effect
on a project's objectives”. Those events having a potential
negative impact are referred to as threats, and those having a
potential positive impact are referred to as opportunities.
Opportunities are essentially treated as positive risks. This
definition ensures that project risk management intrinsically
includes opportunities; there is a common tool referred to as a
SWOT (strengths, weaknesses, opportunities, and threats)
analysis that clearly defines threats and opportunities as
opposites. Thus, there is a good rationale behind this
definition. The difficulty associated with this definition is that
until organizations and industries accept it as a working
standard, it can cause some unnecessary confusion.
4
Causes Versus Risks
An important distinction to understand when defining risks is the
difference between a “cause” and a “risk.” A good way to make
this distinction is using a “risk meta-language” statement. This
statement is a generic sentence structure set up to enable words
or phrases to be inserted to form a compete thought. A risk meta-
language statement is provided below.

As a result of <CAUSE>, <RISK> may occur, which will lead to

<EFFECT>
You fill in the placeholders (<CAUSE>, <RISK>, and
<EFFECT>) to complete a thought and readily identify the three
elements of risk. Below are a couple of examples.

5
Risk Metalanguage Statement: Example 1
“As a result of more than expected test failures, more
design/build/test cycles may occur, which will lead to
schedule delays and added project costs.”

Risk Metalanguage Statement: Example 2

“As a result of organizational resource limitations, critical
path software design activity delays may occur, which will
lead to schedule delays and potential added project costs.” \

6
A complementary metalanguage for describing a risk in the
project's risk register is:
<RISK> due to <CAUSE >

The following descriptions correspond to the two risk

metalanguage examples above:
Risk Description Metalanguage Statement: Example 1
“More design/build/test cycles due to more than expected test
failures”
Risk Description Metalanguage Statement: Example 2 36
“Critical path software design activity delays due to
organizational resource limitations”

7
 The Potential Impact of Risks on Major Project Objectives

Project risks are associated with activities that could impact one or
more of the major project objectives—schedule, budget, scope, and
technical/quality. Project teams typically prioritize these objectives
in their own way, usually in accordance with key stakeholder
expectations.

Typically, the larger, more strategic, and complex the project is, the
more risks need to be addressed. In some circumstances, the team
does not have all the information and/or resources readily available
to address all risks at one time. Trade-off decisions that factor into
project priorities and relative risk-severity ratings are typically
required. it is important to understand the major project objectives
(and their priorities), and how to objectively evaluate and compare
project risks to facilitate sound project trade-off decisions.
8
 Risks to Major Project Objectives:

As previously mentioned, all projects have certain common

features (i.e., the project life cycle structure and the major
project objectives). The super-set of major project objectives
includes project schedule, project costs, project scope, and
product quality. Given their inherent interdependence, an
impact on one of these project objectives will impact (or add
risk to) one or more of the others. Below are some general
examples:

• Quality (or technical) issues typically impose scope changes,

which in turn can result in schedule risk, especially if the scope
change is on or near the project’s critical path.
• Required scope changes typically result in project cost
adjustments or risk.
9
• Schedule issues can also result in cost risk, especially if they

have an impact on the total project duration. On larger

projects, there is likely going to be a “marching-army”
impact associated with schedule—i.e., the impact relative to

funding schedule dependent activities (e.g., project

management and administration, financial support, contracts
support, etc.), which are essentially “level-of-effort” support
functions based on schedule.

10
Deciding on a response to an encountered issue (e.g., a
technical/quality requirements change) can be extremely
difficult at times. Do you accept the resulting risks to one or
more of the project objectives (e.g., try to absorb the change, but
recognize the potential for overrunning the project budget and
pushing out the project delivery schedule)? Do you adjust one
or more of the objectives (e.g., either make a counteracting
additional requirements change or appropriately adjust the
budget for the additional scope and make a commensurate
adjustment to the schedule)? Or do you decide on a combination
of both (e.g., adjust the budget to accommodate the added
scope, and add risk by trying to absorb the potential schedule
impact) based in part on the project priorities? Whatever
decision is made, it can benefit from sound risk management
practices. Objective evaluation of relative risk severities can
help.
11
Sometimes the likelihood of these encountered issues can
be foreseen (maybe due to past experiences) and identified
a priori as potential issues (risks) to project success while
planning the project. To facilitate decision making
regarding how to respond, it is helpful to have some
processes and guidelines (also referred to as “organizational
process assets”) to objectively and consistently assess risk
severity within the performing organization.

12
 Discussion

In a small group, We need to think about what

will happen for any project that the schedule has
been delayed for any reason!
How does that affect the cost? Profit? Time?
And Quality?

13
Risk-Severity Definition

Risk severity is a measure of the relative importance of

individual project risks, and its value is a function of the two
principal components of risk—the probability of occurrence
and the expected impact. This figure of merit can be assessed
numerically by first assigning values to the risk's probability of
occurrence and impact to project objectives. After assessing
each risk component, a severity rating can be determined by
simply multiplying the probability rating and impact rating
together. Higher risk-severity levels are usually represented by
higher resultant scores.

14
Risk Probability and Impact Scales

Figure 3.1 provides an example of a project risk probability

and impact scale for the major project objectives discussed
above. Some organizations standardize these for consistency
between the various projects. In other circumstances they are
developed by the project manager, project sponsor, or
customer. Note that in this example five discrete values
between 0.0 and 1.0 are assigned to numerically represent the
five levels of risk likelihood and impact: very low, low,
moderate, high, and very high. The specific number of levels
and impact level descriptions usually varies based on
organizational preferences.

15
16
Risk Categories and Groupings

Although risks are many times categorized by the major project

objectives they impact (i.e., project schedule, project cost,
project scope, or product quality), there are other meaningful
ways of categorizing (or grouping) them. The two most
practical alternative groupings are: by the elements of a project's
risk breakdown structure (RBS), and by elements of the
project's work breakdown structure (WBS). An RBS can help
the team identify specific causes of risks (e.g., scope omissions,
resource shortages, estimating accuracy, etc.) that may
necessitate additional management attention, while a WBS
breakout can effectively segregate risks and risk severities by
functional discipline (e.g., software engineering, quality
assurance, procurement, etc.) and/or project work activity (e.g.,
design, manufacturing, test, etc.) to determine where more
attentive project leadership and organizational involvement is17
The Risk Breakdown Structure (RBS)

From a practical standpoint, a generic RBS can be created

once and become an organizational asset (i.e., template) for all
projects to utilize—either as is or tailored for specific unique
project needs. Figure 3.2 provides an example of RBS. RBSs
are usually hierarchically organized. They show sources of
project risk by category, and they facilitate grouping risks by
specific causes of unsuccessful project execution. An RBS can
also be easily converted into a checklist. Checklists are good
if they are considered a complete listing of items to consider.

18
19
The Work Breakdown Structure (WBS)

If available and constructed well, a project's WBS can be a

very useful tool for grouping project risks. Figure 3.3 shows
an example WBS. Like the RBS, it is hierarchically organized.
Since WBS items typically relate to segregated work
packages, risks within them are typically separable (i.e., do
not overlap with risks in other work packages). As a result,
one can theoretically determine the potential impact on major
project objectives for each WBS element, and then potentially
combine them to generate an overall project risk assessment.
In addition, one can likely determine which of the activities
are riskiest and worthy of focusing more management
attention on to better control overall project risk.

20
21
Some large project development plans are split into phases,
where each phase is essentially organized as its own project,
which is dependent on the results of the preceding phase. The
project consists of several phases, including project planning,
design feasibility, design development, design verification,
low-rate production, and high-rate production. This type of
project lends itself nicely to the WBS risk categorization
process. For example, risk can be independently assessed for
each phase preceding high-rate production to determine
overall project risk in terms of meeting the major project
objectives up to that project milestone.

Dr. Anis ur Rehman, CBA, UOH, KSA 22