Advanced Project Management

Project Risk Management

Outline
Project Risk
Risk Management
Why Risk Management
Risk Management Planning
Identifying & Quantifying Risks
Response Planning
Risk Monitoring & Control

2
What is Project Risk?
An event that, if it occurs, causes either a
positive or negative impact on a project
Keys attributes of Risk
◦ Uncertainty
◦ Positive and Negative
◦ Cause and Consequence

3
Risk Management
Risk management is concerned with
identifying risks and drawing up plans to
minimize their effect on a project.
A risk is a probability that some adverse
(or positive) circumstance will occur
◦Project risks affect schedule or resources;
◦Product risks affect the quality or
performance of the software being
developed;

4
 Risk Management Process

Steps
Risk Management Planning
Risk Identification
Qualitative/Quantitative
Risk Analysis
Risk Response Planning
Risk Monitoring & Control

5
 Value From Managing Risks
Opportunity to move from “fire-fighting” to
proactive decision making on the project.
Better chance of project success.
Improved project schedule and cost
performance.
Stakeholders and team members better
understand the nature of the project.
Helps define the strengths and weaknesses of
the project.

6
 Why Not Risk Management?
 With so much benefit to managing risk, why is it often
overlooked?

1. The organization is too busy with real problems to

worry about potential ones,
2. There is a perception that there is not too much
that can go wrong, or
3. They have a fatalistic belief that not much can be
done about risks, or
4. Disclosure of project risks will be seen as an
indication of project weakness.
 Won’t identified risks make the project look
bad?
All projects have risks, denial does not make
them go away, it just makes you unprepared
for them if they occur.
Risk in itself is not bad, it is how well the
project plans for and reacts to risks that
counts.
Formal risk management is a cornerstone of
good project management. Stakeholder
visibility into project risks makes it easier to
get additional resources and organizational
support when risks do occur.
 Risk Management Planning
 Plan for the Planning
◦ Risk planning should be appropriate for the
project
◦ Question you should ask:
1. How risky is the project?
2. Is it a new technology or something your organization
is familiar with?
3. Do you have past projects to reference?
4. What is the visibility of the project?
5. How big is the project?
6. How important is the project?
 The Risk Management Plan
What should it include?
◦ How you will identify, quantify or qualify risk
 Methods and tools
◦ Budget…yes budget
◦ Who is doing what
◦ How often
◦ Risk categories, levels, and thresholds for action.
◦ Reporting requirements
◦ Monitoring, tracking and documenting strategies
 The Risk Management Process
Risk identification
◦ Identify project, product and business risks;
Risk analysis
◦ Assess the likelihood and consequences of these
risks;
Risk response planning
◦ Draw up plans to avoid or minimize the effects of
the risk;
Risk monitoring
◦ Monitor the risks throughout the project
The Risk Management Process

Risk Risk
Risk analysis Risk planning
identification monitoring

Risk avoidance
List of potential Prioritised risk Risk
and contingency
risks list assessment
plans
Identifying Risk

Continuous, Iterative Process

What is it and what does it look like
The sooner the better
A fact is not a risk (it’s an issue).
Be specific
Don’t try to do everything at once
Identification Techniques

Brainstorming
Checklists
Interviewing
SWOT Analysis (strengths, weaknesses opportunities, threats)
Delphi Technique (anonymous consensus building)
Diagramming Techniques
◦ Cause & effect
◦ Flow Charts
◦ Influence Diagrams
Risks and Risk Types
Risk type Possible risks
Technology The database used in the system cannot process as many transactions
per second as expected.
Software components that should be reused contain defects that limit
their functionality.
People It is impossible to recruit staff with the skills required.
Key staff are ill and unavailable at critical times.
Required training for staff is not available.
Organizational The organization is restructured so that different management are
responsible for the project.
Organizational financial problems force reductions in the project budget.
Tools The code generated by CASE tools is inefficient.
CASE tools cannot be integrated.
Requirements Changes to requirements that require major design rework are proposed.
Customers fail to understand the impact of requirements changes.
Estimation The time required to develop the software is underestimated.
The rate of defect repair is underestimated.
The size of the software is underestimated.
Risk Analysis
Assess probability, seriousness, and urgency of
each risk.
Probability may be very low, low, moderate,
high or very high.
Risk effects might be catastrophic, serious,
tolerable or insignificant.
Urgency might be immediate, short term, or
long term.
Analyzing Risk - Qualitative
Subjective
Educated Guess
High, Medium, Low
Red, Yellow, Green
1-10
Prioritized/Ranked list of ALL identified risks
First step in risk analysis!
Risk Analysis - Quantitative
Numerical/StatisticalAnalysis
Determines probability of occurrence
and consequences of risks
Should be focused to highest risks as
determined by Qualitative Risk Analysis
and Risk Threshold.
Risk Analysis (i)
Risk Probability Effects
Organizational financial problems force reductions in Low Catastrophic
the project budget.
It is impossible to recruit staff with the skills required High Catastrophic
for the project.
Key staff are ill at critical times in the project. Moderate Serious
Software components that should be reused contain Moderate Serious
defects which limit their functionality.
Changes to requirements that require major design Moderate Serious
rework are proposed.
The organization is restructured so that different High Serious
management are responsible for the project.

PM Lecture 7 by Dr. Saber Elsayed

 Risk Analysis (ii)
Risk Probability Effects
The database used in the system cannot process as Moderate Serious
many transactions per second as expected.
The time required to develop the software is High Serious
underestimated.
CASE tools cannot be integrated. High Tolerable
Customers fail to understand the impact of Moderate Tolerable
requirements changes.
Required training for staff is not available. Moderate Tolerable
The rate of defect repair is underestimated. Moderate Tolerable
The size of the software is underestimated. High Tolerable
The code generated by CASE tools is inefficient. Moderate Insignificant

PM Lecture 7 by Dr. Saber Elsayed

Probability & Impact Analysis

PM Lecture 7 by Dr. Saber Elsayed

Risk Response Planning
 “What are we going to do about it?”
 Techniques/Strategies:
◦ Avoidance – Eliminate it
◦ Transference – Pawn it off
◦ Mitigation – Reduce probability or impact of it
◦ Acceptance – Do nothing
 Strategy should be commensurate with risk
◦ Hint: Don’t spend more money preventing the risk than the
impact of the risk would be if it occurs 

PM Lecture 7 by Dr. Saber Elsayed

 Risk Management Strategies (i)
Risk Strategy
Organizational Prepare a briefing document for senior management
financial problems showing how the project is making a very important
contribution to the goals of the business.
Recruitment Alert customer of potential difficulties and the
problems possibility of delays, investigate outsourcing work.
Staff illness Reorganize team so that there is more overlap of work
and people therefore understand each other’s jobs.

PM Lecture 7 by Dr. Saber Elsayed

 Risk Management Strategies (ii)
Risk Strategy
Requirements Derive traceability information to assess requirements
changes change impact, and maximise information hiding in the
design.
Organizational Prepare a briefing document for senior management
restructuring showing how the project is making a very important
contribution to the goals of the business.
Database Investigate the possibility of buying a higher-
performance performance database.
Underestimated Investigate outsourcing components, investigate use of
development time a program generator

PM Lecture 7 by Dr. Saber Elsayed

Risk Monitoring
Assess each identified risk regularly to
decide whether or not it is becoming less
or more probable.
Also assess whether the effects of the risk
have changed.
Each key risk should be discussed at
management progress meetings.

PM Lecture 7 by Dr. Saber Elsayed

Risk indicators
Risk type Potential indicators
Technology Late delivery of hardware or support software, many
reported technology problems
People Poor staff morale, poor relationships amongst team
member, job availability
Organizational Organizational gossip, lack of action by senior
management
Tools Reluctance by team members to use tools, complaints
about CASE tools, demands for higher-powered
workstations
Requirements Many requirements change requests, customer
complaints
Estimation Failure to meet agreed schedule, failure to fix reported
defects

PM Lecture 7 by Dr. Saber Elsayed

THANKS