Managing Software Project Risk

1. Managing Software Project Risk • By Matthew Heusser • 23 Sept, 2002

2. Overview • Brief Review of the Last Episode • What is Risk? • Analyzing and Capturing Risk • Accounting for Risk • Conclusions

3. Last Time … “No Plan, however perfect, has ever survived initial contact with the enemy.” - Napolean Bonaparte • The Waterfall model doesn’t address the risk that the software will be buggy, or that the software will be late, or over-budget, or lack features, or have integration problems or … anything. • Staged Delivery promises to deliver the product on-time, on-budget, with at least the key features complete.

4. What is risk? • Risk (n) • The possibility of suffering harm or loss; danger. • A factor, thing, element, or course involving uncertain danger; a hazard: “the usual risks of the desert: rattlesnakes, the heat, and lack of water” (Frank Clancy). In Matt’s Words: Risk is the chance that the planned will vary from the actual. As the importance of the project to the organization increases, the importance of managing risk becomes more and more crucial.

5. 3 Risk World-Views The Ostrich The Turtle

6. The Third World-Views • The Killer Rabbit • - The Killer Rabbit doesn’t run from trouble, he looks for it!

7. Analyzing the amount of Risk Donaldson and Siegel, authors of Successful Software Management, offer us a simple exercise to determine how much risk a project has. (See Hand-Out)

8. Risk Metrics - 1 Line up all your risks down the page(*) Project will be late Project will run over-budget High Staff Turnover Project will be low-quality Sub-Contractors will have communication problems Sub-Contractors will have integration problems Customer will refuse to pay Customer will insist on last-minute changes Customer will insist on uncompensated changes (*) - The risk metrics advocated here are covered in detail in Software Engineering: A Practitioner's Guide

9. Risk Metrics – 2 Add a number, 1-10, for the damage caused by the risk, where 1 can be essentially ignored, 5 causes the project to fail, and 10 destroys the organization. (A number is better than no number!) Project will be late 4 Project will run over-budget 4 High Staff Turnover 3 Project will be low-quality 4 Customer will refuse to pay 6 Customer will insist on last-minute changes 3 Customer will insist on uncompensated changes 4 Incomplete Requirements 3 Vague Specifications 2 Sub-Contracters will have communication problems 1 Sub-Contracters will have integration problems 2

10. Risk Metrics – 3 Determine a percentage chance that the event will happen. (Remember, A number is better than no number!) Project will be late 4 90% Project will run over-budget 4 90% High Staff Turnover 3 20% Project will be low-quality 4 80% Customer will refuse to pay 6 10% Customer will insist on last-minute changes 3 30% Customer will insist on uncompensated changes 4 10% Incomplete Requirements 3 50% Vague Specifications 2 60% Sub-Contracters will have communication problems 1 50% Sub-Contracters will have integration problems 2 30%

11. Risk Metrics – 4 Multiply Column 2 by Column 3 to determine risk exposure and sort.

12. The Biggest Risk On Large Projects, the two generally biggest risks will be that the project will be late or over-budget. Staff Salaries cost far more than hardware, software, or leases, so projects that are late are generally also over-budget. Business Plans count on the project being done in, say July, with sales of 1 Million per month. If the project is not done until October, then at the end of the year, the company can only realize sales of 2 millions (instead of 6.) See the problem? Collorary: You must address schedule/cost risk, or risk will address you.

13. Accounting for Risk • The 7-11 Analogy • The Insurance Company Analogy • Fixed Big Contracts Vs. Time and Materials • “If we’re going to take a risk, we’d better be compensated” Risk-Level Est. Charge Risk Adj. Total Cust. Price None $10,000 0% $10,000 Low $10,000 10% $11,000 Medium $10,000 20% $12,000 High $10,000 40% $14,000 These numbers are a good starting point. Ideally, the company would build a history of true cost vs. estimated cost and risk, which would be used when calculating future projects.

14. Anticipating Change • Jerry Weinberg and Quality Software Management • A table of risks like the one above gives a rank order and priority to which risks should be managed and how much time should be spent mitigating which risk. • “Project Tripwires” can be placed in the schedule; you can also learn to look for “bad smells” in the project that hint that things are amiss. • Being aware of risks in advance allows us to move from reacting to problems to anticipating and planning for them.

15. Re-defining Success • Success consists of a series of projects that create growing profits and customer satisfaction • Success is created by committing resources, and adjusting the plan and steering the project to match reality. • In order to get to success, we need to sharpen our senses to notice and deal with “bad smells” in an organization instead of having boundless optimism.

16. Conclusions • Optimism is a force multiplier; unrealistic optimism is just a delaying tactic. Accepting that the plan is going to change is arguably the best way to get a result that is even close to the original plan. • Recognizing that the risks exist is the first step to dealing with them. • If we’re going to pay for risk, we’d better be compensated for it. That’s the only way to cover our costs. • If we’re going to charge for our risks, we’ve got to know what our risk exposure is. • The only “good” way to deal with risk is to be a killer rabbit!

17. References JoelOnSoftware.Com http://www.joelonsoftware.com/articles/NothingIsSimple.html Quality Software Management, by Gerald M. Weinberg Successful Software Development by Donaldson/Siegel DeathMarch by Ed Yourdon (The Complete Software Developers’ Guide to surviving ‘Mission Impossible’ Software Projects) Software Engineering: A Practitioner's Approach by Roger S. Pressman Monty Python and The Holy Grail