- Paperback: 144 pages
- Publisher: Dorset House (March 2003)
- Language: English
- ISBN-10: 0932633609
- ISBN-13: 978-0932633606
- Product Dimensions: 0.5 x 5.8 x 8.8 inches
- Shipping Weight: 10.6 ounces (View shipping rates and policies)
- Average Customer Review: 4.5 out of 5 stars See all reviews (33 customer reviews)
- Amazon Best Sellers Rank: #195,857 in Books (See Top 100 in Books)
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Waltzing With Bears: Managing Risk on Software Projects 0th Edition
Use the Amazon App to scan ISBNs and compare prices.
Frequently bought together
Customers who bought this item also bought
" . . . 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 Labs 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
If you are a seller for this product, would you like to suggest updates through seller support?
Top Customer Reviews
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 [...] 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.
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.