Risk Management

13
Risk Management

C. Ariel Pinto
Old Dominion University

209
Engineering Management Handbook

13.1 Introduction

13.1.1 What is Risk?

Take calculated risks. That is quite different from being rash.

- George S. Patton
US Army general (1885 - 1945)

Engineering managers are the leaders toward successful research, development, and engineering activi-
ties. And monuments of these successes abounds—discoveries of drugs that saves millions of lives, taming
and harnessing nuclear power for energy, design and execution of space exploration programs, and count-
less other feats. But within these same realms exist monuments of apparent failures—disastrous chemical
spills, deadly space shuttle launch, catastrophic flood levee failures, and so on. Would have Gen. Paton
considered these failures the result of calculated risks? Or are these failures remnants of human rashness?
At the heart of this section is the science and art of managing risks in engineering systems. Critical to
managing risk is in knowing what it is. Some have described risk as…

“…the potential for realization of unwanted, adverse consequences”

- Society for Risk Analysis

“… (perceived) feeling of insecurity and fear due to undesirable consequences”

- Organization for Economic Co-operation and Development

“…probability of the occurrence of (the risky) event multiplied by the consequence of the event, given
that it has occurred”

– US Army Corps of Engineers

“…are events that if they occur can jeopardize the successful completion of the projects”

- INCOSE

As the preceding descriptions of risk show, an engineering manager must recognize that risk can be
expressed as number and also may reside at the minds or feelings of humans. Whatever description of risk
is presumed by the engineering manager, one thing that is generally agreed upon is that risk, by itself, is
undesirable.

13.1.2 What is Risk Management?

The management of risk permeates many activities, especially those that involve systems of great value.
It can be an informal process without any set guidelines, or an institutionalized and codified activity. Re-
gardless of the specifics of activities or degree of formalization, applications of risk management have one
common objective: To minimize loss associated with a system in case things go wrong.
Effective risk management is often undertaken concurrent with design and development processes. As
systems are transformed from mere concepts to full-scale entity, risks arise and need to be managed in a
timely manner. As a result, safeguards against risk are often designed and built into the system. As the old
adage goes, an ounce of prevention is worth a pound of cure.
210
 Risk Management

13.1.3 Why is Managing Risk Important for Engineering Managers?

Being true to the engineering manager’s goal, the rigors of the discipline are full of hows and whys
of having a successful engineering activity. By managing risk, the what ifs are added to this list.
For example, one measure of success in constructing a system of flood levees is the protection it
provides to the population and their properties. Engineers will use the appropriate levee heights to
protect against a particular design flood level, say a 100-year flood. The engineer may design, build,
and operate the levees. However, the same engineer, in doing some basic risk management, may
reconsider some previous design, after considering: What if the current land use plan around the
levee changes? What if the current hydrological models are proven wrong? Or, what if drastic climate
change occurs?
It may turn out that these what ifs will not change the decisions made about the levees. However, as
Gen Patton has said, there is a quite a difference between taking calculated risk and being rash. And for
engineering managers, the difference between well and poorly managed risks may be in terms of avoidable
lost of lives and properties.
In the realm of formalized risk management, there are several guiding principles:
Analysis of risk is scenario-driven—Analysis of risk is only possible if we can conceptualize such
risk. Examples are floods for a levy, fires for homes, and defective parachutes for a sky-diver. This
implies that risk analysis is limited by our capacity to identify what can go wrong, which are termed
risk scenarios or simply scenarios. Consequently, before we can conceive the scenarios, we must
first have an idea of the ideal events. Certainly, the ideal events are that there be minimal floods,
no house catches fire, and parachute opens properly. The identification of varied and meaningful
scenarios requires extensive knowledge of the system at hand: how it works, how it was built, how
it will be used, and other information. For complex systems, models are often used to facilitate the
identification of scenarios—and yet there will always be emerging scenarios which will slip identifi-
cation. Moreover, identification of scenarios is often done by teams of people with diverse knowledge
about the system and its environment, effectively resulting to a wider realm of knowledge. Due to
the enormous number of possible scenarios, ranking and filtering of scenarios are often performed to
protect the most valuable of assets.
Importance of catastrophic events—A person often remembers catastrophic events more than
the usual, everyday events. And this is for a good reason: catastrophic events are usually associated
with great loss. These are the same type of scenarios that are of special interest in risk management.
For a civil engineer with a 10-foot levy, a drought or a 5-foot flood is not much of a concern. But the
scenario of a 12-foot flood is critical. This scenario will result to flooding at the other side of the levy,
or even the toppling of the entire levy even though this particular event may happen only once in a
century. In general, designers assure that systems do well on a wide scale of events. However, there
are types of events, often very rare and in only one end of the scale that can prove to be destructive.
Catastrophic events can be capable of premature and unplanned retirement of a system. In the case
of a levy that was planned to be in operation for 50 years, a catastrophic flood on the first year can
prematurely cut its affectivity, and the resources put into building the levy would not be recouped.
In essence, if much of the decisions that went into building the system were based only on long-term
projections (e.g., averages), then the early retirement of a system voids much of these decisions.

13.1.4 What Are the Basic Activities in Risk Management?

Risk management is made up of several activities, one leading to the other. Oftentimes, we need to go
through the activities several times to produce a more detailed management of risk from the previous
time. This section provides a general framework for risk management to enable engineering manag-
ers to conceptually structure the volumes of topics available on risk management, as well as to serve as
guidelines for managing risks in various types of engineering systems. The framework presented herein
is an amalgamation of several frameworks for risk management scattered among bodies of knowledge,
but resembles closely those presented by Haimes (2004) and Conrow (2005). These activities are as
follows:
211
Engineering Management Handbook

(1) Scenario identification starts out by identifying the system of concern, which elements are within our
control, and which are not. We then draw a crisp description of the ideal picture when everything about
the system occurs as planned. We then draw the risk scenarios making sure that we consider the system
from various points of views (one who owns it, one who uses it, one who is affected by it, etc.).

(2.1) Consequence estimation is based on the scenarios we previously identified. We estimate the conse-
quences if each of the scenarios occurs by looking into other events that may occur, and the ultimate cost.
This is often done by looking into the elements of the system that will be affected by the scenarios and the
repercussions.

(2.2) Likelihood estimation is based on the scenarios we previously identified; the frequency of occurrence
is estimated. This can be done by looking into the mechanism of the scenarios and the factors that con-
tribute to their occurrence.

(3) Ranking. At this point, we have a good picture of the risk in terms of the scenarios, their consequences
and frequency of occurrence. We may decide to take a second look into the list of these scenarios and
make distinctions between the more important and less important ones. The purpose of such ranking of
scenarios is to concentrate our resources to the more important ones, and yet recognizing the fact that
none of these scenarios is totally independent of each other.

(4) Generation and tradeoff of mitigation alternatives identifies ways and costs to mitigate each of the risk
scenarios. Mitigations can be in the form of affecting the causes of a scenario, or safeguard to minimize
consequences of a scenario, transferring the risks, or a combination of these.

(5) Potential problem analysis evaluates the effects of the mitigation alternatives to other elements of the
system. Mitigation alternatives are analyzed according to their effects to functionalities of the system, the
manner by which they alter interaction between elements of the system, and their potential to affect fu-
ture decisions. This is also the point where the acceptable level of risk is determined: comparing the costs
and benefits of each mitigation alternative.

(6) Implementation, monitoring, and documentation is putting into place mitigating actions based on the
perceived acceptable level of risk. There is no clear terminal activity in risk management as it is an iterative
process. As stated in the previous section, there is no way of totally eliminating risk and as new sets of sce-
narios come up every time there are changes in the system of interest, the environment, or in the presence
of new information.

This framework, illustrated in Figure 13.1, was formulated with engineering managers in mind and
with consideration toward perceivable trends in risk management tools and techniques. The following sec-
tions discuss these steps in details.

Figure 13.1. Schematic of the Activities in the Risk Management Framework

Scenario Consequence Ranking Generation and Potential Problem Implementation,

Identification Estimation Tradeoff of Analysis Documentation,
Likelihood Mitigation and Monitoring
Estimation Alternatives

Risk scenarios Ranked list Alternatives List of Risk

List of risk with consequence of risk for some risk other risks documentation
scenarios and likelihood scenarios scenarios
estimates

212
 Risk Management

13.2 Scenario Identification

This section describes the first question that needs to be answered toward managing risk—what can go
wrong?—also known as risk scenario identification. This question arises from the fact that for risks to be
managed, risks scenarios need to be identified and described to an appropriate level of detail. The answers
to this question are greatly hinged on describing the goals and performance measures for a particular en-
gineering activity. In essence, the answers to the question: what needs to be right? There can be three phases
to identifying risk scenarios, namely:
1. Identify desired scenarios
2. Identify undesirable or risk scenarios
3. Characterize risk scenarios via causalities and correlation

13.2.1 Identify Desired Scenarios

The identification of desired scenarios is a common and fundamental activity in any engineering and
managerial effort and not just in risk management. This activity is mostly couched under the names
requirement identification, functional design, goal formulation, performance measure identification, and other
related activities. As such, information on desired scenarios lies in documents like requirement contracts,
product or process specifications, mission and goal statements, and others. Consider these examples:
• Total cost of developing a new engine should not exceed $3M
• Maximum sustained torque should be at least 700 foot-pound
• A prototype of the engine should be available for field testing in 18 months

These desirable scenarios are obviously oversimplified but are representative of various types of objec-
tives for an automotive engine engineering activity representing cost, performance, and schedule goals.

13.2.2 Identify Risk Scenarios

The identification of the undesirable or risk scenarios are initially drawn from the previously identified
desirable scenarios. Strictly described, the undesirable scenarios are everything else aside from the desir-
able scenarios—analogous to the notion of complementary sets in set theory. Consider the three desir-
able scenarios listed in the previous section. The broadest risk scenarios are the following complementary
scenarios:
• Total cost of developing a new engine exceeds $3M
• Maximum sustained torque is less than 700
• A prototype of the engine is not available for field testing in 18 months

13.2.3 Characterize Risk Scenarios Via Causalities and Correlation

The characterization of risk scenarios are meant to explore events that cause or contribute toward the oc-
currence of these risk scenarios. The process of characterization draws from various fields of science and
engineering such as reliability and maintainability and survivability analyses and requires a thorough and
possibly specialized knowledge of particular engineering systems. Consider the first of three risk scenarios
from the previous section: Total cost of developing a new engine exceeds $3M. With more specialized infor-
mation of engine development in the automotive industry, some immediately identifiable causes of this
scenario are:
• Devaluation of US$ compared with the Euro (for subcontracted services to European firms)
• Set back in the R&D for new aluminum alloy for the engine block
• New contract with the labor union and significantly higher labor cost rate

The list of possible causes for cost overrun will be much longer in reality, but for the purpose of
example, let us assume for now that the list of three causes is an exhaustive list. One particularly useful
tool often used in establishing causalities of risk scenarios is a fault tree. Fault Tree Analysis (FTA) is a tool
commonly used for reliability and safety analysis that was originally developed by Bell Telephone Labora-
213
Engineering Management Handbook

tories in the 1960s for the U.S. Air Force for use with the Minuteman system, and was later adopted by
the Boeing Company and has since been used by other countless organizations.
The usefulness of FTA in establishing causalities of risk scenarios is due to several characteristics,
namely:
• Its nature of working in the failure space facilitate identification of risk scenarios
• Looks at combinations of failures, suitable to wide range of complexity of many engineering activity
• Symbolic use of events blocks and gates, enabling user-friendly and compact visualization of an other-
wise complex information (see Table 13.1)
• Readily available as a software application, enabling quick adoption

Shown in Table 13.1 are the common symbols used in FTA. This includes symbols for events and for
Boolean operators or gates.

Table 13.1. Basic FTA Symbols

FTA symbols Common name Description

Basic event A basic initiating fault or failure event
External event An event that is normally expected to or not to occur
Undeveloped event A basic event that needs to further details or resolution
Conditioning event A specific condition or restriction that applies to a gate
Transfer Indicates continuation or transfer to a sub-tree

AND gate Output event occurs if ALL input events occur

Output event occurs if at least one of the input events
OR gate
occurs

Consider as an example, the possible causes for the scenario described as Total cost of developing a new
engine exceeds $3M from the previous section. The identified causes can be illustrated using FTA as shown
in Figure 13.2.

Figure 13.2. Simplified FTA Showing How Causalities of Risk Scenarios Can Be Represented by Events and
Gate Symbols

Total cost of
developing a new
engine exceeds
$3M

OR

Devaluation of Set back in the

US $ compared R&D for new AND
with the Euro aluminum alloy for
the engine block

New contract with Significantly higher

the labor union labor cost rate

214
 Risk Management

13.3 Consequence and Likelihood Estimation

This section describes the second activity in the seven-activity risk management framework. The previous
section discussed how risk scenarios can be identified and described at a suitable level of details. However,
this list of risk scenarios has to be scrutinized in preparation for proper management. The ever-present
limitation in available resources necessitates that engineering managers distinguish the more important
from the trivial risk scenarios for proper resource allocation. The general approach to distinguishing the
relative importance of risk scenarios is by describing their chance of occurrence and consequence if they
occur. This approach is loosely derived from the notion of expected value as well as risk itself, e.g., as
described by the US Army Corps of Engineers in Section 1.0.

13.3.1 Consequence Estimation

Consequence estimation, the first component of this section, draws from various activities such as cost
estimation and analysis, cost engineering, and actuarial analysis—essentially estimating the cost of events
that will happen if a particular risk scenario occurs. Similar to all cost-related analyses, consequence estima-
tion is highly dependent on how clearly defined and understood is a particular risk scenario. For clearly
defined and understood risk scenarios, estimating the consequence may be based on historical cost data
using statistical analysis very similar to actuarial analysis performed in the insurance and finance industry.
However, the more challenging cases for engineering managers are the one-of-a-kind, untested, and
complex systems where the risk scenarios are neither well defined nor understood. These cases are better
approached from a stochastic perspective, which essentially brings the engineering manager to the second
component of this section, likelihood estimation.

13.3.2 Likelihood Estimation

It is essential to recognize that there are several ways risk managers may operationalize the concept of like-
lihood or chance. From a statistician’s and mathematician’s perspectives, this may be the frequency of out-
come of repetitive experiments or may be a formal mathematical construct usually represented as a curve.
From a Bayesian’s perspective, this may be the degree of confidence or certainty. There are cases when one
of these perspectives is more appropriate over the other, such as the presence or absence of historical data
regarding a particular risk scenario, or the knowledge or lack thereof of causality.

Statistical-Mathematical Risk Assessment

To describe the likelihood of a risk scenario, traditional data analysis can be used by adapting statistical
and mathematical approaches. These approaches are especially useful in cases when the likelihood of oc-
currence can be expressed in terms of statistics such as mean, variance, skewness, range, etc., or probabil-
ity distributions such as the Normal distribution or non-parametric distributions. Oftentimes, traditional
data analysis for managing risk essentially becomes a task of how to specify probability distributions. For
fairly defined and understood phenomenon, the probability distributions may be assumed via this very
knowledge, such as the use of a Uniform distribution for possible results of rolling of a dice or sequential
coin tosses. For less understood phenomenon but with empirical data, parametric and non-parametric
statistical methods can be used. In-depth discussion of traditional data analysis is in the chapter on prob-
ability and statistics of the ASEM Handbook.
In this chapter, more emphasis will be on the discussion of non-traditional risk assessment appro-
priate for cases where there is less information or knowledge of risk scenarios. Particularly, Bayesian or
evidence-based assessment and assessment of extreme and rare events will be discussed.

Bayesian or Evidence-Based Assessment

Briefly described in the previous section is the role of statistical data analysis in establishing the chance of
occurrence of risk scenarios using knowledge of the phenomenon and empirical data. However, there are
cases in engineering activities where knowledge of risk scenarios may be poor or that there is hardly any

215
Engineering Management Handbook

data, such as in the case of a new and emerging technology or newly studied phenomenon. Instead, there
may be well-established evidences, whether by causality or correlation to describe these risk scenarios. The
Bayesian approach, also known as evidence-based risk assessment can be useful for such cases.
Evidence-based analysis is primarily based on two axioms, Bayes’ theorem and total probability theo-
rem, respectively described in Equations 13.1 and 13.2.

P (A) P (B |A )
P ( A|B ) =
P (B ) (13.1)

P(B) = P(B|A1)P(A1) + ... + P(B|An)P(An),

(13.2)

In this analysis, carefully selected information that helps draw conclusions or evidences are of primary
interest.

Assessment of Extreme and Rare Events

Extreme events imply relatively great magnitude event such as stock-market crash, war, or natural di-
sasters. In most well-engineered systems, undesirable events of great magnitude (i.e., extremes) are rare.
However, these are also situations where there are more to lose or to win. In data measurement, limita-
tion of observation resulting to censoring can be a limitation to analyzing extreme events. In classical
data analysis, extremes are often labeled as outliers, exemplified in data filtering and by the assumption of
stationarity. However, when looking for extremes, which are in the tails of distributions, you often find
that in real-life situations these tails are fatter (heavier) than what classical distributions predict, such as
shown in Figure 13.3.

Figure 13.3. Classical Distributions and How the Tails May Actually be Fatter in Reality

Classical
distributions
Fat tail

Range of random variable

Expected values and use of averages are common in classical data analysis. As a result, observations
of the more-common events dominate the estimation process and because extreme observations consist
of only a small part of the data, their contribution in the estimation is relatively smaller. Therefore,
in such an approach the tail regions are not accurately estimated. This is often emphasized with the
analogy of the frozen-hot hands—One hand in boiling water and one hand in an ice bucket; on the
average—you’re just fine.
Extreme value theory (EVT), unlike classical data analysis, focuses primarily on analyzing the extreme
observations rather than the observations in the central region of the distribution. EVT is most useful in
the study of the asymptotic behavior of extreme observations of a random variable: maxima for extremely
high and minima for extremely low.

216
 Risk Management

Consider a brief review of the Central Limit Theorem:

Let X1,X2,…,Xn be a set of N independent random variates and each Xi have an arbitrary probability
distribution with mean μi and a finite variance σi2 , as N→∞,

The Central Limit Theorem essentially implies that the distribution of an average tends to be Normal,
even when the distribution from which the average is computed is decidedly non-Normal (Normal a.k.a.
Gaussian).

However, when the interests is not the central region but rather the extremes, a new statistic is used:
ordered statistics or the arrangement of random variates in increasing order, such as for sample size n,

X1:n is also called Xmin

Xn:n is also called Xmax

Thus, if an engineering manager is trying to determine the cumulative density function (cdf ) of, say
the Xmax, and by assuming all x’s are independent and have the same cdf = F(x), then

Fmax(x) = Pr(xn:n < x) [by def of a cdf ]

= Pr(X1,X2,…,Xn < x) [by def of xn:n]
= F(X1<x) · F(X2<x) ·… · F(Xn<x) [by prop of independence]
= F(x)n

However, when n→∞, or when n is unknown, or when the cdf of the x’s, F(x) is unknown then esti-
mating [F(x)]n can be unwieldy. The fundamental result of EVT is the identification of the possible classes
of distributions of the extremes irrespective of the actual underlying distribution. EVT incorporates sepa-
rate estimation of the upper and the lower tails due to possible existence of asymmetry.
Asymptotic distributions can be applied when there is large number of data (i.e., sample size n→∞).
EVT shows that Fxn:n(x) can be any of the three extremal distributions, namely:
• Gumbel I (aka Gumbel) with exponential tail
• Gumbel II (aka Frechet) with polynomial tail
• Gumbel III (aka Weibull) with bounded tail

Shown in Figures 13.4a and 13.4b are the three extremal distributions as well as the difference in
their tails.

Figure 13.4. The Three Extremal Distributions Showing (a) Entire Distribution Curves and (b) a Close-Up
View of the Tails of the Curve
Weibull, bounded tail

Frechet polynomial tail

Gumbel, exponential tail

(a)(a) (b)
(b)
217
Engineering Management Handbook

For a known F(x) function but unknown sample size n, the asymptotic distribution can be identified
by using Equation 13.3.

F−1 (1 − ε) − F−1 (1 − 2ε)

lim −1 −1
= 2d (13.3)
ε →0 F (1 − 2ε) − F (1 − 4ε)
Such that:
if d =0, G-I is asymptotic to Fxn:n(x)
if d>0, G-II is asymptotic to Fxn:n(x)
if d<0, G-III is asymptotic to Fxn:n(x)

These is commonly read as “F(x) belongs to the domain of attraction of G-I, G-II, or G-III”.

Example:

Waiting times, w, in an M/M/1-FCFS queuing model (e.g., single grocery cashier with Markovian arrival
and service) is generally known to be:

F(w ) = P( W < w ) = 1 − ρe −µ (1−ρ) w

What is the form of the distribution of extreme waiting times w?

Solution:
F(w ) = 1 − ρe −µ (1−ρ) w

1− w
log( )
ρ
F −1 ( w ) = [Eqt 2]
µ(−1 + ρ)

Substituting Eqt 2 into Eqt 1,

By substituting the above equation into Equation 13.3:

log(1 − (1 − ε)) − log(1 − (1 − 2ε))

= lim = 1 = 20
ε →0 log(1 − (1 − 2ε)) − log(1 − (1 − 4ε))

F −1 (1 − ε) − F −1 (1 − 2ε)
lim = 2 d [Eqt 1]
ε →0 F −1 (1 − 2ε) − F −1 (1 − 4ε)

Since d =0, then G-I is asymptotic to Fn:n(w);

“F(w) belongs to the domain of attraction of G-I”

Other known F(x) functions are shown in Table 13.2.

218
 Risk Management

Table 13.2. Commonly Used Probability Distributions and Their Asymptotic Domain of Attraction

F(x) Asymptotic Fxn:n(x)

Normal Gumbel I
Exponential Gumbel I
Lognormal Gumbel I
Gamma Gumbel I
Rayleigh Gumbel I
Uniform Gumbel III
Cauchy Gumbel II
Pareto Gumbel I

For unknown F(x) using empirical data:

1. Eliminate: Use knowledge of phenomenon to eliminate possible domains of attractions.

2. Plot: Plot the data in a maximal or minimal Gumbel plot.
3. Diagonal/Linear?: If the tail of interest shows linear trend, then domain of attraction is Gumbel (G-I).
4. Going vertical?: If the tail of interest shows vertical asymptote, then domain of attraction is Weibull
(G-III).
5. Going horizontal?: If the tail of interest shows horizontal asymptote, then domain of attraction is
Frechet (G-II).
6. Be safe: If there is no obvious asymptote, use model with heavier tail to be on the safe side (assuming
further to the extreme is undesirable).

Plotting using G-I plot:

1. Plot of the order statistic Xn:n (X1:n for minima) versus plotting position v
2. Plotting position v = -log[-log(pi:m)] (v = log[-log(1-pi:m)] for minima) where i is the rank in m Xn:n,
pi:m=i/(m+1), skip this step if already using G-I plotting paper
3. If G-I is asymptotic to Fxn:n(x), then the plot will approximately be a straight line
4. Otherwise, choose obvious model or be on the safe side

Where log pertains to “natural log,” in MS Excel this is the LN function.

Shown in Figure 13.5 are the sample plots for Couchy, Normal, and Uniform distribution using the
maximal G-I plotting method (modified from Castillo, 1988). Note that by transforming the plotting po-
sitions of the order statistics, the plots of the Couchy, Normal, and Uniform distributions are also trans-
formed such that the right tail corresponding to the maximal statistics are amplified. The straight diagonal
dashed line serves as a comparison of how close or far are the plots from being a true G-I. Obviously,
the plot of the Uniform distribution is not a good fit for a G-I by the mere fact that this distribution is
bounded and can be better represented by G-III. This shows on the plot as a right tail going toward the
vertical direction. The opposite can be observed for on the plot for the Couchy distribution with the right
tail heading toward the horizontal direction and can be better represented by G-II. The Normal distribu-
tion shows a plot that is not exactly a straight diagonal line, but nonetheless has a right tail that is almost
diagonal that this can be termed as close enough to be approximated by G-I.

219
Engineering Management Handbook

Figure 13.5. Sample Plots for Couchy, Normal, and Uniform Distribution Using the Maximal G-I Plotting
Method (modified from Castillo, 1988)

Maximal Gumbel Type I Paper (aka MaxGumbel paper)

0.995
y
0.99 uch
0.98 Co

0.95

Probability 0.9 rm
al
No rm
ifo
0.7 Un

0.4

0.1
0.005
0 0.2 0,4 0,6 0.8 1
x

13.4 Risk Ranking

The previous section described how the consequences and the likelihood of risk scenarios can be esti-
mated. The estimation of these consequences and likelihood of risk scenarios help engineering managers
discern the relative risk of these scenarios for the purpose of eventually allocating limited resources toward
their mitigation. However, risk scenarios have other properties that can be expressed in numbers, much
less encompassed by its consequence and likelihood.

13.4.1 Risk Ranking Using Consequence and Likelihood

There can be several ways to rank risks using consequence and likelihood. One approach is to calculate the
product of the consequence and likelihood for each of the scenarios and treat this product as a unit-less
measure of risk. That is:

Risk of a scenario = (Likelihood of occurrence * Consequence if it occurs)

The ranking among several scenarios can then be based on this calculated risk measure where higher
number denotes higher risk. However, it is important to note that there has been counter argument
against this method because of the equivalence that may result from scenario of low likelihood and great
consequence with that of one with great likelihood and low consequence.
A related approach is the use of a risk matrix or risk cube where each scenario is placed on a two-
dimensional matrix where the axes represent likelihood and consequence, as shown in Table 13.3. In this
example, the estimated consequences are expressed as Severity, which ranges from Negligible to Cata-
strophic, while the likelihood is expressed as Probability, which ranges from Improbable to Frequent. This
example also shows how the ranking can be made, from the lowest, moderate to high risk, color-coded
with blue, yellow, and red, respectively.

13.4.2 Risk Ranking Using Other Properties

Haimes, Kaplan, and Lambert (2002) described some other properties that can be used to better describe
and eventually rank risk scenarios. Some of these properties shown in the following table, as well as some
exploratory questions engineering manager can use to better describe risk scenarios.

220
 Risk Management

Table 13.3. Example of Risk Matrix to Rank Risk Scenarios Based on Consequence and Likelihood

SEVERITY
Catastrophic Critical Marginal Negligible
PROBABILITY
Frequent 1 3 7 13
Probable 2 5 9 16
Occasional 4 6 11 18
Remote 8 10 14 19
Improbable 12 15 17 20

Properties Exploratory questions, and why the property is important in risk ranking.

How is it detected? What is the likelihood that it occurs without being

Undetectability
Uncontrollability/
Irreversibility
Multiple paths to failure
Duration of effects
Cascading effects
Hardware/software
/human/organizational
interaction
Complexity and emergent
behaviors
Design immaturity
detected (i.e., false-negative)? A seemingly benign but undetected risk can escalate
in magnitude and scope, e.g., a small gas leak turning into an explosion.
Once detected, how soon and how much will it take to be controlled to avoid
further damage? Some risk scenarios, once triggered may be difficult or costly to
control or terminate, e.g., lose of cabin pressure during high altitude flight.
How many ways are there for it to occur? How much is known about these
paths to failure? Likelihood of occurrence may be grossly under estimated if it is
know that there are other unaccounted causes.
How long does it or its effects last? Depending on the method used for estimation,
consequence may escalate beyond the estimate if the effects last longer than
foreseen.
Will it result to other risky scenarios? What may initially be a benign scenario
may actually be just one of several contributing to a catastrophic event, e.g., freezing
of an o-ring before a space shuttle launch.
Does it involve interaction among several types of system components?
Scenarios due to interaction of seemingly reliable components may actually result to
higher likelihood than initially estimated.
Is it attributed to complexity or emergent behavior? Complexity and emergence
denotes significant level of uncertainty, such that estimated likelihood and
consequence may be underestimated.
How much is know (or unknown) about pertinent systems? Immature design,
similar to complexity and emergence may have high degree of uncertainty.

13.5 Generation and Tradeoff of Mitigation Alternatives

13.5.1 Mitigation Strategies

• The primary objective of risk mitigation strategies is to reduce risks. In identifying risk mitigation
alternatives, several concepts need to be introduced:
• Vulnerability—openness to damage; usually inherent to system of interest
• Threat—potential cause of system damage; usually external to system of interest
• Security—measures taken to guard against damage
• Safety—relative protection from adverse consequences (SRA); usually associated with life and health

221
Engineering Management Handbook

These concepts are the building blocks of almost any risk mitigation alternatives. Based on these
building blocks, the following questions can be asked to facilitate the generation of alternatives.
• How can vulnerabilities be removed or reduced?
• How can threats be removed or reduced?
• How can consequences be reduced?
• How can consequences be transferred?

Most likely, a risk mitigation alternative will address combinations of the above questions at varying
degrees. It is worth to note that by addressing the vulnerabilities and threats, the likelihood of the risk
scenario is essentially reduced.

13.5.2 Comparative Analysis for Tradeoffs

Risk mitigation alternatives often have costs for implementation. This cost is not necessarily the monetary
and direct cost but can also be in the form of social and opportunity costs. There are a number of tools to
support engineering managers in comparing these alternatives. Some comparative analysis tools for deci-
sion support are:
• Life cycle assessment (LCA) is a method for the comprehensive environmental assessment of products
and services.
• Programmatic comparative risk analysis (PCRA) refers to the application of comparative risk assess-
ment to set priorities for research and risk management actions.
• Risk tradeoff analysis (RTA), sometimes called risk-risk tradeoff analysis or risk-risk analysis for ana-
lyzing countervailing risks that occur due to the management of target risks.
• Health-health analysis (HHA) (also known as wealth-health analysis) attempts to capture the complex
relationship between induced changes in personal disposable income that result from regulation or
policy and their public health consequences.
• Benefit-cost analysis (BCA) attempts to measure both benefits and costs connected to all consequenc-
es of decision alternatives. Usually, monetary values are used as common metrics for both costs and
benefits.
• Cost-effectiveness analysis (CEA) is similar in scope to BCA but measures nonmonetary consequences
in physical indicators.

The following table adapted from Hofstetter et al. (2002) shows when one tool may be more appro-
priate over the other.

Table 13.4. Risk Analysis Tools

Tool Units of Costs Units of Benefits Primary Objective

Benefit cost analysis Monetary Monetary Maximize net benefits
(BCA)
Life cycle assessment Physical impacts and Equal functional unit Lowest impact
(LCA) damages
Risk tradeoff analysis Direct health impact Differences in impacts Lowest health impact
(RTA)
Programmatic Ordinal ranking Not applicable Worst thing first
comparative risk
assessment (PCRA)
Cost effectiveness Monetary Direct health impact Biggest bang for the buck
analysis (CEA)

222
 Risk Management

13.5.3 AHP
A particular comparative tool deserves detailed discussion—the Analytic Hierarchy Process (AHP).
Developed at the Wharton School of Business by Thomas Saaty, AHP is composed of previously exist-
ing concepts such as hierarchical structuring of complexity, pairwise comparisons, redundant judgments,
eigenvector method for deriving weights, and consistency considerations. A popular software implementa-
tion of AHP, “Expert Choice” was developed in 1983 and is currently widely used.
Some important capabilities of AHP are:
• Allows decision-makers to model a complex problem in a hierarchical structure showing the relation-
ship of goals, objectives, subobjectives, and alternatives
• Enables decision-makers to derive ratio scale priorities instead of arbitrarily assigning them
• More than just a decision-making tool can be used in forecasting, resource allocation, and other ap-
plications
• Pairwise Relative Comparisons
• Process can be performed using words, numbers, or graphical bars, and typically incorporates redun-
dancy, which results in a reduction of measurement error
• Accommodates use of expert judgment and its bases (the hard data, knowledge, experience for the
judgments) instead of arbitrarily assigned weights
• AHP allows for inconsistency and provides a measure of inconsistency

A particularly useful concept in risk management built into AHP is the marginal rate of substitu-
tion—essentially showed by the old adage “How much apple is an orange worth for you?” Through the
compensatory natures of AHP, engineering managers are compelled to express utility or preference and
enable them to adopt the otherwise extrinsic objectives, essentially confronting the conflict in the choice
situation by allowing them to trade off a low value dimension for a high value dimension.

13.6 Potential Problem Analysis

13.6.1 Stone-in-the-Pond Analogy

Comparative analysis shows the various costs and benefits of risk mitigation alternatives to the extent that
they can be expressed as unit costs and unit benefits. However, there may be more far-reaching effects that
can be attributed to these alternatives that are not captured by the comparative analysis tools. This goes to
the core of the systems approach to risk management and the realization that elements inside and outside
the systems of interest are often more tightly coupled than initially thought. Hofstetter et al. (2002) used
the stone thrown in the pond and the ripples it produces as metaphor to describe the effects of a present
decision to future decisions, such that:
• The stone thrown stands for the chosen risk mitigation alternative
• The ripples represent the consequences, such that the number of ripples increases as time passes
• Ripples come in various sizes
• Ripples have both up and down sides representing both positive and negative effects

Aside from the original risk scenario, which prompts the whole decision process (aka target risk) often
reflected by the main objective (e.g., minimize public risks to WNV), there maybe two other types of
unintended risk scenarios:
1. Countervailing risk—The risk (i.e., undesirable effect) that arises from the action of managing the
target risk (e.g., increase in health risks due to traffic accidents and pollution).
2. Synergistic effect—Desirable consequence of managing risk other than reducing the target risk (e.g.,
reduction in crime rate at certain hours).

223
Engineering Management Handbook

13.7 Implementation, Documentation and Monitoring

13.7.1 The Need for Documentation and Monitoring

At this point, the chosen risk mitigation alternatives are put into action, i.e., mitigation alternatives are
turned into mitigation actions. Due to the inherent uncertainty of risk and the significant resources that
go into its mitigation, the performance of any mitigation action has to be closely monitored all through-
out its implementation. Risk monitoring pertains to the systematic tracking and evaluation of the per-
formance of risk mitigating actions against established metrics (Conrow, 2005). Monitoring is best done
by diligent documentation in the form of recording, maintaining, and reporting assessments of the target
risks as well as the emergence or expiration of synergistic and countervailing risks. Note that the emer-
gence of synergistic or countervailing risks may trigger another full-blown risk management effort such
that they may eventually become the target risks of another set of mitigation actions. All of these monitor-
ing and documentation is in addition to the traditional project management activities concerned primar-
ily with the cost, schedule, and performance aspects.

13.7.2 Lessons Learned for the Engineering Managers

Engineering managers will benefit greatly from lessons learned by risk analysts and managers on the com-
mon issues of managing risks toward successful research, development, and engineering activities. These
issues are as follows (some were adapted from Conrow, 2004):
1. Risk management is more than just risk assessment—Engineering managers have to keep in mind
that most organizations manage their risk as a secondary objective in support of their primary objec-
tive (e.g., when an automotive company tries to manage its financial liquidity risks).
2. Repeatability vs. flexibility in RM processes—Because every organization may have its own require-
ments for effective management of risks, the monitoring and documentation of risks mitigation
actions may come in many form but has to have some degree of repeatability for ease of scientific
analysis and comparison.
3. Sensitivity and accuracy of quantitative results—Many quantitative tools in risk assessment (e.g.,
statistical analyses packages) may express numerical to a level of accuracy that is not expressive of the
inherent uncertainty of a particular risk scenario.
4. Intersection of knowledge domains and RM—Because the ripple effect of decision in risk manage-
ment transcends time and system boundaries, effective risk mitigation actions usually involves a
multi- and cross-disciplinary approaches.
5. Stove-piped RM processes—Engineering managers must be concerned not to perform risk manage-
ment subject to the artificial constraints placed by organizational, cultural, political, or technical
boundaries; e.g., managing what is initially viewed as purely technical risk will most likely involve
some financial and socio-political risk.
6. Proper use of ordinal and cardinal values; many tools and techniques in risk assessment commits the
sin of adding and comparing ordinal numbers (e.g., adding ranks). Even though this sin is usually ac-
ceptable to some degree of analysis, the engineering manager needs to be aware of the limitation and
possible pitfalls of these actions.
7. Symmetry between measures of probability and consequence—In the simplest form of expressing
risk as a direct mathematical product of consequence and probability resulting to a unit-less number,
the engineering manager should keep in mind the apparent lack of symmetry between the two, e.g.,
probability ranges from 0 to 1 while consequence ranges from $0 to theoretically $∞.
8. Other (elusive) properties of risk aside from probability and consequence—Related to the previous is-
sue, risk has properties that can be difficult to express quantitatively, much less be contained in either
probability and monetary consequences, e.g., social and cultural properties.
9. RM results are only as good as the analyst—Many risk assessment results may be expressed in num-
bers particularly in quantitative risk assessment. However, the high degree of uncertainty and cross-
disciplinary nature of risk places considerable importance on the analyst as much as on the tools and
techniques that may have been used.
224
 Risk Management

10. Choice of model and procedures—Similar to the previous issue, the proliferation of tools and meth-
ods in managing risks results to a lack of de facto standards. Thus, the engineering manager needs to
be aware of the chosen models and procedure and their suitability for the risk scenario at hand.
11. Multiple Stakeholders—Because risk transcends time and system boundaries, there are likely more
than one significant stakeholder who most likely equates to differences in their respective risk concep-
tion, objectives and behavior. These differences have to be recognized in generating alternatives and
tradeoff analysis and the potential for a suboptimal solution.
12. Multiple risk management processes—One very important purpose of monitoring and documenta-
tion in risk management is to be able to review the process at each step of managing risk. The wide
choice of tools and techniques in risk management, each with their own strengths and weaknesses,
may result to an after-the-fact realization of the omission or exaggeration of some risks. Good moni-
toring and documentation hopefully will result to an early diagnosis of such cases and enabling the
engineering manager to avoid its recurrence.

13.8 Advanced and Other Topics

Table 13.5 contains important topics and the respective references for advanced risk analysis.

Table 13.5. References for Advanced Risk Analysis

Importance to Engineering
Topic References
Managers
Risk-based For cases where financial Pinto, A.C., Arora, A., Hall, D., Schmitz, E., Challenges
economic and economic evaluation of to Sustainable Risk Management: Case Example in
evaluation alternatives are critical to Information Network Security. Engineering Management
decisions Journal, vol. 18, no. 1, March 2006.

Arora, A. D., Hall, C.A., Pinto, D.

Vulnerability For cases when threats and
assessment system vulnerabilities are
uncertain or dynamic
Ramsey, and Telang, R., Measuring the Risk-Based Value of
IT Security Solutions, IEEE IT Professional, vol. 6, no.6, pp.
35-42, 2004.
Gheorghe, A. Integrated Risk and Vulnerability Management
Assisted by Decision Support Systems. Relevance and Impact
on Governance (Ed.), Springer, Dordrecht, 2005.

Gheorghe, A. and Mock, R. Risk Engineering. Bridging Risk

Analysis with the Stakeholders Values, Kluwer Academic,
Dordrecht, 1999.

13.9 References
Haimes, Y. Y., Kaplan, S., and Lambert, J. H. Risk filtering, ranking, and management framework using
hierarchical holographic modeling. Risk Analysis, vol. 22, no. 2, pp. 381–395, 2002.
Conrow, Edmund H., “Risk Management for Systems of Systems,” Journal of Defense Risk-Software Engin-
eering, Feb. 2005.
Conrow, Edmund H., “Risk Rant: The top 10 risk analysis issues and why they are important to you,”
Risk Management Intelligence Network, June 2, 2004.
Haimes, Yacov, Risk Assessment, Modeling, and Management, Second Edition, Hoboken, NJ: Wiley—Inter-
science, 2004.
Hofstetter, P. et al., “Tools for Comparative Analysis of Alternatives: Competing or Complementary Per-
spectives?” Risk Analysis, vol. 22, no. 5, pp. 833-851, 2002.
Castillo E. Extreme Value Theory in Engineering. San Diego: Academic Press, 1988.
225
 Samuel Kovacic, Old Dominion University
Samuel F. Kovacic is a Research Scientist with the National Centers for System of Systems Engineering (NCSOSE)
at Old Dominion University.  His primary research is in the philosophical constructs of worldviews and the study
of management and engineering practice as it pertains to complex situations, system of systems, strategic
management and organizational change. he retired from active duty with over 22 years service in the United
States Air Force. During that time Sam has developed extensive experience in flight and combat operations,
and the software/system engineering field working progressively challenging assignments with background
in Operations, Command, Program Management, System and Software Engineering, Budgetary Oversight,
Contractor Officer/Technical Representative, Communications, and Vulnerability Assessments. Samuel  is
currently pursuing a Ph.D in Engineering Management and Systems Engineering from Old Dominion University.
He holds an M.B.A in Aviation from Embry Riddle Aeronautical University, and a B.Sc. in Computer Science from
the University of Maryland.

Donald N. Merino, Stevens Institute of Technology

Donald N. Merino is a tenured full professor and the Alexander Crombie Humphreys Chaired Professor of
Economics of Engineering at Stevens Institute of Technology. He teaches Engineering Economy, Financial
Management, Decision Analysis, Total Quality Management, and Strategic Planning. He is Founder Emeritus
of the undergraduate Bachelor of Engineering in Engineering Management (BEEM) and the Executive Master
in Technology Management (EMTM) Program at Stevens. He was the Editor of the ASEM Engineering Body of
Knowledge (EM BoK) published in 2008. He won the Morton Distinguished Teaching Award for full professors at
Stevens. John Wiley published his book, “The Selection Process for Capital Projects”. Dr. Merino received two
Centennial certificates from the ASEE in Engineering Economics and Engineering Management. He is past Chair
of the Engineering Management Division and Engineering Economy Division of ASEE. Dr. Merino was awarded
the ASEM and ASEE Bernard Sarchet Award. He is an ASEM and ASEE Fellow and past president of ASEM. Dr.
Merino has 25 years of industrial experience in positions of increasing managerial / executive responsibilities.
Since joining academe 24 years ago, he has published 52 refereed journal articles and conference papers and
over 50 research reports.

Greg Parnell, United States Military Academy

Dr. Gregory S. Parnell is a Professor of Systems Engineering at the United States Military Academy at West Point
and teaches systems engineering, decision analysis, and operations research courses. His research focuses
on decision analysis, risk analysis, and resource allocation for defense, intelligence, homeland security, and
environmental applications. He co-edited Decision Making for Systems Engineering and Management, Wiley
Series in Systems Engineering, Wiley & Sons Inc., 2008, and has published over 100 papers and book chapters.
He is Chairman of the Board and a senior principal of Innovative Decisions Inc., a decision and risk analysis firm,
and a former principal with Toffler Associates, a strategic advisory firm.  He teaches professional development
short courses in Systems Decision Making and Multiobjective Decision Analysis. He is a member of the Chief
Technology Officer and Information Assurance Panels of the National Security Agency Advisory Board and is
a former chair of a National Research Council study on bioterrorism risk analysis.  Dr. Parnell has served as
President of the Decision Analysis Society of the Institute for Operations Research and Management Science
(INFORMS) and the Military Operations Research Society (MORS). He is a fellow of INCOSE, INFORMS, and
MORS. Dr. Parnell received his Ph.D. from Stanford University.

C. Ariel Pinto, Old Dominion University

Ariel joined the Department of Engineering Management and Systems Engineering at Old Dominion University
in 2004. Previously, he was a research fellow at the Software Industry Center at Carnegie Mellon University, and
at the Center for Risk Management of Engineering Systems at the University of Virginia. His research interests
are in the areas of risk management in engineered systems, including project risk management, risk valuation,
risk communication, analysis of extreme-and-rare events, and decision-making under uncertainty. He earned
his doctorate degree in Systems Engineering from the University of Virginia and master and bachelor degrees in
Industrial Engineering from the University of the Philippines. In 2009, he co-founded the Emergent Risk Initiative
at Old Dominion University (ERI@ODU) with the vision to create the next generation body of knowledge in
risk management for current and future systems and organizations characterized by uncertainty, emergence,
complexity, and interdependence.

296
Reproduced with permission of the copyright owner. Further reproduction prohibited without
permission.