Presentation on theme: "Managing Software Project Risk By Matthew Heusser 23 Sept, 2002."— Presentation transcript:
Managing Software Project Risk By Matthew Heusser 23 Sept, 2002
Overview uBrief Review of the Last Episode uWhat is Risk? uAnalyzing and Capturing Risk uAccounting for Risk uConclusions
Last Time … uThe 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. u Staged Delivery promises to deliver the product on-time, on-budget, with at least the key features complete. “No Plan, however perfect, has ever survived initial contact with the enemy.” - Napolean Bonaparte
What is risk? Risk (n) yThe 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.
3 Risk World-Views The Ostrich The Turtle
The Third World-Views zThe Killer Rabbit x- The Killer Rabbit doesn’t run from trouble, he looks for it!
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)
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
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 late4 Project will run over-budget4 High Staff Turnover3 Project will be low-quality4 Customer will refuse to pay6 Customer will insist on last-minute changes3 Customer will insist on uncompensated changes4 Incomplete Requirements3 Vague Specifications2 Sub-Contracters will have communication problems1 Sub-Contracters will have integration problems2
Risk Metrics – 3 Determine a percentage chance that the event will happen. (Remember, A number is better than no number!) Project will be late490% Project will run over-budget490% High Staff Turnover320% Project will be low-quality480% Customer will refuse to pay610% Customer will insist on last-minute changes330% Customer will insist on uncompensated changes410% Incomplete Requirements350% Vague Specifications260% Sub-Contracters will have communication problems150% Sub-Contracters will have integration problems2 30%
Risk Metrics – 4 Multiply Column 2 by Column 3 to determine risk exposure and sort.
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.
Accounting for Risk zThe 7-11 Analogy zThe Insurance Company Analogy zFixed Big Contracts Vs. Time and Materials “If we’re going to take a risk, we’d better be compensated” Risk-LevelEst. Charge Risk Adj. Total Cust. Price None$10,0000%$10,000 Low$10,00010%$11,000 Medium$10,00020%$12,000 High$10,00040%$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.
Anticipating Change zJerry Weinberg and Quality Software Management zA 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. z“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. z Being aware of risks in advance allows us to move from reacting to problems to anticipating and planning for them.
Re-defining Success zSuccess consists of a series of projects that create growing profits and customer satisfaction zSuccess is created by committing resources, and adjusting the plan and steering the project to match reality. zIn 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.
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. zIf we’re going to pay for risk, we’d better be compensated for it. That’s the only way to cover our costs. zIf we’re going to charge for our risks, we’ve got to know what our risk exposure is. zThe only “good” way to deal with risk is to be a killer rabbit!
References JoelOnSoftware.Com 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