The Art of Estimation

If you’ve worked in product management or consulting for any amount of time, you’re familiar with the estimation gremlin.

I’ve always hated managing projects. For me, it’s too much whip-cracking and tattletaling, but it’s an unfortunate chore that I’ve been unable to avoid. If you worked on a project I managed, I’m really sorry. I was in a bad place then.

One of the toughest skills a software project manager must have is the ability to understand estimates and know when they’re over- or underestimates. Every project has an end date, and generally, it’s the project manager’s job to make it fit into time parameters that come from on high.

The funny thing is that having development experience yourself won’t get you all the way there either, since writing code is more art than science.

What’s that you say? Why not just accept what your developers and plan according to their estimates?

This can work, but it’s risky and unreliable. Why? Because your developers lie to you.

Maybe not intentionally or maliciously, but every developer has an idea of how much time it will take to do a unit of work. Rarely, if ever, will you know that estimate because there are other forces at work that drive the number the developer will commit to up or down; the good news is that working with the same team on multiple projects helps you understand these reasons and plan for them.

The key here is to know what type of estimator each of your developers is and adjust up/down accordingly. I’ve observed two types; let’s call them the hacker and the scientist.

These are broad characterizations provided for amusement not documentation, and I’m applying the types here to how the developer estimates, not how the developer codes or the quality of said code.

So, take it easy and enjoy.

The Hacker
Even though hacker generally has negative connotations, in this case, it refers to an enthusiast, someone who writes code for fun and for work. Someone who probably contributes to an open source project and has more than two machines, at least one with Linux installed.

The hacker is a chronic underestimator. Beware and always plan for at least double the effort.

The hacker underestimates because s/he wants to kick ass and move on to the next piece of code. It’s the enthusiasm the hacker has for writing code that leads to underestimation. This is good for the product, but dangerous for the project plan.

The Scientist
In contrast, the scientist follows methodical process to estimation, analyzing the task in its parts, probably writing psedo-code before committing to an estimate.

The scientist always, always, always overestimates. Usually by double, sometimes more. The scientist expects a negotiation with you, which is why the original estimate is so high.

Enthusiasm for coding isn’t necessarily lacking here; it’s just dampened by the overall project plan and the prospect of unrealistic expectations, i.e. the scientist doesn’t want to get burned by missing a date. It’s classic CYA estimation.

You Really Need Both Types
The ‘Lab has been around for about a year and a half, and we’ve had the same team for a year. In that time, I’ve worked on several projects with Rich and Anthony, and by now, I feel like I can identify their types.

Rich is a self-described hacker, and surprise, he’s a recidivist underestimator. Keep in mind, this isn’t a bad thing; it’s good to know when Paul asks me to make a plan for something.

Anthony is an overestimator. I knew Anthony from our days in EBS development with David, so I knew to expect this. He’s been through the fire on projects with impossible dates, which has inflated his estimations.

I like having one of each type on a project because it helps me find a balanced estimate. As the project manager, it really helps to have opposing views of the same work, e.g. what Rich says he can knock out on his iPhone at Tahoe in a weekend, Anthony says might take a month of full-time effort.

Of course I exaggerate. The most accurate estimate lies between what they say. Each of them is a rockstar developer, they just come from different schools of estimation.

So, thoughts? Which school of estimating do you follow? Are you a project manager with some other insight?

Find the comments.

Automagically Generated Similar Posts

This entry was written by Jake and posted on 28 August 2008 at 9:01 am and filed under general. Bookmark the permalink. Follow any comments here with the RSS feed for this post. Post a comment or leave a trackback: Trackback URL.
  • Tim
    @Jake, Nice post - estimation becomes laughable when all the manager is interested in is that if you estimated 4 weeks for a project and you're a week in then you should be at 25% complete! Software dev is a little 'hockey stickish' - managers need to remember that.

    @Dave - grey hair!?! ... I wish! When I arrived in the US in 99 I had a full head of it. Those that know me, will know that 'a bit thin on top' is a gross exaggeration :0)
    Im not blaming s/w development - I blame my kids :0)
  • @Tim - now you mention it, s/w is a walk in the park compared to kids
  • Yeah, project planning is so hard b/c it attempts to apply hard and fast dates to work that's highly variable, even hour-to-hour for the same person on the same project.
  • The way discussions often go, is I explain what needs to be done with some squiggles on a white board, a lot of talking and a bit of arm waving. Then I ask the engineer
    "How long do you think that would take?"
    They respond
    "What's the deadline?"
    "I just want an idea how much work you think it is"
    "Well it depends. What deadline do I have?"
    "Tomorrow"
    "Tomorrow! It'll take me at least two weeks"
    "Finally, thanks"
  • Yeah, this is a problem with deadline-based estimating. If only we could build s/w in a vacuum w/o any deadlines. I'll bet that would rock.
  • Totally, this is estimation by bullying with a date. Not sure why this happens so much, but it's very common.
  • gary
    The bit that gets me is whether the manager wants an estimate of effort time, or calendar time. It may take a week of coding to do a module, but you have to wait for an API spec to write one call, or for a db refresh to run a test, so there's two or three weeks between start and end.
    Any estimate that doesn't come in a format like "About x hours for the first week, then y for the next two and another z at the end for sign-off, but only after Fred is back" is too simplistic
  • I am happy to get an estimate of x hours to design, code and unit test. As a project manager my job is to help put all the other moving parts into place, dependencies, documentation, QA, performance testing, vacations etc.
  • You're right. That doesn't make it easy though.
  • You sound like a very scientific estimator.

    You and Meg both bring up a reason that development is hard to estimate; there are inevitably unforeseen and unscoped moving parts that frequently are forgotten or can't be estimated anyway.

    Another reason why project management is maddening.
  • megbear
    Jake, you come close to nailing it for me with this one although I tend to see a few more layers between. One thing I find a lot is not just the estimate time but also the comprehension of "what" the estimate should include. Developers I work with are quick to think of design/code/unit test but what about UE polish? Performance testing? Integration testing? ADA compliance testing? automation? and so on. The "oh, I wasn't including that" is where the biggest risks come into the picture for me. Probably a sign of the size projects I tend to be involved with but all those "little things" can add up to be a project killer if you are not clear on the "what"
  • Good point. From my days in apps development, mandates moved too fast for training to keep up with them, e.g. Forms to OAF impacted estimates across the board, design/code/test/doc all that.

    Don't ever let anyone tell you s/w is easy.
  • writing software is easy, building a robust, performant, scalable, deployable, ADA compliant, platform independent, patchable, upgradeable and commercially viable ERP suite is tough. That's why my hair is turning gray.
  • Your hair isn't gray, and s/w is hard. Everyone should know that by now.
  • pgkiran
    5-6 years back I had a manager, who used to ask me for estimates with break down and when he builds the schedule he used to simple double the estimates and publish it up. It kind of made sense in a way with all the little little things that pop up we could never meet the dates and it also used to give us time to learn, find new ways to things if we do finish things on time. As a dev manager now I try to follow those principles however sometimes we try to break the complexity using Agile development methodologies,twice a month deliverables with a complete dev,qe, integration and product management validaton cycles. For sometime I also used LiquidPlanner to come with estimates with some fluidity built in, I blogged little bit about it at http://www.appme.net/2008/09/09/liquidplanner-p...
  • Doubling the estimate is a classic tactic, but it underlines the fact that the estimate is wrong from the get-go. How great would it be if the estimates were right?

    Whenever possible, I prefer to ask the developers to commit to a number and negotiate down to where we're both comfortable. This means they own the dates as much as management does. Classic wisdom from a box whose name escapes me right now.
blog comments powered by Disqus