Software Risk Management

Dr. Abdul Rauf Malik

1
 What is a Risk?

 Risk is a measure of the probability and

consequence of not achieving a defined
project goal.
 Risk = Size(Loss) * Prob(Loss)
 A probability of occurrence of that event.
 Impact of the event occurring

Dr. Abdul Rauf 2 CCIS-IMAMU

 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
 an aspect of sound project management.

Dr. Abdul Rauf 3 CCIS-IMAMU

 Risk Management
 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
Boehm’s risk engineering task breakdown.
engineering

Risk Risk
Analysis Management

Risk Risk Risk

identification Estimation evaluation

Risk Risk Risk Risk Risk

planning control monitoring directing staffing

Dr. Abdul Rauf 4 CCIS-IMAMU

 A Simplified Risk Management Process

 Risk identification
 Risk analysis/evaluation
 Risk planning strategies
 Risk monitoring and control
 Risk response

Dr. Abdul Rauf 5 CCIS-IMAMU

 Risk Identification

• Proactively identify risks!

• Tools for identifying risks
– Brainstorming
– Nominal Group Technique
• Each member identifies their ideas
• Each member writes their idea on the board
• 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
Dr. Abdul Rauf 6 CCIS-IMAMU
 Risk Identification
 Strength, Weakness, Opportunities, Threats
 Cause and effect diagrams
 Past Projects

Dr. Abdul Rauf 7 CCIS-IMAMU

 Possible Risks

 Creeping user requirements

 Excessive schedule pressure
 Low quality
 Cost overruns
 Poor estimates
 Low customer satisfaction
 Long schedules

Dr. Abdul Rauf 8 CCIS-IMAMU

 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

Dr. Abdul Rauf 9 CCIS-IMAMU

 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

Dr. Abdul Rauf 10 CCIS-IMAMU

 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

Dr. Abdul Rauf 11 CCIS-IMAMU

 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?

Dr. Abdul Rauf 12 CCIS-IMAMU

 Common Software Project Risks
 Requirements:
• Feature creep
• Developer gold plating
 Quality
• Low quality
• Squeeze on testing time
 Over optimism
• Schedules
• Tools

Dr. Abdul Rauf 13 CCIS-IMAMU

 Common Software Project Risks
 Resources
• Not enough
• Weak personnel
• Contractor issues
 Customer
• Customer developer friction
• Customer acceptance

Dr. Abdul Rauf 14 CCIS-IMAMU

 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

Dr. Abdul Rauf 15 CCIS-IMAMU
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
Dr. Abdul Rauf 16 CCIS-IMAMU
 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
Dr. Abdul Rauf 17 CCIS-IMAMU
 Qualitative Risk Analysis

 Probability and Impact

 Impacts a Software Project Manager is most
likely to face:
• Costs
• Schedule
• Quality
 Probability is most often determined by expert
opinion and historical data

Dr. Abdul Rauf 18 CCIS-IMAMU

 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
Dr. Abdul Rauf 19 CCIS-IMAMU
 CONSEQUENCE of FAILURE (Cf) for Technology Risk
Value Fall Back Life Cycle Cost Schedule Down Time (DT)
Solution (LCC) Factor 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
Increase LCC confident will Reduce much
meet IOC
Overall Risk Factor = (Pf + Cf) - (Pf * Cf)
* Initial Operational Capability
Example RF = (.1 + .9) - (.1 * .9) = 0.91
20
Dr. Abdul Rauf CCIS-IMAMU
 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.*
Dr. Abdul Rauf 21 CCIS-IMAMU
  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:
1) cost of delays to scheduled dates for deliverables;
2) cost overruns caused by using additional or more expensive
resources;
3) costs incurred or implicit in any compromise to the system’s quality or
functionality.
Dr. Abdul Rauf 22 CCIS-IMAMU
 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

R6 Module testing demonstrates errors or 1 10 10

deficiencies in design

Dr. Abdul Rauf 23 CCIS-IMAMU

 Thanks!

Dr. Abdul Rauf 24 CCIS-IMAMU