Any software project that's worth starting will be vulnerable to risk. Since greater risks bring greater rewards, a company that runs away from risk will soon find itself lagging behind its more adventurous competition.

By ignoring the threat of negative outcomes—in the name of positive thinking or a Can-Do attitude—software managers drive their organizations into the ground.

In Waltzing with Bears, Tom DeMarco and Timothy Lister—the best-selling authors of Peopleware—show readers how to identify and embrace worthwhile risks. Developers are then set free to push the limits.

You'll find that risk management

* makes aggressive risk-taking possible
* protects management from getting blindsided
* provides minimum-cost downside protection
* reveals invisible transfers of responsibility
* isolates the failure of a subproject.

Readers are taught to identify the most common risks faced by software projects:

* schedule flaws
* requirements inflation
* turnover
* specification breakdown
* and under-performance.

Packed with provocative insights, real-world examples, and project-saving tips, Waltzing with Bears is your guide to mitigating the risks—before they turn into problems.

Average Customer Review: ( 26 customer reviews )
Write an online review and share your thoughts with other customers.

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".

17 of 18 found the following review helpful:

As good, or better, than Peopleware!Mar 25, 2003
By Dr Nic Peeling
To think of this as a book that is just about risk management does not really do it justice - it could have been subtitled "How to prevent software project disasters". It could also have been subtitled "Software Project Management for Grown Ups" ... unfortunately this subtitle highlights the sting in the book's tail, which is that it is also necessary to work for a grown up organisation. The authors point out that their techniques cannot be applied in many company cultures, where the admission of uncertainty by a project manager is not possible.

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.

8 of 8 found the following review helpful:

A must for software development managersJun 02, 2003
By Charles Ashbacher
Risk is everywhere, so we cannot avoid it, only manage to deal with it in the best possible manner. In software development, the most valuable projects are always the most risky. Therefore, the decision to go forward with any project must include an honest assessment of the locations of the virtual land mines.
There are two general areas in which risk can be categorized. Some of the risks are known, either precisely or within a range of parameters. For example, the cost per day for each category of worker involved in the project is well-known. This type of risk is not difficult to manage, and most managers have a great deal of experience handling them, so very little of the book deals with them.
The second category are those risks that are largely unknown. These are items like the risk of mission critical software suffering a catastrophic failure to large, unexpected cost overruns. It is this category that is examined in detail in this book. Of course, the boundaries between these categories are extremely subjective and situation dependent. A small company with limited financial resources would consider a smaller cost overrun to be critical than a company more capable of taking a large financial risk.
After the initial explanation that risk management is necessary, the next step is trying to quantify the risks. This involves charts of likelihood of delivery time that resemble normal distribution curves. Using such charts allows any prediction to include some natural �wiggle room�, which eliminates one of the most recurring and frustrating problems. Development managers are commonly asked to give a date for product delivery, and that date becomes fixed in stone. Upper echelons are notorious for hearing only the �we can deliver on August first� part of the message and ignoring the remaining, �provided all the planets are in alignment, there is no snow in January and no one takes a day off� part of the message. Expressing the date in a diagram of this form means that it is impossible to see the date without also seeing the estimated range.
The authors have also developed a risk assessment tool called RISKOLOGY, which can be freely downloaded from the companion web site. While the tool is not described in complete detail, there is enough background for you to be able to use it quickly. Chapter 13 deals with the core risks of software projects. The five risks listed are:

* 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 don�t 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.

8 of 9 found the following review helpful:

Common Sense advice for Project managementOct 23, 2006
By Raja Mannar "rajmannar"
At a certain fundamental level, projects are about how well one manages the risks in the process of achieving the project objectives. Projects by their very nature and scope of effort entails some level of risk (major or minor), but unfortunately the concept of recognizing and managing the risks is sorely absent in majority of IT projects. And for those of us who have been involved in IT projects, this book is a stark reminder of how poorly risks are managed.

I found this book very useful in understanding the thought process behind risk management and more importantly the challenges and difficulties in implementing them. I have seen projects where Risk management is nothing more than symbolic maintenance of a risk log, which is more "CYA", than anything practically useful. Ofcourse, many other projects don't even maintain this token log too.

There are some striking observations in this book, which is commonsense, but gets lost in the thicket of our daily project management duties.

One of them is about the project delays:

"When a project strays from schedule, it's seldom because the work planned just took longer than anyone had thought; a much more common explanation is that the project got bogged down doing work that wasn't planned at all.

Most software project managers do a reasonable job of predicting the tasks that have to be done and a poor job of predicting the tasks that might have to be done."

Another one is about schedule estimates:

"Software managers have tended to follow a standard rule: The Estimate and the goal are identical. The discipline of risk management though will counsel you to use goals as you always have to help people strive for best performance. At the same time, it will prompt you to use a very different planning estimate when making promises to your clients and management.

Schedule = Goal = N -> Really dumb equation

Schedule > Goal > N -> Sensible (N =Nano-estimate)"

THis is so true. It always happens that whatever is the earliest

articulated date of completion automatically is considered the deadline, which is most of the time unrealistic and working against this timeline makes risk management even more impossible.

I woulf recommend this book to anyone intrested in reading about some common sense advice related to IT project management in general and Risk management in particular.

8 of 9 found the following review helpful:

It is a big risk NOT to read this.Feb 28, 2005
By Mr P R Morgan "Peter Morgan"
There are some very sensible, eminently implementable ideas in this book, even if you have nothing to do with risk management. It is not just about risk, and neither is it just about software projects. Yes, there are strong elements of both, but the discussion is not exclusive. Some of the practical matters discussed include being able to recognise a 'dead' project before it finally rolls over and is declared dead. If there is no life in the beast, then it is no use preserving the carcass.

Risk has been become a vogue word in software development. Everybody talks about it, and says that it is being considered. However, a large part of the discussion is lip service. What is apparent is that 'risk' is not a small subject, and any discussion on this subject will invariably involve weighty matters. How can benefits be calculated? How are costs determined?

So is risk inherently wrong? Risk involves uncertainty. Halfway down the first page of Chapter 1 is a wonderful statement, summing up the gains to be claimed by embarking on a risky venture. "If a project has no risks, don't do it". The authors slay a few myths along the way. It is not wrong to be uncertain. Risk is about trying to minimise the uncertainties, or rather to minimise the damage caused by events that you hope will not happen. Therefore, if you don't know, ask questions about what you do not know. That is very different to some work places, where it is considered bad form to raise items on the risk register. There are instances when blindingly obvious risks have not been considered. "Oh, you mean THAT train" - as it speeds towards you. Projects that negotiate dark railroad tunnels will find trains hurtling towards them. FACT. It is the nightmares that need to be addressed, not the petty worries.

The book is very good about imposed deadlines. By all means perform estimates based upon everything happening correctly, and on time (in other words, 'downhill with a following wind'). However, this is not sufficient for implementing REAL projects, in real timescales. In order to achieve this, it is necessary to add in the uncertainties. Add these in before publishing the figures. There is a tool available on the associated web-site that enables some of the classic uncertainties to be factored in. This uses some industry standard figures to indicate the effect of, say, key staff leaving. The big no-no of software development is also discussed - what if the project fails? Figures indicate that a significant number of software projects fail (the authors quote 15%, but others may use different figures). Therefore failure has to be a risk on any project.

The authors discuss 'Earned Value Running' [EVR] as a way of measuring progress. Using such a measure moves away from the "90% complete" problem, and also enables the 'bells and whistles' of a project to be seen for what they are; items that are nice to have, but not item that are part of the core functionality. Such concepts as EVR can make a difference, and examples are provided from real life projects about many of the items discussed.

Much concerning 'risk' is involved with sharing knowledge, be this what is known or what is unknown. It is only when there is a culture of openness that there is a freedom to share risks (it is after all a risky business to discuss the items that would cause your department to fail to deliver to schedule). There a large variety of items that can follow on from an effective risk management strategy. One of these is what the authors call 'proactive incremental delivery'. This is equated with playing the loosing hands from your bridge hand first. However, what is written is not a prescriptive approach. After all, that would be risky!

There is one final point I wish to mention with this volume. There is a discussion of when NOT to share your risks with others. It takes a good deal of confidence to argue in part against the central thesis of a practical book. This is a VERY good, practical book, whose authors are not afraid to advise when not to use the ideas within.

Peter Morgan, Bath, UK (morganp@supanet.com)

See all 26 customer reviews on Amazon.com