Tulisan 1 : Project Risk Management (Versi Inggris)

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.