5. The Case Against Risk Management
,“Risk management often gives you more reality than you want.”
—Mike Evans, Senior Vice President ASC Corporation1
1 Mike Evans is a fellow governor of the Airlie Council, a group that was set up by the U.S. Department of Defense to help the armed services improve software and systems acquisition.
We must confess that there are a few reasons not to do risk management. We wouldn’t be writing this book if we felt that such reasons were sufficient to make the whole notion unattractive. Nonetheless, you need to know about the negatives as well as the positives.
Most of the negatives have to do with the way that risk management interferes with certain management styles. Many of these styles are generally counterproductive anyway, yet they do have their followers. Being a good manager is nontrivial. It takes hard work, gumption, and most of all, talent. People who don’t have the requisite talent fall back on a host of mechanical approaches, such as Management By Objectives, Parkinsonian scheduling, and a “culture of fear” to scare their subordinates into performing. Though these things are not easily defensible, some managers and some entire organizations are addicted to them. These practices are incompatible with any risk management scheme.
It would be glib of us, though, to suggest that all opposition to risk management comes from scared and talent-free managers. There are some very real reasons to be concerned that the approach might not work. The following sections contain our definitive list of the reasons people cite for not doing risk management, and our comments on each one. (The italicized comment under each heading presents our sense of what the spoken objection probably means.)
1. Our stakeholders are not mature enough to face up to risk.
“If we told the truth, our stakeholders would be too scared to do the project, so we have to lie to them.”
Lying, in this situation, is a real public service.
In the early days of the software industry, the stakeholders were often clerks and managers of clerical departments. That was because the first functions we tended to automate were clerical. These stakeholders were low-level, relatively powerless, and not very well informed about automation. The typical systems analyst on such a project was usually paid a lot more than most of the stakeholders he or she interacted with.
During this period, IT often affected a paternalistic, “we know best” attitude. Maybe this even worked, on occasion, to help useful systems get built.
Today’s stakeholders, however, are different. They are typically more powerful than their IT counterparts, and they have been around for a while. They are savvy about automation. Most of all, they have really good memories.
These days, risk-taking is becoming the norm on more than just IT projects. Your stakeholders are being encouraged to take risks of their own, completely outside the realm of IT. They know about risk. They also know about being lied to. Concealing risk from them is a pretty dumb tactic.
2. The extent of uncertainty is just too much.
“I can cite a window around the date, but not such a big window.”
Many software managers are willing in the abstract to confront the uncertainties of their projects, but they are daunted by the size of those uncertainties. If they could use risk management techniques to show a delivery date that’s plus or minus 2 percent or 5 percent, they’d be delighted. But the uncertainties in our field are much bigger than that. A careful assessment of potential causes of delay should oblige you to admit something like this: “Delivery can be expected sometime between Month 18 and Month 29, with an 85-percent confidence factor date of Month 24.”
The reason you would find yourself believing such a conclusion is that the empirical record of delaying factors and resultant delays has forced you to believe it. But you also know that your organization has been feeding itself on hype for so long that this kind of imprecision will be hard to swallow.
Some organizations are so desperate to believe they’re in complete control that if they realize they aren’t, they settle for the illusion of control instead. The most common symptom of this is a ridiculous precision (a very narrow window of uncertainty) attached to estimates that subsequently turn out to be very inaccurate.
3. Explicit windows of uncertainty excuse poor performance.
“If I tell our developers to get the work finished up just any time between July and December, they’ll go right to sleep.”
We have adopted as standard practice in software the assumption that the estimate and the goal are always 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.
4. A “manage for success” approach is better.
“Look, we don’t do risk management, but we keep an eye on the risks and then we manage to make sure they don’t happen.”
You can manage your risks, but you can’t make them go away. Any “manage for success” approach based on making sure risks don’t materialize just sets a project up for disaster when they do. For any sensibly organized project, the risks are not incidental to the project goal; they come with the terrain. As we discuss in detail later, removal of these intrinsic risks can only be achieved by forgoing much of the value of the product as well.
5. The data needed to do risk management effectively is lacking.
“We just don’t know enough about the risks that will affect this project.”
Many of the risks facing any given project are, of course, intrinsic to that project. Unique risks arise from the product itself as well as from the cultural and political environment of the project. There won’t be much or any data about some of these risks. However, the major risks facing most projects are common to all IT projects. If you only have data on the common ones, you have the wherewithal to contain most of your risk.
6. Risk management in isolation is dangerous.
“I dare not be the only one to do risk management honestly.”
While we’ve tried to pose a reasonable counter to each of the first five reasons (excuses) for not doing risk management, this sixth reason is irrefutable. Risk management makes no sense whatsoever for a single project manager surrounded by peer managers who are practicing pure can-do. By publishing risk lists and quantifying uncertainty, that lone manager will only end up looking like a wimp, or worse, be seen as the carrier of a dangerous infectious disease.
If you work in an organization where risk management is not practiced widely, you may still be able to make use of some of its tools and techniques on your project, but you must not go public with your findings. Telling the truth where optimism (lying) is the norm puts the truth teller at a terrible disadvantage. If you assert that there is only a 10-percent chance of making a hoped-for delivery date, you expose yourself to competition from a hungry peer who may say, “Give me the job, boss, and I’ll bring it home for you on time, guaranteed.”
The worst organizations penalize unappealing forecasts, but not unappealing results. When the project fails, they reason, “Hey, the guy missed the date, but at least he gave it a good try.” This problem feeds upon itself: People understand that promising big is more important than delivering, and everybody learns to act accordingly. If you work for this kind of organization, you might as well go with the flow and keep your risk assessments to yourself.