Risk management
CHAPTER
Risk management
CHAPTER
Objectives
Identify the factors putting a project at risk;
Categorize and prioritize action for risk elimination or
containment;
Risk management
7.1 Introduction
What is risk management?
The probability of an undesirable event occurring coupled
Risk
The probability of an undesirable event occurring coupled with the impact of that event on the desired outcomeRisk
The act or practice of controlling risk
Risk Management
• It systematically identifies risk items that may oppose the implementation of improvements
• It systematically identifies risk items which are a direct result of
Slide# 3 Software Project Management
• It systematically identifies risk items which are a direct result of making process improvements
• It then prevents those high risk items from occurring or minimizes their impact with appropriate risk abatement steps
Risk management
7.1 Introduction
More detailed evaluation:
The identification of possible problems that could cause the The identification of possible problems that could cause the project to run late or over budget and with the identification of the steps that can be taken to avoid those problems or minimize their effects.
The identification of the hazards and possible problems, the evaluation of their importance and the drawing up of plans to monitor and deal with those problems is known as risk
Risk management
7.1 Introduction
Select Project
0
Identify project
1 Identify project 2 Identify project scope and objective
1 Identify project
infrastructure
2
Identify the products and activities
4 Estimate effort for activity 5 Identify activity risks 6 Analyze project characteristics 3
For each activity Lower level detail
Review
Slide# 5 Software Project Management
Allocate resources
7
Review/publicize plan
8
Lower level planning
10
Execute plan
Risk management
History of FMEA
• First used in the 1960’s in the Aerospace industry during the
7.1 Introduction
• First used in the 1960’s in the Aerospace industry during the Apollo missions
• In 1974 the Navy developed MIL-STD-1629 regarding the use of FMEA
• In the late 1970’s, automotive applications driven by liability costs, began to incorporate FMEA into the management of their processes
processes
Risk management
FMEA Basic Definitions
Failure Mode:
• The manner in which a specific part/process fails
7.1 Introduction
• The manner in which a specific part/process fails
• If not detected and either corrected or removed, will cause one of the “effects” to occur (can sometimes be identical to effect)
• Can be associated with a defect - an event that goes outside of specification. How could this process fail to complete its intended function?
Cause:
• A condition that produces a Failure Mode or a process deficiency that results in a Failure Mode
Slide# 7 Software Project Management
Failure Mode
Failure Effect:
• Impact on customer requirements if failure mode is not prevented or detected (often cost, schedule, and/or performance related). Effect is the result of the Failure Mode occuring?
Risk management
Failure modes
Causes
Effects
Examples
7.1 Introduction
No standard process
Lost paperwork Unsatisfied Customers
Computer interface not accurate
User unable to access information
Mismatch between systems
Tool Broken Excessive feed
rate
Damaged part
Risk management
Linking Cause to Effect
Cause 1 Effect 1
7.1 Introduction
Cause 2 Effect 2
Cause 1
Effect 1
Effect 2
Slide# 10 Software Project Management
Cause 1
Risk management
Linking Failure Mode to
FMEA Model
7.1 Introduction
Linking Failure Mode to
Cause and Effect
Cause Failure Mode(Defect) Effect
Risk management
7.2 The nature of risk
Risk
is associated with uncertainty, but we do not
call all uncertain events or outcomes ‘
risks
’. We normally
reserve the word ‘
risk
’ to describe non-desirable events or
outcomes – beneficial occurrences are normally called
‘opportunities’.
Slide# 12 Software Project Management
Risk management
7.2 The nature of risk
Car journey hazards’ case (Example)
Hazard Likely problem Action plan
Unusually bad Could miss start of Listen to traffic reports Traffic congestion interview on radio
Flat tyre Could miss interview Ensure spare tyre is
or be late usable and inflated
or be late usable and inflated
Risk management
7.3 Categories of risk
Describes the
management structures and systems including those affecting planning those affecting planning and control
Slide# 14 Software Project Management
Risk management
7.3 Categories of risk
Domain Class Description
Target Information system The characteristics of the information system – Target Information system The characteristics of the information system – there are independent of the technologies that might be used
Computer system The characteristics of the part of the information system that has been computerized
Project Project Type of task to be undertaken
Structure The communication systems, management structures, work flows etc.
ISPL situational factors
structures, work flows etc.
Actors The people involved in the project
Risk management
7.3 Types of risk
Three types of risk:
Those caused by the inherent difficulties of estimation; Those due to assumptions made during the planning process;
Those of unforeseen (or at least unplanned) events or hazards occurring.
Risk management
7.3 Types of risk
Estimation errors
Problems: lack of experience of similar tasks.
Activities: Estimate with some degree of accuracy how long the task will take and how much it will cost.
Solutions: Estimation can be improved by analysing historic data for similar activities and similar systems. Keeping
Risk management
7.3 Types of risk
Planning assumptions
At each stage in the planning process, it is important to list explicitly all of the assumptions that have been made and identify what effects they might have on the plan if they are inappropriate.
Risk management
7.3 Types of risk
Eventualities
The majority of unexpected event can be identified – the requirements specification might be alter some if the
Risk management
7.4 A framework for dealing with risk
Planning for risk includes these steps:
Planning for risk includes these steps:
I. Risk identification;
II. Risk analysis and prioritization;
III. Risk planning;
IV. Risk Monitoring.
Slide# 20 Software Project Management
Risk management
7.4 Managing risk
The objective of risk management is to avoid
The objective of risk management is to avoid
or minimize the adverse effects of unforeseen
events by avoiding the risks or drawing up
Risk management
7.4 Managing risk
Risk engineering
Two main components – risk analysis and risk management.
Risk analysis
• Risk identification • Risk estimation • Risk evaluation
Risk management
• Risk planning • Risk control
• Risk monitoring
Slide# 22 Software Project Management
Risk management
7.5 Risk identification
The two main approaches to the identification of risks are the The two main approaches to the identification of risks are the use of checklists and brainstorming
Checklists are simply list of the risks that have been found to occur regularly in software development projects.
Brainstorming represents the main stockholders. They then
identify, using their individual knowledge of different parts of the project. Brainstorming can also be used to identify possible
Risk management
7.5 Risk identification
Top ten list of software risks is based on one presented by Barry Boehm
Risk Risk reduction techniques
Personnel shortfalls Staffing with top talent; job matching teambuilding, training and career
Personnel shortfalls Staffing with top talent; job matching teambuilding, training and career
development etc.
Unrealistic time and cost estimates Multiple estimation techniques; design to cost, incremental development, recording
and analysis of past projects, etc.
Developing the wrong software function Improved software evaluation, formal specification methods, user surveys, prototyping, early user manuals
Developing the wrong user interface Prototyping, task analysis, user involvement
Gold plating Requirements scrubbing, prototyping, cost-benefit analysis, design to cost
Slide# 24 Software Project Management
Late change to requirements Stringent change control procedures, high change threshold, incremental
development (deferring change) Shortfalls in externally supplied
components Benchmarking, inspections, formal specifications, contractual agreement, qualityassurance procedures and certification
Shortfall in externally performed tasks Quality assurance procedure, competitive design or prototyping, contract incentives
Real-time performance shortfalls Simulation, benchmarking, prototyping, tuning, technical analysis
Risk management
7.5 Risk identification – Causal mapping
Low staff turnover. … high Experienced staff… inexperienced High productivity …low + + + Deadlines met… missed Heavy management pressure…low + + -Uncertain user requirements …certain Unstable environment …stable +
Risk management
7.5 Risk identification
What is a hazard? What is a hazard?
The first stage in any risk assessment exercise is to identify the hazards that might affect the duration or resource costs of the project.
In identifying and analyzing risks, we can usefully distinguish
between the cause (or hazard), its immediate effect (the problem that it creates) and the risk that it will pose to the project.
Risk management
7.5 Hazard identification
Some hazards are:
Generic risks – they are relevant to all software projects and standard checklists can be used and augmented from an analysis of past projects to identify them.
Specific risks – are relevant to an individual project and these are likely to be more difficult to identify without an involvement of the members of the project team and a working environment that encourages risk assessment.
Risk management
7.5 Hazard identification
Application factors;
Categories of factors:
Application factors;
Staff factors;
Project factors;
Project methods;
Hardware/software factors;
Changeover factors;
Slide# 28 Software Project Management
Changeover factors;
Supplier factors;
Environment factors;
Risk management
Risk management
7.5 Hazard identification
Table 7.2 Hazard ranking
Priority Criteria Action
1 Any critical hazard Take immediate action
2 Significant, likely and near-term Initiate risk planning procedures 3 Significant, likely and far-term Get more information and take
to next review meeting
Slide# 30 Software Project Management
4 Significant but unlikely Get more information about likelihood and reassess
Risk management
7.6 Risk Assessment
Risk exposure
• Probability of a hazard occurring called risk likelihood; • Probability of a hazard occurring called risk likelihood; • Effect that the resulting problem will have on the project
called risk impact
• The importance of the risk called risk value or risk exposure.
Risk exposure = risk impact × risk likelihood
Risk management
7.6 Risk Assessment
Example of Risk Exposure Assessment
Ref. Hazard Likelihood Impact Risk
Ref. Hazard Likelihood Impact Risk
exposure
R1 Changes to requirements specification duringcoding 8 8 64
R2 Specification takes longer than expected 3 7 21
R3 Significant staff sickness affecting critical pathactivities 5 7 35
R4 Significant staff sickness affecting non-criticalactivities 10 3 30
Slide# 32 Software Project Management
R4 activities 10 3 30
R5 Module coding takes longer than expected 4 5 20
Risk management
7.6 Risk Assessment
Probability level Range
High Greater than 50% chance of happening
Significant 30-50% chance of happening Significant 30-50% chance of happening
Moderate 10-29% chance of happening
Low Less than 10% chance of happening
Impact level Range
High More than 30% above budgeted expenditure
Quantitative descriptors of risk probability and associated range values
High More than 30% above budgeted expenditure
Significant 20 to 29% above budgeted expenditure Moderate 10 to 19% above budgeted expenditure
Low Within 10% of budgeted expenditure
Risk management
7.6 Risk Assessment
R6 R1
R6 R1
R2,
R3, R5
R4
High
Significant
Moderate
Note: These matrices have
Slide# 34 Software Project Management
Low
Low Moderate Significant High Note: These matrices have
Risk management
7.6 Hazard analysis
Impact measures, scored on a similar scale, must take into account the total risk to the project. This must include the following
potential costs: potential costs:
• The cost of delays to scheduled dates for deliverables;
• Cost overruns caused by using additional or more expensive resources;
• The costs incurred or implicit in any compromise to the system’s quality or functionality.
Risk management
7.6 Hazard analysis
Prioritizing the risks
Managing risk involves the use of two strategies:
• Reducing the risk exposure by reducing the likelihood or impact;
• Drawing up contingency plans to deal with the risk should it occur.
Slide# 36 Software Project Management
Risk management
7.6 Hazard analysis
Prioritizing the risks
In practice, there are generally other factors, in addition to the risk exposure value, that must also be taken into account when
prioritizing risks.
• Confidence of the risk assessment • Compound risks
• Compound risks
Risk management
7.7 Risk planning
•
Risk Acceptance
•
Risk Avoidance
•
Risk Reduction and mitigation
•
Risk Transfer
Risk management
7.7 Risk planning
Fairley’s four commercial off-the-shelf (COTS) software acquisition risks
Integration Difficulties in integrating the data formats and communication Integration Difficulties in integrating the data formats and communication
protocols of different applications
Upgrading When the supplier upgrades the package, the package might no longer meet the users’ precise requirements. Sticking with the old version could mean losing the supplier’s support for the package.
No source If you want to enhance the system, you might not be able to No source
code If you want to enhance the system, you might not be able todo so as you do not have access to the source code.
Supplier failures or buyouts
Risk management
7.8 Risk management
•
Contingency
•
Deciding on the risk actions
•
Creating and maintaining the risk register
Risk Record
Risk ID Owner
Risk title
Date raised Status
Slide# 40 Software Project Management
Owner Date raised Status
Risk Description
Impact Description
Risk management
7.8 Risk management
Risk reduction leverage
Risk reduction leverage (RRL) formulas:
t
reduction
risk
RE
RE
RRL
before aftercos
_
_
Where REbefore is the original risk exposure value, REafter is the expected risk exposure value after taking action and the risk
Risk management
7.9 Evaluating risks to the schedule
• PERT, a technique which takes account of the uncertainties in • PERT, a technique which takes account of the uncertainties in
the durations of activities within a project.
• Monte Carlo Simulation
• Critical Chain Management
Risk management
7.10 Applying the PERT technique
Using PERT to evaluate the effects of uncertainty
PERT requires three estimates: PERT requires three estimates:
•
Most likely time
•
Optimistic time
•
Pessimistic time
6
4
m
b
a
Risk management
7.10 Applying the PERT technique
Activity Optimistic Most likely Pessimistic Expected S.D.
(a) (m) (b)
A B
5
3 64 85
2 6
A T = 6
B
C T = 3 D
T = 4 T = 2H
B C D E F G H 3 2 3.5 1 8 2 2 4 3 4 3 10 3 2 5 3 5 4 15 4 2.5 Even number Expected date Target date Standard deviation Slide# 44 Software Project Management
1 0 3 4
5 10
4 9 6 13
B T = 4
F T = 10
D T = 4
E T = 3
G T = 3 H
Risk management
7.10 Applying the PERT technique
6
4
m
b
a
t
e
Table 7.6 Expected time and standard deviations
Activity Optimistic Most likely Pessimistic Expected S.D.
(a) (m) (b) (t) (s)
A B
5
3 64 85 6.174.00
6
t
e
Risk management
7.10 Applying the PERT technique
Using expected durations
• Forward pass
Even number Expected Target date Standard
• Forward pass Expected
date
Standard deviation
Table 7.5 PERT activity time estimates, Figure 7.4 PERT network
2 6.17
A t = 6.17
B
C t = 2.83 D
t = 4.08 t = 2.08H
6
Slide# 46 Software Project Management
1 0 3 4 5 10.5 4 9 6 13.5 B t = 4.00
F t = 10.5
D t = 4.08
E t = 2.83
G t = 3.00
H t = 2.08
0 4
10
Risk management
7.10 Applying the PERT technique
Activity standard deviations
a
b
s
6
a
b
s
Table 7.6 Expected time and standard deviations
Activity Optimistic Most likely Pessimistic Expected S.D.
(a) (m) (b) (t) (s)
A B
5
3 64 85 6.174.00 0.500.33
Risk management
7.10 Applying the PERT technique
Calculate Standard Deviation
2
2
s
s
s
2 6.17 A
t = 6.17 s = 0.50
B
C t = 2.83 s = 0.17 D
t = 4.08
H t = 2.08
0.50 6 Even number Expected date Target date Standard deviation
0
.
50
20
.
17
2
0
.
53
4 2 2 2 1
s
s
s
s
Slide# 48 Software Project Management1 0 3 4 5 10.5 4 9 6 13.5 B
t = 4.00 s = 0.33
F t = 10.5 s = 1.17
t = 4.08 s = 0.25 E t = 2.83
s = 0.50 G
t = 3.00 s = 0.33 t = 2.08 s = 0.08
Risk management
7.10 Applying the PERT technique
The likelihood of meeting targets
• calculate SD of each project event;
• calculate the z value for each event that has target • calculate the z value for each event that has target
date;
Risk management
7.10 Applying the PERT technique
Calculating the standard deviation of each project event
Calculating the z values
s
t
T
z
e where t is expected date, T is target datez value is calculated for each node that has a target date.
Slide# 50 Software Project Management
Risk management
7.10 Applying the PERT technique
5
.
13
13
z
Target Date = 13
Expected Date = 13.5
22
.
1
z
Expected Date = 13.5S.D. = 1.22
Z-Value = -0.41
Probability = 0.655
There is an 65.5% risk of not meeting the target date of the end of week 13
The probability is 1-0.655 or about 34.5% that this path will be finished on or before day 13.
Risk management
7.10 Applying the PERT technique
The advantage of PERTs
• Easy identification of the order of precedence
• Easy identification of the critical path and thus critical
activities
• Easy determination of slack time, the leeway to fall
behind on noncritical paths
Slide# 52 Software Project Management
Risk management
7.a Budget Uncertainty and Risk Management
Budget Uncertainty
• It is common in project management to make new forecasts about project completion time and cost at fixed points in the project life cycle.
Risk management
7.a Budget Uncertainty and Risk Management
Budget Uncertainty
• Changes are due to errors, technological uncertainty and so on.
• The project team or client learns more about the nature of the performance goal of the project or the setting in which it is to be used.
• Change is the mandate: new law, government regulation etc. There are three basic causes for change in projects:
Slide# 54 Software Project Management
Risk management
7.a Budget Uncertainty and Risk Management
P ro je ct C o st P ro je ct C o st P ro je ct C o st Time P ro je ct C o st Time P ro je ct C o st
t0 t1 Time
P ro je ct C o st
t0 t1 t2
An estimate at the beginning of the project at t0 as (a), As work on the project progresses, the uncertainty decreases as the project
t0
(a) (b) (c)
Risk management
7.a Budget Uncertainty and Risk Management
BUDGET INFORMATION
Task Name OptimisticCost = a Normal Cost= m PessimisticCost = b Expected Cost(a+4m+b)/6
Begin preparations for tribute dinner select date & secure room
obtain corporate sponsorships for event $ 100.00 $ 150.00 $ 350.00 $ 175.00 identify potential businesses to sponsor
phone/write businesses $ 100.00 $ 150.00 $ 350.00 $ 175.00 Event hosts/MC
identify and secure honoree of event identify and secure master of ceremonies identify/secure person to introduce honoree identify/secure event hosts & hostesses
Slide# 56 Software Project Management
identify/secure event hosts & hostesses Invitations
secure mailing lists
design invitation with PR firm $1,250.00 $ 1,500.00 $ 2,200.00 $ 1,575.00 Print invitation $2,300.00 $ 2,500.00 $ 3,000.00 $ 2,550.00 Mail invitation $ 250.00 $ 300.00 $ 410.00 $ 310.00 RSVP's back
Risk management
7.13 Conclusions
This chapter we have seen how to identify and manage the risks This chapter we have seen how to identify and manage the risks that might affect the success of a project. Risk management is concerned with assessing and prioritizing risks and drawing up plans for addressing those risks before they become problems.
This chapter has also described techniques for estimating the effect of risk on the project’s activity network and schedule.
effect of risk on the project’s activity network and schedule.
