Customer Reviews

Waltzing With Bears: Managing Risk on Software Projects

5 star:		(21)
4 star:		(3)
3 star:		(0)
2 star:		(0)
1 star:		(2)

 

 

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

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.

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

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.

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)

Reading Tom Demarco and Tim Lister is a pleasure. It is so clear that these two authors set out to teach something they believe to be valuable, and all of their effort is directed toward making that valuable thesis accesible to the reader. There is no showing off, no saying, "Look how smart I am." Their books clearly say, "Our many years of experience have taught us some useful stuff and provided us with lots of valuable data. We have put a lot of effort into analyzing that data and we will try as hard as we can to help you understand our analysis. Our objective is make it as clear and as entertaining as we can," and they do. Their explanations are always clear. Their examples are invariably both helpful and entertaining.

What they have to say is always important. "Walzing with Bears" is no exception, and even if you should disagree with parts of the book, their arguments will force you to think about critical aspects of management that you may not have previously considered.

Reading the first few chapters, my only criticism was that they seemed to be oversimplifying some issues. Reading on, I realized that it was a deliberate and brilliant part of their teaching technique. In later chapters, the book carefully added the complexities that covered more and more of my early reservations in ways that made them easily understandable.

It's a terrific book.

Read this unsystematic and occasionally glib book (I concede this point to other reviewers) and you will suddenly realize that you, your colleagues in development, your technical leads, and your CEO have probably all been lying to yourselves and to each other about every single "milestone". Risk analysis is not merely done badly most of the time. It's usually not done at all. I learned enough from this book on a Sunday to return to work the next day and successfully persuade my colleagues that our project plan was worthless, and we needed to come up with a new one *now* that properly took account of the risks. No, I'm not a risk analyst, but merely the effort of thinking about risk in a different way had a payoff. Before this, we were just driving blind.

There are a ton of wonderful anecdotes and motivational examples for doing risk management. Also, he takes a very pragmatic approach towards what's actually possible in different corporate climates. Rather than only telling you what right thing to do is, he helps you decide what the appropriate thing is.

The explanation of the relationship between risk and benefit analysis was both insightful and seemed like it would be useful. It provides a pragmatic framework for a lot of what are considered 'good engineering practices', such as incremental deliverables that can be measured and verified in meaningful ways.

The only downside is that it's very difficult to understand how to take advantage of some of the frameworks he provides without being in a management position already. Individual contributors won't get a lot out of this.

Tom and Tim have another winner! They have taken the generally complex topic of risk management, identified the 20% of it that provides practitioners with 80% of its value, and packaged it in a way that is easy to use and understand. This does not mean that they trivialize risk management in any way. They pull no punches about what software risks will do to you and your project if you ignore them. But they communicate their messages and practical risk management techniques in their usual fresh and stimulating way, along with a boatload of relevant and thought-provoking examples from their wide experience. A must-read for your software career.

What an excellent book, but then what would one expect from Tom DeMarco and Tim Lister, and Dorset House? As well as being an excellent introduction to an extremely vital subject in this day and age, "Waltzing with Bears" provides some practical tips not only on how to do Risk Management, but also regarding how to overcome some of the factors in corporate culture that actively or passively suppress the application of Risk Management (e.g., the "can-do" attitude).

DeMarco and Lister have structured this book logically, beginning with "Why" and "Why Not", progressing through "How" and "How Much", and concluding with a brief "Whether or Not". The chapter on Core Risks of software projects is priceless. The authors provide instruction on how to graphically show the uncertainty that must be managed, and provide a link to a freeware RISKOLOGY tool that will assist those engaged in Risk Management.

Having spent several years in QA and Process Engineering supporting Risk Management, I can only say that I wish I'd had this book several years ago. But I have it now, and am better prepared for future efforts.

Thanks again, Tom and Tim. By the way, I love the cover.