Chapter 10:
Project Risk Management
Copyright Course Technology 2001
1
The Importance of Project Risk
Management
• Project risk management is the art and science of
identifying, assigning, and responding to risk
throughout the life of a project and in the best interests
of meeting project objectives
• Risk management is often overlooked on projects, but
it can help improve project success by helping select
good projects, determining project scope, and
developing realistic estimates
• Study by Ibbs and Kwak show how risk management is
neglected, especially on IT projects
• KPMG study found that 55 percent of runaway projects
did no risk management at all
Copyright Course Technology 2001
2
Table 10-1. Project Management Maturity
by Industry Group and Knowledge Area
Copyright Course Technology 2001
3
What is Risk?
• A dictionary definition of risk is “the possibility
of loss or injury”
• Project risk involves understanding potential
problems that might occur on the project and
how they might impede project success
• Risk management is like a form of insurance; it
is an investment
Copyright Course Technology 2001
4
Risk Utility
• Risk utility or risk tolerance is the amount of
satisfaction or pleasure received from a
potential payoff
– Utility rises at a decreasing rate for a person who
is risk-averse
– Those who are risk-seeking have a higher
tolerance for risk and their satisfaction increases
when more payoff is at stake
– The risk neutral approach achieves a balance
between risk and payoff
Copyright Course Technology 2001
5
Figure 10-1. Risk Utility
Function and Risk Preference
Copyright Course Technology 2001
6
What is Project Risk Management?
The goal of project risk management is to minimize potential risks
while maximizing potential opportunities. Major processes include
– Risk management planning: deciding how to approach and plan
the risk management activities for the project
– Risk identification: determining which risks are likely to affect a
project and documenting their characteristics
– Qualitative risk analysis: characterizing and analyzing risks and
prioritizing their effects on project objectives
– Quantitative risk analysis: measuring the probability and
consequences of risks
– Risk response planning: taking steps to enhance opportunities
and reduce threats to meeting project objectives
– Risk monitoring and control: monitoring known risks,
identifying new risks, reducing risks, and evaluating the
effectiveness of risk reduction
Copyright Course Technology 2001
7
Risk Management Planning
• The main output of risk management planning is
a risk management plan
• The project team should review project
documents and understand the organization’s
and the sponsor’s approach to risk
• The level of detail will vary with the needs of
the project
Copyright Course Technology 2001
8
Table 10-2. Questions Addressed
in a Risk Management Plan
Copyright Course Technology 2001
9
Contingency and Fallback Plans,
Contingency Reserves
• Contingency plans are predefined actions that
the project team will take if an identified risk
event occurs
• Fallback plans are developed for risks that have
a high impact on meeting project objectives
• Contingency reserve or allowances are
provisions held by the project sponsor that can
be used to mitigate cost or schedule risk if
changes in scope or quality occur
Copyright Course Technology 2001
10
Common Sources of Risk on
Information Technology Projects
• Several studies show that IT projects share some
common sources of risk
• The Standish Group developed an IT success
potential scoring sheet based on potential risks
• McFarlan developed a risk questionnaire to help
assess risk
• Other broad categories of risk help identify
potential risks
Copyright Course Technology 2001
11
Table 10-3. Information Technology
Success Potential Scoring Sheet
Success Criterion
Points
User Involvement
19
Executive Management support
16
Clear Statement of Requirements
15
Proper Planning
11
Realistic Expectations
10
Smaller Project Milestones
9
Competent Staff
8
Ownership
6
Clear Visions and Objectives
3
Hard-Working, Focused Staff
3
Total
100
Copyright Course Technology 2001
12
Table 10-4. McFarlan’s Risk Questionnaire
1.
2.
3.
4.
What is the project estimate in calendar (elapsed) time?
( ) 12 months or less
Low = 1 point
( ) 13 months to 24 months
Medium = 2 points
( ) Over 24 months
High = 3 points
What is the estimated number of person days for the system?
( ) 12 to 375
Low = 1 point
( ) 375 to 1875
Medium = 2 points
( ) 1875 to 3750
Medium = 3 points
( ) Over 3750
High = 4 points
Number of departments involved (excluding IT)
( ) One
Low = 1 point
( ) Two
Medium = 2 points
( ) Three or more
High = 3 points
Is additional hardware required for the project?
( ) None
Low = 0 points
( ) Central processor type change
Low = 1 point
( ) Peripheral/storage device changes Low = 1
( ) Terminals
Med = 2
( ) Change of platform, for example High = 3
PCs replacing mainframes
Copyright Course Technology 2001
13
Other Categories of Risk
• Market risk: Will the new product be useful to
the organization or marketable to others? Will
users accept and use the product or service?
• Financial risk: Can the organization afford to
undertake the project? Is this project the best
way to use the company’s financial resources?
• Technology risk: Is the project technically
feasible? Could the technology be obsolete
before a useful product can be produced?
Copyright Course Technology 2001
14
What Went Wrong?
Several information technology projects fail because of technology risk.
One project manager documented an important lesson he learned on a
large IT projectfocus on business needs first, not technology. David
Anderson, a project manager for Kaman Sciences Corp., shared his
lessons learned from a project failure in an article for CIO Enterprise
Magazine. After spending two years and several hundred thousand
dollars on a project to provide new client-server based financial and
human resources information systems for their company, Anderson and
his team finally admitted they had a failure on their hands. Anderson
admitted that he was too enamored by using cutting edge technology
and took a high-risk approach on the project. He "ramrodded through"
what the project team was going to do, and he admitted that he was
wrong. The company finally decided to switch to a more stable
technology to meet the business needs of the company.
Hildebrand, Carol. “If At First You Don’t Succeed,” CIO Enterprise Magazine, April 15, 1998
Copyright Course Technology 2001
15
Risk Identification
• Risk identification is the process of
understanding what potential unsatisfactory
outcomes are associated with a particular project
• Several risk identification tools and techniques
include
–
–
–
–
Brainstorming
The Delphi technique
Interviewing
SWOT analysis
Copyright Course Technology 2001
16
Table 10-5. Potential Risk Conditions
Associated With Each Knowledge Area
Knowledge Area
Risk Conditions
Integration
Inadequate planning; poor resource allocation; poor integration
management; lack of post-project review
Scope
Poor definition of scope or work packages; incomplete definition
of quality requirements; inadequate scope control
Time
Errors in estimating time or resource availability; poor allocation
and management of float; early release of competitive products
Cost
Estimating errors; inadequate productivity, cost, change, or
contingency control; poor maintenance, security, purchasing, etc.
Quality
Poor attitude toward quality; substandard
design/materials/workmanship; inadequate quality assurance
program
Human Resources
Poor conflict management; poor project organization and
definition of responsibilities; absence of leadership
Communications
Carelessness in planning or communicating; lack of consultation
with key stakeholders
Risk
Ignoring risk; unclear assignment of risk; poor insurance
management
Procurement
Unenforceable conditions or contract clauses; adversarial relations
Copyright Course Technology 2001
17
Quantitative Risk Analysis
• Assess the likelihood and impact of
identified risks to determine their magnitude
and priority
• Risk quantification tools and techniques
include
– Probability/Impact matrixes
– The Top 10 Risk Item Tracking technique
– Expert judgment
Copyright Course Technology 2001
18
Table 10-6. Sample Probability/Impact
Matrix for Qualitative Risk Assessment
Copyright Course Technology 2001
19
Figure 10-2. Chart Showing High-,
Medium-, and Low-Risk Technologies
Copyright Course Technology 2001
20
Top 10 Risk Item Tracking
• Top 10 Risk Item Tracking is a tool for
maintaining an awareness of risk throughout
the life of a project
• Establish a periodic review of the top 10
project risk items
• List the current ranking, previous ranking,
number of times the risk appears on the list
over a period of time, and a summary of
progress made in resolving the risk item
Copyright Course Technology 2001
21
Table 10-7. Example of Top 10
Risk Item Tracking
Monthly Ranking
Risk Item
This
Last
Month
Month
Number
Risk Resolution
of Months Progress
Inadequate
planning
1
2
4
Working on revising the
entire project plan
Poor definition
of scope
2
3
3
Holding meetings with
project customer and
sponsor to clarify scope
Absence of
leadership
3
1
2
Just assigned a new
project manager to lead
the project after old one
quit
Poor cost
estimates
4
4
3
Revising cost estimates
Poor time
estimates
5
5
3
Revising schedule
estimates
Copyright Course Technology 2001
22
Expert Judgment
• Many organizations rely on the intuitive feelings
and past experience of experts to help identify
potential project risks
• Experts can categorize risks as high, medium, or
low with or without more sophisticated
techniques
Copyright Course Technology 2001
23
Quantitative Risk Analysis
• Often follows qualitative risk analysis, but both
can be done together or separately
• Large, complex project involving leading edge
technologies often require extensive quantitative
risk analysis
• Main techniques include
– Decision tree analysis
– simulation
Copyright Course Technology 2001
24
Decision Trees and Expected
Monetary Value (EMV)
• A decision tree is a diagramming method used
to help you select the best course of action in
situations in which future outcomes are
uncertain
• EMV is a type of decision tree where you
calculate the expected monetary value of a
decision based on its risk event probability and
monetary value
Copyright Course Technology 2001
25
Figure 10-3. Expected Monetary
Value (EMV) Example
Copyright Course Technology 2001
26
Simulation
• Simulation uses a representation or model of a system
to analyze the expected behavior or performance of the
system
• Monte Carlo analysis simulates a model’s outcome
many time to provide a statistical distribution of the
calculated results
• To use a Monte Carlo simulation, you must have three
estimates (most likely, pessimistic, and optimistic) plus
an estimate of the likelihood of the estimate being
between the optimistic and most likely values
Copyright Course Technology 2001
27
What Went Right?
McDonnell Aircraft Company used Monte Carlo simulation to help
quantify risks on several advanced-design engineering projects. The
National Aerospace Plan (NASP) project involved many risks. The
purpose of this multi-billion dollar project was to design and develop
a vehicle that could fly into space using a single-stage-to-orbit
approach. A single-stage-to-orbit approach meant the vehicle would
have to achieve a speed of Mach 25 (25 times the speed of sound)
without a rocket booster. A team of engineers and business
professionals worked together in the mid-1980s to develop a
software model for estimating the time and cost of developing the
NASP. This model was then linked with Monte Carlo simulation
software to determine the sources of cost and schedule risk for the
project. The results of the simulation were then used to determine
how the company would invest its internal research and
development funds. Although the NASP project was terminated, the
resulting research has helped develop more advanced materials and
propulsion systems used on many modern aircraft.
Copyright Course Technology 2001
28
Figure 10-4. Sample Monte Carlo
Simulation Results for Project Schedule
Copyright Course Technology 2001
29
Figure 10-5. Sample Monte Carlo
Simulations Results for Project Costs
Copyright Course Technology 2001
30
Risk Response Planning
• After identifying and quantifying risk, you must decide
how to respond to them
• Four main strategies:
– Risk avoidance: eliminating a specific threat or risk, usually
by eliminating its causes
– Risk acceptance: accepting the consequences should a risk
occur
– Risk transference: shifting the consequence of a risk and
responsibility for its management to a third party
– Risk mitigation: reducing the impact of a risk event by
reducing the probability of its occurrence
Copyright Course Technology 2001
31
Table 10-8. General Risk Mitigation Strategies for
Technical, Cost, and Schedule Risks
Copyright Course Technology 2001
32
Risk Monitoring and Control
• Monitoring risks involves knowing their status
• Controlling risks involves carrying out the risk
management plans as risks occur
• Workarounds are unplanned responses to risk
events that must be done when there are no
contingency plans
• The main outputs of risk monitoring and control
are corrective action, project change requests,
and updates to other plans
Copyright Course Technology 2001
33
Risk Response Control
• Risk response control involves executing the
risk management processes and the risk
management plan to respond to risk events
• Risks must be monitored based on defined
milestones and decisions made regarding risks
and mitigation strategies
• Sometimes workarounds or unplanned
responses to risk events are needed when there
are no contingency plans
Copyright Course Technology 2001
34
Using Software to Assist in
Project Risk Management
• Databases can keep track of risks. Many IT
departments have issue tracking databases
• Spreadsheets can aid in tracking and quantifying
risks
• More sophisticated risk management software,
such as Monte Carlo simulation tools, help in
analyzing project risks
Copyright Course Technology 2001
35
Results of Good Project Risk
Management
• Unlike crisis management, good project risk
management often goes unnoticed
• Well-run projects appear to be almost effortless,
but a lot of work goes into running a project
well
• Project managers should strive to make their
jobs look easy to reflect the results of well-run
projects
Copyright Course Technology 2001
36