PROJECT RISK MANAGEMENT
What is Risk?
Tolerance of Risk
Categories of Risk
Risk Assessment (identification and analysis)
In the early days of project management on many commercial
programs, the majority of project
decisions heavily favored cost and schedule. This favoritism
occurred because we knew more about cost
and scheduling than we did about technical risks. Technology
forecasting was very rarely performed
other than by extrapolating past technical knowledge into the
Today, the state of the art of technology forecasting is being
pushed to the limits. For projects with time
duration of less than one year, we normally assume that the
environment is known and stable,
particularly the technological environment. For projects over a
year or so in length, technology
forecasting must be considered. Computer technology doubles in
performance about every two years.
Engineering technology is said to double every three or so
years. How can a project manager accurately
define and plan the scope of a three- or four-year project
without expecting engineering changes
resulting from technology improvements?
44.1 What are the Risks?
A Midwest manufacturing company embarked on an eight-year
project to design the manufacturing
factory of the future. The plant is scheduled to go into the
construction phase in the year 2000. How do
we design the factory of the future without forecasting the
technology? What computer technology will
exist? What types of materials will exist and what types of
components will our customers require?
What production rate will we need and will technology exist to
support this production level?
Economists and financial institutions forecast interest rates.
The forecasts appear in public newspapers
and journals. Yet, every company involved in high tech does some
form of technology forecasting, but
appears very reluctant to publish the data. Technology
forecasting is regarded as company proprietary
information and may be part of the company's strategic planning
We read in the newspaper about cost overruns and schedule slips
on a wide variety of large-scale
development projects. Several issues within the control of the
buyer, seller, or major stakeholders can
lead to cost growth and schedule slippage on development
projects. These causes include, but are not
• Starting a project with a budget and/or schedule that is
inadequate for the desired level of
performance or scope (e.g., integration complexity).
• Having an overall development process (or key parts of that
process) that favors performance
(or scope) over cost and schedule.
• Establishing a design that is near the feasible limit of
achievable performance or integration
complexity at a given point in time.
• Making major project design decisions before the relationships
between cost, performance,
schedule, and risk are understood.
These four causes will contribute to uncertainty in forecasting
technology and the associated design
needed to meet performance requirements. And the inability to
perfectly forecast technology and the
associated design will contribute to a project's technical risk,
and can also lead to cost and schedule risk.
Today, the competition for technical achievement has become
fierce. Companies have gone through
life-cycle phases of centralizing all activities, especially
management functions, but are decentralizing
technical expertise. By the mid 1980s, many companies recognized
the need to integrate technical risks
with cost and schedule risks, and other activities (e.g.,
quality). Risk management processes were
developed and implemented where risk information was made
available to key decision-makers.
The risk management process, however, should be designed to do
more than just identify the risk.
The process must also include: a formal
to quantify the likelihood and predict
the impact on the project, a
strategy for selected risks, and the
ability to monitor
in reducing these selected risks to the desired level.
A project, by definition, is something that we have not done
previously and will not do again in the
future. Because of this uniqueness, we have developed a ''live
with it" attitude on risk and attribute it as
part of doing business. If risk management is set up as a
continuous, disciplined process of planning,
assessment (identification and analysis), handling, and
monitoring, then the system will easily
supplement other systems as organization, planning and
budgeting, and cost control. Surprises that
become problems will be diminished because emphasis will now be
on proactive rather than reactive
Risk management can be justified on almost all projects. The
level of implementation can vary from
project to project, depending on such factors as size, type of
project, who the customer is, relationship to
the corporate strategic plan, and corporate culture. Risk
management is particularly important when the
overall stakes are high and a great deal of uncertainty exists.
In the past, we treated risk as a "let's live
with it." Today, risk management is a key part of overall
project management. It forces us to focus on
the future where uncertainty exists and develop suitable plans
of action to prevent potential issues from
adversely impacting the project.
Risk is a measure of the probability and consequence of not
achieving a defined project goal. Most
people agree that risk involves the notion of uncertainty. Can
the specified aircraft range be achieved?
Can the computer be produced within budgeted cost? Can the new
product launch date be met? A
probability measure can be used for such questions; for example,
the probability of not meeting the new
product launch date is 0.15. However, when risk is considered,
the consequences or damage associated
with occurrence must also be considered.
Goal A, with a probability of occurrence of only 0.05, may
present a much more serious (risky) situation
than goal B, with a probability of occurrence of 0.20, if the
consequences of not meeting goal A are, in
this case, more than four times more severe than failure to meet
goal B. Risk is not always easy to
assess, since the probability of occurrence and the consequence
of occurrence are usually not directly
measurable parameters and must be estimated by statistical or
44.2 Components of Risk
Risk has two primary components for a given event:
• A probability of occurrence of that event
• Impact of the event occurring (amount at stake)
Overall risk is a function of its components.
Figure 44.1 shows the components of risk.
Conceptually, risk for each event can be defined as a function
of likelihood and impact; that is,
In general, as either the likelihood or impact increases, so
does the risk. Both the likelihood and impact
must be considered in risk management.
Risk constitutes a lack of knowledge of future events.
Typically, future events (or outcomes) that are
favorable are called opportunities, whereas unfavorable events
are called risks.
Another element of risk is the cause of risk. Something, or the
lack of something, can induce a risky
situation. We denote this source of danger as the hazard.
Certain hazards can be overcome to a great
extent by knowing them and taking action to overcome them. For
example, a large hole in a road is a
much greater danger to a driver who is unaware of it than to one
who travels the road frequently and
knows enough to slow down and go around the hole. This leads to
the second representation of risk:
Risk increases with hazard but decreases with safeguard. The
implication of this equation is that good
project management should be structured to identify hazards and
to allow safeguards to be developed to
overcome them. If enough safeguards are available, then the risk
can be reduced to an acceptable level.
44.3 Tolerance of Risk
There is no single answer on how to manage risk. The
project manager must rely upon sound
judgment and the use of the appropriate tools in dealing with
risk. The ultimate decision on how to deal
with risk is based in part upon the project manager's tolerance
The three commonly used classifications of tolerance for risk
appear in Figure 44.2. They include the
risk averter or avoider, the neutral risk taker, and the risk
seeker or lover. The Y
axis in Figure 44.2
represents "utility," which can be defined as the amount of
satisfaction or pleasure that the individual
receives from a payoff. (This is also called the project
manager's tolerance for risk.) The
X axis in this
case is the amount of money at stake.
Figure 44.2: Risk preference & utility function
With the risk averter, utility rises at a
rate. In other words, when more money is
at stake, the
project manager's satisfaction or tolerance diminishes. With the
risk lover, the project manager's
satisfaction increases when more money is at stake (i.e., an
increasing slope to the curve). A risk averter
prefers a more certain outcome and will demand a premium to
A risk lover prefers the more uncertain outcome and may be
willing to pay a penalty to take a risk.
44.4 Risk Management
Risk management is the act or practice of dealing with risk. It
analyzing) risk issues,
developing risk handling
determine how risks have changed.
Risk management is not a separate project office activity
assigned to a risk management department, but
rather is one aspect of sound project management. Risk
management should be closely coupled with key
project processes, including but not limited to: overall project
management, systems engineering, cost,
scope, quality, and schedule.
Proper risk management is proactive rather than reactive. As an
example, an activity in a
network requires that a new technology be developed. The
schedule indicates six months for
this activity, but project engineers think that nine months is
closer to the truth. If the project
manager is proactive, he might develop a Risk Handling Plan
If the project manager
is reactive (e.g., a "problem solver"), then he will do nothing
until the problem actually occurs.
At that time the project manager must react rapidly to the
crisis, and may have lost valuable
time when contingencies could have been developed. Hence, proper
risk management will
attempt to reduce the likelihood of an event occurring and/or
the magnitude of its impact.
44.5 Categories of Risk
The Project Management Institute
Government regulations, natural hazards,
and acts of God
Cost of money, borrowing rates, raw
The external risks are outside of the project manager's control
but may affect the direction of the project.
Labor stoppages, cash flow problems,
safety issues, health and benefit plans.
The internal risks may be within the control of the project
manager and present uncertainty that may
affect the project.
Changes in technology, changes in state
of the art, design issues, operations/maintenance
issues. Technical risks relate to the utilization of technology
and the impact it has on the direction of the
Licenses, patent rights, lawsuits, subcontractor performance, contractual
To identify risk issues, evaluators should break down program
elements to a level where they can
perform valid assessments. The information necessary to do this
varies according to the phase of the
program. During the early phases, requirement and scope
documents, and acquisition plans may be the
only program-specific data available. They should be evaluated
to identify issues that may have adverse
Another method of decomposition is to create a Work Breakdown
Structure (WBS) as early as possible
in a program, and use this in a structured approach to evaluate
candidate risk categories against
candidate system or lower level designs. To use this approach,
each element at level three of the WBS is
further broken down to the fourth or fifth level and is
subjected to a risk analysis. Items at system,
segment or group, or subsystem levels, as well as management
items, are assessed using attributes such
as maturity and complexity of hardware and software items or the
dependency of the item on existing
systems, facilities, or contractors to evaluate their risk
Another approach is to evaluate risk associated with some key
processes (e.g., design and
manufacturing) that will exist on a project. Information on this
approach is contained in the government
DoD directive 4245.7-M, which provides a standard structure for
identifying technical risk areas in the
transition from development to production. The structure is
geared toward programs that are mid-to-late
in the development phase but, with modifications, could be used
for other projects. The directive
template for each major
technical activity. Each template identifies potential areas of risk.
Overlaying each template on a project allows identification of
mismatched areas, which are then
identified as "at risk." Having used all applicable templates,
the program manager will have created a
"watch list" of production transition risk areas and can
prioritize control actions— many of which will
be the responsibility of systems engineering. DoD Directive
4245.7-M describes technical methods for
reducing the risk in each identified area.
High-risk areas may reflect missing capabilities in the project
manager's organization or in supporting
organizations. They may also reflect technical difficulties in
the design or development process. In
either case, "management" of risk involves using project
management assets to reduce the identified
The value in each of these approaches to risk identification
lies in the methodical nature of the approach,
which forces disciplined, consistent treatment of risk. However,
using any method in a "cookbook"
manner may cause unique risk aspects of the project to be
overlooked. Before acting on the outcome of
any assessment, the project manager must review the strengths
and weaknesses of the approach and
identify other factors that may introduce technical, schedule,
cost, program, or other risks.
Certainty, Risk, and Uncertainty
Decision-making falls into three categories: certainty, risk,
and uncertainty. Decision-making under
certainty is the easiest case to work with. With certainty, we
assume that all of the necessary
information is available to assist us in making the right
decision, and we can predict the outcome with a
high level of confidence.
Decision-Making under Certainty
Decision-making under certainty implies that we know with 100
percent accuracy what the states of
nature will be and what the expected payoffs will be for each
state of nature. Mathematically, this can be
shown with payoff tables.
To construct a payoff matrix, we must identify (or select) the
states of nature over which we
then select our own action to be taken for each of the states of nature. Our
actions are called
strategies. The elements in the payoff table are the outcomes
for each strategy.
A payoff matrix based on decision-making under certainty has two
• Regardless of which state of nature exists, there will be one
dominant strategy that will produce
larger gains or smaller losses than any other strategy for all
the states of nature.
• There are no probabilities assigned to each state of nature.
Decision-Making under Risk
In most cases, there usually does not exist one dominant
strategy for all states of nature. In a realistic
situation, higher profits are usually accompanied by higher
risks and therefore higher probable losses.
When there does not exist a dominant strategy, a probability
must be assigned to the occurrence of each
state of nature.
Risk can be viewed as outcomes (i.e., states of nature) that can
be described within established
confidence limits (i.e., probability distributions). These
probability distributions are obtained from welldefined
Decision-making under Uncertainty
The difference between risk and uncertainty is that under risk
there are assigned probabilities, and under
uncertainty meaningful assignments of probabilities are not
possible. As with decision making under
risk, uncertainty also implies that there may exist no single
dominant strategy. The decision-maker,
however, does have at his disposal four basic criteria from
which to make a management decision. The
decision about which criterion to use will depend on the type of
project as well as the project manager's
tolerance to risk.
Risk Management Process
It is important that a risk management strategy is established
early in a project and that risk is
continually addressed throughout the project life cycle. Risk
management includes several related
actions involving risk: planning, assessment (identification and
analysis), handling, and monitoring:
planning: This is the
process of developing and documenting an organized, comprehensive, and
interactive strategy and methods for identifying and tracking
risk issues, developing risk handling plans,
performing continuous risk assessments to determine how risks
have changed, and assigning adequate
• Risk assessment:
This process involves identifying and
analyzing program areas and critical technical
process risks to increase the likelihood of meeting cost,
performance, and schedule objectives.
is the process of examining the program
areas and each critical technical process to
identify and document the associated risk.
is the process of examining each
issue or process to refine the description of the risk, isolate
the cause, and determine the effects.
• Risk handling:
This is the process that identifies,
evaluates, selects, and implements options in order
to set risk at acceptable levels given program constraints and
objectives. This includes the specifics on
what should be done, when it should be accomplished, who is
responsible, and associated cost and
schedule. Risk handling options include assumption, avoidance,
control (also known as mitigation), and
transfer. The most desirable handling option is selected, and a
specific approach is then developed for
• Risk monitoring:
This is the process that systematically
tracks and evaluates the performance of risk
handling actions against established metrics throughout the
acquisition process and provides inputs to
updating risk handling strategies, as appropriate.
44.6 Risk Planning
Risk planning is the detailed formulation of a program of action
for the management of risk. It is the
• Develop and document an organized, comprehensive, and
interactive risk management strategy.
• Determine the methods to be used to execute a program's risk
• Plan for adequate resources.
Risk planning is iterative and includes the entire risk
management process, with activities to assess
(identify and analyze), handle, monitor (and document) the risk
associated with a program. The result is
often the risk management plan (RMP).
Planning begins by developing and documenting a risk management
strategy. Early efforts establish the
purpose and objective, assign responsibilities for specific
areas, identify additional technical expertise
needed, describe the assessment process and areas to consider,
define a risk rating approach, delineate
procedures for consideration of handling options, establish
monitoring metrics (where possible), and
define the reporting, documentation, and communication needs.
The RMP is the roadmap that tells the project team how to get
from where the program is today to
where the program manager wants it to be in the future. The key
to writing a good RMP is to provide
the necessary information so the program team knows the
objectives, goals, and the risk management
process. Since it is a roadmap, it may be specific in some
areas, such as the assignment of
responsibilities for project personnel and definitions, and
general in other areas to allow users to choose
the most efficient way to proceed. For example, a description of
techniques that suggests several
methods for evaluators to use to assess risk is appropriate,
since every technique has advantages and
disadvantages depending on the situation.
44.7 Risk Assessment
Risk assessment is the
stage of risk management, the stage that
and quantifies program issues in terms of probability and
consequences, and possibly other
considerations (e.g., the time to impact). The results are a key
input to many subsequent risk
management actions. It is often a difficult and time-consuming
part of the risk management process.
There are no quick answers or shortcuts. Tools are available to
assist evaluators in assessing risk, but
none are totally suitable for any program and are often highly
misleading if the user does not understand
how to apply them or interpret the results. Despite its
complexity, risk assessment is one of the most
important phases of the risk management process because the
caliber and quality of assessments can
have a large impact on program outcomes.
The components of assessment— identification and analysis— are
performed sequentially with
identification being the first step.
Risk identification begins by compiling the program's risk
issues. Project issues should be examined and
identified by reducing them to a level of detail that permits an
evaluator to understand the significance
of any risk and its causes (e.g., risk issues). This is a
practical way of addressing the large and diverse
number of potential risks that often occur in moderate- to
For example, a WBS level 4 or 5 element may be made up of
several risk issues associated with a
specification or function.
Risk analysis is a technical and systematic process to examine
identified risks, isolate causes, determine
the relationship to other risks, and express the impact in terms
of probability and consequence of
44.8 Risk Identification
The second step in risk management is to identify all potential
risk issues. This may include a survey of
the program, customer, and users for concerns and problems.
Some degree of risk always exists in project, technical, test,
logistics, production, and engineering areas.
Project risks include cost, funding, schedule, contract
relationships, and political risks. (Cost and
schedule risks are often so fundamental to a project that they
may be treated as stand-alone risk
categories.) Technical risks, such as related to engineering and
technology, may involve the risk of
meeting a performance requirement, but may also involve risks in
the feasibility of a design concept or
the risks associated with using state-of-the-art equipment or
software. Production risk includes concerns
over packaging, manufacturing, lead times, and material
availability. Support risks include
maintainability, operability, and trainability concerns. The
understanding of risks in these and other
areas evolves over time.
Consequently, risk identification must continue through all
The methods for identifying risk are numerous. Common practice
is to classify project risk according to
its source. Most sources are either objective or subjective.
Recorded experience from past projects
and the current project as it proceeds
• Lessons learned files
• Program documentation evaluations
• Current performance data
Experiences based upon knowledgeable
• Interviews and other data from subject matter experts
Risks can also be identified according to life-cycle phases, as
shown in Figure 44.3. In the early lifecycle
phases, the total project risk is high because of lack of
information. In the later life-cycle phases,
the financial risk is the greatest.
Life-cycle risk analysis
Any source of information that allows recognition of a potential
problem can be used for risk
identification. These include:
- Systems engineering documentation
- Life-cycle cost analysis
- Plan/WBS decomposition
- Schedule analysis
- Baseline cost estimates
- Requirements documents
- Lessons learned files
- Assumption analysis
- Trade studies/analyses
- Technical performance measurement (TPM) planning/analysis
- Models (influence diagrams)
- Decision drivers
- Expert judgment
Expert judgment techniques are applicable not only for risk
identification, but also for forecasting and
decision-making. Two expert judgment techniques are the Delphi
method and the nominal group
technique. The Delphi method has the following general steps:
Step 1: A
panel of experts is selected from both inside and outside the organization. The
not interact on a face-to-face basis and may not even know who
else sits on the panel.
Each expert is asked to make an anonymous prediction on a particular subject.
Each expert receives a composite feedback of the entire panel's answers and is
make new predictions based upon the feedback. The process is
then repeated as necessary.
Closely related to the Delphi method is the nominal group
technique, which allows for face-to-face
contact and direct communication. The steps in the nominal group
technique are as follows:
Step 1: A
panel is convened and asked to generate ideas in writing.
The ideas are listed on a board or a flip chart. Each idea is discussed among
Each panelist prioritizes the ideas, which are then ranked mathematically. Steps
2 and 3 may
be repeated as necessary.
Expert judgment techniques have the potential for bias in risk
identification and analysis. Factors
affecting the bias include:
- Overconfidence in one's ability
- Insensitivity to the problem or risk
- Proximity to project
- Recent event recall
- Availability of time
- Relationship with other experts
- There exist numerous ways to classify risks. In a simple
business context, risk can be defined as:
- Business risk
- Insurable risk
Business risks provide us with opportunities of profit and loss.
Examples of business risk would be
competitor activities, bad weather, inflation, recession,
customer response, and availability of resources.
Insurable risks provide us with only a chance for a loss.
Insurable risks include such elements as:
Direct property damage:
This includes insurance for assets such
as fire insurance, collision insurance,
and insurance for project materials, equipment, and properties.
Indirect consequential loss:
This includes protection for contractors
for indirect losses due to third
party actions, such as equipment replacement and debris removal.
This is protection for legal liability
resulting from poor product design, design errors,
product liability, and project performance failure. This does
not include protection from loss of
This provides protection resulting from
employee bodily injury (worker's compensation),
loss of key employees, replacement cost of key employees, and
several other types of business losses
due to employee actions.
On construction projects, the owner/customer usually provides
''wrap-up" or "bundle" insurance, which
bundles the owner, contractor, and subcontractors into one
insurable package. The contractor may be
given the responsibility to provide the bundled package, but it
is still paid for by the owner/customer.
44.9 Risk Handling
Risk handling includes specific methods and techniques to deal
with known risks, identifies who is
responsible for the risk issue, and provides an estimate of the
cost and schedule associated with reducing
the risk, if any. It involves planning and execution with the
objective of reducing risks to an acceptable
level. The evaluators who assess risk should begin the process
by identifying risks and developing
handling options and approaches to propose to the program
manager, who selects the appropriate one(s)
for implementation. There are several factors that can influence
our response to a risk, including but not
• Amount and quality of information on the actual hazards that
caused the risk (descriptive
- Amount and quality of information on the magnitude of the
damage (measurement uncertainty)
- Amount and quality of information on probability of occurrence
- Personal benefit to project manager for accepting the risk
- Risk forced upon project manager (involuntary risk)
- Confusion and avoidability of the risk
- The existence of cost-effective alternatives (equitable risks)
- The existence of high-cost alternatives or possibly lack of
options (inequitable risks)
- Length of exposure to the risk
Risk handling must be compatible with the RMP and any additional
guidance the program manager
provides. A critical part of risk handling involves refining and
selecting the most appropriate handling
option(s) and specific approach (es) for selected risk issues
(often those with medium or higher risk
Personnel who evaluate candidate risk handling options may use
the following criteria as starting points
• Can the option be feasibly implemented and still meet the
• What is the expected effectiveness of the handling option in
reducing program risk to an
• Is the option affordable in terms of dollars and other
resources (e.g., use of critical materials,
and test facilities)?
• Is time available to develop and implement the option, and
what effect does that have on the
overall program schedule?
• What effect does the option have on the system's technical
Risk handling options include: risk assumption, risk avoidance,
risk control, and risk transfer.
Although the control option (often called mitigation) is
commonly used in many high technology
programs, it should not automatically be chosen. All four
options should be evaluated, and the best one
chosen for each risk issue.
The options for handling risk fall into the following
Risk assumption (i.e., retention):
The project manager says, ''I know the
risk exists and am aware of the
possible consequences. I am willing to wait and see what
happens. I accept the risk and its impact
should it occur."
The project manager says, "I will not
accept this option because of the potentially
Risk control (i.e., prevention or mitigation):
The project manager says, "I will take
measures required to control this risk by continuously
reevaluating it and developing contingency plans
or fall-back positions. I will do what is expected."
The project manager says, "I will share
this risk with others through insurance or a
warranty, or transfer the entire risk to them. Perhaps I can
convert the risk into an opportunity."