Sabtu, 11 Januari 2014

Chapter 11 Project Risk Management

Edit Posted by with No comments
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-
tify those risks that should be managed aggressively.
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.
Ù±
Reliability and integrity 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
the risk response planning process, described in Section 11.5
.
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
results may become apparent.

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.
This is described in Section 11.3.3.1
.
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
selected
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
be appropriate, given the likely probability of the risk and its consequences.
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
planned
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
mid-course correction needed to mitigate the risk. 
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
response planning to control the risk. 
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
help risk management of future projects. 

0 komentar:

Posting Komentar