In what follows, I’m going to use an elaborate analogy to make a point about risk management of software projects.
Proceed with caution here: if the analogy works according to my nefarious plan, you’re probably going to have to think very differently about how you manage risks on your next project.
If that thought worries you, you might want to stop reading here.
Here’s the analogy: You are on temporary assignment in San Francisco, working for a boss who spends most of her time in the Los Angeles office. She calls you early in the week and says there is a must-attend meeting scheduled for Friday in LA. She’ll be there, as will her boss, the CEO, as well as the CEO of your company’s biggest client. And you’re the show. You’re going to have to put on a whiz-bang presentation of your new software suite, something that will knock their socks off, and secure a whole line of new and highly profitable business for the company. The best of it is that both you and she know you can do it, it’s going to be a “piece of cake.”
The meeting is scheduled for 11 a.m. Friday. There is an 8 a.m. flight from SFO Friday morning that gets in around 9 a.m., so you figure that will give you plenty of time to get to the office, even though it’s twenty miles off in deepest, darkest Glendale. The flight is actually a little late getting in (damn these airlines and inefficient air traffic controllers!). You give the flight attendant a real piece of your mind. And it takes forever for your bag to come onto the carrousel (damn these inefficient baggage handlers). You rush out onto the curb and to your dismay see that there is a long line for taxis. You let the starter know in no uncertain terms that this is completely unacceptable. When you finally get into a cab it is after 10 a.m. The driver pulls out and is immediately caught up in traffic on La Cienega. The on-ramp to the 405 is jammed and he seems inclined to wait it out, so you tell him angrily to find another way. The guy agrees but doesn’t seem to feel your urgency. It’s nearly 10:20 a.m. by the time he gets onto the freeway. Traffic is moving at a snail’s pace. You can’t take your eyes off your watch. 10:25 a.m., 10:30 a.m. “This is a damn important meeting,” you tell the driver. “I mean really important. You’ve got to get me there by 11 a.m. I’m absolutely counting on you.” He just shrugs. Traffic grinds to a halt. “Well do something,” you tell him, “and make it fast. Time is a wasting.” He pulls off and gets immediately stuck in local traffic. You scream at him, “My meeting, dammit! It starts in fifteen minutes and you have got us nowhere. This is just totally irresponsible on your part.” By the time you arrive it is 11:40 a.m. The client has left and everyone is furious at you. But of course it’s not really your fault, you explain: “The airline, the baggage handlers, the cabbie, the traffic …”
What’s wrong with this picture? You did everything by the book: applied pressure, expressed your annoyance at substandard performance, told off everyone who was messing up your schedule.
What’s wrong is that you started too late. You could have flown in the night before, put up at the pleasant little hotel in walking distance from the Glendale office, had a leisurely breakfast and sauntered into the office a full hour before the meeting was to begin.
I’ve spent much of the last thirty years looking at and counseling software projects that were in trouble. The trouble they were in varied from project to project, at least the causes varied. What was the same in all the projects was that they were late. My clients wanted to know what to do to put them back on schedule, but they usually knew in their hearts that that was no longer in the cards. Their fallback position was they wanted to know what had made the projects so late. I would do my best to lay out the causes. But now, looking back at all of them as a whole, I can see that the real reason they were late finishing was that they started too late. All of them.
Can I really assert that the reason projects finish late is that they started late? All late projects? Isn’t it at least possible that some of them made mistakes along the way, frittered away essential time, or lost effectiveness in mid course, and thus caused lateness in what was otherwise a perfectly doable project? Well, I guess that is possible; it’s just that I’ve never seen it happen.
An elementary school that I pass on a walk into town has a marquis in front that reads, “Want to avoid being late? Be early.” But Tom, you might object, We’re trying to be early, that’s what governs the methods and approaches we use. And my answer would be, Yes, but how early are you trying to be? Are you trying to be months early, or are you only trying to be minutes early? A project that must be done by January two years from now needs to be run on a plan that gives it a highly realistic better than 50-50 chance of being completely done six months before that. Anything else and you’re not doing risk management. A project that starts too late to finish really early is one on which no meaningful risk management is possible. Your best tactic is to cross your fingers.
Tom DeMarco is a Principal of the Atlantic Systems Guild, a New York and London-based consulting practice. He is the author of thirteen books, most of them about the high tech workplace and its denizens, but also including two mainstream novels and a collection of short stories. His most recent business book is about organizational culture. It’s called Adrenaline Junkies and Template Zombies — Patterns of Organizational Behavior, published by Wiley in the US and Hanser Verlag in Europe. A third edition of his classic work, Peopleware: Productive Projects and Teams (with co-author Tim Lister) will come out in July, 2013. His most recent work of fiction is a bit of science fiction: Andronescu’s Paradox.
« Previous Next »