Software Project

Risk Management

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
 Current maturity level of IT industry is not encouraging in this area

1) Rating is also lowest comparing other knowledge areas (Scope,

Time, Cost, Quality, HR…)
2) For risk management IS are at lowest among all, whereas it should
be on the higher side keeping in view its rate of failure.

2
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

Do you think that planning/scheduling is such investment?

Risk
Software disasters can be avoided through:
an explicit early concern with
identifying and resolving
high risk elements [Boehm91].

3
 Risk Utility
Risk utility or risk tolerance is the amount of satisfaction or pleasure
received from a potential payoff (associated with risk)
People or organizations can be categorized from their approach as risk-
averse, risk neutral, risk-seeking

 Utility rises at lower payoff for a person who is risk-averse, or gains

less satisfaction from the risk; lower tolerance for the risk
 The risk neutral approach achieves a balance between risk and payoff
 Those who are risk-seeking have a higher tolerance for risk and their
satisfaction increases when more payoff is at stake
Risk-Averse Risk-Neutral Risk-Seeking
Utility Utility Utility

Potential Payoff Potential Payoff Potential Payoff

4
The SEI Risk Model

n t rol
Co

Id
en
ti f
y
Track

Communicate

e
yz
al
An
Pla
n

5
 Managing Risk
 The goal: minimize potential risks while maximizing potential opportunities.
 The objective of risk management is to avoid or minimize the adverse effects of
unforeseen events by avoiding the risk (mitigations) or drawing up contingency
plans for dealing with them.
 There are number of models for risk management, but most are similar, in that
they identify two main components – risk analysis and risk management.
Risk
engineering
Boehm’s risk engineering
task breakdown.
Risk Risk
Analysis Management

Risk Risk Risk

identification Estimation evaluation

Risk Risk Risk Risk Risk

planning control monitoring directing staffing

6
 Managing risk ….

1) Risk identification consists of listing all of the risks that can adversely
affect the successful execution of the project.
2) Risk estimation consists of assessing the likelihood and impact of
each hazard.
3) Risk evaluation consists of ranking the risks and determining risk
aversion strategies.
4) Risk planning consists of drawing up mitigation/contingency plans
and, where appropriate, adding these to the project’s task structure.
5) Risk control concerns the main functions of the risk manger in
minimizing and reacting to problems throughout the project.
6) Risk monitoring must be an ongoing activity, as the importance and
likelihood of particular risks can change as the project proceeds.
7) Risk directing and risk staffing are concerned with the day-to-day
management of risk and allocating resources.

7
Other Sub-Plans
In addition to risk management plan project can have:
 Risk Mitigation: reducing the impact of risk event by
reducing the probability of its occurrence.
 Contingency Plans: preplanned actions that the team
will take if identified risk event occurs.
 Fallback Plans: developed for high risks, put into
effect if attempts to reduce are not effective.

8
 Boehm’s Top Ten list

1. Personnel shortfall
2. Unrealistic schedules and budgets
3. Developing the wrong functions and properties
4. Developing the wrong user interface
5. Gold-plating
6. Continuing stream of requirements changes
7. Shortfalls in externally furnished components
8. Shortfalls in externally performed tasks
9. Real-time performance shortfalls
10. Straining computer-science capabilities

9
 Other broader Categories includes

 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?

10
 Other broader
Categories………

 Estimation errors
• Some tasks are harder to estimate than others (lack of experience of
similar tasks, nature of a task).
For example: Producing a set of user manuals is reasonably straightforward.
Time required for testing and debugging, might be difficult to predict with a
similar degree of accuracy (even if we have written similar programs in the
past).
 Planning Assumptions
• At every stage during planning, assumptions are made which, if not valid,
may put the plan at risk.
• Important to list explicitly all of the assumptions made (at each stage in the
planning) and identify what effects they might have on the plan if they are
inappropriate.
 Eventualities
• Some eventualities might never be foreseen and fact that unimaginable
things do sometimes happen. But majority of unexpected events can be
identified (a person can take leave, required hardware might not be
delivered on time). 11
 RISK FACTORS
Application factors
• nature of the application a simple data processing, a safety-critical system, or a
large distributed system with real-time elements – is a critical factor.
• Expected size of the application – Larger the system, greater is the likelihood
of errors and communication and management problems.
Project factors
• Well defined project and its objectives and are absolutely clear to all members
of the project team and all key stakeholders.
• An agreed and formal quality plan in place and adhered to by all participants.
• Hardware/software factors
Staff factors
• The experience and skills of the staff involved are clearly major factors
• also consider the appropriateness of the experience.
• Level of staff satisfaction and the staff turn-over rates
Supplier factors
installation of telephone lines or delivery of equipment may be difficult to avoid.
12
Environment factors
Changes in the environment can affect a project’s success. Change in the
taxation for payroll application.
Health and safety factors
possible effects of project activities on the health and safety of the
participants and the environment should be considered.
Customer/User Factors
• client’s confidence in developer is low
• users threatened by application, have little computer experience
• users won't spend the time to define requirements OR unsure of needs
• multi-departmental users
• client project rep. Is part-time
Business Issues:
• highly volatile business area
• very tight deadline has been demanded
Changeover factors
• ‘all-in-one’ pilot changeover to new system (particular risks), Incremental or
• Parallel minimized the risks involved- but what suites with how much risk?
13
Potential Risk Conditions With Each Knowledge Area

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, 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
14
 Risk Identification
• The first stage in any risk assessment exercise is to identify the
hazards that might affect the duration, resource, costs of the
project.
• Several risk identification tools include:
• Brain storming,
• checklists,
• SWOT (Strengths, weaknesses, opportunities, and threats),
and
• interviews.

15
 Qualitative Risk Analysis
• Assessing the likelihood and impact of identified risks
• To Determine their priority and magnitude

RISK FACTOR
• To quantify risk probability and consequence, Defense Systems Management
College (DSMC) developed a technique to calculate risk factor ---
• That is, numbers that represent the overall risk of a specific event based on
their:
Probability of occurring and consequences to the project (if they occur)
Probability/Impact Matrix shows probability (or likelihood) of occurring and
Impact (or consequences) of the risk.
Probability (likelihood) of occurring can be estimated based on unique nature of
project and type of risk (e.g. Factor evaluated for H/W S/W technology includes:
(1) not being matured (2) too complex (3) inadequate support base)
Impact (consequences) of the risk could include factors (1) availability of fallback
solution (2) or consequence of not meeting cost, schedule, performance….
16
 Probability/Impact Matrixes
PROBABILITY of FAILURE (Pf) for Technology Risk
Risk Factors

Value Maturity (HW/SW) Complexity Support Base

(HW/SW)
0.1 Existing Simple Design Multiple Programs
and services
0.3 Minor Redesign Somewhat Complex Multiple Programs

0.5 Major Change Fairly Complex Several Parallel

Feasible Programs
0.7 Complex HW Very Complex At Least One Other
Design/New SW Programs
similar to existing
0.9 Some Extremely Complex No Additional
Research/Never Done Programs
Before
17
 CONSEQUENCE of FAILURE (Cf) for Technology Risk
Value Fall Back Solution Life Cycle Cost (LCC) Schedule Factor Down Time (DT)
Factor * (IOC)
0.1 Several Highly Confident will 90-100% Highly Confident
Alternatives reduce LCC confident will will Reduce DT
meet IOC
0.3 A Few Known Fairly Confident will 75-90% Fairly Confident
reduce LCC confident will will Reduce DT
meet IOC significantly
0.5 Single Acceptable will not change much 50-75% Highly Confident
Sol. LCC confident will will Reduce DT
meet IOC somewhat
0.7 Some Possible Fairly Confident will 25-50% Fairly Confident
Increase LCC confident will will Reduce DT
meet IOC somewhat
0.9 No Acceptable Highly Confident will 0-25% DT may not Reduce
Increase LCC confident will much
meet IOC

Overall Risk Factor = (Pf + Cf) - (Pf * Cf) * Initial Operational Capability
Example RF = (.1 + .9) - (.1 * .9) = 0.91 18
 2. Risk Exposure
Another scheme to perform assessment works similarly
Risk likelihood:
The probability of a hazard’s occurring; assessed as a probability
Risk Impact (RI):
the effect that the risk will have on the project, if it occurs; Ideally estimated in
monetary terms
Importance of risk:
is known as the risk value or risk exposure;
calculated as:
Risk Exposure (RE) = (Risk Likelihood) X (Risk Impact)
 If RI is in monetary terms then risk exposure will represent an expected cost
of that risk
 The risk exposures can then be compared with each other to assess the relative
importance of each risk; and
 Risks can be directly compared with the costs and likelihoods of success of
various contingency plans.*
19
 Issues: Estimation of these costs and probabilities is likely to be difficult,
subjective, time-consuming and costly.
 Alternatively: Some just categorize likelihoods and impacts as high,
medium or low, but this form of ranking does not allow the calculation of a
risk exposure.
 A better and popular approach is:
score likelihood and impact on a scale of, say, 1 to 10
(i.e. most likely to occur = 10 and the least likely = 1).

 Impact measures, must take into account the total risk to the project. This
must include the following potential costs:

20
 Exposure Assessment

  Hazard Likelihood Impact Risk

        exposure

R1 Changes to requirements specification during 1 8 8

coding
R2 Specification takes longer than expected 3 7 21
R3 Staff sickness affecting critical path activities 5 7 35
R4 Staff sickness affecting non-critical activities 10 3 30
R5 Module coding takes longer than expected 4 5 20
Module testing demonstrates errors or
R6 1 10 10
deficiencies in design

21
Discussion on Both Measures
Risk Risk Risk Risk Risk Risk
Risk Factor 1 2 3 4 5 6
Probability of Failure (Pf) 0.1 0.4 0.9 0.1 0.5 0.9
Consequence of Failure (Cf) 0.1 0.8 0.1 0.9 0.5 0.9
Risk Factor== (Pf + Cf) - (Pf * Cf) 0.19 0.88 0.91 0.91 0.75 0.99

Risk Exposure
R1 R1 R3 R4 R5 R6 R7
Likely Hood 1 9 3 5 6 8 9
Impact 9 1 5 4 6 8 9
RE 9 9 15 20 36 64 81
 3. Prioritizing the Risks
 Managing risk involves the use of two strategies:
1) Reducing* the risk exposure by reducing the likelihood or
impact;
2) Drawing up contingency plans to deal with the risk should it
occur.
 Any attempt to reduce a risk exposure or put a contingency plan in place will
have cost associated with it. So first prioritize to decide appropriateness of
strategy.

 Risk exposures based on scoring methods must be treated with some caution
as.
1) we cannot interpret the scoring method (quantitatively).
2) exposure values are far too close to distinguish between them.

Partly, allow us to obtain an approximate ranking in order of importance.

Like R3 and R4 are most important; Next highest exposure, R2 and R5; as
medium priority risks. R1 and R6 can be classified as low risk items.
* Will discuss more
23
 Prioritizing ……

In practice, Other factors in addition to Risk Exposure when prioritizing::

Confidence of the risk assessment: Some of assessments will be relatively poor, then
there is a need for further investigation before action can be planned.
Compound risks: Some risks will be dependant on others; they should be treated together
as a single risk (like, experience & appropriate experience).
The number of risks: There is a limit to the number of risks that can be effectively
considered and acted on by a project manager.
Cost of action:
 Some risks can be reduced or avoided immediately with very litter cost or effort and
it is sensible to take action on these regardless of their risk value (like, power failure
data loss; by UPS)
 For other risks we need to compare the costs of taking action with the benefits of
reducing the risk.
 One method for doing this is to calculate the risk reduction leverage (RRL) using the
equation. • RRL is used as a factor in
REBefore - REafter
prioritizing, and
RRL =
• For evaluating alternatives
Risk reduction cost
24
 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
Risk Resolution Progress

25
 Top Ten Risks: Example

Risk Likelihood Impact

* Failing to understand the 8 10

requirements.
Two team members are 10 6
inexperienced with Java.
* Lack of time for all members. 9 9
* Module interaction problems. 4 10
* Poor communication among team. 4 9
Failure of proof of concept. 7 6
* Putting too much emphasis on one 4 7
aspect of the problem – i.e. too
much quality, not enough features.
* Computer failure. 3 8

26
 Risk Management Plan for the ACIC Project

Seq. Risks Prob Impact Risk Mitigation Plan

No. Exp
1 We will need 0.5 8 4 Plan carefully for the time
support from the required from each of
database architect these groups and give
and the customer’s enough prior notice. Have
database an onsite coordinator work
administrator closely with these groups.
2 Because RUP is 0.9 3 2.7 Work closely with experts
being used for the in the Infosys R&D lab.
first time, the Keep the customer in the
understanding of loop throughout the
the team may not project and escalate
be complete. (raise the level) for any
schedule or effort
deviations. Train the team
on RUP methodology.
Contd………
Seq. Risks Prob Impact Risk Mitigation Plan
No. Exp
3 Personal attrition: 0.3 7 2.1 Assign tasks so that
Team members might more than one person
leave on short notice. is aware of the units
and use cases in the
project.
4 Working with the 0.1 8 0.8 Do extra code reviews,
customer’s mainframe desk checking, etc. to
DB2 over the link: Link minimize the reliance
may not be as efficient on the link.
as it is expected. Escalate as soon as the
link goes down.
 4. Expert Judgment

• Techniques may be misleading: Interpretation of math and

stat, output as good as input, …*

• Many organizations rely on the intuitive feelings and past

experience of experts to help identify potential project risks

• Expert Judgment can be used in lieu of or an additional

analysis activity

• Expert can categorize risks as low, medium, and high

• The Delphi method is a technique for deriving a consensus

among a panel of experts to make predictions about future
developments

29
 Quantitative Analysis

 Qualitative and quantitative analysis can be

done in sequence/parallel or even alone.
 Resources requirement (time, money)
should be justified against the nature of the
project
 Large and complex projects requires
extensive quantitative analysis
 Main techniques:
1) decision tree analysis,
2) evaluating risk to schedule, and
3) simulations
30
Expected Monetary Value (EMV): Decision Tree

 A decision tree is used to represent the Expected Monetary Value

(EMV)
 A multiple choice situation is represented on the tree along with
its likelihood (probability) and outcome in $; and the net EMV
as a product of both.
Probability Times OutCome = EMV

P=0.20 X $300,000 = +$60,000

Project1

P=0.80
Decision X -$40,000 = -$32,000

.20 X -$50,000 = -$10,000

Project2 P=0
P=0.10 X -$20,000 = -$2,000
P= 0
.70
X $60,000 = +$42,000
31
*
 Expected Monetary Value (EMV)…..

Project1’s EMV= $60,000 – 32000= $28,000

Project2’s EMV= –$10,000 – 2,000 + 42,000=$30,000

 EMV provides total dollar value and +ve and higher the better
(like in the example company can go for both projects)
 If to choose one project (limited resources); select project 2;
higher EMV
 Otherwise: project-1 looks more appealing (profit 300,000
comparing to 60,000 in project-2).
 However; only 20% chances to get 300,000 whereas 70% to
get 60,000
 If company is risk seeker; would go for project-1.
 Using EMV helps account for possible outcome and their
probabilities, reducing the tendency to peruse overly aggressive
or conservative risk strategy.
32
 2. Evaluating Risks to Schedule
Two step assessing the effects of uncertainties on the project schedule Using
PERT (Program Evaluation Review Technique).
• Using Expected Duration, and
• Activity Standard Deviations
(1) Expected Duration
• PERT was developed to take account of the uncertainty surrounding estimates
of task durations.
• The method is very similar to the CPM technique (many use PERT and CPM
interchangeably); instead of using a single estimate for the duration of each
task, PERT requires three estimates.
• Most likely time: under normal circumstances (m).
• Optimistic time: shortest time we could expect, barring outright miracles (a).
• Pessimistic time: worst possible time (allowing reasonable eventualities but
excluding ‘acts of god and warfare) (b).
a + 4m + b
• PERT then combines these three te =
estimates to form a single expected 6
duration:
33

N
PERT activity time estimates
Activity Durations (weeks)
Activity Optimistic (a) Most likely (m) Pessimistic (b) Expected (te)
A 5 6 8 6.17
B 3 4 5 4.00
C 2 3 3 2.83
D 3.5 4 5 4.08
E 1 3 4 2.08
F 8 10 15 10.50
G 2 3 4 3.00
H 2 2 2.5 2.08

PERT: Target
Event #
Start building PERT Network similar to CPM Date
PERT Node represents information 
Expected Standard
Date Deviation
34
 Forward Pass: expected durations are used to carry out a forward similar to CPM.
• The PERT network below indicates that we expect the project to take 13.5 weeks –
• Unlike CPM, this does not indicate earliest date of completion but the expected (or
most likely) date. Rather than being
• Places an emphasis on the uncertainty of the real world. tempted to say ‘the
The PERT network after the forward pass. completion date for
the project is …… ‘
2
A we are lead to say ‘we
6.17 C expect to complete
t = 6.17 t = 2.83 the project by …….

1 B 3 D 4 H 6
0 t = 4.00 4 t = 4.08 9 t = 2.08 13.5

E
t = 2.83 G
F 5 t = 3.00
t = 10.5
10.5
(2) Activity Standard Deviations (SD)

• The activity SD is proportional to the difference between the optimistic

and pessimistic estimates, and can be used as a measure of the
degree of uncertainty or risk for each activity.
• This formula is based on the rationale that there are approximately six
standard deviations between the extreme tails of many statistical
distributions.
• A quantitative measure of the degree of uncertainty of an activity
duration estimate obtained by calculating the standard deviation’s of
an activity time; using the formula:

b-a
s=
6

36
 Activity
ActivityStandard
standardDeviations
deviations(SD)…….

Expected times and standard deviations.

Activity Durations (weeks)
Activity Optimistic (a) Most likely Pessimistic Expected Standard Deviation
(m) (b) (te) (s)
A 5 6 8 6.17 0.50
B 3 4 5 4.00 0.33
C 2 3 3 2.83 0.17
D 3.5 4 5 4.08 0.25
E 1 3 4 2.08 0.50
F 8 10 15 10.50 1.17
G 2 3 4 3.00 0.13
H 2 2 2.5 2.08 0.08

37
 The likelihood of meeting targets

• Main advantage of PERT technique: provides a method for estimating the

probability of meeting or missing target dates.
• A single target date – project completion – or set additional intermediate target.
• The PERT technique uses three-step method for calculating the probability of
meeting or missing a target date:

• Calculate the standard deviation of each project event;

• Calculate the z value for each event that has a target date;
• Convert z values to a probability.

Standard deviation of each event

• can be calculated by carrying out a forward pass using activity standard
deviations similar to that used with expected durations.
• One small difference – to add two standard deviations we must add their
squares and then find the square root of the sum.

38
• standard deviation for event 3 depends solely on activity B is therefore 0.33.
• For event 5, two possible paths, (B + E) or F. Total standard deviation for path
B + E is √(0.332 + 0.502) = 0.6 and that for path F is 1.17; i.e greater of the
two, 1.17.
The PERT network with event standard deviations and three target dates.

2
6.17 0.50 C
A t = 2.83
t = 6.17 s = 0.17
s = 0.50
B D H
t = 4.00 t = 2.83 t = 2.08
1 s = 0.33 3 s = 0.25 4 10 s = 0.80 6 15
0 0 4 0.33 9 0.53 13.5 1.22

E
t = 2.83 G
F s = 0.50
t = 10.5 t = 3.00
s = 1.17 5 10 s = 0.33

10.5 1.17
Calculating the z values
The z value is calculated for each node that has a target date. It is equivalent to the
number of standard deviations between the node’s expected and target dates;
calculated as:
T - te Where te is the expected date and T the target date.
z=
s
The z value for event 4 is (10 – 9.00)/0.53 = 1.8867.
Exercise: Calculate the z values for the other events.

Converting z values to probabilities

•A z value may be converted to the probability of not meeting the target date by
using the graph (found in most statistics books)
•The z value for the project completion (event 6) is 1.23. Using graph we can see
that this equates to probability of approximately 11%, that is, 11% risk of not
meeting the target date of the end of week 15.
Note: Same approach can be used to compute likelihood (%of risk) for risk, cost..
Exercise: Find the probabilities of not achieving events 4 or 5 by their target
dates of the end of week 10. What is the likelihood of completing the project by
week 14?
40

N
 3. Monte Carlo Simulation
An alternative to PERT technique, and to provide a greater degree of flexibility in
specifying likely activity durations, we can use Monte Carlo simulation
techniques to evaluate the risks of not achieving deadlines.
Method:
• Calculate event times for a large no of times (typically 100-1000) for a project
network (can use historical data and present environment)
• Each time select activity times randomly from a set of estimates for each activity
• Result for each activity is tabulated (likelihood/probabilities) and graphed as
likelihood

Activity start date

Activity end date
56

80
62

69

Week #
Risk profile for an activity (generated using Monte Carlo Simulation) 41