Know what you're doing (Part I)
By Bob Hueston on Apr 12, 2007
Occasionally I give an internal presentation on project planning, as part of a multi-day class for new software project leaders. As Sun has a widely disperse engineering work force, there's always a few people who fly into the Boston area for the class. My portion is usually on the last day, and I start my lecture with a question...
"Who plans on flying home today?" Inevitably, a few people have tickets for the evening flight. I pick one of those people at random and ask what time their flight is; a typical answer is around 6pm, the last flight to the West Coast. "So, let's plan your trip," I continue. "We're about 15 miles from Logan Airport, so it takes about 20 minutes to drive there. After returning your rental car, the bus ride to the terminal is about 10 minutes. And it takes another 5 minutes to check-in and 10 minutes to get through security. That's 45 minutes, on a good day. So you'll leave for the airport at, what, 5:15?" Laughter usually ensues.
The response is usually, "No! I'm leaving as soon as the lecture is over, 4 O'clock at the latest. If I left at 5:15, I'd probably miss my plane. There could be traffic, a breakdown, lines at the rental car return, or a delay at security."
"Who here has ever missed an airplane, even by just a minute" I'll ask the class. Maybe one or two hands go up. "Who here has ever missed a project deadline, even by one day." All hands go up. "So you plan your personal time better than you plan your software engineering projects?" At this point, a look of enlightenment usually overtakes the room. We do everything we can to avoid missing a flight, but we're not nearly as concerned about missing a project milestone. Missing a flight might cost us another night in a strange city, but missing software project milestones costs companies huge amounts of money in terms of development costs, delays, and time-to-market.
The flight's departure time is a contract, between the airline (they will not leave before the specified time) and you (you will be there before the specified time). The same is true of a project plan. A plan is not an estimate of when you might be done; it is a promise, a contract, of when you will be done. You can't always keep every promise, honor every contract to its fullest, but we need to treat milestone dates like promises, and do everything in our power to hit the dates. And as soon as we know the date is at risk and the promise is in jeopardy of being broken, we must let people know. When I promise my wife I'll be home at 6, she doesn't mind too much if I call at 5 and tell her I'll be an hour late. But she gets really angry if I just stroll in at 7 without any notice. If she knows I'm going to be late, she can change her plans. If I don't tell her, dinner gets burned in the oven and ends up buried in the backyard.
In one class, a person asked, "I see what you're saying. But how do you justify it to management when you identify 6 months of work, but you tell your boss that it will take 12 months?" The same way you justify to yourself leaving two hours before your flight time. You know there are risks driving to the airport, so you allow extra time. But you also plan for the case when the roads are clear and you breeze through security. Maybe you skip dinner and plan to eat at the airport (and if you're late, you may fly hungry, but at least you're in the air on time). Or you bring a book or your laptop so you can read or do work if you have extra time.
The same goes for project planning. You prioritize your requirements, your features, and separate them into must-haves and nice-to-haves. You create your plan for all the requirements, but only promise the must-haves. If you finish the must-have features early, you can do more of the nice-to-haves. But if you start running out of time, you drop the nice-to-haves from the list, low priority first. Returning the rental car, passing through security, and getting to the gate are must-have requirements; eating dinner and reading a book, while important, are still just nice-to-have requirements.
If you approach project planning with the same forethought as a drive to the airport, in the end you will deliver a project with all the must-have features, and maybe some of the nice-to-have features, and you'll deliver it when you promised.
So how do you create a plan? Stayed tuned for my next blog entry...