"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."
—Tim Lister
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
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. |
