Reference no: EM13144438

Could you give me paraphrase of the sentence? Risk It’s a book about risk. Actually, it is a book about uncertainty. And don’t let the title fool you, this isn’t just about software projects; the principles are applicable to any project. I was first exposed to risk management concepts at university, as part of a unit on project management. And ordinary risk management is relatively straightforward: identify risks, track them centrally, and consider how to deal with each risk (eg accept, mitigate or delegate). One of the core concepts of risk is exposure. Exposure involves taking the estimated probability of the risk eventuating, multiplied by the cost of the risk. Ostensibly, a rational planner can sum up exposure and use this to create efficient risk reserves. Over the breadth of a project portfolio, this should balance out to about zero. All bunkum, of course. Humans are bloody awful at every part of the equation. We routinely miss the existence of risks, underestimate their probability of occurring, underestimate the severity of their effects and — as and when they finally eventuate — refuse to accept that they are, in fact, actually coming to pass. But gosh, it’s a very attractive idea. Multiply some numbers together, get a precise exposure. Precision does funny things to human beings, instilling as it does great confidence in a calculation. And this doesn’t just happen in software. Everywhere, in every business, this is always occurring. The Global Financial Crisis notoriously has some of its causal roots in extremely precise and utterly inaccurate models of risk. Here’s the problem: we were too certain of our single numbers. Uncertainty What DeMarco and Lister do is to place uncertainty at the centre of their concept of risk. Risk is not a single number. It is not even a three-point statement. It is a distribution of probabilities; in their case usually drawn as a left-skewed normal curve. DeMarco and Lister go further than expressing risk in uncertain terms. They apply that to value also. In their proposed methodology, each project has both risk curves and value curves; and the net outcome curve is used to rank projects and decide which projects are worth pursuing. Sounds like a lot of work… It is. Or rather, it would have been in times past. These days, of course, we have computers. Years ago my dad had a book called How To Bluff Your Way In Computers. It was from a series of humorous snapshots of various fields and as a boy I read it. The one thing that has stuck with me as an actually insightful nugget of wisdom is this: Computers do not do exciting things. They do lots of little boring things, very quickly. And in fact this turns out to be true at every level of abstraction. The entire goal of every software engineer is to do as little boring work as possible; seeking instead to delegate the boring details to some other code, which delegates still further. Until you reach NAND gates in silicon, it’s delegations all the way down. The practical upshot of all this, though, is that computers can do a stunning amount of tedious heavy lifting. Acts of virtual paper shuffling become possible that were previously in fevered dreams made of Byzantium multiplied by Brazil. It looks exciting because lots of boring stuff has been done by the computer. And so too risk management: why reduce things to a single number, and destroy valuable information, when the computer can keep the fuller picture for you? In the book DeMarco and Lister use the Monte Carlo method to simulate project outcomes based on normally distributed random variables. One could also do this with computer programs that handle calculus with a certain degree of aplomb. The point is that it doesn’t matter, because the tool liberates us from the limitations of our own selves. Tools Beget Paradigms I think folk sometimes underestimate how drastically tools shape our thinking, and not the other way around. A lot of tools developed at a human scale work by destroying information early, so as to keep things within manageable bounds for human comprehension. Take double-entry bookkeeping. It is one of the most important inventions in history, making it possible to reliably determine profit and loss, to effectively determine business activity and to understand the value of a business at any point in time. All bunkum, of course. I mean, double-entry bookkeeping is a great advance on trying to do things with cash by itself, or on simply tallying up receipts and invoices. It gives a far better insight into a business than what came before. But it is once again filled with deceptive precision. The double-entry system demands that only scalar values can be entered into the books. Uncertainty has no place. It transpires that a lot of accounting is actually a series of rules for transforming uncertain information from the business into scalar values that can be entered in the books. This uncertainty is not completely destroyed — any decent financial statement comes with a collection of notes — but it is certainly conspicuously absent from the hard, precise batch of numbers that turn up on the income statement or the balance sheet. Information has been, if not destroyed, then at least muted. I sometimes wonder what an uncertainty, range-based accounting system would look like. Perhaps one already exists. It would be interesting to see financial reports with confidence bands and error bars, don’t you think? Certainly some of the false precision might be taken out of life. Accounting is, after all, meant to be a faithful representation of a business — accuracy ought to trump precision when the two are in conflict. Conclusion Uncertainty is a central problem in life, and by framing their book on Risk around uncertainty, DeMarco and Lister do the reader a great service. As is usual for a Dorset House book, the printing is good, the book well-edited and proofed, the production quality decent (some larger publishers these days foist you off with what are basically perfect-bound photocopies — I’m looking at you, Wiley). DeMarco and Lister are always a delight to read and this book is no exception. With a gentle sprinkling of anecdotes, friendly, approachable writing and lucid explanations, I think this book makes a strong addition to the library of any software professional or project management professional.