| 
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