It’s time to stop beating ourselves up about how bad we are at estimating project delivery.

Have you ever been on a project that is good at estimating?

I know everyone thinks they have, but I reckon if we’re really honest we’d admit that even when we seem to get it right, someone, somewhere in our team has probably compensated for poor estimation by working longer hours.

That’s not to say that we can skip deadlines.

There will be situations where they are unavoidable; software is discontinued, certificates run out, millennia come and go, and market opportunities arise.

And if deadlines don’t happen to us, they still happen to others, which means there will be times when we have to work to a deadline simply because another team is working to a deadline.

But for the most part estimates and deadlines are setting ourselves up for failure.

And that’s not because some people are ‘bad’ at estimating while others are ‘good’. It’s because estimating how long a particular task will take, with any accuracy, is near enough impossible.

If you want to be a bit scientific about it, in most projects the variation between the lead time for tasks (i.e., the time measured from when the team committed to doing the work, through to its delivery) is far greater than the variation between the task-work itself. To put it differently, even if you were always 100% accurate in your estimates of how much effort a task would take, you could still be wrong every time when it comes to estimating how much time will elapse between getting the task from the customer and delivering back a finished item.

So what’s the answer? Do we simply remove estimation altogether?

We don’t, but what we do instead is frame the answer differently.

To do this we must measure lead time–ideally tracking different lead times for the different types of work we are involved in. Once we’re armed with historical data then the answer to the question how long will this task take? requires no skill! The answer becomes simply this: on average, this type of task usually takes this number of days.

Alongside collecting this data we should reduce lead times, since this will reduce their variability and make the range of possibilities narrower. There is plenty that can be done in this area, from working in smaller batches of committed work (which will immediately reduce lead time), through to improving quality (which reduces lead time by reducing rework).

Topics for another day–but for now, it’s enough to say that if you are providing fixed delivery dates based on your attempts to estimate, then it’s almost inevitable that both your customers and your developers are going to be very disappointed.