4. What is Risk?
• Risk is the possibility of suffering loss
• Risk is a measure of the probability and
consequence of not achieving a defined
project goal.
• Possible – but not certain, so it is
expressed as probability
• Risks change though out the life of a
project
• Loss - is any unwanted consequence that
might occur 4
5. Risk in Projects
• In a development project, the loss
describes the impact to the project which
could be in the form of diminished quality
of the end product, increased costs,
delayed completion, or failure.
5
6. 6
Possible Risks in a Project
• Creeping user requirements
• Excessive schedule pressure
• Low quality
• Cost overruns
• Poor estimates
• Low customer satisfaction
• Long schedules
7. Project Risk
Project Risk
Scope
Integration
Communication
Human Resources
Cost
Procurement
Quality
Time
8. The Importance of Project Risk Management
• Project risk management is the art and science of
identifying, analyzing, and responding to risk throughout the
life of a project and in the best interests of meeting project
objectives
• Risk management is often overlooked in projects, but it can
help improve project success by helping select good
projects, determining project scope, and developing realistic
estimates
• Unfortunately, crisis management has higher visibility due to
the obvious danger to the success of the project but it’s risk
management that helps a project have fewer problems to
begin with.
8
10. Risk Can Be Positive
• Positive risks are risks that result in good
things happening; sometimes called
opportunities
• A general definition of project risk is an
uncertainty that can have a negative or
positive effect on meeting project objectives
• The goal of project risk management is to
minimize potential negative risks while
maximizing potential1 0positive risks
11. 11
Risk Management
• Risk management is the act or practice of
dealing with risk.
• Risk management is proactive rather than
reactive.
• Risk management is not a separate
activity but rather on aspect of sound
project management.
12. Elements of Risk Management
• Effective Risk Management is made up of:
– Risk Assessment: identify, analyze, prioritize
– Risk Control: planning, resolution, monitoring
RISK
ASSESSMENT
12
RISK
MANAGEMENT
RISK
CONTROL
IDENTIFICATION
ANALYSIS
PRIORITIZATION
PLANNING
RESOLUION
MONITORING
13. 13
Common Mistakes in Risk
Management
• Not understanding the benefits of Risk
Management
• Not providing adequate time or resources
for Risk Management
• Not identifying and assessing risk using a
standardized approach
14. Project Risk Management
Processes
• 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
the characteristics of each
• Qualitative risk analysis: prioritizing risks
based on their probability and impact of
occurrence 14
15. Project Risk Management Processes
• Quantitative risk analysis: numerically estimating
the effects of risks on project objectives
• Risk response planning: taking steps to enhance
opportunities and reduce threats to meeting project
objectives
• Risk monitoring and control: monitoring
identified and residual risks, identifying new risks,
carrying out risk response plans, and evaluating
the effectiveness of risk strategies throughout the
life of the project
15
17. Risk Management
• Four Main Steps
Risk
Identification
Risk
Risk Response
Development
Assessment
Risk Response
Control
• Before these activities?
Plan Risk Management Process
17
18. Risk Identification
• The possible risk is determined by a number of
interrelated factors such as:
– Nature of the Project
– Aggressive or Conservative Schedule/Budget
– Skills and motivation of the Project Team
18
19. 19
Risk Identification
• The need to proactively identify risks.
– When an event happens it is too late to plan.
• Tools for identifying risk
– Brainstorming
– Nominal Group Technique
• Each member identifies their ideas
• Each member writes an idea on the board until all
ideas are listed
20. 20
Risk Identification
• The group discusses each idea
• Each individual ranks each of the ideas
• The group then ranks all the ideas
• Each individual ranks all the ideas again
• Rankings are summarized
– Delphi technique
• Experts asked individually to provide input
• Input summarized and distributed
• Experts rank input
21. 21
Risk Identification
– Strength, Weakness, Opportunities, Threats
– Cause and effect diagrams
– Past Projects
22. Likelihood
• What is the likelihood of risk?
– Expressed as a Probability (Percentage)
– Example – There is a 5% chance of a programmer
breaking their big toe whilst coding in any 6 month
period
22
23. Impact
• What impact will it have on the project?
– Example – A broken toe on average results in the loss of 20
working days for a programmer
– Expected Value of Loss/Profit
• Expected Value = Loss/Profit x Likelihood
• -20 x 0.05 = -1
• So we will lose 1 day of coding per programmer on a 6 month
project
23
24. Urgency
• How urgently do we need to deal with it?
– Immediate remedy or Can it wait?
– Additional means of prioritising action
24
25. Example Risk Assessment
Team Conflict and Injuries
Description: Teammates in the group might have conflicts with one another
throughout the semester. Injuries might result from conflict, accidents,
and other mishaps throughout the semester.
How to
Avoid It:
If any of the teammates show signs of conflict against one another, we
need to mediate between them in order to make our team working
smoothly and such throughout the whole semester. Thus that will reduce
a factor for injury. However, for the other factors of injury, we need to
make sure that we take good care of ourselves such that no harm will
befall upon us (such as carpal tunnel syndrome, leg breaking, finger
breaking, etc).
What It Will
Affect:
If there is a large enough conflict, we might lose some teammates.
Same with for injuries, if the injury is bad enough to cause teammates to
not be able to work on the project.
Possible
Likelihood:
3/100 chance
The Real World Lab: http://www.cc.gatech.edu/classes/RWL/Web/
25
26. Quantifying Risk
• Programmer has 5% chance of breaking toe in
any 6 month period
– Broken toe results in the loss of 20 programmer days
– Cost of a programmer-day = £500
• Expected Loss per year due to broken toes
– 2 x (0.05 x -20) = -2 days
– Expected loss = -£1000
26
27. Techniques
• Risk Map/Probability Impact Matrix
• Hazard Control Matrix
• Payoff Matrix
• Decision Tree
27
28. Risk Map
Likelihood of Occurrence
High Medium Low
Large
Medium
Scale of impact
Small
28
30. Risk Map
Likelihood of Occurrence
High Medium Low
Large
Medium
Scale of impact
Small
A B
C
D
30
31. Risk Map
• List the risks in
order of priority
• What else can we
use to help
prioritise?
Likelihood of Occurrence
High Medium Low
Large
Medium
Scale of impact
Small
A B
C
D
31
32. Hazard Control Matrix
From Curtis, G (1998) "Business Information Systems" Addison Wesley
Errors
and
omissions
Lost data
and
documents
Computer
Failure
Unauthorized
Access
Fire Fraud
Input
controls
Processing
controls
Output
controls
Storage
controls
Operating
system
controls
Records
management
Accounting
controls
Contingency
plan
Physical
security
32
33. Hazard Control Matrix
From Curtis, G (1998) "Business Information Systems" Addison Wesley
Errors
and
omissions
Lost data
and
documents
Computer
Failure
Unauthorized
Access
Fire Fraud
Input
controls
Processing
controls
Output
controls
Storage
controls
Operating
system
controls
Records
management
Accounting
controls
Contingency
plan
Physical
security
33
34. Hazard Control Matrix
From Curtis, G (1998) "Business Information Systems" Addison Wesley
Errors
and
omissions
Lost data
and
documents
Computer
Failure
Unauthorized
Access
Fire Fraud
Input
controls
Processing
controls
Output
controls
Storage
controls
Operating
system
controls
Records
management
Accounting
controls
Contingency
plan
Physical
security
34
35. Hazard Control Matrix
From Curtis, G (1998) "Business Information Systems" Addison Wesley
Errors
and
omissions
Lost data
and
documents
Computer
Failure
Unauthorized
Access
Fire Fraud
Input
controls
Processing
controls
Output
controls
Storage
controls
Operating
system
controls
Records
management
Accounting
controls
Contingency
plan
Physical
security
35
36. Identification and Assessment
• Problems
– Not a particularly interesting task
– Needs experience to do well
• Are these good reasons to not do it?
36
37. Risk Response Development
• How are we going to deal with risks when they
occur?
– What about those we weren’t expecting?
37
38. 38
Risk Response Planning
• Who is going to detect when the risk
occurs?
• Who has the responsibility to respond and
communicate?
• What is the response?
39. Risk Response Planning
• After identifying and quantifying risks, you
must decide how to respond to them
• Four main response strategies for negative
risks:
– Risk avoidance
– Risk acceptance
– Risk transference
– Risk mitigation
39
40. Risk Management Planning
Risk Response Definitions
• Avoidance – Changing a project
objective to eliminate the threat posed
by an adverse risk event.
41. Risk Management Planning
Risk Response Definitions
• Transference – Shifting the negative
impact of a threat, along with the
ownership of the response, to a third
party.
42. Risk Management Planning
Risk Response Definitions
• Mitigation – Reducing the Probability or
Impact of an adverse risk event (threat)
to an acceptable threshold.
43. Risk Management Planning
Risk Response Definitions
• Acceptance – The project team decides
not to change project objectives to deal
with the risk.
• Passive acceptance: no action , deal with threats as they occur
(workarounds)
• Active acceptance: establish a contingency reserve to handle risks
44. 44
Risk Strategies
• Factors impacting the strategy
– Impact of the risk
– Project constraints
– Tolerances
• Strategy
– Accept or Ignore
• Provide reserves
– Contingency plans
• Natural disaster/backup plans
45. 45
Risk Strategies
– Avoidance, eliminate the risk
– Mitigate, lessen the impact of the risk
• Performance impact, provide extra hardware
– Transfer the risk
• Offsite backup planning
• Server farms
• Outside management
46. 46
Risk Monitoring and Control
• Risk monitoring
– Determine who is responsible for monitoring
– How are risks monitored?
• Project tracking, resources, quality, etc
– Communicating the status of identified risks
• Reviews and Audits
• Once a risk is identified as occurring
– Communicate
– Take action
47. Control Systems
• Preventive Control
– Stops undesirable events (disturbances) from
occurring (see Curtis, 1998 Chapter 8)
• Feedback Control
– Doesn’t attempt to prevent unpredictable
disturbances
– Is able to recover from effects
• Systems will usually combine both
47
48. Risk Control
• Goals of Control
– Prevention
– Detection
– Minimise Loss
– Recovery
– Investigation
H. A. Simon
• Risk Response
– Avoidance
• Prevention
– Mitigation
• Transfer
– Acceptance
Cadle and Yeates
48
49. Risk Response Control
• Implement Risk Responses
• Identify new Risks
– Implement new responses
49
50. 50
Risk Response and Evaluation
• Trigger the defined risk response plan
– Identify the risk owner
– Assign resources
– Understand the impacts
• PERTs, Dependencies
• Communicate
• Evaluate once action is taken
– Is more action needed?
– What additional risks are triggered?
51. Risk Register
• Can be used to keep information about identified
risks
– Title and description
– Risk Status - e.g. candidate, live, closed
– Potential impact
– Risk owner
– Actions
– Action Log
51
52. Risk Ownership
• Risk owner is someone who:
– Has sufficient information concerning the risk
– Has the necessary resources to do something
about the risk
– Possesses the authority to do something
about the risk
52
53. Don’t take the risk if...
• the organization cannot afford to lose.
• the exposure to the outcome is too great.
• the situation (or project) is not worth it.
• the odds are not in the project’s favor.
• the benefits are not clearly identified.
• there appear to be a large number of acceptable
alternatives.
53
54. Don’t take the risk if...
• the risk does not achieve the project objective.
• the expected value from baseline assumptions is
negative.
• the data is unorganized, without structure or
pattern.
• there is not enough data to understand the
results.
• a contingency plan for recovery is not in place
should the results prove unsatisfactory.
54
