Underpromise & Overdeliver

by

Everything Sysadmin has an interesting post that ends up talking about the whole “underpromise and overdeliver” strategy.

I’ve always had a rocky relationship with that strategy, mainly because I really think people just need to stop acting like they’re heroes on Star Trek and get better at time estimation.

Certainly when there’s doubt about how long something will take it’s better to overestimate, because that way the promises your customers made to their customers, coworkers, or boss aren’t lies because of you. It also helps to give yourself a little breathing room, so that if something urgent comes up you can deal with that and still deliver. The trick is just not to overdo it. People aren’t dumb, and consistent “underpromising” to the same set of people means that they will start expecting it. Do you really want people disappointed that it actually took you two days to do something when you said it would take two days? Of course not. You also don’t want them heading to your boss and complaining about how long something might take, just to discover that you weren’t completely honest with them at other times (or now). What are you, lazy? Exactly how are you spending that extra time?

In my opinion it is better to make consistently accurate time estimates and follow through on them. And, if you discover that your estimates might not be right, be honest about it, but also figure out what made you wrong and remember it next time.

3 thoughts on “Underpromise & Overdeliver”

  1. It is identical to padding your budget. You don’t want to come in over, because that’s bad. Coming in under is bad, too, though not as much so. Instead, we overestimate, and if there are resources left over, we use them for good.

    Or play X Tanks. Either way 😉

    Of course, just because I do it doesn’t mean that I abuse it. It’s an unfortunate aspect of my job (or fortunate, depending on your view) that I frequently do new things. In fact, I only generally do things three times. Once in a mock up, once in production, and once in warm backup.

    I have a really good idea of how long the warm backup is going to take to setup, because I’ve done it twice. It also takes the least amount of time.

    After the mockup, I’ve got a pretty good idea about how it’ll be before it’s completed in the production setup, before I start, I have only the vaguest idea when it comes to the mock up. The irritating part is that no one but me cares about the mock up, they want the time from start to “done”.

    So I estimate based on the knowledge I have of the procedure, pad my time, then multiply by two and a half or so. It usually ends up, if not accurate, then in the same ballpark.

    I’m very much interested in how other people do this. I’ve never been exposed to the kind of structured environments that call for rigid time spans.

  2. Matt, you’re absolutely right. New stuff is often the trickiest to estimate time for, because it’s new and you’ve never done it before. I usually try to indicate that to my customers, and if they’re willing I’ll only give them a time estimate after I’m done with the mock-up. Some customers just don’t get that new stuff is an unknown, though…

    My problem usually lies with multiple customers controlling my priorities, and therefore my schedule. Everybody is my most important customer!

Comments are closed.