1. February 15, 2004 Software Risk Management Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Simple Steps for Effective Software Risk Management Dennis J. Frailey

2. 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. 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. 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

5. February 15, 2004 Software Risk Management Copyright © 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. 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. 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. 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. 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.

10. February 15, 2004 Software Risk Management Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Details

11. 11 Software Risk Management Copyright © 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. 12 Software Risk Management Copyright © 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. 13 Software Risk Management Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved February 15, 2004 B) Risk Analysis Partition 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. 14 Software Risk Management Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved February 15, 2004 B) Risk Analysis Identify 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. 15 Software Risk Management Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved February 15, 2004 Example of Multiple Contributing Factors Risk: Not enough memory to hold the software Possible 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. 16 Software Risk Management Copyright © 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. 17 Software Risk Management Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved February 15, 2004 A Sample Risk Hierarchy StaffingFunding... Processor Too Slow... Size of Memory Programming Experience Compiler Efficiency Choice of Algorithms Memory Too Small Performance Failure Project Failure

18. 18 Software Risk Management Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved February 15, 2004 C) Risk Prioritization Rank the Risks Prioritize on the basis of probability (how likely) and impact You cannot prevent all risks - focus on the big ones

19. 19 Software Risk Management Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved February 15, 2004 D) Risk Mitigation Doing Something About Risks BEFORE they happen Risk: memory size inadequate Factor: Compiler produces bloated code Potential mitigation: Choose a more efficient compiler Negotiate improvements with vendor Factor: Inexperienced programmers Potential mitigation: Training program Use more experienced programming staff

20. 20 Software Risk Management Copyright © 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

21. 21 Software Risk Management Copyright © 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 exceeded Contingency Plan: Switch to a slower but smaller algorithm Use a more efficient compiler Use a smaller operating system Use larger memory size

22. February 15, 2004 Software Risk Management Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Risk Control Things You Do During Project Execution

23. 23 Software Risk Management Copyright © 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. 24 Software Risk Management Copyright © 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. 25 Software Risk Management Copyright © 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. 26 Software Risk Management Copyright © 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

27. February 15, 2004 Software Risk Management Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved You Cannot Prevent All Risks But you can Manage Them