RSK520 ReferenceMaterial

Copyright ESI International
J anuary 2007
All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or
transmitted, in any form or by any means, electronic, mechanical, photocopying,
recording, or otherwise, without the prior written permission of ESI International.

All material from A Guide to the Project Management Body of Knowledge (PMBOK
Guide), Third Edition is reprinted with permission of the Project Management Institute,
Four Campus Boulevard, Newtown Square, Pennsylvania 19073-3299, USA, a
worldwide organization of advancing the state-of-the-art in project management. Phone:
(610) 356-4600, Fax: (610) 356-4647.

PMIdid not participate in the development of this publication and has not reviewed the
content for accuracy. PMIdoes not endorse or otherwise sponsor this publication and
makes no warranty, guarantee, or representation, expressed or implied, as to its
accuracy or content.

PMIdoes not have any financial interest in this courseware and has not contributed
any financial resources.

"PMI" is a service and trademark of the Project Management Institute, Inc., which is
registered in the United States and other nations.

"PMBOK" is a trademark of the Project Management Institute, Inc., which is registered in
the United States and other nations.

"PMP" is a certification mark of the Project Management Institute, Inc., which is
registered in the United States and other nations.

ESI International
901 Glebe Road
Suite 200
Arlington, VA 22203
Phone (703) 558-3000
Fax (703) 558-3001
ESI International, Inc. iii
CONTENTS
Page
Chapter 1: Introduction to Risk .................................................................................................... 1
Introduction to Risk ............................................................................................................ 2
Risk Characteristics and Exposure ....................................................................................... 2
Risk Management ............................................................................................................... 4
Risk Management and the Project....................................................................................... 5
Types of Risk...................................................................................................................... 8
Characteristics of Risk Events .............................................................................................. 9
Factors Affecting Risk Perceptions..................................................................................... 11
Chapter Summary............................................................................................................. 13
Next Steps Action Plan ..................................................................................................... 14
Chapter 2: Risk Management Planning and Identifying Risks...................................................... 17
Risk Management Planning and Identifying Risks.............................................................. 18
Risk Management Process ................................................................................................ 18
Risk Identification............................................................................................................. 20
Risk Events and Risk Event Lists ........................................................................................ 28
Chapter Summary............................................................................................................. 30
Next Steps Action Plan ..................................................................................................... 31
Chapter 3: Analysis Fundamentals .............................................................................................. 34
Establishing Risk Measurement Parameters ....................................................................... 35
Presenting Risk Information .............................................................................................. 35
Probability Analysis and Rules of Probability .................................................................... 39
Chapter Summary............................................................................................................. 45
Next-Steps Action Plan ..................................................................................................... 46
Chapter 4: Analyzing and Prioritizing Risk ................................................................................. 49
Next Steps in Risk Management........................................................................................ 50
Step 3: Analyzing Risks .................................................................................................... 50
Impact Analysis ................................................................................................................ 51
Tools and Techniques for Risk Analysis ............................................................................ 52
Overall Risk Rankings....................................................................................................... 58
Step 4: Prioritizing Risks ................................................................................................... 59
Risk Prioritization Process and Tools................................................................................. 60
Prioritized Risk Listing...................................................................................................... 62
Chapter Summary............................................................................................................. 63
Chapter 5: Risk Response Planning ............................................................................................. 67
Risk Response .................................................................................................................. 68
Risk Response Planning Process ....................................................................................... 68
Risk Response Strategies for Threats.................................................................................. 70
Risk Response Strategies for Opportunities ....................................................................... 71
ESI International, Inc. iv
Page
Schedule Risk Response Planning..................................................................................... 72
Response Analysis Matrix ................................................................................................. 72
Reserves........................................................................................................................... 74
Risk Management Plan ..................................................................................................... 76
Chapter Summary............................................................................................................. 77
Chapter 6: Risk Execution, Evaluation, and Updating ................................................................. 81
The Final Risk Management Steps..................................................................................... 82
Risk Monitoring and Control............................................................................................. 82
Step 6: Execute Risk Strategy ............................................................................................ 84
Step 7: Evaluate Results .................................................................................................... 85
Step 8: Document Risk Management Results .................................................................... 88
Chapter Summary............................................................................................................. 90
ESI 1
Introduction to Risk
Chapter 1
This chapter introduces the fundamentals of risk in a project.

Formula
Chapter Overview
Legend
1

ESI 2
Any study of risk and risk management should begin with the
fundamentals: those basic terms and concepts that underlie all the more
detailed methods and activities that project managers and their
organizations apply and undertake. Some of these terms and concepts
are related to the project itself, because it is the project manager who is
ultimately responsible for risk management in his or her project. Others
relate strictly to the discipline of risk management. In any event, risk is
something that is a part of every project and has to be continuously
evaluated and dealt with throughout the project life cycle.
Whether you are encountering some of these terms for the first time or
whether you are an accomplished project manager, you have
undoubtedly experienced the realities of risk events in a project. In fact,
a project manager is in simple terms a risk manager. Every project
contains some level of risk. If it did not, it would not be worth pursuing.
As a result, project managers have to live with the reality of risk. Their
challenge is managing it.
Risk is an uncertain event or condition that, if it occurs, has a positive or
a negative affect on a project objective. Notice that in the definition, we
clearly stated that there is either a positive or negative affect on the
project. Risk is one of those words that immediately conjure up the
image of something bad. But it is important to remember that risk can
also provide positive benefits as well as negative ones. We will discuss
this in more detail later.
Risk management is the systematic process of identifying, analyzing, and
responding to project risk. We want to maximize the probability and the
impact of any positive risk factors and minimize the probability and
impact of those that might negatively affect the project.
Some organizations establish a risk office or assign a person to be the
risk manager. This generally is a mistake. The project manager is
ultimately responsible for risk, and taking the risk function out of the
project or establishing it as a separate function from the project may
cause the project manager to be less careful about risk events because
someone else is responsible for them. Besides, a person or group outside
the project knows less about the project requirements (and consequently
its risks) than the project manager and the project team do.
So as a project manager, assume you are responsible for the risks in your
project because, frankly, you are.
Risk Overview
Key Risk Definitions
4 1

ESI 3
Risk Characteristics and Exposure
A project risk has three defining elements:
It is a definable event.
There is a probability the event will occur.
There is a consequence to the project if the event occurs.
The event is what could happen, both good and bad, to the project.
Remember that risk by itself is a neutral word; it could be something
devastating that might happen, or it could be an opportunity to improve
the organizations capability or profit. Regardless, the risk event is what
could happen to the project.
It is very important to determine when a risk event might occur. If the
event is likely to occur early in the project life cycle, then it must be
addressed immediately. Potentially long-term risk events, that is, events
that probably will occur later in the project life cycle, must be planned
for but dont have to be addressed immediately (other than for
contingency planning).
The frequency of an event also is important to determine. A risk event,
even a low risk event, can be disrupting and even disastrous to a project
if it is likely to occur over and over. So if you can determine the
likelihood that an event will keep occurring, it can help you plan for the
eventuality and perhaps even eliminate the risk completely.
The probability of the risk is simply the chances the event will occur.
Clearly, there may be a potential event, but if the chances of it occurring
are slim to none, then it is not really a risk at all as a practical matter. As
we will see later, it is important to consider this aspect of risk and, if
possible, assign an actual percentage probability to the occurrence of risk
events. Assigning a probability figure enables one to use additional
planning tools in preparing against the risks impact.
The consequence of the occurrence of any risk event is measured in
terms of its impact on the project. The project can have an identified risk
event with a high probability of its happening; but if the impact (even if it
does happen) is low, then the risk can be ignored or at least tolerated.
With these elements described, the amount of risk exposure to the
project and to the organization can be determined.
Risk exposure is another way to describe the impact of a risk event
occurring. Risk exposure is determined by multiplying the probability
times the impact. Stated another way, most project managers equate risk
exposure with expected value. (Expected value is a common measure
used in risk and quality assessments, but it will be reviewed in a later
Three Defining
Elements
Risk Exposure

ESI 4
Risk Characteristics and Exposure (continued)
chapter.) This is one instance in which the senior management is not
particularly interested in the gain from a risk event; when he or she asks,
What is our risk exposure? the interest is in determining what the cost
to the project or organization could be.
One of the challenges the project manager and the project team face is
defining risk. Even though we provided a definition of risk and described
its elements, the reality is that everyone views risk differently. For
example, if one asks, What is the risk? he or she may be asking for a
description of the risk event.
Another person might ask, What is the risk? and be referring to the
impact of the risk or the risk exposure to the organization. Thus, it is
imperative that the project manager be well versed in risk management
and particularly adept at determining exactly what the person wants to
know. More importantly, the project manager must be able to describe
exactly what the person wants to know within his or her frame of
reference. The latter can be greatly aided by understanding the different
types of risks.
Risk Management
Knowing that the project manager is responsible for project risk
management may not provide a sense of comfort, but considering how a
good risk management program can benefit the project and organization,
every project manager should strive to be an accomplished risk manager.
There are several benefits of risk management. They include:
Minimizing management by crisis: When a risk event occurs,
there is always a reactive response to it if the risk was not
anticipated.
Minimizing surprises and problems: As you will soon discover,
identifying and planning for risk is the best way to avoid being
surprised by it.
Gaining competitive advantage: Any well developed,
documented, and implemented risk process reduces schedule
and cost impacts of risk events, thus improving the organizations
advantage in the marketplace.
Decreasing overall project variances: One major problem in
project management is maintaining project progress within tight
variances from the plan. Risk management is one of the principal
ways of reducing these variances. If the risk is expected and a
response is rapidly implemented, then the projects planned track
is more likely to be maintained.
Risk Exposure
(continued)
Benefits of Risk
Management

ESI 5
Risk Management (continued)

Increasing the probability of success: Keeping the project on its
planned schedule and budget enhances the probability that the
project can be completed successfully.
Increasing profitability: Poor risk planning invariably leads to
rework, scheduling problems, and cost overruns; good risk
planning eliminates many of these problems and contributes
directly to the bottom line.
We mentioned earlier that the project manager has ultimate responsibility
for risk management in his or her project. We also mentioned that it is
not wise to assign a separate person or group to be responsible for risk
because the tendency is to assume someone is taking care of the risk
problems when, in fact, he or she may not be. That does not mean that
the project manager cant assign task leaders or other team members to
be responsible for watching the potential risks that have been identified
in their tasks and for implanting the risk response strategy to cope with a
risk should it happen.
The project manager is responsible for initiating and leading the risk
management process. This is done by integrating the risk management
plan into the project plan and then ensuring that every team member is
familiar with the identified potential risks, when they are likely to occur
during the project life cycle, the task(s) they are likely to affect, and the
approved response strategy to mitigate each risk.
The project team members are responsible for performing the risk
management process by watching for risk triggers (that is, indicators that
a risk event could occur), actually implementing the appropriate risk
response strategy, and most importantly, reporting the status of the risk to
the project manager. A closely coordinated risk management plan and a
defined and documented risk management process will help ensure a
smoothly run and successful project.
Risk Management and the Project
Risk management has to be performed through out the project life cycle,
and the identification of potential risk events is begun during the earliest
project planning stages.
There are several steps in the risk planning process, and each one is
discussed separately in detail in this text. But it is important to remember
that the risk management process cannot be performed piecemeal; it
must be done as a total process with every step reevaluated every time
risk is assessed during the project.
Benefits of Risk
Management
(continued)
Project Manager and
Team Member
Responsibility in Risk
Management
Risk Management Is
Integrated with the
Project Planning
Process

ESI 6
Risk Management and the Project (continued)
Generally, the steps of the risk process are
Identification
Quantification
Response development
Response control
These are the major steps, which will be expanded and discussed in
depth in the next chapter when we introduce the ESI Risk Model. The
reasons for introducing these steps here are twofold: to lead into how
one can begin identifying risks during project planning and to accentuate
the fact that there are specific steps to the risk management process that
cannot be overlooked. This concept will become clearer during the
following discussion.
At the beginning of a project, the earliest that you will have some sense
of its risks is during the assessment of the requirements. The customer
almost always makes some statements as to when the product or service
is needed. That statement potentially defines a risk. For example, if the
customer states that the product must be operational by no later than a
particular date, that may create a risk because it may not be possible to
deliver by that date without extraordinary efforts such as working
overtime, hiring new resources, teaming with another company, or
engaging consultants. There also will be other statements in the
requirements that indicate risks. For example, the customer may place
restrictions on the budget and product reliability or maintenance
requirements.
The next opportunity to identify risk is in the development of the WBS.
The WBS is, in the opinion of most project managers, the best place to
identify risks because after the tasks are identified, the attendant risks
almost identify themselves. For example, if a required task is one that
your organization has little or no expertise to deliver, then clearly it is a
risk; even if your organization has the expertise, the resources may not be
available when they are needed. Another opportunity for identifying risk
is while doing budget and schedule estimates. Obviously, when tasks
are planned and the cost and time to do them are considered, there may
or may not be an impact to the project. Again, it is a matter of pure
resource availability and, during this assessment period, the skill sets that
are needed and available.
Thus, every aspect of the planning process offers opportunities to identify
risk. In addition, every project manager or team action or consideration
should be weighed against other project considerations because every
time a decision is made relative to one task, it invariably impacts other
tasks.

Risk Management Is
Integrated with the
Project Planning
Process (continued)

ESI 7
Risk Management and the Project (continued)
By the time the cost, schedule, and scope baselines are defined and
agreed upon, most of the risks in the project should be identified and
assessed as to whether they represent real risks, response strategies
should be developed, and an overall risk plan should be written.
The best project managers are those who constantly evaluate and test
their plans and revise them on a regular basis. That is not to imply that
the projects baseline changes every few days; it does not. But planning
by definition involves estimating, which does require reevaluating and
refining. Every time any plan or any portion of a plan is updated, the risk
management plan must be reevaluated and updated too. Thorough risk
management is integral to the success of the project and without it, the
project may be doomed to failure before it ever begins.
But the news is not all dismal. As the project progresses, risk decreases.
It decreases simply because we learn more about the project and its risks
as time passes. Also, risk events that were predicted at the beginning of
the project either may actually not occur; and if they do occur, our
response strategies are put into place, and we know how well the project
responded.
However, risk only decreases in the sense that the probability of a risk
event happening decreases. The impact of a risk event, if it should
happen, increases as the end of the project gets closer. This is true
because by the time the project is in its final phases, the investment of
time and money in the project is at its highest.
Risk Management Is
Integrated with the
Project Planning
Process (continued)
(continued)
Risk Management Is a
Full Project Life-
Cycle Responsibility
Project Life Cycle
Risk
Impact
Level
Time

ESI 8
Types of Risk
Actually, there are different types of risk. Remember that we spoke of
opportunity for gain and the possibility of loss when risk is considered.
In a very real sense, that notion defines the types of risks that are
confronted in a project. Basically, at least for all practical purposes, there
are four types of risk that project managers and their teams need to be
aware of. They are
Business risk
Pure or insurable risk
Known risk
Unknown risk
Business risk is the normal risk of doing business and carries with it the
potential for both loss and gain. For example, suppose the customer for a
project decides to change the scope. The change may involve a negative
risk, that is, loss, because it might require expertise that your organization
does not possess. On the other hand, it might involve considerable gain
because it could mean significantly more profit if you can accomplish the
scope change efficiently. Business risk is the kind of risk an organization
should not only embrace but also pursue. It is the type of risk we can
manage.
Pure or insurable risk is the risk that is associated only with loss and has
no opportunity for gain. This includes threats such as fire or hurricane.
The organization needs to avoid or at least greatly reduce the direct
impact of this form of risk by passing it on to another party. This can be
accomplished by purchasing insurance or by teaming with another party
that has the expertise to do the job.
Generally, we think of this kind of risk in terms of catastrophic events,
such as fire, but the fact is, this kind of risk occurs when an organization
attempts to do a job without having the requisite skill sets or expertise.
Those are the cases where the solution is simply to team with a company
that has the skill and expertise to accomplish the task(s) in question.
Known risk includes those risks one should naturally be aware of (such as
scheduling problems because of limited or committed resources) that
must be identified and watched. Known risks are usually manageable,
because we know they exist and we know what has to be done to avoid
or deal with them. It is almost always possible to develop a strategy that
will deal with this type of risk. For example, if the known risk is that the
schedule could be impacted because of a shortage of resources at a
Are There Different
Types of Risk?
Business Risk
Pure or Insurable
Risk
Known Risk

ESI 9
Types of Risk (continued)
particular time, then the decision could be made to either hire additional
resources, team with another company, outsource the work, or negotiate
with the customer to delay work on that particular portion of the project.
Unknown risk is not so easy to deal with. By its very definition, it
includes risks that we cannot anticipate or plan for, except perhaps by
adding money to the management reserve fund.
An unknown risk is, for example, a tornado that strikes in an area not
usually susceptible to such weather phenomenon. The disease AIDS was
an unknown risk before it hit millions of people.
Having reviewed the different types of risk, it is important to consider
some of the characteristics of risk events themselves.
Characteristics of Risk Events
Recognizing risk characteristics aid in planning responses to them. One
or more of several characteristics are inherent in every risk event. Risk
events are
Situational
Interdependent
Magnitude dependent
Value based
Time based
Because risks can occur from actions by team members, stakeholders
(internal or external to the project) or just from the normal project
activities, risk inevitably must be handled on a case-by-case basis. In
short, risks are predictable only within limited parameters, and so the
ongoing use of sound project management tools and techniques that are
tried, documented, and available to team members is crucial.
One of the many problems in dealing with risks is that they are
interdependent; any risk event may affect or even create others. This
characteristic has two important ramifications. First, it means that every
risk must be frequently assessed to ensure that there are no
interdependencies or, if there are, that they are known and understood.
Known Risk
(continued)
Unknown Risk
Risk Events Overview
Situational
Interdependent

ESI 10
Characteristics of Risk Events (continued)
Second, if the domino effect of interdependent risks is large enough, the
immediate perception is that the project is too difficult. In the second
case, a too risky project is one that loses stakeholder and team member
support very rapidly.
Low risk events usually involve only a few people or relatively low costs.
In other words, the risk is low enough that its affect on the project can be
ignored. However, as the magnitude of the risk increases, it has impacts
on many people, organizations, and costs. The fact that the risk impact is
potentially greater is not necessarily bad; remember that risk has both a
loss and gain component. For example, if the customer increases the
scope of the project, the change might add increased risk to the
organization because the new requirement(s) may involve work outside
the organizations expertise. However, the increased scope may mean
larger profits if the organization can increase its skill base by either
teaming with another company, hiring the requisite experience and skills
needed, or negotiating a delay in providing the additional scope
requirements until the skill sets are trained.
Again, if the perception of risk is that it is too big to be handled, then the
project manager will lose stakeholder and team support. Arguably, the
bigger problem is that risks can become so big and affect so many people
or groups of people that the cost of involvement in the project outweighs
its potential payoff.
Risk means different things to different people. The banking industry, for
example, is very conservative. Bankers do not lend money to people
who have poor credit ratings. On the other hand, venture capitalists
have no problem lending money on very risky ventures, provided the
payoff is large. So risk management in each organization will take on a
different complexion depending upon the organizations industry, its
business goals, its culture, and how well they are equipped and trained to
handle risks.
Risk is a phenomenon that is time based; it is always in the future. In
fact, one can think of risk as a problem or opportunity that has not yet
arisen. Time also has a way of affecting the perception of risk. If there is
a lot of time remaining in a project or if a long period of time has passed
without any significant risk event occurring, then risk anxiety lessens. If
there is less time available to accomplish a task or project, then risk
anxiety heightens.
Interdependent
(continued)
Magnitude
Dependent
Value Based
Time Based

ESI 11
Characteristics of Risk Events (continued)
In the former case, having more time available, risk actually does lessen.
The more time we have, then the more we understand about the project
requirements, how well the technical solution is working, whether the
proper personnel are on the project, and the more efficient the
management processes, including risk management, are working.
It is important to remember these risk characteristics because they affect
how we plan our risk responses, which is discussed in more detail later
in this text. One way to remember them is with the mnemonic, STIM-V,
which is (S)ituational, (T)ime based, (I)nterdependent, (M)agnitude based,
and (V)alue based.
Factors Affecting Risk Perceptions
Organizations and individuals have perceptions of risk that influence
their approach to them. There are many reasons why project teams and
organizations in general do not do a good job managing risk.
Understanding these reasons and factors affecting the perception of risk is
one key to improving the risk management process for your organization
and your project.
The factors that most affect the perceptions of risk are
Lack of control
Lack of information
Time
Risk preference
Much of project risk is not within the control of the project team. It is
risk that is created by outside influences such as weather phenomena,
environmental or other regulations, or even actions from other project
and organizational activities. Perhaps the most common risks occur
when one projects schedule depends upon the schedule of resources
within other projects. If a key task requires, for example, tests by an
overworked, small, specialized test group within the organization, the
risk of that task and the projects schedule being affected has a high
probability.
Notice that one of the exacerbating factors with the lack of control
problem is that these risks tend to be unknowns. This is not always so, as
the lack of testing capabilities example shows; but it very often is.
Time Based
(continued)
STIM-V
Risk Perceptions
Overview
Lack of Control

ESI 12
Factors Affecting Risk Perceptions (continued)
Lack of information is the norm, particularly in the early stages of risk
identification. Generally, the lack of information is caused by incomplete
or poorly stated requirements, unfamiliarity with the customer or the
customers needs, or lack of experience or skills with the likely technical
solution. The single biggest obstacle in obtaining adequate information is
time. Given enough time, we could collect all the relevant data needed
to identify and plan for nearly every risk, but most projects must meet
either a customers operational schedule or time to market imperative.
In addition to the impact of time on how much information is or is not
available, time has other important implications as well, some perceptual
and some real.
The farther the potential risk event is into the future, then the greater the
degree of uncertainty is about the risk impact should the event occur.
On the other hand, the perception often is out of sight and out of mind.
We tend to become complacent about the risk, and unless a
conscientious effort is made to continue assessing it, the risk events
occurrence may come as a surprise and turn out worse than expected.
There is one good thing about time when it is used properly in the sense
of risk planning. Given adequate time, the project manager and his or
her team can change their approach or plan contingency approaches to
minimize the negative effects and maximize the opportunities that the
risk event holds.

Lack of Information
Time

ESI 13
Chapter Summary
There are three defining components of risk:
o The event itself (what can happen, good or bad, to the
project?)
o The probability of occurrence (how likely is it that the
event will occur?)
o The impact of the event (what is the effect on the
project if the event does occur?)
Risk can have either a negative or positive component if it
is business risk. This is the kind of risk every project and
organization should be pursuing, with the aim of reducing
the former and maximizing the latter.
Risk that has only a potential for loss is called pure or
insurable risk. This kind of risk should be avoided or
passed to a third party either by purchasing insurance, by
teaming with another company, hiring additional
personnel, or by renegotiating the delivery schedule.
Risk events are inherently situational, interdependent,
magnitude dependent, value based, and time based.
Risk management is the process of identifying, analyzing,
and responding to the risks in a project.

Chapter Summary

ESI 14
Next-Steps Action Plan
Take a few minutes to review what you have learned from the last unit
and how you will apply the principles learned when you return to your
organization.
1. How is risk managed in your organization today?
2. How does your organization view risk?
What are typical threats in your environment?
What are typical opportunities in your environment?
3. Who is responsible for dealing with risk in your organization?
4. Why is it so important for risk management to be performed
through the project life cycle?
5. Turn to the Action Plan on the next page and document your next
steps.
6. Develop a list of two or three actions you will complete when
you return to work.
7. Identify who you need to involve for each item you have listed.
8. Finally, identify the appropriate time frame for accomplishing
each of these steps. For items you know will be ongoing, identify
milestones for each period (3, 6, 9, and 12 months and over).

Next-Steps Action
Plan

ESI 15
Risk Management Chapter 1: Introduction to Risk
Action Plan: Apply what you have learned from this unit by developing a list of actions you will complete when you return to your organization.
Time
What do I want/need to do next? Who 3 months 6 months 9 months 12+ months
1.

2.

3.

ESI 16
Time
4.

5.

6.

ESI 17

Risk Management Planning and Identifying Risks
Chapter 2
This chapter discusses the first two steps of the Risk Management Model.

Formula

Chapter Overview
Legend
2

ESI 18
Risk Management Planning and Identifying Risks
Risk Management Planning and Identifying
Risks
To manage risks effectively, the project manager must obtain thoughtful
input on project risks from the project team. To do this, the project
manager must be able to convince the project team of the importance
and benefits of risk management based on his or her own understanding.
The project manager should be able to describe the basic eight-step ESI
risk management model and the activities that it includes, identify risks
using a variety of tools and techniques, and develop a risk listing for a
project.
What is the relationship between risk management and project
management? Project management involves planning, organizing,
directing, and controlling company resources to provide a product or
service on schedule, within budget, and in accordance with the
customers stated requirements. Risk management is that part of project
management that deals with the processes of identifying, quantifying,
responding to, and controlling the risks inherent in a project.
In other words, there is a fundamental difference between risk
management and project management. Project management is the
process that gets us to an objective; risk management is an enabler to that
process. Risk management considers issues that could possibly affect that
process as it unfolds; project management looks at the process itself. Risk
management looks at how we can avoid problems; project management
looks at how we get beyond problems. It is a fundamental, very simple
difference. When it comes to risk management, we are looking at the
reality of day-to-day life and how we can have an impact on those things
that might stop us from getting to our objective. Project management is
the effort to work toward and actually reach that objective.
Risk Management Process
Like all project management processes, risk management involves the
application of tools and techniques to certain inputs to achieve certain
outputs. Inputs include such factors as the people involved and their
expectations. However, particular attention should be paid to the triple
constraints of time, cost, and scope (or schedule, budget, and quality). If
you lack experience in risk management, these constraints offer good
places to start looking for input, because all projects will have risks
associated with schedule, budget, and quality.
Overview
Risk Management
and Project
Management
Risk Management
Process Overview
2

ESI 19
Risk Management Process (continued)
The desired outputs resulting from the use of various tools and techniques
include a list of prioritized risks, a risk response plan, and a list of risk
indicators that, with proper monitoring, will provide early indications of
risks that come to pass.
Both PMI
and ESI International have developed risk management

models. ESIs is an eight-step model based on practical experience and
best practices that go beyond the information in A Guide to the Project
Management Body of Knowledge (PMBOK
Guide).
The ESI model will
serve the structure for the remainder of this text. They are listed in order
below with the corresponding steps from the model provided by the
PMBOK
Guide in parentheses
. T
he first two steps are addressed in this
chapter.
Risk Management Planning (Risk Management Planning)
Identify (Risk Identification)
Analyze (Qualitative and Quantitative Risk Analysis)
Prioritize (Qualitative and Quantitative Risk Analysis)
Plan (Risk Response Planning)
Execute (Risk Monitoring and Control)
Evaluate (Risk Monitoring and Control)
Document (Risk Monitoring and Control)
Risk management planning is the first step of an eight-step process. It
must be completed so that risk planning and analysis do not become
afterthoughts to project planning. It is important to set aside time and
processes to plan for project risk. This is done by conducting a team
meeting specifically to address risk issues. The agenda for the meeting
should include reviewing lessons learned from previous, similar projects
and reviewing all the project documents (statements of work, contracts,
specifications, resource availability charts, and so on) to ensure that the
team is aware of all potential risk sources. It should conclude with an
agreement on the process that will be followed and the tools and
techniques that will be used in planning for the risks associated with the
project in question.
Documenting and communicating are two activities throughout the eight-
step model that are ongoing and crucial to risk management planning.
Identifying risks is the second step in risk management, and it is
absolutely crucial. Risk identification is considered a key step in the
process according to ESI, PMI
, and virtually everyone else who deals

with the subject. It is arguably the most important step for several
reasons. First, it is one of the initial functions that the project manager
Risk Management
Process Overview
(continued)
ESIs Risk
Management Model
Step 1: Risk
Management
Planning
Step 2: Identify Risks

ESI 20
Risk Management Process (continued)
must perform. Second, when the project manager and project team do
not identify risks, they cannot take steps to mitigate them. Finally, simply
identifying the risks begins to reduce risk from the start.
Risk identification continues to be important throughout the duration of
the project. Although the initial project planning phase is the first time to
identify risk, it is not the only time to do so. Risks should be identified
continuously throughout the life of the project. In addition, the initial list
of risks may be used until the project is completed. This means that each
risk event must be stated specifically and clearly for the risk management
process to operate effectively, because the project team members must be
able to understand exactly what was meant when they refer at a later date
to the original risk management plan.
Risk Identification
Certain guidelines should be followed in describing risk events to ensure
that they are specific and fully defined. The effectiveness of the risk
management process relates directly to how well each risk event is
defined. If a risk event is not stated specifically, how can a project
manager develop a good risk response? How will the organization be
able to use lessons learned effectively in the future? Guidelines for risk
identification include the following:
The risk description should state the event that may happen,
when it is likely to occur, and what its impact will be. For
example, on a prison construction project the supplier of difficult-
to-find alarm glass windows might go out of business before
completing fabrication, thereby causing delays to accomplish
reprocurement with another supplier.
Use the WBS as a good tool for risk identification. This will help
ensure coverage of all significant risks and facilitate analysis of
their potential effects on the projects cost and schedule.
In identifying risks, be thorough but dont be absurd. Its easy to
start brainstorming risks based on every WBS activity only to
develop a ridiculously long list of trifling risks. Risk identification
should stick to those items with a reasonable likelihood of
occurring and a reasonably significant impact on the project if
they did occur.
The risk identification process should be completed by the team
in a group effort and not by individuals.

Step 2: Identify Risks
(continued)
Risk Identification
Guidelines

ESI 21
Risk Identification (continued)
Specific tools and techniques can be used to help the project team
identify risks. They include the following:
Expert interviews*
Delphi technique*
Brainstorming*
Nominal group technique
Crawford slip method
Affinity Diagram
Analogy process
Checklists, questionnaires, and templates*
These are all proven tools and techniques, and each has different nuances
in exposing risk and allowing the project team to find risk. The project
manager should be careful to select the most appropriate tool for each
situation.
The expert interviews process starts with identifying appropriate
individuals to interview. The right experts are not just those individuals
who have pertinent knowledge. Rather, they are individuals who will be
willing to share that information in the interview. The team must also
prepare for the interview and target subjects of interest. This requires
preparing open-ended questions that allow interviewees to expand on
ideas. If you ask yes or no questions, then you probably will get yes
or no answers.
During the actual interview, when the expert talks, the team must listen
carefully. Active listening is work, indeed hard work, but it is also the
key to a useful interview. Listening closely and responding with
intelligent follow-up questions will yield the very best information. To
obtain the maximum benefit from the process, document what was said
during or immediately after the interview. Otherwise, all the valuable
information garnered during the interview may be lost.
The Delphi technique is a more involved form of the expert interview
technique. It is named for the Greek oracle located at the foot of Mt.
Parnassus whose most famous prediction was that Oedipus would kill his
father and marry his mother. Not knowing that he lived with foster
parents, Oedipus tried to avoid these two awful risks but ironically
precipitated them by fleeing to the city where his real parents lived.
Hopefully, the use of the Delphi technique by project managers will lead
to less dramatic and more successful results!

*Source: PMBOK
Guide, pp. 247248

Risk Identification
Tools and Techniques
Expert Interviews
Delphi Technique

ESI 22
The RAND Corporation developed the Delphi technique in 1948 as a
way of obtaining the input of several experts on specific issues. The
technique proceeds according to the following steps:
Step 1. The coordinator formulates the problem and distributes it
to experts in the field. This is the hardest step. If you phrase the
question improperly, different experts can interpret it differently
and undermine chances for the success of the Delphi technique.
When applying this technique, devote a lot of time to Step 1. In
the risk identification process, the basic problem is to determine
the reasonably significant project risks, how likely each is to
occur, and what kind of effects each will have on the project.
Step 2. The experts review the problem and send their written
position statements to the coordinator.
Step 3. The coordinator then sends out the position papers
without attributing them to their authors. Each expert knows only
his or her position, but this step gives each an opportunity to
compare it to the other experts positions.
Step 4. The experts can then reconsider their positions and submit
changes as appropriate.
The cycle of reviewing and resubmitting positions can be repeated
several times as needed. Sometimes experts are very reluctant to change
their opinions. Ultimately, in a risk identification exercise, the list of risks
is finalized on a Risk Listing form.
The Delphi technique can be advantageous when soliciting input from
individuals who are geographically dispersed. In these circumstances,
travel time and cost make frequent group meetings infeasible, so using a
group information gathering technique with limited personal interaction
works well. Because the parties providing input do not interact directly,
this technique can be useful for addressing issues that are politically
sensitive or seeking input from diverse (or adverse) individuals. The
Delphi technique also works well when the problem being addressed
requires some attention to detail, does not lend itself to precise analytical
techniques, or can take some time to be resolved. Conversely, if you
need quick answers based on interpersonal group input, the Delphi
technique is not for you.
There are numerous situations where the Delphi technique can be too
costly or too time consuming to allow for it to play out properly. This is
where a modification to the approach has become more common than
the original technique itself. The modifications take out the constraints of
anonymity and allow for the reviewers to not necessarily be experts; it
also provides for the coordinator (a central person) to be an equal part of
the proceedings.
Delphi Technique
(continued)
Advantages of the
Delphi Technique
The Modified Delphi
Technique

ESI 23
In short, the modified Delphi approach is a more practical way to get the
needed information without the rigor (or the time) needed for the original
model. This other approach allows companies to do it on their own and
provides for quicker resolution/solution of the multiple cycles. It,
however, will be more biased than the original technique. The central
person needs to be a good facilitator to draw out all of the information in
the meetingsto allow the silent members an opportunity to
contribute.
The steps of the modified technique are very similar to the original.
Step 1: The facilitator prepares materials and coordinates
reviewers. Since all reviewers meet in Step 5, it is less imperative
to get the questions exactly right. Do try to remove ambiguity,
but know that you will get an opportunity again to tell them what
you really want.
Step 2: Reviewers attend kickoff meeting to discuss the objective,
due date, expectations, and so on. Provide common ground; let
the reviewers ask clarifying questions, then let them go.
Step 3: Reviewers review materials and offer modifications or
alternatives to the facilitator and/or bring them to the final
meeting.
Step 4: The facilitator reviews and analyzes all of the submissions
and develops a clean document that contains the consensus of the
reviewers. Any issues that do not have consensus are annotated
and become the focus of the working meeting. NOTE: This step
may not happen if the expectation is to do all work in an
extended working meeting.
Step 5: All reviewers attend the working session to come to
consensus on issues with the new solution. The goal of this
meeting is to answer all questions and resolve all issues.
Step 6: The facilitator takes all data and compiles the information
into the final solution/documentation.
Brainstorming begins with the auction stage. Each member of the
group is asked to provide input in the form of project risks. Members are
encouraged to use each others ideas to generate new ones, and all ideas
are written on a list. Start evaluating the ideas only after the
brainstorming is complete. This is the big challenge for the moderator.
When identifying all the risks in a given project or process, there may be
people who consider some risks as silly. None are to be evaluated as
they are being recorded at this point, and the person leading the session
should ensure that everyone has a chance to identify all the risks they can
think of.
The Modified Delphi
Technique
(continued)
Brainstorming Process

ESI 24
When the group has run out of ideas, they proceed to the evaluation
stage. The group reviews each risk on the list and discusses the merits of
each idea. The results of this evaluation are then summed up as the
groups results and placed on Risk Listing form. Both stages of
brainstorming rely on group dynamics and depend on the group process
for valuing the creative merit of all ideas.
One advantage of brainstorming is that it affords everybody an
opportunity to participate, promoting feelings of belonging and
acceptance among team members. Another is that it allows for feeding
off anothers ideas: One team member offers a good idea; another
catches part of it and thinks of another idea. That is synergy.
Brainstorming can have disadvantages too, though. It can sometimes
lead to groupthink, so the critical issue in brainstorming is to afford
everyone an opportunity to speak to the question of what risks a project
might face. Unfortunately, the process can intimidate less assertive
participants. Many times, one team member may offer seemingly endless
ideas while another is quiet, reluctant to participate, and difficult to draw
into the process. This is a pitfall of brainstorming. Vocal people in the
group tend to win in the sense that they tend to get their opinions
voiced and documented on the flip chart or wherever information is
recorded. It is amazing how a brainstorming session can be dominated
by a few individuals. This is known as false synergy.
The nominal group technique is similar to brainstorming and the Delphi
technique in that it derives extra information by asking others for their
insights. It uses groups that are physically together as in brainstorming,
but much like the Delphi technique, it involves a lot of individual
thought and written input. A relatively small group of five to seven
people is the ideal size, and a group of 12 is considered the maximum
size for a productive exercise.
The technique proceeds according to the following steps:
Step 1. A question or issue is posed by the group facilitator. In a
risk identification exercise, the question might be What risks are
associated with this project?
Step 2. All members of the group consider the question and
silently write all their answers on a sheet of paper. No talking is
allowed.
Step 3. After participants have finished writing all their answers
to the question, the facilitator asks each person in turn to read one
answer from his or her list. The responses are recorded on a flip
chart or other visual aid so that all group members can see them.
This step is repeated until all the responses of each group member
have been posted. As in Step 2, no talking is allowed.
Brainstorming
Process (continued)
Nominal Group
Technique (NGT)

ESI 25

Step 4. The facilitator then leads a discussion of each idea by
asking for any questions, clarifications, or explanations that the
group members may have. Each idea is given equal
consideration. There is no evaluation of the ideas at this time,
just questioning, explanation, and clarification.
Step 5. The facilitator then asks each group member to make a
list of the ideas that he or she thinks is especially important. This
may be limited to a certain number, such as the five most
important ideas, in order to facilitate the process. This is another
silent process.
Step 6. The facilitator tabulates the results for the entire list to
narrow it down to the most important ideas, which may be
limited to a certain number. Differences of opinion can be
clarified and explained at this time, and the previous step and this
one can be repeated if necessary to arrive at a clearer consensus
based on consistent understanding among the group members.
Step 7. The facilitator asks each group member to rate the ideas
in order of priority. This could be done numerically (for example,
ranking a list of five items with scores of one through five from
the least to the most important) or descriptively (for example,
ranking a list of 10 items as having high, medium, or low
importance). Every idea is ranked by each of the team members
in another silent process. The facilitator then develops
cumulative scores for the ideas remaining in order to prioritize
them. This step may involve clarification, explanation, and
repetition like the preceding one. The end result is that the
facilitator finalizes a prioritized list of risks on a Risk Listing form.
The name of the nominal group technique explains its underlying
rationale. The group is a group in name only for the most part because it
requires individual work and prohibits group discussion during most
steps in the process. This is a direct reaction to the problems associated
with brainstorming. Nominal group technique is a good way to elicit
input from people who are shy or unwilling to speak up in those
situations. This is because it treats everybody equally by giving all ideas
equal consideration and because it focuses on the ideas rather than the
people offering them. Nominal group technique also helps eliminate
groupthink and jumping on the bandwagon. Its drawback is that it can
lose opportunities for synergy, because it emphasizes the individual
instead of the group.
Although we would probably use adhesive note pads of any color
nowadays, this method was originally known as the Crawford blue slip,
because the participants actually used blue slips of paper to write down
their own ideas. They used blue paper for two reasons. First, blue
signified blue sky or more creative thinking.
Nominal Group
Technique (NGT)
(continued)
Crawford Slip
Method

ESI 26
Second, blue paper was more expensive and thus showed the importance
of the ideas and the people offering them.
If you have ever read the same book or seen the same movie twice and
experienced new insights the second time around, then you can
understand the premise underlying the Crawford slip method.
The process is very simple and follows these steps:
Step 1. The facilitator establishes a question for the group to
consider, for example, What risks are associated with this
project?
Step 2. Each group member is given several slips of paper and
writes one answer to the question on one piece of paper. The
facilitator gives them a full minute to write their responses.
As soon as the group members have finished Step 2, the facilitator asks
the same question again and has them write new answers, repeating the
same two steps 10 times so that each person provides 10 different
answers.
Crawford was smart. Each time the process is repeated, the question is
more fully investigated and analyzed. By the time the group members
give their tenth set of ideas on any topic, they are dredging the bottom.
They are down to silly ideas and goofy stuff, but they have also provided
the best information they had to offer. The facilitator has everything the
group could offer in a format that is easy to work with.
Affinity diagramming is an excellent tool for organizing and categorizing
large ideas or concepts that use group dynamics to great advantage. It
allows project teams to gather new information and sort it in new ways.
It is a great tool for finding risk symptoms and for finding huge categories
of risk that might not otherwise be discovered. The development of an
affinity diagram proceeds as follows:
Step 1. Write all the ideas to be organized on slips of paper, one
to a slip. In the risk identification process, each slip of paper
would contain a single risk event description. Based on this first
step, it is easy to see that affinity diagramming can be used as a
natural follow-on to brainstorming, the nominal group technique,
or the Crawford slip processes.
Step 2. Spread all the slips randomly (with no organization
whatsoever) on a large table so that they are easily seen and
moved about.

Crawford Slip
Method (continued)
Affinity Diagramming

ESI 27

Step 3. Have each member of the team help group ideas by
placing slips next to other slips with related ideas. All members
must work simultaneously but without communicating. Each
member may move only one piece or a few pieces at a time. At
no time may a single participant completely reorganize all the
information. Encourage the participants to react quickly to what
they see and not to agonize over decisions.
Step 4. Stop the grouping process when no team member wants
to make any more moves or after about 15 to 20 minutes. If there
is an obvious conflict because two members keep moving a
particular slip or group of slips back and forth, duplicate those
slips and put them in both groups.
Step 5. Have the participants discuss and determine appropriate
headings for the groups that have been created, either by using
existing slips that will serve well as headings or by creating new
ones through group discussion.
Step 6. Reduce the results to a formal diagram.
You now have a risk listing that is well organized by categories of risk
that were logically determined by the team based on the individual risk
events they previously identified. It will not only help you to organize
your risk management planning; it may also reveal major categories of
risk that have been overlooked and need further attention. This method
of categorization is preferable to putting up the headings first because that
approach tends to create in the box thinking and stifle creativity.
It also helps ensure team buy-in and understanding because each person
contributes and no single person dominates the outcome.
You now have a risk listing that is well organized by categories of risk
The rationale behind the analogy process is as ancient as Ecclesiastes 1:9:
What has been will be again, what has been done will be done again;
there is nothing new under the sun. Indeed, few processes are totally
unique. Even the Apollo moonwalk project used already existent and
previously implemented technology.
The analogy process is a simple one. You first identify the type of
information you need. In the case of risk identification, this would be
what risks might be encountered on your project. You then look for
similar projects. It is important, however, to realize that although there
will be similar projects, the trick is to recognize which components of
those projects are truly analogous to the project in question. After you
have mastered that, it is easy to identify the risks that carry over from one
project to another and to address them in the current context.
Affinity Diagramming
(continued)
Analogy Process

ESI 28
Checklists, questionnaires, and templates are additional tools that can be
used for risk identification. Like the analogy process, they are based on
the idea that no new project represents a completely new set of risks.
People and companies often compile lists of risks that occurred on
previous projects and then create checklists, questionnaires, and
templates from those lists.
Industry organizations and associations also produce such information.
The Software Engineering Institute (SEI) has produced a checklist called
the SEI Risk Taxonomy and made it available to the general public. The
Software Program Managers Network (SPMN) has done the same with its
list.
Whether they are developed internally by the projects sponsoring
organization or obtained from other sources, these tools are used by
project teams as lists of potential project risks. The project team
examines the risks and decides which, if any, pertain to their project.
These instruments bear an interesting relationship to the concept of
known and unknown risks. To improve project management and risk
management over time, project teams should record unknown risks on a
checklist, questionnaire, or other tool when they occur. In this way, lists
of known risks are generated from previously unknown risks.
Risk Events and Risk Event Lists
There are three problems that often occur in developing a risk event list:
Risk event descriptions are too vague.
The list of risk events is not sufficiently thorough.
The risk events identified lack a consistent level of detail.

Each risk event must be specifically described. The risk event should be
stated as
Something that may or may not happen
Occurring at a particular point in time
Causing a particular impact to the project
For example, If software programmers are not available, the test will not
be able to be conducted, with the result that the schedule will be
delayed. It is extremely important that statements of risk events be
complete and definitive, because how they are understood will affect
everything in the process that follows. Each risk event statement is
analogous to a scope statement.
Checklists,
Questionnaires, and
Templates
Common Problems
with Risk Event Lists
Specificity of Risk
Event Statements

ESI 29
Risk Events and Risk Event Lists
As such, a poor risk event statement will have the same effect on risk
management that a poor scope statement has on project management.
These rules and recommendations apply to both threats and
opportunities.
The risk event list must be as thorough and comprehensive as reasonably
possible. If the team identifying risks becomes too focused on a
particular type of risk, they may fail to include important threats or
opportunities on the risk event list and fail to plan for them. The use of
categories will help ensure thoroughness and the avoidance of critical
omissions. Examples of categories might include such subjects as legal
risks, technical risks, procurement risks, environmental risks, personnel
risks, health risks, and so on.
There are other ways to categorize risks, such as external versus internal.
External risks are those that are beyond any team control; internal risks
are those that are somewhat within team control, such as financial,
schedule, legal, and technical risks. External risks can be further
categorized into unpredictable versus predictable but uncertain.
Unpredictable risks would include such categories as natural disasters,
public opinion, and government regulations. Predictable but uncertain
risks would include threats and opportunities such as changes in inflation
or interest rates.
Many times the risk list will contain a mixture of very small risks and
broad, sweeping risks. For example, a risk list could include either of the
following:
Power test failures during rework of power supply could delay
milestone #2.
Use of new technology could increase cost and affect schedule
throughout the project.
The use of such varying degrees of detail in describing risk events can
distort risk process results. If a person were to analyze and prioritize
these two risk events, the second risk event would always show more
impact probability, because the risk associated with new technology is so
broad. It would likewise be ranked first in any prioritization scheme.
This is because the risk associated with new technology is stated at too
high a level.
The risk associated with new technology should not be totally eliminated
from the risk listing. It needs to be broken down, restated at a more
particular level of detail, and linked to specific work packages that it may
affect. For example, The use of new technology could delay completion
of the design task.

Specificity of Risk
Event Statements
(continued)
Categories Help
Ensure Thorough Risk
Event Lists
Risk List Level of
Detail

ESI 30

Chapter Summary
Risk management is a full project life-cycle activity.
Risk management is composed of eight major processes:
risk management planning, identifying, analyzing,
prioritizing, response planning, executing, evaluating, and
documenting.
Risk identification should involve group techniques.
Group techniques should be used based on their specific
characteristics, advantages, and disadvantages to maximize
the effectiveness of risk identification for the project in
question.
Chapter Summary

ESI 31
organization.
1. What process does your organization use to identify risks?
2. How well have your project teams identified risks (both threats
and opportunities) in the past?
3. Which of the methods in this chapter would work in your
environment? Why?
steps.
you return to work.
Next-Steps Action
Plan

ESI 32
Risk Management Chapter 2: Risk Management Planning and Identifying Risks
Time
1.

2.

3.

ESI 33
Time
4.

5.

6.

ESI 34
Analysis Fundamentals
Chapter 3
This chapter discusses how to place a value on the probability of a risk event
occurring.

Formula

Chapter Overview
Legend
3

ESI 35
Analysis Fundamentals
Establishing Risk Measurement Parameters
Perhaps the most difficult aspect of analyzing and planning for risk is not
risk identification, but determining how to place some value, numerical
or otherwise, on the probability that the risk event will occur. Without a
way to quantify this aspect of risk, it is impossible to analyze the impact
of risks on the project and to prioritize risks for an appropriate degree of
management attention.
Risk analysis is most effective when a numerical probability of risk
occurrence can be determined. Although it is not always possible to do
that, the project manager should understand the fundamental concepts of
probability theory to better estimate the chances of a risk occurring, and
to determine additive and multiplicative risk properties when they are
interrelated. The project manager should also understand the differences
among quantitative, qualitative, and narrative approaches to measuring
risks, and the advantages and disadvantages of each.
Presenting Risk Information
Risk information is typically presented in one of three forms, or a
combination of the three:
Qualitative
Quantitative
Descriptive
Qualitative risk information makes use of terms such as high,
medium, or low to describe the probability or impact of the
occurrence of risk events. Unless the person providing the information is
an exceptional writer, this form of presenting risk information is generally
better than the narrative form for explaining the severity of a risk impact.
But even the qualitative form has its limitations. Describing a risk event
as having a medium probability of occurrence provides a sense of how
likely the risk is to occur, but leaves a wide range of possibilities to
consider. In addition, high, medium, and low are very subjective terms;
a high risk for one person may be a medium risk for another. Even with
the qualitative form of presentation, it is more helpful if the qualitative
scale can be defined more quantitatively. For example, defining low
risks as those falling between zero and 20 percent probability of
occurrence clarifies what is meant by low risk. However, it still is
better to use a specifically quantified number than a range whenever
possible.
Quantification
How Risk Information
is Presented
Qualitative
4 3

ESI 36
Presenting Risk Information (continued)
In a quantitative analysis, numbers are used to assess probabilities and
impact. This is useful for two important reasons. First, assigning a
number to the risks probability affords the opportunity to use more tools
to assess the risk. Second, quantifying the risks probability provides
some objectivity to the assessment of risk. Like it or not, we have to
realize that there will always be a certain amount of subjectivity in
assigning risk probabilities to a risk event, but there are powerful tools
that can help us mitigate risk if we can first quantify them.
Descriptive risk information, in some respects, is very useful because it
offers an easy way to provide a lot of information about a risk event. For
example, a person can provide a complete description of the potential
risk event, the source of the risk, and what might be done about
precluding it or controlling it if it occurs. The major disadvantage of this
form of presenting risk information is that it provides no way to measure
the risks probability or its impact to the project or organization.
Risks can be presented using various formats. One of the most
commonly used formats is the following grid. This grid is particularly
useful when only qualitative data using high, medium, and low rankings
are available.
Looking at the grid, it is easy to see that risks falling in the low probability
and low impact (L/L) quadrant may be ignored or assigned a lower
priority, while those falling in the high probability and high impact (H/H)
quadrant must be dealt with proactively. The two quadrants high
probability and low impact (H/L) and low probability and high impact
(L/H), depending on where they fall within the grid, likewise may be
ignored or assigned a lower priority. If a risk has a high probability of
occurring but minimal impact, then we are likely to accept the risk and
deal with it when and if it happens. Likewise, if there is a low probability
of a risk event occurring, we are likely to accept the risk even if there is a
very high impact.
An example of an L/H risk event is flying. If a commercial airliner
crashes, the impact is catastrophic, but the probability of such an
occurrence is so low that most of us never even consider the risks of
flying. An example of a common H/H risk arises when a company has
one or more projects requiring expertise not available within its
personnel ranks. This H/H risk becomes a low risk or no risk at all when
the company outsources one of the projects, hires additional personnel,
or teams with another company to perform the work in question.
Quantitative
Descriptive
Handling Probability
and Impact

ESI 37

P
r
o
b
a
b
i
l
i
t
y
Impact
H
L H
H/L H/H
L/L L/H
M/L M/H M/M

Whenever risks are rated, the level of risk acceptance has to be
considered. Organizational culture will have developed a level of risk
tolerance that will cause each person to see a particular risk in a very
different light. A low risk for one person may be a high risk for another,
so delineating between levels of risk becomes very difficult, particularly
when a qualitative analysis is done.
The following graphic can be used to define the high, medium, and low
categories of risk event probability and impact for most organizations in
most instances.

Handling Probability
and Impact
(continued)
Examples of
Qualitative and
Quantitative Risks
Rank Probability Impact
High Risk event is very likely to occur
Risk event has high probability of
occurrence
If risk event occurs, a significant
impact to cost, schedule, quality,
or customer satisfaction will occur
Medium Risk event is likely to occur
Risk event has medium probability
of occurrence
If risk event occurs, a moderate
impact to cost, schedule, quality,
or customer satisfaction will occur
Low Risk event is unlikely to occur
Risk event has low probability of
occurrence
If risk event occurs, a small impact
to cost, schedule, quality, or
customer satisfaction will occur

ESI 38
A quantitative risk presentation is one that has numbers associated with
it. For example, if we can say that an event has a 15 percent probability
of occurring and that its impact would be a cost to the project of
$10,000, then we have quantitatively defined the risk. As with the
qualitative analysis, it is difficult to assign accurately a probability to a
risk event; it is a matter of experience, expert opinion, lessons learned,
and so on. The better the historical data, the more accurate the
probability and impact assessments.
Given the particularly difficult task of assigning accurate qualitative risk
ratings, can these presentation models be combined in a way that
mitigates the subjective nature of the rating? The answer is, Yes, they
can. Qualitative ratings can be broken down so that within one level
there are two or more levels. For example, high might have additional
levels of very high, medium high, and low high. Then numerical
probability ranges can be assigned to aid in determining a reasonable
probability number for each risk event. The graphic below demonstrates
how this is done.
85%
65%
35%
15%
0%
50%
0%
High Very high
Probable probability High
Medium Medium
probability
Improbable Low Low
probability Very low
100% 100%

Each of the three risk presentation formats has its own advantages and
disadvantages, but when they are used together, a description of the risk
event, its likelihood of occurrence, and its impact can be clearly
documented and communicated. The table below summarizes the
characteristics of the approaches:
Examples of
Qualitative and
Quantitative Risks
(continued)
Comparing Risk
Presentation
Approaches

ESI 39
Comparison of Risk Presentation Approaches
Qualitative Quantitative Descriptive
Fast and easy to
administer and
understand
Difficult to enforce
uniformly across
organization and
projects
Requires definitions,
rules, standards, and
processes
Preferred
methodology, often
mandated by
management
More time consuming;
requires estimation
Misleading in that
numbers may give
appearance of
precision and
specificity, unless the
precision of the
estimate is given
Difficult if team resists
deriving the numbers
Easier to forecast
Able to use trends
Substantially more
valuable in developing
risk response strategies
and reserves
Difficult to quantify
Usually based on
experience

Probability Analysis and Rules of Probability
Probability analysis determines how likely a risk event is to occur.
Although the sources of probability assessment data were briefly
mentioned previously in this chapter, they are worth reviewing.
Generally speaking, a large portion of the data used for risk analysis
comes from experience. This does not necessarily mean the data are
bad, but care when using the data is crucial. The project manager should
always evaluate the source of the data and how biased the data source
is. Bias in this case is a function of whether the source or person
providing the data is open to accepting some risk or is adverse to any
risk.
Comparing Risk
Presentation Approaches
(continued)
Probability Analysis

ESI 40
Probability Analysis and Rules of Probability (continued)
His or her assessment may be colored by how tolerant he or she is to the
risk. Once again, knowing what the organizational culture can tolerate
relative to risk and especially to risk impact is extremely important.
When the experience is based upon historical data (that is, lessons
learned), and especially when lessons learned are documented, the data
source tends to be less biased because there are actual examples of risk
events and how they were handled. Historical data also can take some of
the subjectivity out of probability and impact assessments.
Theoretical distributions are another source of probability data that can
be used to good advantage. Many standards are developed from surveys
or other data taken over the years about processes, methods, and actual
project or manufacturing events. The resulting probability formulas are
more accurate than just basing the risk estimate on an educated guess.
One of the most accurate methods for determining probabilities can be a
simulation. For example, Monte Carlo analysis is a well-known
simulation that examines many data points or what if scenarios to
determine the most likely outcome. Whatever the method used, an
understanding of basic probability principles is necessary for
understanding risk analysis.
The probability that a particular event will occur can be predicted by
using one of three methods: classical probability, relative frequency, and
subjective probability.
Classical probability is a form of deductive logic that states that the
likelihood of an event occurring (P) equals the ratio of the number of
possible outcomes yielding that event divided by the number of all
possible outcomes. Logically, the number of all possible outcomes
equals the number of outcomes where the event in question (A) occurs
plus the number of outcomes where it does not occur (B). A classic
example is the probability of getting heads when flipping a coin.
Mathematically, this concept can be expressed as follows:
P(A) = A/(A + B)
P(heads) = (1 head)/(1 head + 1 tail)
P(heads) = 1/2 = 50%

Probability Analysis
(continued)
Approaches to
Predicting Probability

ESI 41
This approach works well with simple situations where each outcome
can be identified and is equally likely to occur. But what if the coin is
known or even suspected to be biased? Or what if the question is
something complex such as how likely a finely calibrated engine part is
to fail within one year? In these cases, relative frequency offers a
better approach.

Relative frequency uses inductive logic to draw conclusions about
probability based on empirical results of samplings of actual events. For
example, if 1,000 engine parts were sampled and 100 failed, the relative
frequency of failure for that sample would be 100/1,000. Applying
inductive logic, the probability of failure for all engine parts would be
predicted to equal the relative frequency and be deemed 10%.

In the case of a biased coin, the results might be that heads occurred 6
times in a sample of 10 coin flips. This would be evidence of a bias
toward heads, but sample size is important, because the larger the
sample, the more reliable the use of relative frequency. A relative
frequency of 60 out of 100 coin flips would be stronger evidence of a
60% probability of heads, and 600 out of 1,000 would be stronger still.
Conversely, when different outcomes really are equally likely (that is, the
coin is unbiased), the larger the sample, the closer the relative frequency
will come to the classical probability prediction. In that case, one might
see 6 heads out of the first 10 flips, then 56 out of the first 100, then 520
out of the first 1,000, and so on until the relative frequency closely
approaches 50%.

What can be done to predict probability when the situation is too
complex for application of the classical approach and not susceptible to
sampling? This is when subjective probability must be used. Subjective
probability is not based on deductive logic, inductive logic, or empirical
observation of test samples. It is purely an application of individual
intuition. For example, suppose the probability of prime interest rates
rising above 6% must be predicted because of the effects such an
increase would have on a project. This event is far too complex for use
of the classical approach, and there is no way to conduct valid test
sampling. The only way to assign probability is based on conclusions
reached intuitively by individuals, and that is the subjective approach.

Approaches to
Predicting Probability
(continued)

ESI 42
There are some basic rules or principles for dealing with probabilities,
including these key concepts:
Mutually exclusive events
Nonexclusive events
Independent events
Dependent events
Probability representation
These concepts are most easily explained by examples. Suppose you
have a stack of index cards numbered 1 through 10 and a coin with the
usual sides of heads and tails. Then consider the following cases.
Mutually exclusive events are those that can never happen at the same
time. If one occurs, the other cannot. If you draw one card from the 10
cards, you may draw an odd or even number, but if you draw odd, you
cannot draw even, and vice versa. Drawing an odd card and drawing an
even card are therefore mutually exclusive events. So are getting heads
and getting tails when you flip the coin.
Nonexclusive events may or may not happen at the same time, such as
drawing an even card and a card less than five. Drawing a two or a four
would mean doing both. Drawing a 7 or 9 would mean doing neither.
Any other draw would mean doing one or the other.
Independent events are nonexclusive events where the outcome of one
event cannot be affected by the outcome of another event. If you draw a
card, you may get any number from 1 through 10; and if you flip the
coin, you may get heads or tails. These are independent events.
Suppose you are trying to both draw the number 5 from the cards and get
heads from the coin flip. The probability of both occurring is calculated
as follows:
P(A and B) = P(A) x P(B), or
P(5 and heads) = 1/10 x = 5%
The probability of either drawing the number 5 or getting heads from the
coin flip is calculated as follows:
P(A or B) = P(A) + P(B), or
P(5 or heads) = 1/10 + = 60%

Rules for Dealing with
Probability
Mutually Exclusive
Nonexclusive Events
Independent Events

ESI 43
This formula is slightly more complex for nonexclusive events, which
may happen at the same time. An example would be determining the
probability of drawing, on a single draw, either an even-numbered card
or a card less than five. The additional complexity in the formula is
necessary to avoid double-counting the two numbers (two and four) that
satisfy both conditions. The probability is calculated as follows:
P(A or B) = P(A) + P(B) P(A and B)
P(even or <5) = P(even) + P(<5) P(even and <5)
P(even or <5) = 5/10 + 4/10 2/10 = 7/10 = 70%
Dependent events are events where the outcome of one event is affected
by the outcome of another event. If you are trying to draw even cards,
and draw one card from the set of 10 and keep it separate from the rest,
then draw another card, the odds of drawing an even card the second
time will be affected by which card you drew the first time. These are
therefore dependent events. The probability (P) of picking two even
cards, where event A occurs first and both events stand for drawing an
even card, is calculated as follows:
P(A and B) = P(A) x P(B, after A occurs), or
P(even and even) = 5/10 x 4/9 = 22%
Ratios have been used to represent event probabilities for ease of
understanding in the examples above. However, normal practice in risk
analysis is to express probabilities as decimals between 0 and 1 or as
percentages from 0 to 100%.
Risk analysis often involves mutually exclusive events because the
question being evaluated is the probability of a risk event happening or
not happening. Two particularly important rules to keep in mind for
mutually exclusive and independent risk events are the addition rule and
the summation rule. These formulas are set forth below. On the surface,
these rules look the same, but they are slightly different concepts.
The addition rule says that the probability of either one outcome or
another outcome occurring is equal to the sum of the probabilities of the
outcomes occurring individually, which can be written as:
P(A or B) = P(A) + P(B)

Independent Events
(continued)
Dependent Events
Addition, Summation,
and Multiplication
Rules

ESI 44
The summation rule states that the sum of the probabilities of occurrence
for all possible outcomes from a single event must be equal to 1.0 (that
is, 100%). Stated mathematically,
(P1 + P2 + P3 Pn) = 1.0
For events that are not mutually exclusive, one very important rule is the
multiplication rule. It states that the probability of both one outcome and
another outcome occurring is equal to the product of the probabilities of
the outcomes occurring individually.
P(A and B) = P(A) x P(B)
Addition, Summation,
and Multiplication
Rules (continued)

ESI 45
Chapter Summary

Three formats are commonly used for presenting risk
information. They are narrative, qualitative, and
quantitative.
Because each of these formats has certain advantages and
disadvantages, neither by itself is usually sufficient. The
best approach is to use some combination of the three.
In the case of mutually exclusive events or independent
events, the probability of either one event or the other
happening is the sum of their probabilities of occurring
individually.
In the case of events that are not mutually exclusive, the
probability of both one event and the other event
happening is the product of their probabilities of occurring
individually.
The sum of the probabilities for every possible outcome for
a given event must equal 1.0 (that is, 100%).

Chapter Summary

ESI 46
organization.
1. Which form of presenting risk does your organization typically
usequalitative, quantitative, descriptive, or a combination?
Is it the best one for your organization?
How will you apply probability analysis on your next project?
steps.
you return to work.
Next-Steps Action
Plan

ESI 47
Risk Management Chapter 3: Analysis Fundamentals
Time
1.

2.

3.

ESI 48
Time
4.

5.

6.

ESI 49

Analyzing and Prioritizing Risk
Chapter 4
This chapter discusses the next steps in the risk management process,
analyzing and prioritizing risks.

Formula

Chapter Overview
Legend
4

ESI 50
Analyzing and Prioritizing Risk
Next Steps in Risk Management
After leading the project team through the identification of risks, the
project manager must lead them in analyzing and prioritizing the
identified risks using a variety of techniques. Examples of these
techniques include decision trees, which can be used to evaluate relative
levels of probability and risk, and financial measures, which can be used
to quantify risk. By performing risk analysis, the project team
accomplishes several risk management objectives. These include
determining the values of the variables involved, identifying various
consequences of the occurrence of risk events, estimating the magnitude
of the risks identified, and reducing the possibility of surprise, which can
never be eliminated altogether. Taken together, these efforts are aimed at
the overall objective of preparing a thorough value analysis of the risks
entailed by a project.
Step 3: Analyzing Risks
Risk analysis is the third step in the risk management process and follows
risk identification. It involves systematically estimating the probability of
occurrence and magnitude of impact for each risk event that was
identified in Step 2 (risk identification). The objective of this step is to
reduce the uncertainty that always accompanies risks.
Risk analysis is a process itself within the larger risk management process.
Its primary input is the risk event listing generated by the risk
identification process. Using a qualitative or quantitative approach or a
combination of both, various tools are used to assess both the probability
of the occurrence and the likely impact of each risk event. The end
product is a fully analyzed risk event listing.
Certain guidelines should be kept in mind while performing risk analysis.
It is important to cover all the risk events listed at the end of risk
identification. This effort can be extensive, but distributing risk analysis
tasks among team members will break down the workload into
manageable pieces and speed up the process. Assignments should be
made based on the technical skills involved to ensure that the most
knowledgeable people are analyzing each risk. Wherever possible, each
risk should be evaluated both quantitatively and qualitatively. In doing
so, it is wise to assess the best-case, worst-case, and most likely scenarios
to understand the whole range of possibilities. This is especially true for
risk events with high uncertainty.
Analyzing and
Prioritizing Risk
Introduction
Overview
Risk Analysis
Guidelines
4

ESI 51
Step 3: Analyzing Risks (continued)
The primary thing to avoid during risk analysis is trying to prioritize the
risks at the same time. People have a natural tendency to want to
prioritize risks as they analyze them. This is a bad practice because if
project team members prioritize as they analyze, they may lose focus and
never perform the sort of rigorous analysis that is necessary to validate the
prioritization of risks.
Impact Analysis
There are two basic impact categories for any risk, because a risk may
affect either the project cost or the project schedule. Schedule impacts
can often have cost impacts, especially when a project incurs additional
costs as a corrective action to keep the project on schedule. Cost impacts
may affect scheduling in cases where work must be delayed to address
cost issues.
There are several sources of data for impact analysis. Historical data
based on similar situations that actually occurred on previous projects
can be considered. Estimates and subjective judgments are common data
sources that should not be confused. They differ in that subjective
judgments are opinions based on intuition without the substantiation of
an analytical process such as estimating. Finally, simulations can be used
in more complex scenarios. Regardless of what approach is used, those
performing the analysis are basically undertaking an estimating process.
The project team must analyze all identified risks to determine the impact
of each on project cost. In doing so, they must consider the effects of the
risk on cost factors such as level of effort, labor rates, labor hours
required, materials required, and tools and equipment. Cost impact
assessment must be done for both opportunities and threats.
Similarly, all listed risks need to be analyzed to determine their impact on
the project schedule. Factors such as resource shortages, extended task
durations, and the effects of the risk on parallel and dependent activities
must all be evaluated. Any impact on the schedule needs to be checked
against the network diagram to assess the impact on other activities.

Risk Analysis
Guidelines
(continued)
Impact Analysis
Overview
Project Cost
Impacts
Project Schedule
Impacts

ESI 52
Impact Analysis (continued)
To be meaningful, all these effects should be considered against the
project schedule. Although an impact assessment may determine that the
outcome may be a 5-week delay to a procurement task, the only way to
understand the effect on the project end date is to examine the network
diagram and critical path. The delay may be on a chain of activities with
10 weeks of float, which means that the impact on the overall schedule is
nil. As with cost impact analysis, it is important to analyze the effect of
both opportunities and threats on the project schedule.
Tools and Techniques for Risk Analysis
Fortunately, certain proven tools and techniques are available to help in
risk analysis. They include the following:
Expert judgment
Financial measurements
Expected value
Decision trees
Statistical sums
Computer simulation
Each of these tools will be discussed more fully in this chapter, but two
require some immediate clarification. The term statistical sum refers to a
process that combines statistical distributions into a single overall
distribution, the most notable example being Program Evaluation and
Review Technique (PERT). The term computer simulation refers to the
process of constructing a computer model of the project to simulate
execution and analyze possible outcomes, the most notable example
being the Monte Carlo simulation.
An experts judgment can be used to help analyze risks much like an
expert interview can be used to help identify them. The source of
expertise may be outside consultants or team members assigned to the
project. Because they are performing the work, team members often will
have a better understanding of the impact the risk will have on the
project.
Expert judgment is most often used when no precise analytical
techniques are available. Although expert judgment is subjective, it can
be helpful in cases when objective information is not available. The
Delphi technique also can be used as a tool for gathering expert opinions
about risk impacts. The process would be the same as the one used in
risk identification, except that the experts would provide estimates of
probability or impacts.
Project Schedule
Impacts
(continued)
Proven Tools and
Techniques
Expert Judgment
in Risk Analysis

ESI 53
Tools and Techniques for Risk Analysis (continued)
Many financial measurements or techniques are available to help analyze
risks, particularly business risks. The importance of financial
considerations when determining risk impact and probability is difficult
to overstate. If the financial risk is too high, the project may not even get
off the ground. An organization normally decides to undertake a
particular project based on certain expected business results as
determined by a general business financial measurement, for example, a
certain level of return on investment (ROI). Life-cycle costing (LCC) is
another financial measurement tool that is more focused on project
management. The project manager should be able to use such measures
in quantifying the financial impact that risks may have on the project.
Where project risks have a lasting effect, the project manager should
examine them in relation to the entire life cycle of the project
deliverables, not just the duration of the project. The project life cycle
will go through closeout, but the project deliverables may be
implemented, operated, maintained, and enhanced for a much longer
period of time.
For example, assume a project manager is thinking about reducing the
amount of testing for a new software program to reduce a projects cost
and scheduled duration. This may look like a good way to meet original
cost and schedule targets if project managers limit their perspective to the
project only. However, there may be significant savings or benefits later,
such as reduced repair and maintenance costs, if the testing is performed
during the project life cycle. Immediate cost savings should be examined
against later benefits or cost savings by using the life-cycle concept.
Expected value is a means of mathematically combining assessments of
risk event probability and impact. The expected value (EVnot to be
confused with earned value, which uses the same abbreviation in other
contexts) can be defined by the following formula:
EV = (probability of occurrence) x (amount at stake)
An example of the formula applied would be the case of a risk event that
has a 20 percent likelihood of occurring and would cost $100,000 if it
did
EV = 20% x $100,000 = $20,000
Expected value is also referred to as exposure in the case of threats and as
leverage in the case of opportunities.
Financial
Measurements in
Risk Analysis
Impact Analysis
Life-Cycle Costing
(LCC)
Expected Value

ESI 54
At the project level, overall expected value (that is, cost) can be assessed
in several ways:
Baseline (the estimated cost of the project with no risks accounted
for)
Best case (the estimated cost of the project if all risk opportunities
occur and no risk threats occur, that is, all good things happen
and no bad things happen)
Worst case (the estimated cost of the project if all risk threats
occur and no risk opportunities occur, that is, all bad things
happen and no good things happen)
Expected value (the sum of the baseline and all risk events
expected values, both threats and opportunities)
Contrary to Murphys Law, the final actual cost of the project will
probably fall between best case and worst case. Expanding on the
preceding example, suppose the following:
A project with a $1 million baseline estimate
A threat Risk A worth $200,000 and having a 10 percent
probability
A threat Risk B worth $50,000 and having a 20 percent
probability
An opportunity Risk C worth $100,000 and having a 5 percent
probability
An opportunity Risk D worth $200,000 and having a 50 percent
probability
Because we are addressing project cost, the expected values for the threat
risks will be positive values, and the expected values for the opportunity
risks will be negative values. The expected values for the four risks
would be as follows:
A = 10% x $200,000 = $20,000 EV
B = 20% x $50,000 = $10,000 EV
C = 5% x $100,000 = ($5,000 EV)
D = 50% x $200,000 = ($100,000 EV)
At the project level, overall expected cost can be assessed as follows:
Baseline = $1,000,000
Best case = $1,000,000 $100,000 $200, 000 = $700,000
Worst case = $1,000,000 + $200,000 + $50,000 = $1,250,000
Expected value = $1,000,000 + $20,000 + $10,000 $5,000
$100,000 = $925,000

Assessing EV

ESI 55
A decision tree is a diagram that can be used to depict a series of
alternative decisions, events, or outcomes. It is most useful where
numerous possible alternatives can occur. It is referred to as a decision
tree because it is a convenient way of depicting the consequences of
different choices that must be made at different points over a period of
time. The diagram therefore often begins with a decision to be made.
However, in performing risk analysis, project managers often use
decision trees to understand possible outcomes and not to make
decisions. Therefore, the decision tree actually may begin with a risk
event and depict the consequences that flow from it.
Consider the following example of a make or buy decision regarding a
particular project component:

Decision Tree
Make or buy?
Rework or no
rework
Rework or no
rework
Make
$80,000
Buy
$100,000
No rework
Rework
No rework
Rework
30% x $40,000 = $12,000
70% x $0 = $0
30% x $0 = $0
70% x $0 = $0

ESI 56
For this particular component, there is a 30 percent risk that the customer
will require some rework that will not justify an increase in contract
price. The component can be fabricated in-house for an estimated
baseline cost of $80,000, but rework would have a cost impact of
$40,000. In the alternative, the work can be fabricated by a
subcontractor who would contractually assume the responsibility for the
performing any necessary rework for a contract price of $100,000.
As the example illustrates, decision trees are normally constructed
according to the following conventions:
Represent decisions by boxes (decision nodes).
Represent outcomes or events by circles.
Enter the primary decision on the left side of the tree and work
through the possibilities from left to right.
Represent all possible scenarios by paths.
Assign probabilities to all path segments leading from events.
Determine the expected value for each segment (the sum of the
probabilities from each node must equal 100 percent).
Add expected values from right to left along all path segments
leading to a decision node to determine the most advantageous
path.

As you can see from the example, decision trees are most powerful when
used in conjunction with expected values. Depending on ones risk
tolerance, the information provided by a decision tree can be seen from
multiple perspectives. For example, the total expected values for each of
the four outcomes in the example are as follows:
Make and rework = $12,000 + $80,000 = $92,000
Make and no rework = $0 + $80,000 = $80,000
Buy and rework = $0 + $100,000 = $100,000
Buy and no rework = $0 + $100,000 = $100,000
However, the best and worst case scenarios are quite different:
Best case for making = $0 + $80,000 = $80,000
Worst case for making = $40,000 + $80,000 = $120,000
Best case for buying = $0 + $100,000 = $100,000
Worst case for buying = $0 + $100,000 = $100,000
An organization that bases all its project risk management decisions on
thorough risk analysis and expected values would decide to make the
component despite the $40,000 risk of rework, because expected risk
impacts of rework would be much lower on average than the cost of
Decision Tree
(continued)
Decision Tree
Diagramming
Conventions

ESI 57
hiring subcontractors. An organization that is extremely risk intolerant
and places a high value on certainty of results would probably decide to
buy for $100,000 and forego the likely savings of $20,000 that might
come with a decision to make the component.
Statistical sums can be used to calculate a range of total project durations
and costs from estimated ranges for individual work items. This makes
them powerful tools for understanding the likelihood of completing the
entire project for a certain cost and within a certain amount of time.
For example, if all the estimated ranges of work durations of all the
project activities are statistically summed, they can be used to generate a
normal distribution curve of possible overall project durations. You may
then calculate that curves standard deviation. A normal distribution has
half of its values above its mean and half below. It also has 68 percent of
its values within one standard deviation of the mean, 34 percent above
and 34 percent below. This means that the project manager can predict
that there is an 84 percent probability that the project will finish on or
before the duration that is one standard deviation greater than the mean.
This is because 50 percent of all outcomes are below the mean and half
of the 68 percent of outcomes within one standard deviation of the mean
(that is, 34 percent of the total outcomes) are above the mean.
Statistical sums can be used for both project costs and project durations.
One of the best-known and most significant statistical sums that can be
used in risk analysis is the beta distribution using the Program Evaluation
and Review Technique (PERT).
PERT is a network scheduling technique that is similar to critical path
method (CPM) scheduling. However, CPM is based on activities with
fixed durations, whereas PERT is based on variable activity durations. In
PERT, each activity is assigned three durations:
O = optimistic time
ML = most likely time
P = pessimistic time
From these, a fourth duration called the expected time is calculated using
the following formula:
O + 4ML + P
6
Decision Tree
Diagramming
Conventions
(continued)
Statistical Sums in
Risk Analysis
PERT

ESI 58
The statistical model upon which PERT is based is known as the beta
distribution. The beta distribution looks and behaves like the normal
distribution when ML is exactly centered between O and P. When ML is
closer to either O or P, the beta distribution for the specific activity
becomes skewed, and this is the usual situation. Nevertheless, when all
activities for a project are beta distributed and statistically summed, the
result approaches the normal distribution and can be used to estimate
probabilities for overall project completion times.
Monte Carlo simulation is a computer analysis of the project using the
network schedule diagram and probability distributions for activities to
determine all possible project outcomes and their probabilities. It
requires the use of special software but has some significant advantages
over summation techniques, such as PERT. First, it can be used to
evaluate possible project outcomes for both costs as well as durations.
Second, in evaluating durations, it accounts for path convergence and
is the only tool available that does so. Path convergence is a scheduling
phenomenon that increases the probability of delaying the start of an
activity as the number of parallel predecessor activity paths increases.
Finally, unlike PERT, Monte Carlo does not require the assumption that
all task distributions be beta distributions.
To run a Monte Carlo simulation, the project manager must begin by
establishing probability distributions for the duration and cost for each
project activity, using whatever assistance is necessary. The project
manager may specify any type of probability distribution desired for an
activitys duration or cost. All the information that has been gathered is
loaded into the software. The software then runs multiple, randomly
chosen simulations based on the activities and their probability
distributions and plots the outcomes as a range of potential overall
project results.
Standard estimating techniques and some of the methods used for risk
identification can be used as potential sources of information for input
into the simulation. These, of course, include the project managers and
project teams previous experiences. The Delphi method, expert
judgments, and actual data on previous projects can also be useful.

PERT
(continued)
Monte Carlo
Simulation in Risk
Analysis
The Monte Carlo
Process

ESI 59
Overall Risk Rankings
After the probabilities and impacts of each risk event have been
evaluated, the project manager may find that not all risk events can be
evaluated in the same way. Some may have been evaluated
quantitatively, some qualitatively, and some only in narrative format.
Before the risk events can be prioritized, an overall risk rating that
accounts for both risk probability and risk impact and allows comparison
of all risk events must be determined and applied to each one.
The project manager must decide what this risk rating system will look
like and how it will work. One simple two-step approach would be:
(1) to equate certain probability percentages and cost impacts with
corresponding categories of high, medium, and low, and (2) to further
simplify the risk ratings by combining the two components of risk into
unified numerical ratings.
Because there would be three rating levels for both probability and
impact, there could be as many as nine numerical ratings using this
approach, depending on the relative value assigned to the different
combinations of probability and impact to the organization.
For example, would a high-impact/moderate-probability risk or a high-
probability/moderate-impact risk be of greater concern? The answer
depends on the individual and the organization. Organizations that can
withstand a high-impact risk may readily accept the first scenario but be
cautious about high-probability events. Organizations that cannot handle
a high-impact risk may be more concerned about the first scenario.
Regardless of the organizations values and how they influence the scale
of overall risk ratings, the project manager should be able to generate a
risk listing that is suitable for the project team to use in the risk
prioritization process.
Step 4: Prioritizing Risks
The risk prioritization process is an effort to rank risks that have been
identified and analyzed in order of importance. It is a way of narrowing
the focus of risk management and managing by exception. In the overall
risk management process, it is the step that occurs after risk analysis has
been completed. The risk response plan should not be developed at this
time. After the risks are ranked and prioritized, a response plan can be
developed.

Overview
Two-Step Approach
Overview

ESI 60
Step 4: Prioritizing Risks (continued)
The objective of risk prioritization is to let the project team determine
which risks will be planned for in advance and which will not, based on
the fact that there never will be enough time and resources to respond to
all the risks associated with the project. When a prioritized list is created,
there is a point when the team can see that the risks are better handled
through workarounds than through strategies that have been carefully
planned up front. At the same time, prioritizing risks gives you a sense of
the level of risk tolerance in the project team and in the organization.
The project manager must not forget that ranking and prioritizing must be
done with both opportunities and threats. This point highlights another
way to characterize the main objective of prioritization. It is done to
decide which threats to avoid or mitigate and which opportunities to
pursue or enhance.
Risk Prioritization Process and Tools
The risk prioritization process is based on input that comes from the risk
analysis process in the form of a list of analyzed risks and a prioritization
structure. Proven tools and techniques to help prioritize risks include
quantitative and qualitative assessments, expected value analysis,
filtering, and comparative risk ranking. The final output should be two
lists of prioritized risk events, one for threats and one for opportunities.
Each risk should be ranked quantitatively (that is, 1 through n), if
possible, because quantitatively ranking provides more tangible
information. Otherwise, a qualitative ranking system may be used (first
all high risks, second all medium risks, and so on). These two
approaches were discussed previously in Chapter 3. Risks should be
prioritized by the whole team to consider all useful input and try to reach
consensus.
Expected Value (abbreviated as EV and also known as exposure for
threats and leverage for opportunities) was addressed in detail
previously in this chapter. It is a technique that naturally lends itself to
relative risk ranking and prioritization. For example, a $50,000 risk
impact with a 50 percent probability might be given higher priority than a
$100,000 risk impact with a 10 percent probability, because the
respective EVs are $25,000 and $10,000.
Filtering and comparative risk ranking (CRR) are two more approaches to
prioritization. Although they are two separate techniques, ESI
recommends using them together. The filtering process does not really
prioritize. It is a question and answer technique that removes risk events
Objective of
Prioritizing Risks
Overview

ESI 61
Risk Prioritization Process and Tools (continued)
that are currently less important from immediate consideration. CRR
actually ranks or prioritizes risk events. Naturally, the information
developed is only as good as the people involved, so people who
understand the risks being analyzed and the organizations risk tolerance
characteristics must participate.
Filtering is using a series of questions to set aside risks that will not be
immediate priorities. This is an example of a very simple three-question
filtering process:
For each risk, ask whether the probability of the risk exceeds 25
percent. If it does not, remove it from the priority listing.
For each remaining risk, ask whether the cost impact of the risk
exceeds $10,000. If it does not, remove it from the priority
listing.
For each remaining risk, ask whether the risk is expected to occur
within the next three months. If it is not, remove it from the
priority listing.

The remaining risks make up your active priority risk listing. To use
filtering effectively, you must know your or your organizations priorities.
That allows you to establish the filters that will focus risk management on
the right risks. Some organizations put higher priorities on other issues
than the sequence presented here. It is perfectly reasonable to use
different questions and use them in whatever order best reflects project
and organizational priorities.
Note that you never discard a risk event just because it does not satisfy
one of the filtering questions. The answer to the question for a filtered
risk event could change at a later date, so instead of removing such risk
events from your risk listing, you temporarily exclude them from further
consideration in the risk management process at the step of risk
prioritization. You can only safely discard a risk event from your listing
when you are absolutely sure that the risk event can no longer be an
issue. You must therefore revisit the filtering process on a regular basis
during the course of the project.
Comparative risk ranking is a technique that asks a group of people one
comparative question about each risk event on a risk event listing
compared to each other risk event. It is based on the fact that any priority
listing assumes that the items being listed have more or less importance
relative to each other.
Overview (continued)
Filtering
Comparative Risk
Ranking

ESI 62
Risk Prioritization Process and Tools (continued)
Using a very simple example, this technique works as follows:
Assume you have five risk events to prioritize.
Assume you have three people ranking the risk events.
The comparative question for each possible pair of risk events is:
Which risk deserves higher priority?
For each pair, each person must answer the question by choosing
one risk event or the other. The possible breakdowns of answers
for any pair of risk events include 30, 21, 12, and 03. For
any given pair, each risk event may be chosen one, two, or three
times; these choices are assigned as points to each risk event
whenever it is chosen over another.
After all pairs are evaluated this way, the points for each risk event from
all its pairings are summed. The higher the number of points a risk event
has, then the higher its priority is deemed to be.
CRR is best used for ranking risks that have similar levels of impact.
When it is difficult to decide which high-probability, high-impact risk is
worse among a grouping, CRR can help find an answer. Because it is the
only tool that compares each risk event to every other risk event, it is an
unusually powerful tool, and the results of which deserve great credence.
Prioritized Risk Listing
The final output of risk prioritization should be two ranked and fully
analyzed lists of risk events, one for threats and one for opportunities.
Ideally, all risk events would be presented using uniform quantitative
formats for probability, impact, overall rating, and priority. That is often
impossible in the real world. Some risk events may be expressed
quantitatively, some qualitatively, and some even in narrative format. It
is rare that all project risk events will be completely quantifiable or that
none will be quantifiable.
Comparative Risk
Ranking
(continued)
Final Output

ESI 63
Chapter Summary

The product of the probability and impact of a risk event
determine its expected value.
Risks may be analyzed using narrative, qualitative, or
quantitative approaches.
You must prioritize risks because there is never enough
time or money to respond to all risks.
Financial measurements can be used to assess business
risks.
PERT analysis can be used to assess schedule and cost risk.
Monte Carlo simulations can be used to assess risk for
large, complex projects.

Chapter Summary

ESI 64
organization.
1. How will you prioritize risk?
What steps will you take to ensure that you prioritize both
threats and opportunities on your next project?
What new tools will you use in prioritizing risk? When?
steps.
you return to work.
Next-Steps Action
Plan

ESI 65
Risk Management Chapter 4: Analyzing and Prioritizing Risk
Time
1.

2.

3.

ESI 66
Time
4.

5.

6.

ESI 67

Risk Response Planning
Chapter 5
This chapter discusses step five in the risk management process, risk
response planning.

Formula

Chapter Overview
Legend
5

ESI 68
Risk Response Planning
Risk Response
After completing the identification, analysis, and prioritization of project
risks, the project manager must lead the team in planning effective risk
response strategies. This requires the evaluation of risk response options
and documentation of the response strategies to be used. In performing
this function, the project manager should be aware of the types of risk
response strategies available and choose appropriately based on the
nature of the risks involved.
Risk response planning is basically about answering the question, What
should we do about this particular risk? In this step in the risk
management process, the project manager uses information previously
collected about project risks to develop specific strategies for handling
them. This step must be performed for both threats and opportunities,
and the responses that are developed should be incorporated into the
project risk plan and the overall project plan.
Risk Response Planning Process
The risk response planning process is a process within the overall risk
management process. It begins with two key pieces of input, the
prioritized risk listing and the project plan.
The process should include the planning of several strategies, followed
by the selection of the best strategy, including ways to handle both
threats and opportunities. This part of the process can be considered an
attempt to answer questions such as the following:
Can this threat be accepted?
Can this opportunity be ignored?
Can this threat be avoided or minimized?
Can this opportunity be maximized?
Can this threat be transferred to another party?
Because risks often do not operate in isolation, a response strategy for
one risk may affect others by exacerbating them or by making them more
tolerable. A risk response strategy also may create an entirely new risk.
Therefore, after making preliminary decisions about response strategies,
the project manager should conduct an assessment of the effects of
implementing those strategies on other project risks. If alternative
strategies can be used, they should be substituted into the plan.
Overview
Step 5: Risk
Response Planning
Introduction
5

ESI 69
Risk Response Planning Process (continued)
Evaluation of each strategy against the other should continue until the
optimum set of strategies is chosen. That set of strategies should then be
incorporated into the risk management plan and the project plan.
Regardless of which options are ultimately chosen for incorporation into
the plan, documentation of all response options available should be
maintained. If the primary response fails, the project team can then
examine the documentation, reassess its options, and substitute a back-up
risk response if that proves practical.
The project manager must be cognizant of the overall context within
which risk response strategies are developed. Recall that the project plan
is one of the two primary inputs to the risk response planning process.
This is because the whole purpose of risk management is to increase the
chances for a successful project outcome. Risk response strategies must
therefore be consistent with and assist in achieving overall project
objectives. The existence of a combination of risks is an important
context because a single strategy could sufficiently mitigate several risks.
The ability of the project team to assimilate the strategy is another
essential context, since the team must be ready, willing, and able to
execute the strategy in order for it to be effective. Finally, the strategies
adopted must account for any project constraints. If there are constraints
prohibiting the implementation of certain strategies, those strategies must
not be selected.
Risk Response Strategies for Threats
In addressing risks that are threats, there are four types of threat response
strategies that may be used according to the PMBOK
Guide p. 261263:
Accept
Mitigate
Transfer
Avoid
Sometimes a project manager must accept a risk because there simply are
no strategies available to deal with it. At other times, a project manager
may decide to accept a particular risk because that is the most sensible
approach. This should happen if analysis of all possible avoid, transfer,
and mitigate strategies reveals that their costs will be higher than the
amount of risk that can be tolerated. In either case, the project manager
and the organization must be able to tolerate the consequences of the
accepted risk should it occur.
Introduction
(continued)
Response Strategy
Context
Four Types of Risk
Response Strategies
Accept

ESI 70
Risk Response Strategies for Threats (continued)
There is, however, more than one way to accept a risk. As explained in
the PMBOK
Guide, p. 263, it may be accepted actively or passively.

Passive acceptance means that nothing will be done to prepare for the
risk in advance; instead, it will be dealt with if and when it occurs.
Active acceptance means that the risk is accepted for the time being, but
a contingency plan is developed for implementation later in case the risk
occurs. This can be done using some amount of money or resources in
reserve to be drawn on if the risk occurs.
Threat mitigation means either reducing the probability of the threats
occurrence or minimizing its impact if it does occur. In other words, it is
an attempt to reduce risk exposure that is too high to be acceptable. This
is so because risk exposure is the product of probability and impact.
The probability of a threat events occurrence can be reduced by using
similar techniques to those used to avoid threats, for example, adopting
simpler approaches or adding resources. The difference is that the
chances of the threats occurrence are merely reduced, not eliminated
altogether.
The impact of a threats occurrence can be reduced through the use of
safety measures. Good examples of this approach can be taken from
projects that conclude with the cutover to a major new software program.
The threat of system failure and loss of data during cutover can be
mitigated by backing up the legacy system and running both systems in
parallel until the stability of the new system has been fully confirmed.
Threat transfer does not eliminate the threat. Instead, it shifts the threat
and responsibility for responding to it to another party. Transference
almost invariably involves some sort of legal or contractual relationship.
The most obvious is liability insurance, for example, shifting the risk of
property damage to an insurance company. Buyers in all industries risk
purchasing deliverables that fail after sellers have completed their work
on the project and been fully paid; the buyers transfer that risk back to
the sellers through warranties and guarantees, and sellers transfer some of
it back issuing strictly limited warranties and guarantees. Owners of large
construction projects invariably transfer the threat of contractor default by
requiring the contractor to provide surety bonds for performance and
payment of subcontractors. Even simple contract terms that seemingly
have nothing to do with risk can be used to transfer enormous threats.
Price terms are good examples, where cost-plus contracts place the risk
of cost overruns entirely on the buyer and fixed-price contracts place it
entirely on the seller.
Accept (continued)
Mitigate
Transfer

ESI 71
Risk Response Strategies for Threats (continued)
In adopting a threat transfer strategy, you should always remember that
transference is not likely to be free. The party that the threat is transferred
to will invariably want something in return, and that will usually mean
some form of payment. Often the end result is that the risk-intolerant
buyer rids itself of the possibility of facing an extremely damaging worst-
case scenario while the seller accepts the threat transfer for a fee based
on risk exposure (expected value) plus some reasonable return. The
seller can do this because its risks actually occur according to expected
probabilities over the course of many contracts.
Avoid is the most direct threat response strategy. It means eliminating a
threat or at least eliminating the possibility of it having any impact on the
project. How can you avoid a threat? You will not always be able to,
but depending on the nature of the threat, it can be done. For example,
the chances of a resource shortage on an earthen dam construction
project may be eliminated altogether through the purchase of additional
heavy equipment. Substituting a simpler, time-tested component may
eliminate the possibility of delays to a systems integration project
because of incorporation of a highly complex and previously untried
product. In general, any significant threat should be avoided if the
avoidance approach is relatively simple and has no other adverse effects.
Risk Response Strategies for Opportunities
Like threats, opportunities also can be addressed using various response
strategies. The basic approaches, according to the PMBOK
Guide,
pp. 262263, include the following:
Accept
Enhance
Exploit
Share
Strategies for dealing with opportunities are conceptual opposites of
corresponding strategies for dealing with threats.
Accepting an opportunity, which means choosing to do nothing about a
desirable risk, corresponds to accepting a threat. You simply decide to
deal with the matter if and when it arises.

Transfer (continued)
Avoid
Overview
Accept

ESI 72
Risk Response Strategies for Opportunities (continued)
Enhancing an opportunity means trying to increase its expected value. It
is the opposite of threat mitigation because you try to increase rather than
decrease either the probability or the impact of the opportunity, or both.
Exploiting an opportunity is the opposite of avoiding a threat, since you
try to ensure that the risk does occur instead of ensuring that it does not.
Sharing an opportunity uses the same logic as transferring a threat. You
share the opportunity with another party that takes the responsibility for
making the opportunity occur. Then you both can share in the wealth.
Schedule Risk Response Planning
Schedule risk response planning also must include an evaluation of the
projects network schedule. In fact, the project manager cannot properly
understand schedule risk exposures without the aid of a network
schedule. That is one of the main reasons why network scheduling
techniques are strongly preferred for project schedules.
In the case of scheduling impacts, the harm that a particular threat risk
might cause to the project is significantly influenced by the presence of
float in the network schedule. For example, suppose that there is a 50
percent risk of a 90-day delay in procuring a particular project
component. There appears to be a worst-case impact of a 90-day delay
and a risk exposure (or expected value) of a 45-day delay; but if that
particular procurement activity has 180 days of float, there is actually no
impact or risk exposure at all, and the risk can be ignored.
Thus, schedule risk exposure only arises when the risk of delay
approaches or exceeds the amount of float available to the activity at risk.
When that situation occurs, the project manager should be concerned
and should consider whether the threat is acceptable or requires some
risk response planning. If it does, measures to avoid, transfer, or mitigate
the risk should be evaluated against the network schedule until the
optimum plan is determined.

Enhance
Exploit
Share
Overview
Scheduling Impacts

ESI 73
Response Analysis Matrix
Risks and responses can interact in strange ways. Project managers need
to analyze this interaction. The easiest way to do this is to create a matrix
of risks and risk responses with the risks listed by row in priority order
from top to bottom and the response strategies listed across the columns.
An example of a simple matrix is provided here for a shopping center
developers project.

For each combination of a risk and a risk response, the matrix is marked
with a plus (+) or minus (-) sign to indicate a positive or negative effect
on risk exposure. As the sample matrix shows, one response strategy
may actually solve more than one risk problem. Requiring performance
and payment bonds addresses the risks of contractor default and non-
payment of subcontractors, and providing additional soil borings
minimizes the chances of encountering unexpected subsurface
conditions and also reduces the likelihood of contractor claims.
On the other hand, the response to one risk may exacerbate another, as
in the case of shortening the contract time. Although this strategy is
designed to maximize chances of completing the project in time for the
holiday shopping season, it also increases the probability of contractor
claims by making the schedule more difficult to meet. And of course,
one risk may be affected in different ways by two different strategies as
Overview
Responses:
Risks
Builders
Risk
Insurance
Payment and
Performance
Bonds
Perform
Additional
Soil Borings
Reduce
Contract
Time
Fire or natural
disaster
+
Prime
contractor
default
+
Liens from
unpaid
subcontractors

+

Unexpected
subsurface site
conditions

+

Open after
holiday season
+
Claims by
contractor for
additional time
and money

+

_
Overview

ESI 74
Response Analysis Matrix (continued)
the risk of claims is by providing additional soil borings and by
shortening the contract time.
The key point to recognize is that risks and responses can interact in
unexpected ways, so the relationships of all risks and response strategies
must be considered together at the conclusion of response planning. The
risk response matrix is a useful tool for studying this interaction. The
final step in using it is to decide which strategies will be implemented
and which will not. The plus and minus signs for those that remain a part
of the risk response plan can be circled on the matrix to indicate that
decision.
Reserves
Reserves are an important part of the project plan and risk management
plan. They are needed to cover all the risks that have been passively or
actively accepted. They also are needed to provide an allowance for
unknowns. According to the PMBOK
Guide (pp. 372, 355), reserves

are defined as follows:
Reserves: A provision in the project management plan to [set
aside dollars or other resources] to mitigate cost and/or schedule
risk.
Contingency reserves: The amount of funds, budget, or time
needed above the estimate to reduce the risk of overruns of
project objectives to a level acceptable to the organization.
Another special case of reserves is management reserves. Management
reserves are a separately planned quantity used to allow for future
situations that are impossible to predict, that is, unknown unknowns.
Reserves are primarily intended for threats. Some organizations,
however, use opportunities to counterbalance threats.
Many factors need to be assessed to determine reserve amounts. The
earlier the risk occurs in the project life cycle, the higher the need for
reserves because additional unknowns may occur. The type of contract
is significant to a sellers project manager because fixed-price contracts
require more reserves than cost-plus contracts. The corporations risk
tolerance level also will affect the reserve level. If a company has a high
tolerance for risk, it may not want much reserve, because it is willing to
run the risk. If a company has low tolerance for risk, it may opt for a
solid reserve. Risk exposure is an obvious factor influencing the size of
the reserves. If the risk exposure is high, set aside a comparable reserve.
If there is not much risk exposure, a reserve is not as important.
Overview
Factors in
Determining Reserves

ESI 75
Reserves (continued)
There are two key points to consider in budgeting reserves. First, the
determination of reserves is essentially an estimating process. Second,
reserves should be broken into smaller units in the WBS, using the same
process that was used for actual work tasks. This is essential to accurate
reserves estimating.
The total project budget is composed of the total of the project
performance budget and the reserves budget. When risk response
planning is completed, tasks included in the plan or WBS to mitigate risk
events should be included in the project performance budget. They
should still be tracked as costs related to risk management for lessons
learned purposes.
When the project manager has contingency plans for actively accepted
risks, the costs associated with executing the contingency plans must be
accounted for in contingency reserves. This is done by calculating the
total or net amount of the cost impact after the contingency plan was
executed and the cost of executing the contingency plan. For example,
assume the following situation:
A risk event with an impact of $30,000 and a 50 percent
probability
A contingency plan that will cost $5,000 to execute and reduce
the impact of the risk event to $10,000
In that case, the original and contingency plan risk exposures (expected
values) can be calculated as follows:
Original EV = 50% x $30,000 = $15,000
Contingency plan EV = 50% x ($5,000 + $10,000) = $7,500
By performing this sort of analysis for all actively accepted risks and
summing all the risk exposures, the amount of money needed for the
contingency reserve allowance can be determined.
Contingency reserves are established to allow for estimating inaccuracies
associated with passively accepted risks. There are no industry standards,
but many organizations have their own. The objective is to put enough
into reserves to cover overall systematic estimating errors. Based on ESI
client experience, the percentage of contingency reserves is typically 5 to
20 percent of the total project budget.
The problem being addressed is that a project manager may have a
lengthy list of passively accepted risks. Some of these risks will occur
and some will not. The risks that occur will have an impact, and the
project manager must determine how much should be put into reserves
Risk Reserves
Budgeting
Contingency Reserves
for Actively Accepted
Risks
for Passively
Accepted Risks

ESI 76
Reserves (continued)
to account for this situation. Since not all of the risk events will occur,
some average or weighted average amount should be set aside based on
historical data if it is available. A general rule of thumb is to add an
additional 10 percent that can be used to account for these risks.
The quantification of management reserves is usually based on an
organization-wide planning standard set by management. This standard
usually is a percentage that has been derived from historical data and
variances. Based on ESI client experience, the percentage of
management reserves typically is two to five percent of the overall
project budget.
Risk Management Plan
The risk management plan is the final output of all the risk response
work. It should contain the results of the preceding steps of risk
identification, analysis, and prioritization. It should document what
responses will be taken to manage various risks, how they will be
implemented, and who will be responsible for each one. Finally, the risk
management plan should specify how reserves will be used and who will
manage their use.
for Passively
Accepted Risks
(continued)
Management
Reserves
Final Output

ESI 77

Chapter Summary
Risk responses must be developed for each significant risk.
There are four basic threat responses: accept, mitigate,
transfer, and avoid.
There are four basic opportunity responses: accept,
enhance, exploit, and share.
One risk response strategy may affect another risk response
strategy.
Reserves should be used to mitigate both cost and
scheduling risks.
Risk response strategies should be integrated into the risk
management plan and the project plan.
Chapter Summary

ESI 78

organization.
1. How well have you planned risk responses in the past?
Given what you have learned in this unit, what can you do to
improve or enhance your risk plan on your project?
How does your organization use reserves? What steps will
you take to ensure that the reserves for your projects are
appropriate?
steps.
you return to work.
Next-Steps Action
Plan

ESI 79

Risk Management Chapter 5: Risk Response Planning
Time
1.

2.

3.

ESI 80
Time
4.

5.

6.

ESI 81
Risk Execution, Evaluation, and Updating
Chapter 6
This chapter discusses the final step in the risk management process,
monitoring and control.

Formula

Chapter Overview
Legend
6

ESI 82
Risk Monitoring and Control
The Final Risk Management Steps
After completing risk response planning and the steps in the risk
management process that precede it, the project manager must be able to
lead the project team through effective execution, evaluation, and
documentation of risk responses while the project work is actually
accomplished and the risks that occur are actually addressed. Working
with the project team members, the project manager must implement
clear lines of responsibility for risk responses.
For those cases where risks are planned for, the team must evaluate the
effectiveness of existing risk strategies and deploy updated strategies
when necessary. For cases where workarounds are relied on instead of
planned risk strategies, the team must also assess the viability of any
unplanned risk responses.
Risk Monitoring and Control
According to the PMBOK
Guide (page 264), the process of risk

monitoring and control during project execution is the process of
identifying, analyzing, and planning for newly arising risks, keeping track
of the identified risks and those on the watchlist, reanalyzing existing
risks, monitoring trigger conditions for contingency plans, monitoring
residual risks, and reviewing the execution of risk responses while
evaluating their effectiveness. This process must be integrated with the
overall project planning, execution, and control processes, relate to the
accomplishment of project objectives, and be performed continually
during the project. It essentially involves the three steps of the risk
management processexecuting, evaluating, and documenting the risk
management planall of which are performed continually and
simultaneously during the course of the project.
Certain common terms are used in connection with risk response control
in general. Risk events that materialize in a project are problems. This
is true for both known risk events that are anticipated and identified on
the projects risk listing and unknown risk events. In other words, when
project managers and others discuss problems that have occurred on a
project, they are really referring to risks that have materialized. A
windfall is the opportunity equivalent of a problem. In other words, it
is a realized opportunity rather than a realized threat, and may be known
Introduction
Overview
Risk Response
Control
6

ESI 83
Risk Monitoring and Control (continued)
or unknown. A workaround is a response to a problem that has not
been planned for. Corrective action is the execution of a response to a
problem, whether planned or unplanned.
The risk management plan is the basis for risk response control. It tells
project managers what actions they will take to help control risk, how
they will control risk, who will take action, how the plan will work, and
when the plan will be initiated. Risk response control is based on a
feedback cycle of executing responses to problems and windfalls,
reassessing the risks that have occurred and the effectiveness of the
responses to those risks, and updating risk response plans accordingly.
Risk response plans will cause the project team to execute planned
responses, and the results will cause them to see how effective the
responses are compared to the plan and to respond further if necessary.
These actions are integrally related to project execution and control
processes.
Meanwhile, deviations and variances from the overall project plan will
affect the project risk management plan. As project performance unfolds,
the project manager should regularly reassess risks and the projects risk
management plan and update it in light of what has happened so far on
the project. Project managers should continue going through that
process until execution is complete.
As problems materialize, certain choices must be made. If the problem
was not planned for, the project manager may decide to accept its impact
or develop a workaround on the spot that is designed to avoid, transfer,
or mitigate the problem. If the problem was planned for, the project
manager may execute the planned corrective action and do no more if
the results are acceptable or implement additional workarounds if they
are not. The project manager also may execute contingency plans.
Meanwhile, the project manager should be regularly reassessing risks and
identifying new ones.
In order for risk response control to work, the project manager must
adopt the following practices:
Closely monitor project progress
Promptly execute risk responses when problems or windfalls
occur
Thoroughly evaluate the effectiveness of risk responses
Implement further responses when necessary
Regularly monitor and follow up on the status of project risks
Risk Response
Control (continued)
Risk Response
Control Guidelines

ESI 84
Risk Monitoring and Control (continued)
The risk management plan is a critical component of the project plan
because the only way to perform all these functions effectively is to
perform them as part of the overall project management plan and
process.
Step 6: Execute Risk Strategy
The sixth step in the risk management process is executing the risk
strategy. Just as the project manager must follow through and execute
the project plan, he or she must do the same with the risk management
plan. Because the risks arise out of the project, there is no way to
implement a risk plan without implementing the project plan at the same
time. At the most basic level, the execution step in the risk management
process means carrying out risk response strategies. Note that not all risk
strategies require implementation. Many (particularly acceptance)
require action only when the risks become actual events. Meanwhile, as
the project progresses, risk evolves and the project team must be kept up-
to-date. This can be done by the project manager in a variety of ways,
including through meetings, e-mail, or MBWA.
One key to successful execution of a risk management plan is catching
problems before it is too late to respond to them effectively. Establishing
early warning systems that identify risk triggers and provide notice that a
problem may need to be addressed can do this. These triggers can be
specifically associated with particular risks or more general feedback
mechanisms about the status of the project.
A specific trigger event is a situation that alerts someone that a particular
risk event has occurred or is about to occur. For example, the risk of
depleting a battery power back-up system during a data-conversion
process may use a power outage of more than 30 minutes as the risk
trigger and the start-up of an emergency generator as the risk response.
More general feedback from basic project status reports can also serve as
triggers for responses to a variety of risks. Examples include such project
performance measures as earned value, cost variance, delays in the
project completion date, or disappearance of float time. Negative
variances in any of these measures may serve as warnings of problems
with subcontractor performance, customer cooperation, or the original
project estimates.
Risk Response
Control Guidelines
(continued)
Overview
Early Warning
Systems

ESI 85
Step 6: Execute Risk Strategy (continued)
You should monitor risks exactly as you would monitor project status.
This means that risk review should be included as a regular agenda item
for project status meetings. Such a review should involve discussions of
the following topics:
Progress made to date in executing the risk management plan
Any threats or opportunities that have passed without becoming
problems or windfalls
Any new problems or windfalls observed or anticipated
Any actions required in terms of updated or implementing risk
response plans
Someone must be responsible for each aspect of risk response control.
The project manager needs to assign responsibility for risk response
control just as carefully as he or she would any other important task.
This is extremely important, but it is not particularly difficult. Simple
tools such as responsibility matrixes or action item lists can be used to
make clear who is responsible for what. Responsibility for particular risks
and for execution of their response strategies also can be documented on
the projects risk listing. The important thing is that the method used must
identify specific individuals for specific responsibilities.
Step 7: Evaluate Results
On a regular basis throughout the project, the project manager should
evaluate the effectiveness of risk responses and the risk management
plan. It is important to determine whether a risk response strategy proved
to be either effective or ineffective so that others can be informed of the
results and decide whether to use it in the future. Opportunities to revise
the risk management plan that might not be seen without such ongoing
evaluation also may arise during the project.
The input for risk evaluation starts with the risk management and project
plans. It also includes cost and schedule data and information about any
technical or scope issues that have arisen. All this information is
evaluated along with corrective actions that have been taken and their
results in order to determine the effectiveness of the risk management
process to date.
Early Warning
Systems (continued)
Responsibility for
Risk Response
Control
Overview

Risk Evaluation

ESI 86
Step 7: Evaluate Results (continued)
This determination is made by periodic reassessment of risks throughout
the execution process. This reassessment may raise a variety of
questions, such as the following:
Are the identified risks still the same? (New risks may have
arisen; others may have passed.)
Are the probabilities of the identified risks still the same? Are
their expected impacts still the same? (Either of these
components of risk exposure may have changed for any risk as a
result of what has already transpired on the project.)
Were the consequences of the response strategies the same as
envisioned? (In other words, how well did the response strategies
work?)
Given the answers to those questions, should planned risk
responses stay the same or be revised? (Depending on the
timeliness of the reassessment, it may not be too late to try a
different course of action.)
All risks and responses, including risks that were filtered out, must be
regularly evaluated in this manner throughout the project life cycle. The
net result is that the project manager is trying to determine if any
additional actions are required.
The evaluation process for risk responses and corrective actions should
be specifically related to the nature of the risk responses that were
selected. Questions to be answered include the following:
Have avoided risks truly been eliminated?
Have mitigated risks been sufficiently contained? (The intent of a
mitigation response is not to eliminate the threat entirely, just
enough to be tolerated.)
Have transferred risks been fully shifted to other parties?
(Sometimes they have a way of coming back to haunt the party
transferring the risk, especially if the risk transfer is based on
onerous contract provisions that shift risks to a party that is not
well positioned to manage them.)
Can accepted risks that have materialized really be tolerated?
(Their impacts may be worse than expected.)
Have contingency plan results been satisfactory?
Have workaround results been effective?
Has the possibility of the risk events occurrence expired?
Is any further action required?
Risk Evaluation
(continued)

Evaluating Risk
Responses

ESI 87
In addition to evaluating corrective actions, project managers must
continually reassess the risk management plan, starting with risk
identification. This means validating risks already being tracked and
identifying any new risks that have arisen. Common sources of new risks
include:
Cost or schedule variances
Changes in requirements
Personnel or stakeholder changes
Organizational and environmental changes
Changes in resources and their utilization
The output of this step is an updated list of risk events, and the list should
address both threats and opportunities.
The next step in risk reassessment is reanalyzing risks. This starts with
determining whether the probability of each risk occurring is the same
and whether the impact of each risk is the same. For example, suppose
the following:
The project uses a work force of several trades in five different
unions.
When the project was launched, all five union agreements were
due for negotiations within the next six months, and threats of
strikes were common.
Each union would honor any others picket line.
The original project risk listing identified a project shutdown
caused by a strike as a risk with a 60 percent probability and an
impact of 30 days on the project schedule.
The original mitigation strategy was to accelerate the work by
paying considerable overtime to trades working on critical
activities, because that would be less expensive than the risk
exposure associated with delaying completion of the project.
Now, further suppose that three months into the project, four of the five
agreements have been successfully renegotiated with remarkably few
problems and that rumors of a strike have ceased. Clearly, the risk of a
strike requires reanalysis. The project team might now reassess the risk
exposure as having a 10 percent probability and an impact of 20 days.
Depending on how the product of those two factors compares to the cost
of the mitigation strategy, acceleration of the project through use of
overtime might be reduced or eliminated altogether. The latter choice
would mean accepting the reduced risk exposure.

Risk Reassessment
Updated Risk
Identification

Risk Reassessment
Updated Risk
Analysis

ESI 88
After reanalyzing the updated risk list, the project manager must
reprioritize the entire list, since priorities can change. This is true
because tolerances for particular risks and risk tolerances in general may
change over time, even during the duration of the project. Project
stakeholders or sponsors may change, and a new sponsor of a project
might want one risk given priority over another risk, changing the order
of priority. In addition, entirely new risks may have been identified
during the risk reassessment process.
Generally speaking you should reassess risk at regular intervals. The
intervals should vary based on the nature of the project. If you are
running a major project that spans 10 years, you do not want daily
reviews. If your project spans four weeks, a weekly review may not be
enough.
Regardless of the overall project duration, you should reassess risk
whenever major changes occur. Project managers must never forget that
changes occur on projects. Things go right, and things go wrong. Things
move ahead of schedule, and things fall behind. As changes occur, risks
must be reassessed. Similarly, if some major decision must be made, it is
time to reassess risk. This means that before major decisions are made,
planning for the associated risks should be completed.
Step 8: Document Risk Management
Results
Documentation is the one remaining step in the risk management
process. Although many people think documentation is a waste of time,
it is important for a variety of reasons. Documentation provides a written
account that risk management occurred and can be used to prove that
risk management was integrated into the management of the project if
that should become necessary. Naturally, a written record is preferable
to an oral record or institutional memory, either of which can often be
unreliable and biased. Documentation also provides information on how
risk management was approached and the rationale for actions taken.
This documentation can be vital to a later understanding or explanation
of the course of action that was taken. Without such a record, the project
manager might be hard pressed to explain his or her actions to upper
management.

Risk Reassessment
Updated Risk
Prioritization
When to Perform
Risk Reassessment
Overview

ESI 89
Step 8: Document Risk Management Results (continued)
Keeping thorough documentation also ensures that the organization will
have historical data available for use in managing future projects and
helps produce valuable lessons learned records. It provides information
on what worked, what did not, and why or why not.
Risk documentation should include all the input and output of the risk
management process, such as the original risk listing, risk analyses, the
original prioritized risk listing, and the risk response plan. It should
likewise include any updates or revisions to these items that were
generated during the evaluation and reassessment of risks in the project
execution phase.
Because risk documentation spans the duration of the project, it needs to
be maintained on an ongoing basis. Organizations that document
projects successfully document them in a consistent way. Some
organizations encourage project managers to read the documentation of
other project managers. They do so by ensuring that project managers
are rewarded on their ability not to repeat the mistakes of others. This
incentive is made part of their performance package.
Everything covered so far has been going on continually during the
project life cycle. However, the project eventually will come to an end.
At that point, the final project documentation, including a final risk
assessment and lessons learned, should be prepared by the project
manager.
In the final risk assessment, the project manager prepares an overall
assessment of how the project concluded from a risk management
perspective. The assessment should cover issues such as the effects of
risks and response strategies on the projects cost, schedule, and
performance; whether the customer was satisfied with how risks were
managed; the extent to which risk management objectives were
achieved; and identification of any organizational recognition or rewards
associated with risk management.
Whether it is incorporated in the final risk assessment or prepared
separately, the project manager should prepare documentation of risk
management lessons learned when the project nears its end. The
purpose is to reduce threats and increase opportunities for future projects
by documenting the experience with risks on the project being
completed. The lessons learned also can include improvements and
updates to standard forms and processes such as WBS templates, network
schedules, estimating, procurement, and contracts.
Risk Documentation
Final Steps During
Project Closeout

ESI 90
Chapter Summary
The project team must perform each risk response and
contingency plan during the project life cycle.
If unknown risks occur during the project, workarounds
should be used to control variances.
Risk reassessment should be continually performed
throughout the project life cycle.
The project team should fully document the performance
and results of the risk management plan on an ongoing
basis throughout the project life cycle.
Chapter Summary

ESI 91
organization.
1. How well does your organization identify early warnings or risk
triggers?
What can you do to enhance this on your projects?
Currently, how often do you reassess risks on your projects? Is
it enough?
How does your organization share project documentation
(including risk documentation)?
steps.
you return to work.

Next-Steps Action
Plan

ESI 92
Risk Management Chapter 6: Risk Execution, Evaluation, and Updating
Time
1.

2.

3.

ESI 93
Time
4.

5.

6.

RSK520 ReferenceMaterial

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

RSK520 ReferenceMaterial

Caricato da

Copyright:

Formati disponibili

Copyright ESI International

and ESI International have developed risk management

, and virtually everyone else who deals

Guide, pp. 247248

Guide, p. 263, it may be accepted actively or passively.

Guide (pp. 372, 355), reserves

Guide (page 264), the process of risk

Potrebbero piacerti anche