Risk management is the systematic process of identifying, analyzing,
and
|
responding to project risk. It includes maximizing the probability and
conse-
|
quences of
positive events and minimizing the probability and consequences of
|
adverse events to project objectives.
Figure 11-1 provides an
overview of the fol-
|
lowing
major processes:
|
11.1
|
Risk Management Planning
|
—deciding how to approach and plan the risk
man-
|
agement activities for a project.
|
11.2
|
Risk Identification
|
—determining which risks might affect the
project and doc-
|
umenting their characteristics.
|
11.3
|
Qualitative Risk Analysis
|
—performing a qualitative analysis of
risks and con-
|
ditions to prioritize their effects on
project objectives.
|
11.4
|
Quantitative Risk Analysis
|
—measuring the probability and
consequences of
|
risks and estimating their implications for
project objectives.
|
11.5
|
Risk Response Planning
|
—developing procedures and techniques to
enhance
|
opportunities and reduce threats to the
project’s objectives.
|
11.6
|
Risk Monitoring and Control
|
—monitoring residual risks, identifying new
risks,
|
executing risk reduction plans, and
evaluating their effectiveness throughout the
|
project life cycle.
|
These processes interact with each other and with the processes in
the other
|
knowledge areas. Each process generally occurs at least once in every
project.
|
Although processes are presented here as discrete elements with
well-defined inter-
|
faces, in practice they may overlap and interact in ways not detailed
here. Process
|
interactions are discussed in detail in Chapter 3.
|
Project
risk is an uncertain event or condition that, if it occurs, has a positive
|
or a
negative effect on a project objective. A risk has a cause and, if it occurs,
a
|
consequence.
For example, a cause may be requiring a permit or having limited
|
personnel assigned to the project. The risk event is that the permit
may take
|
longer than planned, or the personnel may not be adequate for the
task. If either
|
of these
uncertain events occur, there will be a consequence on the project cost,
|
schedule, or quality. Risk conditions could include aspects of the
project envi-
|
ronment that may contribute to project risk such as poor project
management
|
practices,
or dependency on external participants that cannot be controlled.
|
Project
risk includes both threats to the project’s objectives and opportunities
|
to improve on those objectives. It has its origins in the uncertainty
that is present
|
in all projects.
Known risks are those that have been identified and analyzed
project managers may address them by applying a general contingency
based on
|
past
experience with similar projects.
|
Organizations perceive risk as it relates to threats to project
success. Risks that
|
are threats to the project may be accepted if they are in balance
with the reward
|
that may be gained by taking the risk. For example, adopting a
fast-track schedule
|
that may be
overrun is a risk taken to achieve an earlier completion date. Risks
|
that are opportunities may be pursued to benefit the project’s
objectives.
|
To be successful, the organization must be committed to addressing
risk man-
|
agement throughout the project. One measure of the organizational
commitment is
|
its dedication to
gathering high-quality data on project risks and their characteristics
11.1
RISK MANAGEMENT PLANNING
|
Risk
management planning is the process of deciding how to approach and plan
|
the risk management activities for a project. It is important to plan
for the risk
|
management processes that follow to ensure that the level, type, and
visibility of
|
risk management are commensurate with both the risk and importance of
the
|
project to
the organization.
|
11.1.1 Inputs to Risk
Management Planning
|
.
|
1
|
Project charter.
|
The project
charter is discussed in Section 5.1.3.1.
|
.
|
2
|
Organization’s risk management policies.
|
Some organizations may have prede-
|
fined
approaches to risk analysis and response that have to be tailored to a par-
|
ticular
project.
|
.
|
3
|
Defined roles and responsibilities.
|
Predefined roles, responsibilities, and authority
|
levels for
decision-making will influence planning.
|
.
|
4
|
Stakeholder risk tolerances.
|
Different organizations and different individuals
|
have different tolerances for risk. These may be expressed in policy
statements or
|
revealed in
actions.
|
.
|
5
|
Template for the organization’s risk
management plan.
|
Some
organizations have
|
developed
templates (or a pro-forma standard) for use by the project team. The
|
organization will continuously improve the template, based on its
application
|
and
usefulness in the project.
|
.
|
6
|
Work breakdown structure (WBS).
|
The WBS is described in Section 5.3.3.1
11.1.3 Outputs from Risk
Management Planning
|
.
|
1
|
Risk management plan.
|
The risk
management plan describes how risk identifi-
|
cation, qualitative and quantitative analysis, response planning,
monitoring, and
|
control
will be structured and performed during the project life cycle. The risk
|
management
plan does not address responses to individual risks—this is accom-
|
plished in the risk response plan, which is discussed in Section
11.5.3.1. The risk
|
management
plan may include the following.
|
Ù±
|
Methodology. Defines the
approaches, tools, and data sources that may be used
|
to perform risk management on this project. Different types of
assessments
|
may be appropriate, depending upon the project stage, amount of
information
|
available,
and flexibility remaining in risk management.
|
Ù±
|
Roles and responsibilities.
Defines the lead, support, and risk management
|
team membership for each type of action in the risk management plan.
Risk
|
management teams organized outside of the project office may be able
to per-
|
form more independent, unbiased risk analyses of project than those
from the
|
sponsoring
project team.
|
Ù±
|
Budgeting. Establishes a
budget for risk managment for the project.
|
Ù±
|
Timing. Defines how often the
risk management process will be performed
|
throughout the project life cycle. Results should be developed early
enough to
|
affect
decisions. The decisions should be revisited periodically during project
|
execution.
|
Ù±
|
Scoring and interpretation. The
scoring and interpretation methods appropriate
|
for the
type and timing of the qualitative and quantitative risk analysis being
|
performed. Methods and scoring must be determined in advance to ensure
|
consistency.
|
Ù±
|
Thresholds. The threshold criteria for risks that will
be acted upon, by whom,
|
and in what manner. The project owner, customer, or sponsor may have a
|
different risk threshold. The acceptable threshold forms the target
against
|
which the project team will measure the effectiveness of the risk
response
|
plan execution.
|
Ù±
|
Reporting
formats. Describes the content and
format of the risk response plan
|
described in Section 11.5.3.1. Defines how the results of the risk
management
|
processes will be documented, analyzed, and communicated to the project
|
team,
internal and external stakeholders, sponsors, and others.
|
Ù±
|
Tracking. Documents how all facets of risk activities
will be recorded for the
|
benefit of
the current project, future needs, and lessons learned. Documents
|
if and how risk processes will be audited.
Organizational
risks—such as cost, time, and scope objectives that are inter-
|
nally inconsistent, lack of prioritization of projects, inadequacy or
interruption
|
of funding,
and resource conflicts with other projects in the organization.
|
Ù±
|
External risks—such as shifting legal or regulatory environment,
labor issues,
|
changing owner priorities, country risk, and weather. Force majeure risks such
|
as earthquakes, floods, and civil unrest generally require disaster
recovery
|
actions
rather than risk management.
|
.
|
4
|
Historical information.
|
Information on prior projects may be available from the
|
following
sources:
|
Ù±
|
Project files—one or more of the organizations involved in the project
may
|
maintain
records of previous project results that can be used to identify risks.
|
These may be final project reports or risk response plans. They may
include
|
organized
lessons learned that describe problems and their resolutions, or be
|
available
through the experience of the project stakeholders or others in the
|
organization.
|
Ù±
|
Published information—commercial databases, academic studies, bench-
|
marking,
and other published studies may be available for many application
|
areas.
|
11.2.2 Tools and Techniques for
Risk Identification
|
.
|
1
|
Documentation reviews.
|
Performing a structured review of project plans and
|
assumptions, both at the total project and detailed scope levels,
prior project files,
|
and other
information is generally the initial step taken by project teams.
|
.
|
2
|
Information-gathering techniques.
|
Examples of information-gathering techniques
|
used in
risk identification can include brainstorming; Delphi; interviewing; and
|
strengths,
weaknesses, opportunities, and threats (SWOT) analysis.
|
Ù±
|
Brainstorming
. Brainstorming is probably the most frequently used risk iden-
|
tification technique. The goal is to obtain a comprehensive list of
risks that can
|
be
addressed later in the qualitative and quantitative risk analysis processes.
|
The project team usually performs brainstorming, although a
multidisci-
|
plinary set of experts can also perform this technique. Under the
leadership of
|
a facilitator, these people generate ideas about project risk.
Sources of risk are
|
identified in broad scope and posted for all to examine during the
meeting.
|
Risks are then categorized by type of risk, and their definitions are
sharpened.
|
Ù±
|
Delphi technique . The Delphi technique is a way to reach a consensus
of
|
experts on a subject such as project risk. Project risk experts are
identified but
|
participate
anonymously.
|
A facilitator uses a questionnaire to solicit ideas about the
important project
|
risks. The
responses are submitted and are then circulated to the experts for
|
further comment. Consensus on the main project risks may be reached in
a
|
few rounds of this process. The Delphi technique helps reduce bias in
the data
|
and keeps
any person from having undue influence on the outcome.
|
Ù±
|
Interviewing . Risks can be identified by interviews of experienced
project man-
|
agers or
subject-matter experts. The person responsible for risk identification
|
identifies the
appropriate individuals, briefs them on the project, and provides
identify risks on the project based on their experience, project
information,
|
and other
sources that they find useful.
|
Ù±
|
Strengths, weaknesses, opportunities, and threats (SWOT) analysis .
Ensures
|
examination of the project from each of the SWOT perspectives to
increase the
|
breadth of
the risks considered.
|
.
|
3
|
Checklists.
|
Checklists for risk identification can be developed based on
historical
|
information and knowledge that has been accumulated from previous
similar
|
projects and from other sources of information. One advantage of
using a check-
|
list is
that risk identification is quick and simple. One disadvantage is that it is
|
impossible to build an exhaustive checklist of risks, and the user may
be effec-
|
tively
limited to the categories in the list. Care should be taken to explore items
|
that do not appear on a standard checklist if they seem relevant to
the specific
|
project. The checklist should itemize all types of possible risks to
the project. It is
|
important to review the checklist as a formal step of every
project-closing pro-
|
cedure to
improve the list of potential risks, to improve the description of risks.
|
.
|
4
|
Assumptions analysis.
|
Every project is conceived and developed based on a set of
|
hypotheses,
scenarios, or assumptions. Assumptions analysis is a technique that
|
explores
the assumptions’ validity. It identifies risks to the project from inaccu-
|
racy,
inconsistency, or incompleteness of assumptions.
|
.
|
5
|
Diagramming techniques.
|
Diagramming
techniques may include:
|
Ù±
|
Cause-and-effect
diagrams (also known as Ishikawa or
fishbone diagrams)—
|
useful for
identifying causes of risks (described in Section 8.1.2.3).
|
Ù±
|
System or process flow charts—show how various elements of a system
inter-
|
relate and
the mechanism of causation (described in Section 8.1.2.3).
|
Ù±
|
Influence
diagrams—a graphical representation of a problem showing causal
|
influences,
time ordering of events, and other relationships among variables
|
and
outcomes.
|
11.2.3 Outputs from Risk
Identification
|
.
|
1
|
Risks.
|
A risk is an uncertain event or condition that, if it occurs, has a
positive or
|
negative effect on a project objective.
|
.
|
2
|
Triggers.
|
Triggers, sometimes called risk symptoms or warning signs, are
indications
|
that a risk has occurred or is about to occur. For example, failure to
meet interme-
|
diate milestones may be an early warning signal of an impending
schedule delay.
|
.
|
3
|
Inputs to other processes.
|
Risk identification may identify a need for further action
|
in another area. For example, the WBS may not have sufficient detail
to allow ade-
|
quate identification of risks, or the schedule may not be complete or
entirely logical.
|
11.3 QUALITATIVE RISK ANALYSIS
|
Qualitative
risk analysis is the process of assessing the impact and likelihood of
|
identified risks. This process prioritizes risks according to their
potential effect on
|
project
objectives. Qualitative risk analysis is one way to determine the impor-
|
tance of
addressing specific risks and guiding risk responses. The time-criticality
|
of risk-related actions may magnify the importance of a risk. An
evaluation of the
|
quality of the available information also helps modify the assessment
of the risk.
|
Qualitative risk analysis requires that the probability and
consequences of the
|
risks be evaluated
using established qualitative-analysis methods and tools
Use of
these tools helps correct biases
|
that are
often present in a project plan. Qualitative risk analysis should be revis-
|
ited during the project’s life cycle to stay current with changes in
the project risks.
|
This process can lead to further analysis in quantitative risk
analysis (11.4) or
|
directly to
risk response planning (11.5).
|
11.3.1 Inputs to Qualitative
Risk Analysis
|
.
|
1
|
Risk management plan.
|
This plan
is described in 11.1.3.
|
.
|
2
|
Identified risks.
|
Risks
discovered during the risk identification process are eval-
|
uated along
with their potential impacts on the project.
|
.
|
3
|
Project status.
|
The
uncertainty of a risk often depends on the project’s progress
|
through its life cycle. Early in the project, many risks have not
surfaced, the design
|
for the project is immature, and changes can occur, making it likely
that more risks
|
will be discovered.
|
.
|
4
|
Project type.
|
Projects of
a common or recurrent type tend to have better under-
|
stood probability of occurrence of risk events and their consequences.
Projects
|
using state-of-the-art or first-of-its-kind technology—or highly
complex projects—
|
tend to
have more uncertainty.
|
.
|
5
|
Data precision.
|
Precision describes the extent to which a risk is known and under-
|
stood. It measures the extent of data available, as well as the
reliability of data. The
|
source of the data that was used to identify the risk must be
evaluated.
|
.
|
6
|
Scales of probability and impact.
|
These
scales, as described in Section 11.3.2.2,
|
are to be
used in assessing the two key dimensions of risk, described in Section
|
1
|
1
|
.3.2.1.
|
.
|
7
|
Assumptions.
|
Assumptions
identified during the risk identification process are
|
evaluated
as potential risks (see Sections 4.1.1.5 and 11.2.2.4).
|
11.3.2 Tools and Techniques for
Qualitative Risk Analysis
|
.
|
1
|
Risk probability and impact.
|
Risk probability and risk consequences may be
|
described in qualitative terms such as very high, high, moderate, low,
and very low.
|
Risk
probability is the likelihood that a
risk will occur.
|
Risk
consequences is the effect on project
objectives if the risk event occurs.
|
These two dimensions of risk are applied to specific risk events, not
to the
|
overall
project. Analysis of risks using probability and consequences helps iden-
|
ratings (very low, low, moderate, high, and very high) to risks or
conditions based
|
on combining probability and impact scales. Risks with high
probability and high
|
impact are likely to require further analysis, including
quantification, and aggres-
|
sive risk management. The risk rating is accomplished using a matrix
and risk
|
scales for each risk.
|
A
risk’s probability scale naturally falls between 0.0 (no
probability) and 1.0
|
(certainty).
Assessing risk probability may be difficult because expert judgment
|
is used, often without benefit of historical data. An ordinal scale,
representing rel-
|
ative probability values from very unlikely to almost certain, could
be used. Alter-
|
natively, specific probabilities could be assigned by using a general
scale (e.g.,
|
.1
|
/ .3 / .5 /
.7 / .9).
|
The risk’s impact scale reflects the severity of its effect on the
project objective.
|
Impact can be ordinal or cardinal, depending upon the culture of the
organization
|
conducting
the analysis. Ordinal scales are simply rank-ordered values, such as
|
very low,
low, moderate, high, and very high. Cardinal scales assign values to
|
these impacts. These values are usually linear (e.g., .1 / .3 / .5 /
.7 / .9), but are
|
often nonlinear (e.g., .05 / .1 / .2 / .4 / .8), reflecting the
organization’s desire to
|
avoid high-impact risks. The intent of both approaches is to assign a
relative value
|
to the
impact on project objectives if the risk in question occurs. Well-defined
|
scales, whether ordinal or cardinal, can be developed using
definitions agreed
|
upon by the
organization. These definitions improve the quality of the data and
|
make the process more repeatable.
|
Figure
11-2 is an example of evaluating risk
impacts by project objective. It
|
illustrates its use for either ordinal or cardinal approach. These
scaled descriptors
|
of relative impact should be prepared by the organization before the
project begins.
|
Figure
11-3 is a Probability-Impact (P-I)
matrix. It illustrates the simple mul-
|
tiplication
of the scale values assigned to estimates of probability and impact, a
|
common way to combine these two dimensions, to determine whether a
risk is
|
considered
low, moderate, or high. This figure presents a non-linear scale as an
|
example of
aversion to high-impact risks, but linear scales are often used. Alter-
|
natively,
the P-I matrix can be developed using ordinal scales. The organization
|
must determine which combinations of probability and impact result in
a risk’s
|
being classified as high risk (red condition), moderate risk (yellow
condition),
|
and low
risk (green condition) for either approach. The risk score helps put the
|
risk into a
category that will guide risk response actions.
|
.
|
3
|
Project assumptions testing.
|
Identified
assumptions must be tested against two
|
criteria:
assumption stability and the consequences on the project if the assump-
|
tion is
false. Alternative assumptions that may be true should be identified and
|
their consequences on the project objectives tested in the
qualitative risk-analysis
|
process.
|
.
|
4
|
Data precision ranking.
|
Qualitative
risk analysis requires accurate and unbiased
|
data if it is to be helpful to project management. Data precision
ranking is a tech-
|
nique to evaluate the degree to which the data about risks is useful
for risk man-
|
agement. It
involves examining:
|
Ù±
|
Extent of
understanding of the risk.
|
Ù±
|
Data
available about the risk.
|
Ù±
|
Quality of
the data.
|
Ù±
|
The use of data of low precision—for instance, if a risk is not well
understood—
|
may lead to
a qualitative risk analysis of little use to the project manager. If a
|
ranking of data precision is unacceptable, it may be possible to
gather better data.
|
11.3.3 Outputs from Qualitative
Risk Analysis
|
.
|
1
|
Overall risk ranking for the project.
|
Risk ranking may indicate the overall risk posi-
|
tion of a project relative to other projects by comparing the risk
scores. It can be
|
used to assign personnel or other resources to projects with
different risk rankings,
|
to make a benefit-cost analysis decision about the project, or to support
a recom-
|
mendation for project initiation, continuation, or cancellation.
|
.
|
2
|
List of prioritized risks.
|
Risks and conditions can be prioritized by a number of cri-
|
teria. These include rank (high, moderate, and low) or WBS level.
Risks may also
|
be grouped by those that require an immediate response and those that
can be
|
handled at a later date. Risks that affect cost, schedule,
functionality, and quality
|
may be assessed separately with different ratings. Significant risks
should have a
|
description
of the basis for the assessed probability and impact.
|
.
|
3
|
List of risks for additional analysis and
management.
|
Risks classified as high or
|
moderate would be prime candidates for more analysis, including
quantitative
|
risk
analysis, and for risk management action.
|
Trends in qualitative risk analysis
results.
|
As the analysis is repeated, a trend of
|
results may become apparent, and can make risk response or further
analysis
|
more or
less urgent and important.
|
11.4 QUANTITATIVE RISK ANALYSIS
|
The quantitative risk analysis process aims to analyze numerically
the probability
|
of each risk and its consequence on project objectives, as well as the
extent of
|
overall project risk. This process uses techniques such as Monte
Carlo simulation
|
and
decision analysis to:
|
Ù±
|
Determine
the probability of achieving a specific project objective.
|
Ù±
|
Quantify
the risk exposure for the project, and determine the size of cost and
|
schedule
contingency reserves that may be needed.
|
Ù±
|
Identify risks requiring the most attention by quantifying their
relative con-
|
tribution
to project risk.
|
Ù±
|
Identify
realistic and achievable cost, schedule, or scope targets.
|
Quantitative risk analysis generally follows qualitative risk
analysis. It requires
|
risk identification. The qualitative and quantitative risk analysis
processes can be
|
used separately or together. Considerations of time and budget
availability and the
|
need for qualitative or quantitative statements about risk and
impacts will deter-
|
mine which method(s) to use. Trends in the results when quantitative
analysis is
|
repeated can indicate
the need for more or less risk management action.
11.4.1 Inputs to Quantitative
Risk Analysis
|
.
|
1
|
Risk management plan.
|
This plan
is described in Section 11.1.3.
|
.
|
2
|
Identified risks.
|
These are
described in Section 11.2.3.1.
|
.
|
3
|
List of prioritized risks.
|
This is
described in Section 11.3.3.2.
|
.
|
4
|
List of risks for additional analysis and
management.
|
This is
described in Section
|
1
|
1
|
.3.3.3.
|
.
|
5
|
Historical information.
|
Information
on prior, similar completed projects, studies
|
of similar projects by risk specialists, and risk databases that may be
available
|
from
industry or proprietary sources (see Section 11.2.1.4).
|
.
|
6
|
Expert judgment.
|
Input may come from the project team, other subject matter
|
experts in the organization, and from others outside the
organization. Other sources
|
of information include engineering or statistical experts (see Section
5.1.2.2).
|
.
|
7
|
Other planning outputs.
|
Most
helpful planning outputs are the project logic and
|
duration estimates used in determining schedules, the WBS listing of
all cost ele-
|
ments with
cost estimates, and models of project technical objectives.
|
11.4.2 Tools and Techniques for
Quantitative Risk Analysis
|
.
|
1
|
Interviewing.
|
Interviewing techniques are used to quantify the probability and con-
|
sequences of risks on project objectives. A risk interview with
project stakeholders
|
and subject-matter experts may be the first step in quantifying risks.
The infor-
|
mation needed depends upon the type of probability distributions that
will be
|
used. For
instance, information would be gathered on the optimistic (low), pes-
|
simistic (high), and the most likely scenarios if triangular
distributions are used,
|
or on mean and standard deviation for the normal and log normal
distributions.
|
Examples of three-point estimates for a cost estimate are shown
in Figure 11-4 .
|
Continuous
probability distributions are usually used in quantitative risk
|
analysis. Distributions represent both probability and consequences of
the project
|
component.
Common distribution types include the uniform, normal, triangular,
|
beta, and
log normal. Two examples of these distributions are shown in Figure
|
11-5
|
(where the vertical axis refers to probability and the horizontal
axis to impact).
|
Documenting the rationale of the risk ranges is an important component
of
|
the risk
interview, because it can lead to effective strategies for risk response in
|
.
|
2
|
Sensitivity analysis.
|
Sensitivity
analysis helps to determine which risks have the
|
most
potential impact on the project. It examines the extent to which the uncer-
|
tainty of each project element affects the objective being examined
when all
|
other
uncertain elements are held at their baseline values.
|
.
|
3
|
Decision tree analysis.
|
A decision analysis is usually structured as a decision tree.
|
The
decision tree is a diagram that describes a decision under consideration and
|
the implications of choosing one or another of the available
alternatives. It incor-
|
porates probabilities of risks and the costs or rewards of each
logical path of
|
events and future decisions. Solving the decision tree indicates which
decision
|
yields the
greatest expected value to the decision-maker when all the uncertain
|
implications, costs, rewards, and subsequent decisions are
quantified. A decision
|
tree is
shown in Figure 11-6 .
|
.
|
4
|
Simulation.
|
A project simulation uses a model that translates the uncertainties
|
specified at a detailed level into their potential impact on objectives
that are
|
expressed at the level of the total project. Project simulations are
typically per-
|
formed
using the Monte Carlo technique.
|
For a cost risk analysis, a simulation may use the traditional
project WBS as its
|
model. For a schedule risk analysis, the Precedence Diagramming
Method (PDM)
|
schedule is
used (see Section 6.2.2.1).
|
A cost risk
simulation result is shown in Figure
11-7 .
|
11.4.3 Outputs from Quantitative
Risk Analysis
|
.
|
1
|
Prioritized list of quantified risks.
|
This list of risks includes those that pose the
|
greatest threat or present the greatest opportunity to the project
together with
|
a measure
of their impact.
|
.
|
2
|
Probabilistic analysis of the project.
|
Forecasts of potential project schedule and
|
cost results listing the possible completion dates or project duration
and costs
|
with their
associated confidence levels.
|
.
|
3
|
Probability of achieving the cost and time
objectives.
|
The probability of achieving
|
the project
objectives under the current plan and with the current knowledge of
|
the risks
facing the project can be estimated using quantitative risk.
|
.
|
4
|
Trends in quantitative risk analysis
results.
|
As the
analysis is repeated, a trend of
|
11.5
RISK RESPONSE PLANNING
|
Risk response planning is the process of developing options and
determining actions
|
to enhance opportunities and reduce threats to the project’s
objectives. It includes
|
the identification and assignment of individuals or parties to take
responsibility for
|
each agreed risk response. This process ensures that identified risks
are properly
|
addressed. The effectiveness of response planning will directly
determine whether
|
risk increases or decreases for the project.
|
Risk response planning must be appropriate to the severity of the
risk, cost
|
effective in meeting the challenge, timely to be successful, realistic
within the
|
project context, agreed upon by all parties involved, and owned by a
responsible
|
person.
Selecting the best risk response from several options is often required.
|
11.5.1 Inputs to Risk Response
Planning
|
.
|
1
|
Risk management plan.
|
This plan
is described in Section 11.1.3.
|
.
|
2
|
List of prioritized risks.
|
This list from qualitative risk analysis is described in Section
|
11.3.3.2.
|
.
|
3
|
Risk ranking of the project.
|
.
|
4
|
Prioritized list of quantified risks.
|
This list from quantitative risk analysis is described
|
in Section 11.4.3.1.
|
.
|
5
|
Probabilistic analysis of the project.
|
This is
described in Section 11.4.3.2.
|
.
|
6
|
Probability of achieving the cost and time
objectives.
|
This is
described in Section
|
11.4.3.3.
|
.
|
7
|
List of potential responses.
|
In the risk identification process, actions may be iden-
|
tified that
respond to individual risks or categories of risks.
|
.
|
8
|
Risk thresholds.
|
The level of risk that is acceptable to the organization will influ-
|
ence risk response planning (see Section 11.1.3).
|
.
|
9
|
Risk owners.
|
A list of project stakeholders able to act as owners of risk
responses.
|
Risk owners
should be involved in developing the risk responses.
|
.
|
0
|
Common risk causes.
|
Several risks may be driven by a common cause. This situ-
|
ation may reveal opportunities to mitigate two or more project risks
with one
|
generic
response.
|
.
|
1
|
1
|
Trends in qualitative and quantitative risk
analysis results.
|
These are
described in
|
Sections
11.3.3.4 and 11.4.3.4. Trends in results can make risk response or fur-
|
ther
analysis more or less urgent and important.
|
11.5.2 Tools and Techniques for
Risk Response Planning
|
Several
risk response strategies are available. The strategy that is most likely to
|
be effective should be selected for each risk. Then, specific actions
should be
|
developed to implement that strategy. Primary and backup strategies
may be
|
1
|
Avoidance.
|
Risk
avoidance is changing the project plan to eliminate the risk or
|
condition or to protect the project objectives from its impact.
Although the project
|
team can never eliminate all risk events, some specific risks may be
avoided.
|
Some risk
events that arise early in the project can be dealt with by clarifying
|
requirements, obtaining information, improving communication, or
acquiring
|
expertise.
Reducing scope to avoid high-risk activities, adding resources or time,
|
adopting a
familiar approach instead of an innovative one, or avoiding an unfa-
|
miliar
subcontractor may be examples of avoidance.
|
.
|
2
|
Transference.
|
Risk transfer is seeking to shift the consequence of a risk to a
third
|
party together with ownership of the response. Transferring the risk
simply gives
|
another
party responsibility for its management; it does not eliminate it.
|
Transferring liability for risk is most effective in dealing with
financial risk expo-
|
sure. Risk transfer nearly always involves payment of a risk premium
to the party
|
taking on the risk. It includes the use of insurance, performance
bonds, war-
|
ranties,
and guarantees. Contracts may be used to transfer liability for specified
|
risks to another party. Use of a fixed-price contract may transfer
risk to the seller
|
if the project’s design is stable. Although a cost-reimbursable
contract leaves more
|
of the risk with the customer or sponsor, it may help reduce cost if
there are mid-
|
project changes.
|
.
|
3
|
Mitigation.
|
Mitigation seeks to reduce the probability and/or consequences of an
|
adverse
risk event to an acceptable threshold. Taking early action to reduce the
|
probability of a risk’s occurring or its impact on the project is
more effective than
|
trying to
repair the consequences after it has occurred. Mitigation costs should
|
that will reduce the problem—e.g., adopting less complex processes,
conducting
|
more seismic or engineering tests, or choosing a more stable seller.
It may involve
|
changing conditions so that the probability of the risk occurring is
reduced—e.g.,
|
adding
resources or time to the schedule. It may require prototype development
|
to reduce
the risk of scaling up from a bench-scale model.
|
Where it is
not possible to reduce probability, a mitigation response might
|
address the
risk impact by targeting linkages that determine the severity. For
|
example,
designing redundancy into a subsystem may reduce the impact that
|
results from a failure of the original component.
|
.
|
4
|
Acceptance.
|
This technique indicates that the project team has decided not to
|
change the project plan to deal with a risk or is unable to identify
any other suit-
|
able
response strategy. Active acceptance may include developing a contingency
|
plan to execute, should a risk occur. Passive acceptance requires no
action,
|
leaving the
project team to deal with the risks as they occur.
|
A contingency plan is applied to identified risks that arise
during the project.
|
Developing a contingency plan in advance can greatly reduce the cost
of an
|
action should the risk occur. Risk triggers, such as missing
intermediate mile-
|
stones, should be defined and tracked. A fallback plan is developed if the risk has
|
a high impact, or if the selected strategy may not be fully effective.
This might
|
include
allocation of a contingency amount, development of alternative options,
|
or changing
project scope.
|
The most usual risk acceptance response is to establish a contingency allowance ,
|
or reserve, including amounts of time, money, or resources to account
for known
|
risks. The allowance should be determined by the impacts, computed at
an accept-
|
able level of risk exposure, for the risks that have been accepted.
|
11.5.3 Outputs from Risk
Response Planning
|
.
|
1
|
Risk response plan.
|
The risk
response plan (sometimes called the
risk register )
|
should be written to the level of detail at which the actions will be
taken. It
|
should include
some or all of the following:
|
Ù±
|
Identified risks, their descriptions, the area(s) of the project
(e.g., WBS element)
|
affected, their causes, and how they may affect project objectives.
|
Ù±
|
Risk owners
and assigned responsibilities.
|
Ù±
|
Results
from the qualitative and quantitative risk analysis processes.
|
Ù±
|
Agreed responses including avoidance, transference, mitigation, or
acceptance
|
for each
risk in the risk response plan.
|
Ù±
|
The level of residual risk expected to be remaining after the
strategy is imple-
|
mented.
|
Ù±
|
Specific
actions to implement the chosen response strategy.
|
Ù±
|
Budget and
times for responses.
|
Ù±
|
Contingency
plans and fallback plans.
|
.
|
2
|
Residual risks.
|
Residual
risks are those that remain after avoidance, transfer, or
|
mitigation
responses have been taken. They also include minor risks that have
|
been accepted and addressed, e.g., by adding contingency amounts to
the cost or
|
time
allowable.
|
.
|
3
|
Secondary risks.
|
Risks that arise as a direct result of implementing a risk
|
response are termed secondary
risks . These should be identified and responses
|
each party’s responsibility for specific risks, should they occur,
and for insurance,
|
services,
and other items as appropriate to avoid or mitigate threats.
|
.
|
5
|
Contingency reserve amounts needed.
|
The probabilistic analysis of the project
|
(11.4.3.2) and the risk thresholds (11.1.3.1) help the project
manager determine
|
the amount of buffer or contingency needed to reduce the risk of
overruns of
|
project
objectives to a level acceptable to the organization.
|
.
|
6
|
Inputs to other processes.
|
Most responses to risk involve expenditure of addi-
|
tional time, cost, or resources and require changes to the project
plan. Organi-
|
zations require assurance that spending is justified for the level of
risk reduction.
|
Alternative strategies must be fed back into the appropriate processes
in other
|
knowledge
areas.
|
.
|
7
|
Inputs to a revised project plan.
|
The results of the response planning process must
|
be incorporated into the project plan, to ensure that agreed actions
are imple-
|
mented and
monitored as part of the ongoing project.
|
11.6
RISK MONITORING AND CONTROL
|
Risk monitoring and control is the process of keeping track of the
identified risks,
|
monitoring residual risks and identifying new risks, ensuring the
execution of risk
|
plans, and evaluating their effectiveness in reducing risk. Risk
monitoring and
|
control
records risk metrics that are associated with implementing contingency
|
plans. Risk monitoring and control is an ongoing process for the life
of the
|
project. The risks change as the project matures, new risks develop, or
antici-
|
pated risks
disappear.
|
Good risk
monitoring and control processes provide information that assists
|
with making
effective decisions in advance of the risk’s occurring. Communica-
|
tion to all
project stakeholders is needed to assess periodically the acceptability
|
of the
level of risk on the project.
|
The purpose
of risk monitoring is to determine if:
|
Ù±
|
Risk
responses have been implemented as planned.
|
Ù±
|
Risk
response actions are as effective as expected, or if new responses should
|
be
developed.
|
Ù±
|
Project
assumptions are still valid.
|
Ù±
|
Risk
exposure has changed from its prior state, with analysis of trends.
|
Ù±
|
A risk
trigger has occurred.
|
Ù±
|
Proper
policies and procedures are followed.
|
Ù±
|
Risks have
occurred or arisen that were not previously identified.
|
Risk control may involve choosing alternative strategies,
implementing a con-
|
tingency plan, taking corrective action, or replanning the project. The
risk
|
response owner should report periodically to the project manager and
the risk
|
team leader
on the effectiveness of the plan, any unanticipated effects, and any
|
11.6.1 Inputs to Risk
Monitoring and Control
|
.
|
1
|
Risk management plan.
|
The risk management plan is described in Section 11.1.3.
|
.
|
2
|
Risk response plan.
|
The risk
response plan is described in Section 11.5.3.1.
|
.
|
3
|
Project communication.
|
Work
results and other project records described in Sec-
|
tion 10.3.1 provide information about project performance and risks.
Reports
|
commonly used to monitor and control risks include Issues Logs , Action-Item Lists ,
|
Jeopardy
Warnings , or Escalation Notices .
|
.
|
4
|
Additional risk identification and
analysis.
|
As project performance is measured and
|
reported, potential risks not previously identified may surface. The
cycle of the six
|
risk processes should be implemented for these risks.
|
.
|
5
|
Scope changes.
|
Scope changes often require new risk analysis and response
|
plans.
Scope changes are described in Section 5.5.3.1.
|
11.6.2 Tools and Techniques for
Risk Monitoring and Control
|
.
|
1
|
Project risk response audits.
|
Risk
auditors examine and document the effective-
|
ness of the
risk response in avoiding, transferring, or mitigating risk occurrence
|
as well as
the effectiveness of the risk owner. Risk audits are performed during
|
the project
life cycle to control risk.
|
.
|
2
|
Periodic project risk reviews.
|
Project
risk reviews should be regularly scheduled.
|
Project
risk should be an agenda item at all team meetings. Risk ratings and pri-
|
oritization may change during the life of the project. Any changes may
require
|
additional
qualitative or quantitative analysis.
|
.
|
3
|
Earned value analysis.
|
Earned value is used for monitoring overall project per-
|
formance against a baseline plan. Results from an earned value
analysis may
|
indicate
potential deviation of the project at completion from cost and schedule
|
targets. When a project deviates significantly from the baseline,
updated risk
|
identification and analysis should be performed. Earned value analysis
is
|
described
in Section 10.3.2.4.
|
.
|
4
|
Technical performance measurement.
|
Technical performance measurement com-
|
pares
technical accomplishments during project execution to the project plan’s
|
schedule of
technical achievement. Deviation, such as not demonstrating func-
|
tionality as planned at a milestone, can imply a risk to achieving the
project’s scope.
|
.
|
5
|
Additional risk response planning.
|
If a risk emerges that was not anticipated in the
|
risk response plan, or its impact on objectives is greater than
expected, the
|
planned response may not be adequate. It will be necessary to perform
additional
|
11.6.3 Outputs from Risk
Monitoring and Control
|
.
|
1
|
Workaround plans.
|
Workarounds are unplanned responses to emerging risks that
|
were
previously unidentified or accepted. Workarounds must be properly docu-
|
mented and
incorporated into the project plan and risk response plan.
|
.
|
2
|
Corrective action.
|
Corrective
action consists of performing the contingency plan
|
or
workaround.
|
.
|
3
|
Project change requests.
|
Implementing
contingency plans or workarounds fre-
|
quently
results in a requirement to change the project plan to respond to risks.
|
The result
is issuance of a change request that is managed by integrated change
|
control, as
described in Section 4.3.
|
.
|
4
|
Updates to the risk response plan.
|
Risks may occur or not. Risks that do occur
|
should be documented and evaluated. Implementation of risk controls may
|
reduce the impact or probability of identified risks. Risk rankings
must be
|
reassessed so that new, important risks may be properly controlled.
Risks that do
|
not occur
should be documented and closed in the risk response plan.
|
.
|
5
|
Risk database.
|
A repository that provides for collection, maintenance, and
|
analysis of data gathered and used in the risk management processes.
Use of this
|
database will assist risk management throughout the organization and,
over
|
time, form
the basis of a risk lessons learned program.
|
.
|
6
|
Updates to risk identification checklists.
|
Checklists
updated from experience will
|
0 komentar:
Posting Komentar