Upload
constance-lyons
View
216
Download
1
Tags:
Embed Size (px)
Citation preview
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
3 Software Risk Management
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
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)
4 Software Risk Management
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
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
Software Risk ManagementCopyright © 1995-2004, Dennis J. Frailey,
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
6 Software Risk Management
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
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
7 Software Risk Management
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
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
8 Software Risk Management
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
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
9 Software Risk Management
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
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
Software Risk ManagementCopyright © 1995-2004, Dennis J. Frailey,
All Rights Reserved
Details
11
Software Risk ManagementCopyright © 1995-2004, Dennis J. Frailey,
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
Software Risk ManagementCopyright © 1995-2004, Dennis J. Frailey,
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
Software Risk ManagementCopyright © 1995-2004, Dennis J. Frailey,
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
Software Risk ManagementCopyright © 1995-2004, Dennis J. Frailey,
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
Software Risk ManagementCopyright © 1995-2004, Dennis J. Frailey,
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
Software Risk ManagementCopyright © 1995-2004, Dennis J. Frailey,
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
Software Risk ManagementCopyright © 1995-2004, Dennis J. Frailey,
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
Software Risk ManagementCopyright © 1995-2004, Dennis J. Frailey,
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
Software Risk ManagementCopyright © 1995-2004, Dennis J. Frailey,
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
Software Risk ManagementCopyright © 1995-2004, Dennis J. Frailey,
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
Software Risk ManagementCopyright © 1995-2004, Dennis J. Frailey,
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
February 15, 2004
Software Risk ManagementCopyright © 1995-2004, Dennis J. Frailey,
All Rights Reserved
Risk Control
Things You Do During Project Execution
23
Software Risk ManagementCopyright © 1995-2004, Dennis J. Frailey,
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
Software Risk ManagementCopyright © 1995-2004, Dennis J. Frailey,
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
Software Risk ManagementCopyright © 1995-2004, Dennis J. Frailey,
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
Software Risk ManagementCopyright © 1995-2004, Dennis J. Frailey,
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 ManagementCopyright © 1995-2004, Dennis J. Frailey,
All Rights Reserved
You Cannot Prevent All Risks
But you can Manage Them