11 November 2014, by Zoe Cunningham
The following is an excerpt from my new book, “Galvanizing the Geeks – Tips for Managing Technical People”. You can buy the full book on my website, here.
Why people underestimate
The single most common cause of failure for software projects is misalignment between the time that the project is expected to take to develop and the amount of time that it actually takes. There’s a good reason why estimating is known as ‘the black art’. Assuming that you’re far enough down the line not to be estimating against tasks that bear little resemblance to those that you’ll eventually undertake, there are two main ways in which your estimates can be horribly, horribly out.
Firstly, single tasks may overrun by hundreds of percent. The coarser-grained your estimate is, the more likely this is to happen. I’ve found that tasks that are in the order of a day or two are easiest to estimate. It is too easy to underestimate the size of a ‘large’ task; there are very few tasks that don’t feel like they will fit inside a 20-day estimate – that is, until you break them down. Even a task of five days is likely to be concealing hidden gotchas, simply because, to get a five-day estimate, you don’t need to know exactly what you’ll be doing on each day. So Rule One of estimating is to break down large estimates into smaller ones.
The second most common cause of overrun is The Missing Task. You can have a whole spreadsheet of perfectly estimated line items, but, if there is just one task that isn’t on there, your project will slip by the amount of that task. To help avoid such omissions, it can be useful to have a standard set of tasks that you always estimate (or explicitly omit) for every project – and to make sure you think carefully about what exactly needs to be done. Estimating in small numbers, as described above, can help in dealing with omissions that may or may not have been included as part of a line item.
It’s hard for anyone to assume that there are tasks hidden within a single day estimate – but however thorough your process and however rigorous your analysis, you will still miss some tasks. It is inevitable. So you need to leave some contingency, preferably just by adding a big fat contingency task as a new line item. Without any contingency, you are guaranteed to fail.