Waltzing with Bears: Managing Risk on Software Projects [Englisch] [Taschenbuch]

It may be surprising where DeMarco & Lister start from, explaining what risk is, why we need to accept it and why we must manage it, but they explain how common attitudes in the IT industry, which they correctly term "pathologies", can make it almost impossible to properly acknowledge and manage risks.

Maybe it's my background as a physicist, but I assumed that most project managers understand the concept of uncertainty in estimates of cost, timescale and benefits. The authors clearly start from the opposite position. This may be a little off-putting for some readers, but will definitely help those to whom this is a new concept, while the use of "uncertainty diagrams" (probability profiles) will be a useful addition to the toolkit even for those more familiar with the underlying ideas.

The book is very strong on how risk impacts budget and schedule, and how to more scientifically make goals and committed targets more realistic. There's a very good discussion of how to assess deadlines using probability theory, which shows the folly of trying to manage large efforts by single deadlines. The book also includes a very good section on brainstorming and analysing different stakeholders' "win" conditions to identify potential risks.

One weakness is the almost total lack of discussion of risk prevention - actively working to prevent a risk materialising, or at least to reduce its probability as well as mitigating its impact. For example they quote the example of an operating system upgrade which is incompatible with a "make or break" product development. Any sensible manager would work with the OS vendor and its developer information programmes to actively prevent this, rather than just worrying about its possible impact.

When it comes to combining the effects of multiple risks, the authors rely entirely on Monte-Carlo simulation and the "black box" outputs from a spreadsheet (which is downloadable from a web site for the book). This will be a useful tool, but a simple worked example showing the mathematical principles at work would be much better (see www.andrewj.com/thoughts/combining risks.htm for my attempt at this).

The book is dismissive of time-constrained scheduling as "schedule flaw", and there is only limited consideration of methods such as Agile Modeling and eXtreme Programming which aim to mitigate or even prevent the effects of requirements change. However there is a good section on the use of incremental delivery to mitigate risk, but possibly somewhat unrealistic in relying on very complete requirements and design before the incremental delivery plan can be completed.

The approach to benefits, and the importance of properly assessing and measuring benefit is excellent. As DeMarco and Lister state, you can't do any meaningful risk management or prioritisation unless costs and benefits are estimated, measured and controlled to almost exactly the same degree. Conversely, if you can build realistic models of both cost and benefit in risk terms, you have a very powerful but relatively simple model for project prioritisation.

Overall this is a good book which I can recommend, but not the definitive answer I expected from the authors of "Peopleware".

The author's book Peopleware is one of my all time favorite books, so I was really worried that this book would be a let down. In many ways I think Waltzing with Bears is an even more significant book. Peopleware was one of the few books that pemanently changed the way I view the world, and this book I believe will have the same long-term effect. It has the same deep truthfulness that the "Mythical Man Month" has.

In many ways the five-star markings on Amazon have become de-valued. This is truly a great book and should not be confused with the "run of the mill" five-star books.

* Schedule flaw.
* Requirements inflation.
* Personnel turnover.
* Specification breakdown.
* Under-performance.

None of these risks is any surprise to experienced managers, although including them was necessary and the authors do a good job in explaining them.
Chapter 14 puts forward a process for discovering risks, which is excellent and in the realm of how to learn what it is that you dont know. It is this approach that will separate those who succeed from those who must resort to faking success. The greatest and most dangerous risks are those never considered as possible events. Catastrophe brainstorming followed by scenario analysis is the strategy that the authors put forward.
As a mathematician, I was pleased to see that the concept of probability is used to perform the risk analysis. Probability charts are used throughout the book to demonstrate the concepts and of course this more accurately describes our knowledge of the future. Nothing in life is certain, so the probability limits need to be placed around every event.
The software project without risk is so dull and uninteresting that no one with any talent would go near it. So, if you have talent, gear up by buying this book and plunge forward to take on the enormous challenges of making software that matters to the world.