Better Software - June 2008 - (Page 33)

UnqUantiFiable Risks In games of chance, the probability of an adverse event can be determined. However, knowing the probability of such an event in a software development project is essentially unknowable because software projects are essentially human activities, and humans are unpredictable. Even in games of chance where the probabilities are directly computable, most people will drastically overestimate their chance of winning as is evidenced by the number of people who buy lottery tickets. Yes, someone will eventually win the big prize, but the chance that it will be you is usually less than one in ten million, so the expected return on a $1 ticket is in most cases less than fifty cents. (Lotteries have expenses, many are designed to raise money for charity, so few lotteries pay out more than 50 percent of the money they bring in.) We are not good at assigning probabilities to events, even when we have good statistical data, and we fail miserably when we don’t have any historical data. A good example is how much certainty we ascribe to our estimates. We typically believe our estimates are within 50 percent even though empirical studies show that estimates can be off by a factor of four. Even when we have good statistical data, it is not always available to the project team. For example, when planning a project, it is useful to know the level of staff turnover. If it is more than 15 percent, there is a good chance that one in six team members will leave before completing a one-year project. But many companies will not make this information available to project managers, so although they know that their project will have some turnover, they cannot quantify the risk. Even if the project manager is given the overall corporate turnover numbers, the risk is still unquantifiable because the circumstances of the project can change the probability that team members will leave. If a project is afflicted with particularly bozo decision making, then the team may suffer an almost complete turnover of staff. Even worse, you may find that although a central core survives, there is rapid attrition of all new hires, which could have been predicted given the overall average turnover for the organization. Dealing with unquantifiable risks requires accepting that not everything is reducible to numbers and probabilities. It requires senior managers who are comfortable with unknowns and who are willing to accept that some things are unknowable. Risk averse managers cause many projects to fail because they make “safe” decisions that end up putting the entire project at risk. the UnexPected (no one exPects the sPanish inqUisition!) Even in organizations that seem to identify risks early, there always are some items that just pop up to cause a major impact on a project. Even worse, these often are things that catch everyone by surprise but seem obvious in hindsight. A good example of this is the “slashdot effect” [3], in which your Web site goes from total obscurity to overwhelming popularity and then crashes due to overload. Yes, in hindsight it is obvious that Web sites should be designed to support large numbers of visitors, but as few as five years ago, major corporations with eCommerce Web sites were regularly failing whenever they had a sale or major promotion. The problem with drawing attention to such unexpected events, however, is that someone, somewhere will add them to a risk checklist for all future projects to assess. But again, it is not the events that you are prepared for that cause the biggest problems—it is the events that catch you by surprise. Few, if any, surprises in software development result in a project that is easier to deliver—most surprises mean that something has gone wrong. Big checklists of possible risks are not much use. After all, the likelihood that your building will be destroyed is very low, but because we have seen some very visible examples of this type, most organizations now have some sort of disaster recovery plan in place. That means the organization is spending a substantial amount of money to address a single, unlikely risk and thereby has less money to spend on figuring out ways to respond to all of the other types of risks or on improving existing systems. Most risk management plans, while useful in a CYA way, have no impact on the overall success of projects. The risks that make it onto the risk mitigation lists www.StickyMinds.com are interesting in an academic sense, but not all that useful. Good project managers know that suppliers may be late so they schedule appropriately; they do not list this as an item in the risk mitigation plan. I’ll say it again: It is not the known risks that cause problems; it is the completely unexpected things that get you. Too many projects crash and burn because senior managers are completely out of touch with the realities of their projects. Flexibility is the key to surviving the unexpected. Rather than making detailed project plans and creating interminable mitigation strategies for every conceivable risk only to be blindsided by something that wasn’t in the plans, organizations need to understand that bad stuff happens. Forget about Risk own Insurance Management, Create Your The current methods used to manage risk are obviously failing or there would not be as many stressed projects. An “insurance model” of project management may sound a little crazy, but having insurance is usually less risky or expensive than the alternative. What would project insurance look like? What would we be insuring against? The insurance should cover: • Incomplete information • Learning the wrong lessons • Death by a thousand cuts • Late-breaking news incomPlete inFoRmation All projects must insure themselves against incomplete information, especially information about how a project is tracking. While most management teams set up structures that keep them informed of project concerns, most managers want to be brought “solutions, not problems.” As a result they live in a world that is out of touch with the underlying project realities because nobody is allowed to raise an issue without having a well thought out plan for addressing the problem. The result of this policy is that intractable problems are not being raised as issues. It’s common among developers to say that things would go much better if managers would just listen to them and JUNE 2008 BETTER SOFTWARE 33 http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - June 2008

Better Software - June 2008 Contents Mark Your Calendar Contributors Technically Speaking eLightenment Code Craft Test Connection Management Chronicles Agile Model-Driven Development The Myth of Risk Management Stop the Insanity! Product Announcements 10 Things You Might Not Know About … The Last Word Ad Index

Better Software - June 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.