Product Description

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.

Product Details

• Amazon Sales Rank: #253587 in Books
• Published on: 2003-03
• Format: Illustrated
• Original language: English
• Number of items: 1
• Binding: Paperback
• 144 pages

Features

• ISBN13: 9780932633606
• Condition: NEW
• Notes: Brand New from Publisher. No Remainder Mark.
• Click here to view our Condition Guide and Shipping Prices

Review
" . . . destined to become the Bible for serious IT professionals and project managers." -- Edward Yourdon

"Advice projects must not ignore (but often do) . . . A must for the project manager (and his or her boss)." -- Conrad Weisert, IDINews

"Bold, provocative yet coolly pragmatic . . ." -- Michael Schrage, Co-Director of MIT Media Lab’s e-Markets Initiative, Author of Serious Play

"The book is a brilliant tour de force. . . . should be on your bookshelf . . . ." -- Paul Gray, Information Systems Management

"The seminal work on managing software project risk. . . . Finally we have a guide to risk management . . . ." -- Rob Austin, Professor, Harvard Business School

Customer Reviews

A good book covering an important and negelected area
This book is an interesting mix. It starts with a philosophical discussion of why it is ethically wrong and success-endangering to ignore risks, but commercially weak to simply avoid them, thus establishing that we must accept and manage risk. The book then develops a comprehensive method for risk management in IT (or other) projects.

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

As good, or better, than Peopleware!
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.

A must for software development managers
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.