1. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 1 1/11/2004 Day 3, Part 3 Software Risk Management

2. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 2 1/11/2004 Outline Overview of the Risk Management Process Risk Assessment Risk Control Risk Examples The Risk Management Plan

3. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 3 1/11/2004 The Overall Planning Cycle Analyze Job Manage Risks Execute Generate Detailed Plans Generate Initial Plans Measure, Manage Productivity and Quality

4. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 4 1/11/2004 Software Management: A Framework for Risk Management Software Development Risk Management Project Management

5. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 5 1/11/2004 Another Model of the Risk Management Process Risk Management Plan Execute Measure Engineer Quality

6. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 6 1/11/2004 What is a Risk? Something that might go wrong with the project, the product or the process When stating a risk, be sure 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

7. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 7 1/11/2004 Other Examples “Lack of familiarity with the language” < states a cause but no problem “Incorrect software due to lack of familiarity with the language” < states a product problem and a cause “Fail to meet schedule due to lack of familiarity with the language” < states a project problem and a cause

8. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 8 1/11/2004 The Risk Management Process: 1) Risk Assessment (4 activities) 2) Risk Control (2 activities)

9. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 9 1/11/2004 1) Risk Assessment (This is Done as part of planning) A) Risk Identification - What are the risks? B) Risk Analysis - What is the likelihood & impact? C) Risk Prioritization - Which risks are most serious? D) Risk Planning & Mitigation - Minimizing impact

10. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 10 1/11/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

11. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 11 1/11/2004 2) Risk Control (This is done as part of project execution) A) Risk Monitoring - Watching to see if risks happen B) Risk Abatement - Counteracting risks - Taking contingency actions

12. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 12 1/11/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.

13. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 13 1/11/2004 Risk Management Methods The following methods will be discussed: 1) Barry Boehm’s Method –Widely known –Very pragmatic approach –Combines assessment with control 2) Dennis Frailey’s Method –Somewhat more comprehensive –Derived from DoD standards for defense system software development

14. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 14 1/11/2004 Top 10 Risks on Project Alpha 1. Staffing 2. Late Hardware 3. Requirements Definition 4. Real-time perf- Boehm’s Method of Risk Management (5 steps) Risk Assessment (steps 1-2): 1) Identify the top 10 risk items (identification, analysis and prioritization) 2) Present a plan to resolve each of the top 10 items (mitigation; planning for control)

15. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 15 1/11/2004 Boehm’s Method (continued) Risk Control (steps 3-5): 3) Update the list and the plan monthly (monitoring) 4) Highlight the risk items at monthly project reviews (monitoring) 5) Initiate corrective action for risks that occur ( abatement) [6) Follow-up until the issue is resolved]

16. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 16 1/11/2004 Frailey’s Method of Risk Management (11 steps) Risk Assessment (steps 1-7) –Identification (Step 1) –Analysis (Step 2- 4) –Prioritization (Step 5) –Planning (Step 6,7) Risk Control (steps 8-11) –Monitor (Step 8, 10) –Abatement (Step 9) –Planning (Step 11)

17. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 17 1/11/2004 Risk Assessment Frailey Method (steps 1-7)

18. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 18 1/11/2004 1) Identify all Risk Elements (risk identification) Risk Elements consist of: –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

19. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 19 1/11/2004 Notes Most risk identification is performed as a part of other planning processes (see the previous chapters in these notes) But it is also good to have a pro-active attempt to identify all risks in case something “fell through the cracks”

20. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 20 1/11/2004 Risk Identification Meeting A supplementary meeting to identify risks –Some may have been overlooked –The meeting also helps to focus attention on risk issues Identify the patterns of risk –Risk patterns change over the lifecycle –For example, cost estimating risks occur early, whereas risks of staff burnout occur later

21. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 21 1/11/2004 Recall How All Planning Activities Identify Risks Analyze Job Manage Risks Execute Generate Detailed Plans Generate Initial Plans Measure, Manage Productivity and Quality

22. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 22 1/11/2004 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

23. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 23 1/11/2004 Why Partition Into Categories? Risks may need to be prioritized as demanded by the situation –“continue at any cost” vs. “only do if low cost” Different categories of risks may require different mitigation approaches –Technical risks may require performance analysis –Schedule risks may require process changes

24. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 24 1/11/2004 Other Reasons to Partition Risks into Categories Different people may be concerned about different risks –Technical lead vs. –Finance manager vs. –End user waiting for delivery Different people may be responsible for different risks

25. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 25 1/11/2004 3) Identify Contributing Factors (Analysis) Many risks can occur in several ways If you aren’t careful, you will only be looking for one of the ways

26. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 26 1/11/2004 Example of Multiple Contributing Factors Risk: Not enough memory to hold the software Possible Contributing Factors (Causes): Size of computer memory Expertise of programming staff Efficiency of compiler Choice of algorithms Operating system

27. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 27 1/11/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)

28. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 28 1/11/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

29. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 29 1/11/2004 4) Identify Potential Risk Monitoring & Mitigation Plans (Analysis) This must be done for each contributing factor See next slides for examples

30. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 30 1/11/2004 Potential Risk Mitigation Plan 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

31. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 31 1/11/2004 Multiple Risks with One Approach Risk: memory size inadequate Factor: Compiler produces bloated code Factor: Inexperienced programmers Potential mitigation that applies to both: Select a larger memory size Potential monitoring that applies to both: Track size estimates monthly Update at each major milestone

32. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 32 1/11/2004 5) Rank and Prioritize Each Risk (Prioritization) Prioritize on the basis of probability (how likely) and impact You cannot prevent all risks - focus on the big ones

33. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 33 1/11/2004 6) Identify Monitoring Procedures for Each Risk (Planning for control) 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

34. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 34 1/11/2004 7) Develop a Contingency Plan (Planning) 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

35. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 35 1/11/2004 Risk Control Frailey Method (steps 8-11)

36. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 36 1/11/2004 Review Status and Take Action (Steps 8, 9) 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

37. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 37 1/11/2004 “Do Your Homework” (Steps 10, 11) 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

38. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 38 1/11/2004 Whatever Method You Use It should be possible to see a thread for each identified risk: –Risk –Risk Factors / Causes (there may be many) –Evidence –Priority –Mitigation –Monitoring –Contingency

39. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 39 1/11/2004 Beware of Subcontractors and Co-contractors Risk management applies to these as well Include risk management elements in contracts We want to monitor your risks Just trust us

40. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 40 1/11/2004 Risk Assessment

41. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 41 1/11/2004 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 and your plans for managing them –Communicates responsibilities to all affected parties Update with changes in current risks & their impact/likelihood of occurrence

42. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 42 1/11/2004 Risk Identification The First Step of Risk Assessment We have seen how all management activities, especially planning activities, serve to identify risks It helps if you know what to look for Several authors have talked about risks associated with software development

43. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 43 1/11/2004 Boehm’s Top Ten Software Risks This is Boehm’s list, based on experience with many projects in the 1960-1980 time period He also provides management techniques for mitigating them... Your project must define its own list But this is a good place to start looking

44. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 44 1/11/2004 1) Personnel Shortfalls 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

45. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 45 1/11/2004 Use 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 2) Unrealistic Schedules & Budgets

46. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 46 1/11/2004 3) Developing the Wrong Software Functions Mission analysis –Understand what is supposed to happen User surveys and communication –Know what the user needs expects Prototyping –Try it out Document the end user needs early in the project & use as requirements documents

47. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 47 1/11/2004 4) Developing the Wrong User Interface Prototyping –Involve the user in trying it out Task analysis Scenario models etc,

48. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 48 1/11/2004 5) Gold Plating 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.

49. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 49 1/11/2004 6) Continuing Stream of Requirements Changes Establish a high change threshold –Make it costly to make a change Information hiding Incremental development –Do the stable requirements first Establish bounds for requirements Monitor requirements stability & completion –Know the risk of proceeding

50. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 50 1/11/2004 7) Shortfalls in Purchased Software/Hardware Benchmarking –Learn what is the best Inspections –Make sure it is in good shape before you buy –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.

51. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 51 1/11/2004 8) Shortfalls in Externally- Performed Tasks Subcontract management 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

52. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 52 1/11/2004 9) Real-time Performance Shortfalls Simulation Benchmarking Modeling Prototyping Instrumentation Tuning

53. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 53 1/11/2004 10) Straining the Limits of Computer Science Technical analysis Cost-benefit analysis Prototyping Reference Checking

54. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 54 1/11/2004 Risk Analysis & Prioritization Which ones are Important? A popular method is to compute two numbers for each risk: –How likely is it to happen (a probability from 0 to 1) –How much will it cost if it happens (dollars) Then make a table showing risks, likelihood, cost, and weighted cost (likelihood * cost)

55. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 55 1/11/2004 Risk Analysis Table

56. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 56 1/11/2004 Prioritized Risk Analysis Table

57. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 57 1/11/2004 Alternative Risk Analysis Table Note that this method produced a different ordering, but the extreme cases came out in the same order.

58. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 58 1/11/2004 WARNING This method of risk prioritization has many risks itself! Not all risks can be quantified in terms of dollar impact Estimates of impact are very subjective Impacts change over time -- must be revisited Risk mitigation techniques may have risks of their own

59. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 59 1/11/2004 Risk Mitigation

60. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 60 1/11/2004 Risk Mitigation 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

61. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 61 1/11/2004 This is the Step where you Impact the Planning Process Analyze Job Manage Risks Execute Generate Detailed Plans Generate Initial Plans Measure, Manage Productivity and Quality

62. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 62 1/11/2004 Mitigation 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

63. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 63 1/11/2004 Risk Table After Mitigation

64. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 64 1/11/2004 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

65. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 65 1/11/2004 Risk Control

66. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 66 1/11/2004 Risk Control Monitoring –Watch what is happening –Watch for signs of danger Risk Abatement –Applying contingency plans –Minimizing impact

67. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 67 1/11/2004 Methods of Risk Monitoring Reviews –Periodic status reports –Must be honest reviews, not “dog and pony shows” Metrics –Data to compare actuals with plans and past performance

68. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 68 1/11/2004 What to Monitor All high priority risk items Consider cost of monitoring –Monitor only what is worthwhile Consider the changes caused by measurement to the organization & the process

69. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 69 1/11/2004 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

70. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 70 1/11/2004 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

71. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 71 1/11/2004 Don’t Monitor Too Often Demotivates people Costs a lot Robs resources from productive activities

72. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 72 1/11/2004 Don’t Monitor in 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

73. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 73 1/11/2004 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

74. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 74 1/11/2004 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

75. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 75 1/11/2004 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

76. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 76 1/11/2004 Things to Watch Out For - IV Failing to get the data because of high overhead –Automate collection –Consider using a separate metrics collection/analysis staff to minimize impact on development staff but not if it destroys teamwork

77. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 77 1/11/2004 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

78. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 78 1/11/2004 Things to Watch Out For - VI Failure to trust past performance –Your “track record” is your most reliable indicator

79. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 79 1/11/2004 The Learning Process Information is Communicated Information is Received Information is Analyzed Action Each step offers many opportunities for error

80. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 80 1/11/2004 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

81. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 81 1/11/2004 Rate Chart - Actual vs. Plan Shows actual vs. planned progress for some artifact being produced –Coded units –Tested units –Inspected units –Specifications –Requirements defined –Requirements tested –etc. Rate charts work for anything that has discrete, measurable units

82. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 82 1/11/2004 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

83. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 83 1/11/2004 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!

84. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 84 1/11/2004 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

85. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 85 1/11/2004 The Risk Management Plan

86. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 86 1/11/2004 Risk Management Plan A documented plan that communicates the risks and the plans for managing them to everyone concerned It also helps everyone know what to do during a crisis The plan should be reviewed and updated from time to time

87. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 87 1/11/2004 Goals of a Risk Management Plan To show all concerned that you … … understand the risks of the project … know how to manage those risks … have taken appropriate actions to mitigate risks … have plans in place to monitor those risks The purpose of the risk management plan is not to deny that you have risks, to avoid mentioning important risks, or to belittle the importance of key project risks.

88. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 88 1/11/2004 Contents of a Risk Management Plan The risk management process to be used during execution of the project Results of initial risk analysis –Analysis and priorities –Key risks identified –Actions taken to mitigate key risks Minimize impact Reduce likelihood Monitoring and abatement plans

89. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 89 1/11/2004 Sample Process Description We will hold a monthly meeting attended by … at which we will –Review actions from previous meetings –Review the status of the top 10 risks –Re-prioritize the risks –Assign actions as required Roles during this meeting –Record keeper –Facilitator –Etc. We will revisit the plan and consider an update every … months

90. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 90 1/11/2004 Sample Chart Showing Risk Analysis and Prioritization Be sure to explain WHY each risk is important – provide EVIDENCE that it is as likely or as expensive as indicated.

91. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 91 1/11/2004 Sample Risk Occurrence Chart Etc. Med Hi Space too small Etc.Med Low Memory too small Etc.Hi Med Low Turnover …JMAMFJ LikelihoodRisk A chart like this helps you know when to expect certain risks to be more likely.

92. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 92 1/11/2004 Sample Description of a Risk Risk: high turnover of key staff Evidence: recent turnover rates are 22%, competition from growing companies in town Priority: Red (urgent) Likelihood is 75% Impact is high

93. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 93 1/11/2004 Sample Description of a Risk (continued) Mitigation Plans and Actions: Increased salaries 15% Giving employees a bonus for successful completion on time Monitoring: Will monitor project turnover rate monthly and take action if exceeds 10% Contingency plans: Increased hiring rates, use of contract labor

94. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 94 1/11/2004 Chart Showing Links to Metrics Etc. Rqmts Etc.  Cost Etc.  Schedule Etc.  Memory Etc.  Staffing Etc. Mor ale Earn ed Value Turn over Size MetricsRisks

95. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 95 1/11/2004 Opportunities An opportunity is the opposite of a risk –Example: we might relieve schedule pressure by reusing the data communication modules from another project Opportunities can be analyzed the same way that risks can Many organizations to risk / opportunity planning, analysis, etc. together as one activity

96. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 96 1/11/2004 Summary Risk Management 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

97. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 3, Part 3, Page 97 1/11/2004 References Risk Management Boehm, Barry, Software Risk Management, IEEE Computer Society Press, 1989, ISBN 0- 8186-8906-4 Jones, Capers, Assessment and Control of Software Risks, Yourdon Press, 1994.