Why software delivery estimations are often wrong and what product managers can do to help

There were a few meetings when, coming out of the room I said “So what do we do when we’re late with this thing”.

Estimations are sensible subject. It still divides the product teams (judging by the /r/programming and the /r/productmanagement communities) and for good reason.

We need estimates because we need to coordinate a finite number of people across alternative paths for the product.

Most of the problems come not from giving the estimates, but the downhill turn of events that comes after: estimates are considered hard deadlines, them being underestimated makes the team look late, the company founders put pressure that goes down the chain of reporting and so on.

Why do we tend to underestimate the amount of work required? Some theories:

We tend to try and estimate things that do not have a known level of complexity. We’re good at estimating how much time dinner is going to take to cook, if we cooked it before.

Building a new company, probably less.

There’s some very insightful feedback from the /r/programming community from Reddit.

Correct estimations are not “aiming high enough”.

There’s an awesome post from mountaingoatsoftware.com that claims that underestimated projects are actually the ones that get funded the most, since no boss would sign off on the actual project estimations.

[...] when the boss hears that the project is going to take 1,500 hours, she decides not to do it. This project never sees the light of day and no one ever knows that the team overestimated. A project that is underestimated is much more likely to be approved than a project that is overestimated. This leads to a perception that development teams are always late, but it just looks that way because teams didn’t get to run the projects they had likely overestimated.

And this awesome, condensed reply:

Giving a wrong estimate is still better for shipping than nothing - aiming at a delivery date keeps the team working towards a goal, keeps everyone pragmatic, less things get built from scratch and refactored and the product team actually learns how good the product is by it being in front of actual users.

What can product managers do about it?

There are various exercises in trying to provide better estimations linked in the exercises at the end of the post.

For this, I am going to focus on helping with the product politics side of things:

Own the estimate, even if it’s not yours

This means course-adjusting based on latest findings. Speak with your team and recalibrate the estimation. If you’ll ship early, enjoy some padding time to do proper testing. If you are going to ship late, be the one responsible in front of your stakeholders.

If you throw your team under the bus, they will be as reluctant to be honest with you in the future. Build that relationship of trust and work hard at preserving it.

Be the one to align both sides, if no one does

This means clearly stating that:

  • It’s an estimate, not a hard deadline. Most people will push back on this, so you can provide reassurance by saying that you will provide regular updates about the status of the delivery time and that you will let them know in advance if anything changes.
  • If late, tell people as early as possible. And not with a “we’ll be late, sorry”. You can make a list of the unknowns and try and have a track record of what decisions were made. The best way to de-escalate a “why is this late” is to:
  • reiterate what we aimed for
  • go over what your assumptions were at that time
  • make an argument for why your assumptions were wrong or you couldn’t have predicted the thing that made the project get delayed
  • provide an action plan, and a new estimate

Awesome pieces for further reading:

Subscribe to tibi iorga

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.
jamie@example.com
Subscribe