20 May 2011

How good are WE at estimating?!?

[Start at the beginning]

Personally I suck at estimating.  Estimating in the number 1 reason I feel stressed and pressured.  Bad estimated are, for me at least, the primary source of problems with customer satisfaction, and my personal satisfaction with my personal work in progress.

And honestly, at the project team level, estimates are so consistent bad, across so many teams that I wonder why we even bother with the pretense.  Even frequent feedback doesn't seem to overcome people's inherent bias for optimism or pessimism.

The one thing I know about estimates is that if they are met, it was most likely a co-incidence.

So just because you know the likely scope - which is what you planned, plus a factor for the quality of your outputs (related to available time, politics and a whole bunch of intangibles), plus your company's very own scope creep standards and the project estimated duration...

Well, even with all that, your estimates are likely to be crap.

Maybe, as a business analyst you can absolve yourself of the responsibility of tracing estimates to actuals and making corrections.

On the other hand, as a team member you are committed to project success or you aren't.

Which is it hombre?


  1. Anonymous7:29 pm

    I have found that estimates are pretty useless. Inevitably, if a developer says it will take 10 days, it takes 10 days. I never get a report back that the estimate was way off. Why would anyone tell me that their estimate was wrong?
    Anyway, I think the best thing to do is to work at gathering the best, minimum requirements and reviewing with the developer. By that point, everyone should have a good idea of the scope and the deliverable and then everyone accepts a schedule. But whether or not the estimate is "correct" is really beside the point.

  2. I agree IT work estimation is significantly challenging. Equally challenging is when those fundamentally inaccurate work estimates are used in critical business decisioning. Yet, until someone comes up with a new magic technique, business and IT partners will continue to struggle through work estimation and prioritization.

    Although not perfect, I've written about a technique that I've found some success with when it comes to helping developers break work down for more effective guestimation ... I mean estimation: http://bit.ly/gqegGi

  3. Craig, I'm not sure I understand your point here. Are you suggesting that it might be the BA's job to track actuals vs.estimates? Is this what we would normally expect the PM to do?

  4. @shim, I am suggesting this - but only so far as you can make your requirements define the project scope (which you should be able to get close to.)

    Consider that a part of a BA job is to track the state of requirements through the various development stages through to fulfilled and in production.

    It's happening anyway with good requirements traceability. Most requirements management tools also have a place for assigning estimate to fulfill, so even the tools are ready and equipped.

  5. Just because a developer is good at the technical stuff does not mean that he/she is good at estimating. Many have no idea of effort versus duration, for example, and are driven by optimism and a need to please the boss. Many of us have no idea where our time goes during the working day, and just how little time is left over for work!


Search This Blog