Professional Documents
Culture Documents
RISK
MANAGEMENT
Risk Management is a
Continuous Process
Manage Risks
Monitor Execution
Another Model of the
Risk Management Process
Understand
Needs
Generate
Detailed
Plans
Outline of This Chapter
Manage Risks
Monitor Execution
2) Partition into Categories
(analysis)
• 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
Why Partition Into Categories?
Project
Failure
Performance
Staffing Funding ...
Failure
Memory Processor
...
Too Small Too Slow
150
100
Limit
50 Threshold
Estimate
0
Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
7) Develop a Backup or
Contingency Plan
(planning)
Identify what to do if the risk occurs despite
your mitigation efforts
Example:
Risk: memory size exceeded
Contingency Plan:
– switch to a slower but smaller algorithm
– use a more efficient compiler
– use a smaller operating system
– use larger memory size
Frailey’s Method - Risk Control
(4 steps)
8) Review status of risks at periodic reviews
(monitor)
– Metrics
– Changes in impact analysis
9) Take appropriate action when called for
(abatement)
– Closer monitoring
– Contingency activities
10) Track all actions to closure (monitoring)
– Don’t forget about them
11) Update the plan (planning)
– Keep it consistent with current knowledge and status
Beware of Subcontractors and
Co-contractors
• Risk management applies to these as well
• Include risk management elements in
contracts
We want to
Just trust us monitor your
risks
9.2 - Risk Assessment
Mitigation Techniques:
• Use top talent
• Use people who are well matched to the
problem (i.e., they know the application,
tools, etc.)
• Pre-schedule the key people
• Cross training -- so you don’t depend on
heroes
• Team building
Boehm 2: Unrealistic Schedules
and Budgets
Mitigation Techniques:
• Good estimating techniques
– Know before you commit
• Incremental development cycles
• Detailed milestones within each phase
– Spot trouble early
– Provide evidence of progress
• Software reuse
– Don’t build what was built before
• Requirements scrubbing
– Don’t build what is not required
Boehm 3: Developing the
Wrong Software Functions
Mitigation Techniques:
• Mission analysis
– Understand what is supposed to happen
• User surveys and communication
– Know what the user needs and is expecting
• Prototyping
– Try it out - a prototype is worth a million bytes
• Write end-user documentation early in the
project and use as requirements documents
Boehm 4: Developing the
Wrong User Interface
Mitigation Techniques:
• Prototyping
• Task analysis
• Scenario models
• etc,
Boehm 5: Gold Plating
Mitigation Techniques:
• Requirements scrubbing
– Don’t build what is not required
• Cost-benefit analysis
– Determine what counts the most
• Design-to-cost
– Development costs include debugging, error
correction
• Design to life-cycle-cost
– Life cycle costs include maintenance, debugging,
etc.
Boehm 6: Continuing Stream of
Requirements Changes
Mitigation Techniques:
• Establish a high change threshold
– Make it costly to make a change
• Information hiding
– Minimize the impact of change
• Incremental development
– Do the stable requirements first
• Establish bounds for requirements
– Limit the scope of changes
• Monitor requirements stability and completion
– Know the risk of proceeding
Information Hiding
Device
Fo Target
g
When you know the
Requirement: “device must find
range of the “TBD”
target in fog of density TBD.”
requirement, you can
Bounded Requirement: “TBD will make many software
range from .02 to 1.7 densograms” design decisions.
Requirements Stability
Monitoring
Requirements Stability
Manage Risks
Monitor Execution
Example
Risk:
Subcontractor will fail to deliver
Weighted Cost:
$50,000
Mitigation Options:
Do it in-house -- Costs $100,000 extra
Send staff to live with subcontractor - $50,000
Monthly visits -- $12,000
Risk Table After Mitigation
Mitigated
Risk Likelihood Cost
Weighted Cost
Late 0.75 $100,000 $75,000
Hardware
Memory Size 0.50 $50,000 $25,000
Subcontractor $12,500 +
Failure 0.05 $250,000 $12,000
Test Equip. 0.30 $40,000 $12,000
Delay
Requirements 0.99 $5,000 $4,990
Changes
Building Hit 0.0000001 $50,000,000 $5
by Airplane
Risk Plan May Include Tables of
Mitigation, Contingency, etc.
Memory Size X
Subcontractor X
Delayed
etc. X
9.3: Risk Control
• Monitoring
– Watch what is happening
– Watch for signs of danger
• Risk Abatement
– Applying contingency plans
– Minimizing impact
9.3.1: Risk Monitoring
Methods of monitoring:
• Reviews - periodic status reports
– Must be honest reviews, not “dog and pony shows”
• Metrics - data to compare actuals with plans
and past performance
What to monitor:
• All high priority risk items
• Consider cost of monitoring - only monitor
what is worthwhile
How Often to Monitor
Information is Information is
Communicated Received
Information is
Action Analyzed
Not Enough
Productivity is Work Being
Low Done
– Specifications 50
40
Plan
– Requirements defined 30
20
Actual
History
– Requirements tested
10
0
1 2 3 4 5 6 7 8 9 10 11
– etc.
– etc.
• It works for anything that has discrete,
measurable units
Testing Rate Chart
Units Tested
80
70
60
50
40
30 Plan
20 History
10
0
1 2 3 4 5 6 7 8 9 10 11
Testing Rate Chart
Units Tested
80
70
60
50
40
Plan
30
Actual
20 History
10
0
1 2 3 4 5 6 7 8 9 10 11
Testing Rate Chart
Units Tested
80
70
60
50
40 Plan
30 Actual
20 History
10 Projected
0
1 2 3 4 5 6 7 8 9 10 11
Testing Rate Chart
Units Tested
80
70
60
50
Plan
40
Actual
30
History
20 Projected
10 Likely
0
1 2 3 4 5 6 7 8 9 10 11
Another Rate Chart
30 Historical Average
Plan
25
Actual
20 Projected
15
10
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
9.3.2: Risk Abatement
To be Subcontracted
Risk Identification:
• Vendor A: best product, positive attitude, but
in financial jeopardy
• Vendor B: mediocre product, sound finances,
blasé attitude
Analysis and Prioritization
Risk Identification:
• Memory size very limited - might not be
enough
– Compiler is new
– Requirements are unstable
• Processor may be too slow
• Shortage of programmers for this processor
• Schedule very tight
Risk Mitigation
• Memory Size
– Compiler Performance
» evaluation
» backup vendor (different host system)
» assembly language option
– Requirements Stability
» evolutionary lifecycle with prototype phase
» strong requirements control
– Other
» Design hardware to accommodate larger memory
chips
» Use a smaller operating system
Risk Mitigation (continued)
• Speed
– Prototype of key algorithms
– Design to allow faster clock
– Plan to monitor performance regularly, starting with
simulation of design model
– Consider alternative processor design
– Consider use of multiple processors
Risk Mitigation (continued)
1 Risk Assessment
-- done as part of the planning
-- continues indefinitely
-- includes planning for risk control
2 Risk Control
-- done as part of the execution
-- important to respond promptly when monitoring
indicates a problem