february 15, 2004 software risk management copyright © 1995-2004, dennis j. frailey, all rights...

February 15, 2004

Software Risk ManagementCopyright © 1995-2004, Dennis J. Frailey,

All Rights Reserved

Simple Steps for Effective Software Risk Management

Dennis J. Frailey

2 Software Risk Management

Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved

February 15, 2004

Objective

• To present some basic risk management techniques – Some of these are not widely used

• And some basic elements of a risk management plan



February 15, 2004

Frequent Problems

• No consensus on what the real risks are

• Different perspectives on necessary level of risk decomposition

• Vague processes for risk management

• Poor risk assessment• Confusion between mitigation and

abatement (contingency actions)



February 15, 2004

Recommended Solutions

• A clear risk management process– Defining risk properly– A consistent analysis/assessment procedure– Specific steps for identification, analysis,

mitigation, monitoring and abatement

• A good risk management plan– Defining who does what, when and how– Checklists to make sure the process is

followed– Decomposition to a level where specific

causes are identified

February 15, 2004


All Rights Reserved

The Risk Management Process

1) Risk Assessment • The things you do as you plan

your project

2) Risk Control• The things you do during the

project



February 15, 2004

1) Risk Assessment

A) Risk Identification- Clearly stating the real risks

B) Risk Analysis- Causes, categories, impact

C) Risk Prioritization- Which risks should get the attention?

D) Risk Planning & Mitigation- Minimizing impact- Planning contingency actions



February 15, 2004

Risk Management Plan Should Indicate …

• What process you have already followed to identify, analyze, prioritize, and mitigate risks– What risks you have identified• And the evidence that you base this on

– How you have analyzed these risks– How you have prioritized them– How you have mitigated them



February 15, 2004

2) Risk Control

A) Risk Monitoring

- Watching to see if risks happen

B) Risk Abatement

- Counteracting risks

- Taking contingency actions as needed

C) Updating the Plans



February 15, 2004

Risk Management Plan Should Indicate …

• What process you will follow during the project to control risks– How you will monitor them (this

usually ties strongly to your measurement plan)

– How you will abate risks (contingency plans, ongoing mitigation)

• And what process you will use to keep the plan up to date– Ongoing assessment, updating of

plans, priorities, etc.

February 15, 2004


All Rights Reserved

Details

11


All Rights Reserved

February 15, 2004

A) Risk Identification

• Risks are:– things that can go wrong – patterns of risk change over the

lifecycle• for example, cost estimating risks occur

early, whereas risks of staff burnout occur later

• If it has already happened, or is certain to happen, it is a problem, not a risk!– You should be discussing your action plan

for managing the problem

12


All Rights Reserved

February 15, 2004

How to State a Risk• Indicate the problem and the cause– “The project might be late”

This doesn’t say much. Why might it be late?

– “There might be employee turnover”So what? This states the cause but not the

problem

– “The project might be late due to employee turnover”Good. This states both the cause and the

problem

13


All Rights Reserved

February 15, 2004

B) Risk AnalysisPartition Into Categories

• Sample Categories:-- cost risks

-- schedule risks -- other management risks -- technical risks -- other risks specific to the situation,

such as safety or security risks• One Risk may have multiple categories– Estimating inaccuracies can lead to cost and

schedule risks

14


All Rights Reserved

February 15, 2004

B) Risk AnalysisIdentify Contributing Factors

• Many risks can occur in several ways (from several causes)

• If you aren’t careful, you will only be looking for one of the ways

• You need to get to the actual causes

15


All Rights Reserved

February 15, 2004

Example of Multiple Contributing Factors

Risk: Not enough memory to hold the softwarePossible Contributing Factors (causes): Size of computer memory is too small Expertise of programming staff too low Inefficiency of compiler Choice of algorithms – too large Operating system requires too much space

16


All Rights Reserved

February 15, 2004

Using a Hierarchy of Contributing

Factors• Each risk can be seen as a

contributing factor to a larger risk• The top level risk is that the

project will fail• Sometimes it helps to use a

hierarchy to organize risks and contributing factors

• (See next slide)

17


All Rights Reserved

February 15, 2004

A Sample Risk Hierarchy

Staffing Funding . . .

ProcessorToo Slow

. . .

Size ofMemory

ProgrammingExperience

CompilerEfficiency

Choice ofAlgorithms

MemoryToo Small

PerformanceFailure

ProjectFailure

18


All Rights Reserved

February 15, 2004

C) Risk PrioritizationRank the Risks

• Prioritize on the basis of probability (how likely) and impact

Risk Likelihood Cost

Weighted

CostLate Hardware 75% 100,000 75,000

Sub-Contractor Failure 20% 250,000 50,000

Memory Size 50% 50,000 25,000

Test Equipment Delay 30% 40,000 12,000

Requirements Changes 99% 5,000 4,950

Building hit by plane 0.0001% 50,000,000 50

You cannot prevent all risks - focus on the big ones

19


All Rights Reserved

February 15, 2004

D) Risk MitigationDoing Something About Risks

BEFORE they happen

Risk: memory size inadequateFactor: Compiler produces bloated codePotential mitigation:

•Choose a more efficient compiler•Negotiate improvements with vendor

Factor: Inexperienced programmersPotential mitigation:

•Training program •Use more experienced programming staff

20


All Rights Reserved

February 15, 2004

Identify Monitoring Procedures for Each Risk

• Determine how to tell if it is a problem; how frequently to monitor; etc.

• Example: monitor projected size vs. memory limits on a monthly basis

0

50

100

150

Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec

Limit Threshold Estimate

21


All Rights Reserved

February 15, 2004

Develop a Contingency Plan• Identify what to do if the risk occurs

despite your mitigation efforts

Risk: memory size exceededContingency Plan:

• Switch to a slower but smaller algorithm• Use a more efficient compiler • Use a smaller operating system• Use larger memory size

23


All Rights Reserved

February 15, 2004

Review Status and Take Action

• Review status of risks at periodic reviews (Monitor)– Measurements– Changes in impact analysis

• Take appropriate action when called for (Abatement)– Closer monitoring– Contingency activities

24


All Rights Reserved

February 15, 2004

Risk Monitoring• Establish thresholds so you know when to

act– Beware of the “frog in the water” problem

– Historical experience is a good basis to judge when things are getting out of hand

25


All Rights Reserved

February 15, 2004

“Do Your Homework”

• Track all actions to closure (Monitoring)– Don’t forget about them

• Update the plan (Planning)– Keep it consistent with current knowledge

and status– Risks and their priorities will change as you

progress through the project

26


All Rights Reserved

February 15, 2004

The Risk Thread Should be Visible in your Plan

• Risk • Evidence• Analysis• Risk Factors / Causes– There may be many

• Priority• Mitigation• Monitoring• Abatement/Contingency

february 15, 2004 software risk management copyright © 1995-2004, dennis j. frailey, all rights...

Documents

risk identification

risk monitoring

risk management plan

good risk management

clear risk management

frailey slide

d risk planning mitigation

impact c risk prioritization