In response to Tom LaRock’s Meme Monday, I’m writing about working with deadlines. I’m going to take the developer approach and talk in terms of new project deadlines.
My favorite approach to working with deadlines is to take control of the time. Deadlines are much like a line on a graph where time (the x-axis) and scope (the y-axis) intersect. Time and scope have a direct relationship — as scope increases, so does the time necessary to complete the items in the scope. Usually only one of the axes is negotiable. I’ve found the most common scenario to be, “We need a solution that can do this, this, and this. How long will that take?” Rarely have I heard the opposite, “We have this much time. What can we build in that window?” It’s up to me to answer how long the given feature set will take to build and deploy. In other words, I have control over time, not scope.
Before I go on, I must confess that even after years of software development, I am a dreadful estimator of project time. I often fail to consider adequately the interruptions and other projects that will forestall what I’m working on. It’s like the difference between the first time I played golf and the second: noticeable improvement but still horrendous.
My time estimates were totally unreliable until I picked up a book by Steve McConnell called Rapid Development: Taming Wild Software Schedules. In it, I found a truly golden section on time estimation that includes the following passage:
At the time when developers are typically asked to provide a rough estimate, there can be a factor-of-16 difference between high and low effort estimates. Even after requirements have been completed, you can only know the amount of effort needed to within about 50 percent, and by that time most organizations want their estimates to the dollar.
In other words, take your best guess of time, make 25% of that number your best-case scenario and make 400% your worst-case scenario. As you get further along in the project, you can refine your estimates down because there are fewer unknowns that can be introduced. Also, your estimates become more reliable as the project nears completion because people are reluctant to add/change features that will affect the deadline. If features are introduced later on, you can try to reject them citing the effect it would have on time. More likely, you’ll have to renegotiate the timeline (which I’ve found to be easier and more agreeable anyway). Another point mentioned in the passage above is that organizations typically expect far more precision that you are in a position to deliver at that time. If you relent and give a date certain when you yourself are not certain, you’re gambling you can come out on the low side of the estimate funnel, which if you subscribe to this process, gives you only a 50-50 chance of success.
If compelled to give a date certain, do yourself the favor of selecting the worst-case scenario at that time. In Star Trek III, Scotty confessed he did exactly that (multiplied his repair estimates by a factor of four) to keep up his reputation as a miracle worker.
The range estimate method has worked wonders for me. People understand there is uncertainty in the development process and actually appreciate that I don’t throw out a specific date haphazardly. Being honest about the variability of time required also frees me from the looming specter of a date I was never sold on in the first place. As the project progresses, I give updates with narrowing ranges, until the very end, when I can say we’re ready to go live with the project next Tuesday.
I highly recommend you give this method a try when time is negotiable. I’ve found it results in more realistic expectations and deadlines. By taking control of project time, you make uncertainty a natural and acceptable part of the process, rather than struggling futilely to eliminate it.
