Our Blog Excerpts Savings Contact


Dorset House Publishing
High-Quality Books on Software Engineering and Management.  Since 1984.
dorsethouse.com > features
Features       Excerpts       Interviews


iDH Sign-Up

Get Our e-News
Delivered by FeedBurner

Shocked, Disappointed, and Dismayed

by Tom DeMarco and Timothy Lister

Adapted from Waltzing with Bears: Managing Risk on Software Projects. Reprinted by permission. All rights reserved. See below for copyright notice.

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

AddThis Social Bookmark Button




COPYRIGHT NOTICE: This excerpt from Waltzing with Bears: Managing Risk on Software Projects [ISBN:0-932633-60-9] appears by permission of Dorset House Publishing. Copyright © 2003 by Tom DeMarco and Timothy Lister. All rights reserved. See http://www.dorsethouse.com/books/waltz.html. The material contained in this file may be shared for noncommercial purposes only, nonexclusively, provided that this Copyright Notice always appears with it. This material may not be combined with advertisements, online or in print, without explicit permission from Dorset House Publishing. For copies of the printed book or for permissions, contact Dorset House Publishing, 1-800-342-6657, 212-620-4053, http://www.dorsethouse.com, info@dorsethouse.com, New: 3143 Broadway, Suite 2B, New York, NY 10027 USA. Additional rights limitations apply, as presented in the Legal Disclaimer posted at http://www.dorsethouse.com/legal.html.



New:3143 Broadway, Suite 2B  New York, New York 10027  USA
1-800-DH-BOOKS or 212-620-4053, fax 212-727-1044
Copyright © 1996-2008 by Dorset House Publishing Co., Inc. All rights reserved.
Home | Blog | Savings | Stores | Features | Titles | Authors | Subjects | Orders | About | Contact | Legal