Waltzing with Bears

I've seen many software projects fail because risks weren't addressed. So I was interested to see what Tom DeMarco and Timothy Lister had to say about risk in Waltzing with Bears - Managing Risk on Software Projects.

Software projects are all about risk. How do you deal with the risk? Do you welcome it? Embrace it? Search it out? Or do you avoid it?

Waltzing with bears explores these questions. The right answer, according to the book, is to take on risk in a mature, honest and informed manner. Because where there is risk there is reward. And ultimately, competitive advantage.

But dealing with risk is definitely not easy to do, or do well.

The book defines risk management as the process of thinking out corrective actions before a problem occurs. The opposite of risk management is crisis management, or trying to figure out what to do about a problem after it happens.

The prologue begins with a story to focus on how beliefs are acquired, and how beliefs can drive the approach to risk. Do you honestly earn your beliefs in patient investigation? Or do you simply stifle your doubts?

To manage risks you must define and categorize them and not just make them disappear by ignoring them.

The book explores 5 basic parts of risk management:

1. Understand why it's important to do it
2. Explore when it's appropriate to not do it
3. Decide on much risk to take on
4. How to go about it
5. Know whether or not it's working

The book also provides a simple plan for risk:

Categorize it up front
Plan for mitigation
See it coming
Deal with it

The book is full of practical advice to make the job of risk management a whole lot easier.

My favorite quotes from the book:

"Risk management is not the same as worrying about your project."

"Risk management is project management for adults."

"When a seven-month project ends up taking twelve months, angry upper managers seldom blame the schedule; Instead, they blame those who were supposed to make that schedule - no matter how ridiculous it was - into reality."

Precisely stated costs and vaguely hinted-at benefits make a travesty of cost-benefit analysis. More importantly, they also make sensible risk management impossible.

Justification for the death march always takes the form of project importance: This effort is so essential that it requires the utmost of project personnel. But there is a bit of a conundrum built into that statement. If the project is so essential, why can't the company spend the time and money required to do it properly?