7. Luck
,TRL: Good luck on your next project . . . but don’t count on it.
When you choose to ignore a risk, you’re depending on luck to keep the undesirable thing from happening. This may be a perfectly sensible way to deal with some risks, but not all of them. The “not all” part is essential here because a common pathology is the decision to count on luck to take care of all risks.
Just for the record, though, before dealing with the pathology, let’s take a look at the kinds of risks that may be sensibly excluded from management.
“We’ll take our chances on that one.”
Can you think of a real risk (a bad thing that legitimately could happen and which would certainly have awful consequences) that makes no sense to manage? One that’s not even worth putting on your list?
The one that often comes up in our risk management seminars is “asteroid demolishes company.” What are the characteristics of the asteroid risk that make it not worth managing? We’ve come up with the following two:
1. The probability of materialization is small enough to ignore.
2. Should the risk materialize, it makes the effort under management (the product that you’re building) irrelevant.
It may be tempting to add a third characteristic here: There isn’t much we can do about the risk should it materialize. While this is true, it is not a legitimate reason alone for choosing to ignore any risk. A given risk may be fatal to a project, but it may not be fatal from the point of view of some participants of that project. Those who are likely to survive must manage the very risk that could prove fatal to the others.
The two numbered reasons listed above give you leave to ignore the asteroid risk. Here are two other valid reasons to excuse yourself from managing risks:
1. The risk has minimal consequences and requires no mitigation.
2. It’s somebody else’s risk.
Sure, ignore a risk like “Ted may call in sick on Tuesday” because you can safely pay for the loss out of project petty cash (in the time sense). Do be sure, though, that this is not one of those risks that only have minimal consequences if you’ve prepared in advance. If it is one of those risks and you want your mitigation effort to be available once your risk moves into transition, you’ll need to do your prep work beforehand. (If the risk belongs to someone else, see our discussion in Chapter 9.)
We have identified four good reasons not to manage a given risk. No surprise, most of the risks facing your project will not fall into any of these four categories. The ones that don’t are your real and meaningful risks.
Why would you ever find yourself not managing your project’s real and meaningful risks, but instead, counting on luck to make them all go away? Well, suppose the project had been conveyed to you in the form of a personal challenge like this one:
“I know April will be tough—that’s why I’m giving the job to you!”
When a project comes wrapped as a challenge, it forces you into a posture of counting on a certain amount of luck. If the boss tells you, for example, that you and your eight people are the company’s last, best hope to get a key piece of work done by April (groan, the CEO’s been talking to the press again), what else can you do? What if your boss looks you right in the eye and begs you to bring this one in for the Gipper? With that kind of a hand-off, you may be inclined just to do your best and keep your fingers crossed.
You realize that there is no chance of making April without catching some important breaks along the way. Catching those breaks has become an integral part of your project plan. This is the exact opposite of risk management, where your project planning is very much focused on what to do if you don’t catch breaks.
Projects that start off as personal challenges seldom have their risks managed sensibly. They depend instead on luck. There’s not a lot you can do about it if the project comes to you that way, but you can learn for the future. When you’re in a position to engender projects yourself, make sure you don’t package them in such a way that luck has to be built into the plan. Offer reasonable stretch goals, but make sure that real expectations make room for the breaks that don’t happen.
Shocked, Disappointed, and Dismayed
TRL: Without knowing anything at all about your current project, I’ll bet even money that you’ll be late. After all, well over half of all projects deliver late or deliver less than was promised by the original deadline. It’s far worse when a project is on an admittedly aggressive schedule. Project people seem disconcerted when I proclaim that I’m willing to bet against them. They try so hard to believe that they’ll buck the odds. What usually happens is that everyone agrees that the deadline is very tight; everyone works very hard; and then, when people see that they won’t make it, they are shocked, disappointed, and deeply dismayed.
Somehow, the tactic of professing to be shocked, disappointed, and dismayed when you don’t catch all the lucky breaks makes it okay to have followed a plan that depended on catching those breaks. But depending on luck for success is not okay; it’s real kid stuff.
The Indy 500 Analogy
Enough about software projects, for the moment. For the next page or so, you’re going to be an Indy Racing League driver. There you are behind the wheel of the Panther Racing Penzoil Dallara machine with its huge Aurora engine roaring. This is the maximo racing experience. You downshift going into the third turn and skid slightly, but you come out of it nicely, shifting up and accelerating. Your speed on the straightaway is maybe 220 or 225. You pass one, two cars in a blur, and by golly, you’re leading the pack. This is your dream and it’s coming true.
Take an instant to get perspective: You’ve been driving for two hours and fourteen minutes, and it’s no wonder you’re tired. This is lap 198. There are fewer than five miles between you and the checkered flag. Whatever you do, don’t let up. Keep applying the heat, but play it safe because this race is yours to lose. In fact, the only real threat is Team Green. They’re still behind you, but not very close. You place yourself tight on the rail and concentrate. Only one little piece of your mind is focused on anything but driving: It’s the piece that’s listening to the gas alarm. You glance down and see that the needle is on empty. But there are only a few miles left. Your pit crew is waving you in, but a pit stop now means losing. The engine has never sounded better. You bear down, holding your position exactly between Team Green and the finish. The last lap. This is it—you’re going to win! But wait, the engine is sputtering. It’s coughing; you’re starting to lose momentum. Hold on, baby. You urge it on as best you can, but there is no engine now. What the hell, you think, being first across is still a win, even if you’re coasting. You coast, nearer and nearer and nearer the line . . . but then you stop, just a few feet short. Team Green goes roaring past.
What just happened? You made a calculated decision to skip the pit stop in order to have any chance at all of winning. You willingly took a chance of not finishing at all in order to hang on to even a remote hope of finishing first.
That makes good sense if you’re an Indy 500 racer. But you aren’t. (Sorry.) You’re a software project manager. The same mind-set on a software project is a disaster. When you take every chance in order to win, you may raise the consequences of losing, far beyond where they need to be.
It’s a strange calculus but true: Limiting the extent of your losses in software project work is more important, on average, than doing anything about your wins. Every organization suffers defeats in this business. The ones that get hurt most by their defeats (like DIA) are the losers, no matter that they win a few others.
When you challenge your subordinates to pull out the stops and bring the project home on time (even though the schedule is ludicrous), you need to understand that you’re staffing your key positions with NASCAR racers. They will take every chance, ignoring every imaginable downside, in order to preserve—at least for the longest time possible—any thin, little chance of winning.
Call that what you will, but it ain’t risk management.