Recently, a local builder handed me an estimate for some construction work on my home. Once my eyes had stopped watering, he calmly explained to me that I wasn’t paying him for what he could do, so much as what he knew. He’d been in the trade for 30 years. “That” he declared, pointing at the estimate “is exactly how much it will cost, and exactly how long it will take”. Three weeks later the work was complete, exactly as he said it would be, and I gratefully handed over a vast sum of money.

Why do so few IT projects proceed in this way? Why are most developers so poor at estimating projects? The first trick, when estimating, is to break down the project into all of its component parts. Accurately identifying all of these steps is difficult, and is a skill that comes with experience. The second task is to assign time estimates to each step. Again, the more times a developer has been through the mill, the higher the likelihood that a given task is one has been seen before, and the more accurate the estimations become.

Even then, given that software development always tends to be on the cutting edge of technology, there will always be a few steps that even the experienced developer will not have encountered before. It is at this point that a developer is likely, if pressed, to give his “best guess” as to how long the “unknown” step will take. It has been wisely observed that the inaccuracy of these “guesstimates” increases exponentially with time. If the estimate is a day, you can expect it to be finished in around a day. If the estimate is a week, it will probably be finished in 1-2 weeks. If the estimate is a month, then the developer really has no idea how long it will take.

Any step that is estimated at over 1 week is a danger signal. Any step that none of the team has encountered before is an “unknown” and therefore a risk. Instead of “guesstimating” such steps, the developer should apply solid three-valued logic. If a step is “unknown” then a NULL should be inserted into the time column for that step. Of course, thanks to NULL propagation, that means the entire project timeline is NULL. The developer must then insist on having time to prototype these NULL steps, so that estimates can be made based on hard evidence, rather than hunches and guesswork.

Inevitably, there are many “agile” techniques, such as planning poker and velocity measurements, which you can use to produce more accurate project estimates. Most of them are well-documented. However, the biggest problem still remains that the IT industry, unlike the building trade, is notoriously bad at retaining experience. In the main, companies hire and pay developers based on what they can do (write code) rather than on the knowledge that comes with experience, such as effective project estimation and management. If these skills were properly valued and rewarded, the industry would do a better job at retaining experience in the role, and the development team’s estimation skills, like fine ales, would refine and mature with age.

Cheers,

Tony.