Chapter 6:

Project Risk Management

 Learning Objectives
• Understand what risk is and the importance of good project
risk management
• Discuss the elements involved in risk management planning
• List common sources of risks on information technology
projects
• Describe the risk identification process and tools and
techniques to help identify project risks
• Discuss the qualitative risk analysis process and explain
how to calculate risk factors, use probability/impact
matrixes, the Top Ten Risk Item Tracking technique, and
expert judgment to rank risks
 Learning Objectives
• Explain the quantify risk analysis process and how to
use decision trees and simulation to quantitative risks
• Discuss what is involved in change and risk monitoring
and control
• Describe how software can assist in project risk
management
• Explain the results of good project risk management
• Explain what change management refers to
 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
• A number of studies show how risk management is
neglected, especially on IT projects
• One study found that 55 percent of runaway projects
did no risk management at all
Project Management Maturity by Industry
Group and Knowledge Area
 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
 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
Risk Utility Function and Risk
Preference
 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
 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
Questions Addressed in a Risk
Management Plan
 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 reserves 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
 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
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
 McFarlan’s Risk Questionnaire
1. 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
2. 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
3. Number of departments involved (excluding IT)
( ) One Low = 1 point
( ) Two Medium = 2 points
( ) Three or more High = 3 points
4. 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
 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?
 What Went Wrong?
Many information technology projects fail because of technology risk. One
project manager learned an important lesson on a large IT project: focus on
business needs first, not technology. David Anderson, a project manager for
Kaman Sciences Corp., shared his experience 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 revealed that he had been too enamored of the use of cutting-edge
technology and had taken a high-risk approach on the project. He "ramrodded
through" what the project team was going to do and then 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
 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
 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
 Qualitative 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
Sample Probability/Impact Matrix
Sample Probability/Impact Matrix for
Qualitative Risk Assessment
Chart Showing High-, Medium-, and
Low-Risk Technologies
 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
 Example of Top 10 Risk Item
Tracking
Monthly Ranking
Risk Item This Last Number Risk Resolution
Month Month of Months Progress

Inadequate 1 2 4 Working on revising the

planning entire project plan
Poor definition 2 3 3 Holding meetings with
of scope project customer and
sponsor to clarify scope
Absence of 3 1 2 Just assigned a new
leadership project manager to lead
the project after old one
quit
Poor cost 4 4 3 Revising cost estimates
estimates
Poor time 5 5 3 Revising schedule
estimates estimates
 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
 Quantitative Risk Analysis

• Often follows qualitative risk analysis, but both

can be done together or separately
• Large, complex projects involving leading edge
technologies often require extensive quantitative
risk analysis
• Main techniques include
– decision tree analysis
– simulation
 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
Figure 11-4. Expected Monetary
Value (EMV) Example
 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 times 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
 What Went Right?
A large aerospace 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
multibillion-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.
 Risk Response Planning
• After identifying and quantifying risks, 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
General Risk Mitigation Strategies for
Technical, Cost, and Schedule Risks
 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
 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
 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
 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
Change Management
 What is Project
Change Management?
Project change management encompasses all of the processes necessary to
determine where you are at compared to where you planned to be and the
activities required to get back on track if those are not aligned
 Why is Project Change
Management Important?

• Projects seldom run exactly according to plan. Project deliverables must be

maintained by carefully and continuously managing changes, either by
rejecting changes or by approving changes so those approved changes are
incorporated into a revised baseline

• Enables the project team to identify potential problems in a timely manner

and take corrective action, when necessary, to control the execution of the
project

• Ensures the project team and stakeholders have an accurate understanding of

what has been completed in the project to-date and what will be delivered in
total
 Actual vs Planned

Determining where you are vs. where you planned to be:

Requires project details be documented and approved
• Documented scope, cost, time, quality, people, other (eg. Charter)
• Documented details of product / service functionality (eg. Requirements
Document)

Requires processes and tools to assess performance to determine whether

any corrective or preventative actions are indicated, and then recommending
those actions as necessary
• Scope and requirements verification throughout the project
• Budget tracking and forecasting
• Task duration tracking
• Overall project timeline tracking & verification
 Getting Back on Track

How can we get on track again?

– Identify that a change needs to occur or has occurred
– Document the complete impact of requested changes
– Follow approved processes for documenting and approving requested changes
– Maintain the integrity of baselines by releasing only approved changes for
incorporation into project products or services, and maintaining their related
configuration and planning documentation
– Control and update the scope, cost, budget, schedule and quality requirements based
upon approved changes, by coordinating changes across the entire project
– Influence the factors that circumvent integrated change control so that only approved
changes are implemented
 Recall

Project Change Management - a general term describing the procedures used to

ensure that changes are introduced in a controlled and coordinated manner.

Change Request – Requests to expand or reduce the project scope, modify

policies, processes, plans or procedures, modify costs or budgets, or revise
schedules.

Change Order – Used in some companies to identify approved change requests

(change request when the request is made and change order once it has been
approved)
NOTHING IS PERMANENT IN
THIS WORLD BUT
“change”
Some important connections

And over all Remarks

 PM Knowledge Areas
& Process Groups
PM Process Initiating Process Planning Process Group Executing Process Monitoring & Controlling Closing
Groups / Group Group Process Group Process
Knowledge Area Group
Processes

Project Develop Project Charter Develop Project Management Direct and Manage Monitor and Control Project Close Project
Management Develop Prelim Project Plan Project Execution Work
Integration Scope Statement Integrated Change Control

Project Scope Scope Planning Scope Verification

Management Scope Definition Scope Control
Create WBS

Project Time Activity Definition & Sequencing Schedule Control

Management Resource Estimating
Duration Estimating
Schedule Development

Project Cost Cost Estimating Cost Control

Management Cost Budgeting

Project Quality Quality Planning Perform Quality Assurance Perform Quality Control
Management

Project HR Human Resources Planning Acquire Project Team Manage Project Team
Management Develop Project Team

Project Communications Planning Information Distribution Performance Reporting

Communications Manage Stakeholders
Management

Project Risk Risk Management Planning Risk Monitoring and Control

Management Risk Identification
Qualitative / Quantitative Risk
Analysis
Risk Response Planning

Project Plan Purchases and Acquisitions Request Seller Responses Contract Administration Contract
Procurement Plan Contracting Select Sellers Closure
Management