A blog post about estimating

First of all, a provocative but sweeping statement about the subject to kick us off: If your agency won’t talk to you about how they estimate projects then they’re either liars or fools.

You’ll have heard of Zeno’s Paradox. The one where a journey can theoretically never be completed because in order to travel the full distance you must first go halfway. And then once you’re halfway, you must then go half the remaining distance and so on.

The paradox is that in order to do something as simple as walking across a room, one must complete an infinitely regressing set of tasks. And yet, without wishing to boast, I’ve crossed the room twice already today and I managed it just fine.

Software estimation is a bit like that. If you analyse it closely you’ll see the tasks you have to complete multiply infinitely until even the simplest thing looks impossible and the budget is smashed to smithereens. And yet, as a company, we’ve got a track record of delivering on time and to budget that goes back years.

The various methods that we use are described in the episode of our podcast that this post supports (Why not go and check it out?) and we won’t go into detail here suffice to say that the process is always time-consuming and rarely problem-free.

So it’s hard. And prone to error. And time consuming to even do badly. So why do it?

The obvious answer – so you know how much to charge – is not actually all that applicable. More and more of the work we do on agile projects is charged on a time and materials basis. Additionally, there are a hundred good reasons why an agency might want to charge a price that wasn’t just literally [amount of time estimated] multiplied by [hourly rate].

No, the real reason that we put so much effort into estimation is that estimation is a great disinfectant. Everyone who works in this industry has a story about a project that went from perfectly fine to completely awful in a matter of seconds. Estimation helps us expose and resolve the factors that cause this horror: hidden complexity, differences of assumption, Just Plain Goofs etc.

It’s important to note though that even a carefully produced estimate can still be wrong and so the other key tools an agency needs are mature processes and procedures. You need to be able to effectively communicate how the estimate failed, assess what the impact of the failure will be to the broader project and, vitally, put all this information in a place where it can’t be forgotten or ignored.

This last step is effectively giving the organisation an institutional memory that lasts longer than 10 working days and it’s the vital step that ensures that by the end of the project the stakeholders can remember that there was a problem, see that it was resolved and how it affected timelines overall. Mistakes are always going to be made but the key thing is to ensure you’re always making exciting new ones rather than repeating the old ones.

All of the above is discussed to some extent in our Estimating podcast. Myself, Andy Theyers and Richard Newton spend around half an hour discussing the subject and, honestly, it’s quite interesting. I urge you to check it out.