1. Copyright 1995-2009, Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M26 - Version 9.01 SMU CSE 7315 Planning and Managing a Software Project Module 26 The Risk Management Process, In Detail

2. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 2 Objective of This Module  To discuss the details of the risk management process

3. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 3 The Risk Management Process In Detail  Risk Assessment –Risk Identification –Risk Analysis –Risk Prioritization –Risk Planning & Mitigation (contingency planning)  Risk Control –Risk Monitoring –Risk Abatement

4. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 4 Risk Assessment  Goal: understand what the risks are, what they mean, and how best to manage them  Method: develop a risk management plan -- documents your risks -- documents your plans for managing them -- communicates responsibilities to all affected parties  The plan must be updated as new risks are identified  For each risk, the likelihood and impact change over time

5. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 5 The Risk Management Process In Detail  Risk Assessment –Risk Identification –Risk Analysis –Risk Prioritization –Risk Planning Mitigation (contingency planning)  Risk Control –Risk Monitoring –Risk Abatement 

6. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 6 Risk Identification The First Step of Risk Assessment  We have seen how all management activities, especially planning activities, serve to identify risks  And we discussed the value of a risk identification brainstorming meeting  It helps if you know what to look for  Several authors have talked about risks associated with software development

7. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 7 Boehm’s Top Ten Software Risks (and management techniques for mitigating them)  This is Boehm’s list, based on experience with many projects in the 1960-1980 time period  Your project must define its own list  But this is a good place to start looking

8. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 8 Possible Exam Question  Consider a particular situation (provided with the exam). What risks apply? (careful analysis shows that these three risks are of greatest concern...)  List of Boehm’s top ten risks

9. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 9 Boehm 1: Personnel Shortfalls 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

10. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 10 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

11. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 11 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

12. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 12 Boehm 4: Developing the Wrong User Interface Mitigation Techniques:  Prototyping  Task analysis  Scenario models  etc,

13. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 13 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.

14. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 14 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

15. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 15 Information Hiding  A programming technique whereby information is made available only where it is required  This minimizes the impact of change Student Records (details known only to access program) Access Program Student Data Base Update.. Display.. Examine.. Compute..

16. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 16 Requirements Bounds Device Fog Requirement: “device must find target in fog of density TBD.” Bounded Requirement: “TBD will range from.02 to 1.7 densograms” When you know the range of the “TBD” requirement, you can make many software design decisions. When you know the range of the “TBD” requirement, you can make many software design decisions. Target

17. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 17 Requirements Stability Monitoring CDRPDR

18. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 18 Boehm 7: Shortfalls in Purchased Software/Hardware Mitigation Techniques:  Benchmarking –Learn what is the best  Inspections –Make sure it is in good shape before you buy it  Reference Checking –Are they able to do the work? –Do they deliver?  Compatibility Analysis –Make sure it fits with your standards, tools, documentation requirements, etc.

19. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 19 Boehm 8: Shortfalls in Externally-performed Tasks Mitigation Techniques:  Subcontract management (a KPA for Level 2 in the SEI CMMI)  Reference checking  Pre-award audits and capability evaluations  Award fee contracts –Reward or bonus if satisfied  Competitive design or prototyping  Team building –Make them want you to succeed

20. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 20 Boehm 9: Real-time Performance Shortfalls Mitigation Techniques:  Simulation  Benchmarking  Modeling  Prototyping  Instrumentation  Tuning

21. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 21 Boehm 10: Straining the Limits of Computer Science Mitigation Techniques:  Technical analysis  Cost-benefit analysis  Prototyping  Reference Checking

22. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 22 Possible Exam Question  List four of Boehm’s “top ten” risks.  For each of the above, list three methods of risk mitigation  Explain each of the risks and each of the mitigation techniques

23. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 23 Possible Exam Question  Consider the risk mitigation technique of prototyping. Describe this technique, and list three risks that this technique helps to mitigate. For each explain how prototyping mitigates the risk.

24. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 24 The Risk Management Process In Detail  Risk Assessment –Risk Identification –Risk Analysis –Risk Prioritization –Risk Planning & Mitigation (contingency planning)  Risk Control –Risk Monitoring –Risk Abatement  

25. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 25 Risk Analysis & Prioritization Which Risks are Most Important?  A popular method is to compute two numbers for each risk: –How likely is it to happen (a probability from 0 to 1 or a ranking from low to high or 1 to 10) –How much will it cost if it happens (dollars, impact)  Then make a table showing risks, likelihood, cost, and weighted cost (likelihood * cost)

26. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 26 Risk Analysis Table

27. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 27 Prioritized Risk Analysis Table

28. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 28 Alternative Risk Analysis Table (1-10 scale for likelihood & impact) Note that this method produced a different ordering, but the extreme cases came out in the same order.

29. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 29 Another Way to Show Risk Prioritization ImpactImpact HighHigh Med Med LowLow LowMediumHigh Probability of Occurrence X Subcontractor Failure Late Hardware X Memory Size X Test Equipment Delay X Requirements Change X

30. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 30 WARNING These methods of risk prioritization have many risks themselves!  Not all risks can be quantified in terms of dollar impact  Estimates of impact and probability are highly subjective  Impacts change over time – risks must be revisited from time to time  Risk mitigation techniques may have risks of their own

31. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 31 The Risk Management Process In Detail  Risk Assessment –Risk Identification –Risk Analysis –Risk Prioritization –Risk Planning & Mitigation (contingency planning)  Risk Control –Risk Monitoring –Risk Abatement 

32. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 32 Risk Mitigation Minimizing the Impact or the Likelihood  Taking actions to reduce the likelihood or net impact of a risk  We saw many such actions in reviewing Boehm’s list of risks  Each potential action must be evaluated in terms of its cost vs. the potential impact

33. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 33 This is the Step Where You Impact the Planning Process Manage Risks Define the Approach Generate Detailed Plans Understand the Need Execute and Monitor

34. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 34 Mitigation Example Risk: Project delay or failure because 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

35. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 35 Risk Table After Mitigation

36. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 36 Showing the Effects of Risk Mitigation ImpactImpact HighHigh Med Med LowLow LowMediumHigh Probability of Occurrence X Subcontractor Failure Late Hardware X Memory Size X Test Equipment Delay X Requirements Change X X X X X X

37. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 37 Risk Plan May Include Tables of Mitigation, Contingency, etc. Methods Risks Memory Size Bench mark Extra Hardware Backupetc.Proto type Subcontractor Delayed Late Test Equip. etc. Late HardwareX X X X X X

38. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 38 The Risk Management Process In Detail  Risk Assessment –Risk Identification –Risk Analysis –Risk Prioritization –Risk Planning & Mitigation (contingency planning)  Risk Control –Risk Monitoring –Risk Abatement  

39. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 39 Risk Control  Monitoring –Watch what is happening –Watch for signs of danger  Risk Abatement –Applying contingency plans –Minimizing impact

40. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 40 Risk Monitoring Methods of monitoring:  Reviews - periodic status reports –Must be honest reviews, not “dog and pony shows”  Measurements - data to compare actuals with plans and past performance What to monitor:  All high priority risk items  Consider the cost of monitoring –Only monitor what is worthwhile

41. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 41 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

42. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 42 How Often to Monitor  It depends on priority - you must plan. For example: –Critical items daily or weekly –Normal items weekly or monthly –Minor items quarterly  Monitoring too often costs money and slows down the process

43. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 43 Watch Known Danger Points  Monitor status at key milestones or progress points –Are we where we should be by now? We always have a flurry of changes prior to CDR

44. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 44 Don’t Monitor Too Often or in Too Much Detail  Too often –De-motivates people –Costs a lot –Robs resources from productive activities  Too much detail (overly precise) –Costs a lot –Does not give significant additional information –May generate a lot of misleading numbers Late by 2.7321 weeks is not much different from late by 3 weeks

45. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 45 Things to Watch Out For - I Hiding the facts to save face –The purpose of monitoring is to manage properly, not to find fault with individuals –Individuals must trust that you will use the metrics properly to fix the process, not to punish the messengers –One solution is self-measurement -- have the individuals measure and monitor themselves without communicating higher except on an aggregate scale or with big problems that they cannot handle

46. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 46 Things to Watch Out For - II Hiding the facts to save the project –Egos and jobs of technical staff vs. judgment of management vs. pocketbook of sponsor –This can get very political and very complex

47. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 47 Things to Watch Out For - III Failure to get the data because of fear, overconfidence, or other psychological factors –Be careful of human nature –Focus on teaming, responsibility, and professional behavior

48. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 48 Things to Watch Out For - IV Failing to get the data because of high overhead cost –Automate collection –Consider using a separate data collection/analysis staff to minimize impact on development staff  but not if it destroys teamwork

49. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 49 Things to Watch Out For - V Misinterpretation of data –Any number can be interpreted in many ways  The “three ways to get it wrong” rule –Be prepared to ask lots of questions –Define standard measures and methods of graphing data to minimize unintentional misinterpretation –Educate everyone in statistics

50. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 50 Things to Watch Out For - VI Failure to trust past performance –Your “track record” is your most reliable indicator

51. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 51 The Learning Process Information is Communicated Information is Received Information is Analyzed Action Each step offers many opportunities for error

52. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 52 Example of Misinterpretation Productivity is Low Not Enough Work Being Done Not Working Hard Enough More Overtime Perhaps the Real Problem is Too Much Overtime Already

53. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 53 Rate Chart Actual vs. Plan  A Rate Chart shows actual vs. planned progress for some artifact being produced –Coded units –Tested units –Inspected units –Specifications –Requirements defined –Requirements tested –etc.  It works for anything that has discrete, measurable units

54. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 54 Testing Rate Chart

55. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 55 Testing Rate Chart

56. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 56 Testing Rate Chart

57. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 57 Testing Rate Chart

58. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 58 Another Rate Chart

59. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 59 The Risk Management Process In Detail  Risk Assessment –Risk Identification –Risk Analysis –Risk Prioritization –Risk Planning & Mitigation (contingency planning)  Risk Control –Risk Monitoring –Risk Abatement  

60. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 60 Risk Abatement  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

61. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 61 Risk Abatement (continued)  Act promptly when necessary –Establish action plans before they are needed –Learn the plan (fire drills) -- there may be no time in an emergency  Use backup plans if needed –Develop them during the planning phase –Practice them too!

62. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 62 Risk Abatement (continued)  Let the team participate in the planning –Their cooperation is necessary for success –Their ownership of the plan will improve chances of cooperation

63. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 63 The Risk Thread Should be Visible in your Plan  Risk  Evidence  Analysis  Risk Factors / Causes –There may be many  Priority  Mitigation  Monitoring  Abatement/Contingency

64. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 64 Summary of Module 1) Risk Assessment –Done as part of project planning –Continues throughout the project –Includes planning for risk control 2) Risk Control –Done as part of project execution –You must respond promptly when monitoring indicates a problem A risk management plan is an important part of planning

65. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 65 Possible Exam Questions  Explain the difference between risk mitigation and risk abatement (risk contingency)  Explain why a risk management plan should be documented  Explain why a risk management plan should be periodically revisited  Explain why one would go to all the trouble to write a risk management plan when it tells your manager and your customer that you have a risky project

66. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 66 Possible Exam Questions  Define an opportunity management process based on what you have learned about risk management

67. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M26 - Version 9.01 67 END OF MODULE 26