Some thoughts on project estimation & risk! (Part 1: The anchoring trap)
Alex Corradi / +Alex / November 12, 2014

If a man will begin with certainties, he shall end in doubts; but if he will be content to begin with doubts, he shall end in certainties. - Francis Bacon, The Advancement Of Learning

An estimate, after all, is only an estimate, and whilst some projects can be sized more accurately than others, the reality is that in software development there are usually too many factors and unknowns at play which make trying to predict the exact time it will take to build something pretty much impossible! Anyone that thinks otherwise is simply asking for trouble.

The anchoring trap: What is it? And how to avoid it? 

As identified in 'The Hidden Traps in Decision Making' (Harvard Business Review, 1998), the anchoring trap is when your boss or client comes to you with their own estimate (or desire) i.e "is it possible to build this fancy new website in one week?" By doing so, they have anchored your response and established the terms on which a decision will be made. In other words, the expectation has been set around a single point estimate (a narrow minded perspective) which means that the risks and uncertainties surrounding this potential project have been pushed your way, for you to deal with and these are risks for which you will ultimately be held accountable for!

A single-point estimate is usually a target masquerading as an estimate - Steve McConnell

One way to avoid the anchoring trap, and something we're starting to experiment with here at GPMD, is to present your estimate as a range.

In simple terms, an estimate range consists of getting two (or more) estimates - one that's "aggressive but possible" i.e we know how to approach this task, we've done it before, if all goes well and no issues pop up along the way, there's a high probability that we will deliver this project within this timeframe. The second estimate is more "conservative" and takes into account possible pitfalls and problems. If we think about it, this is really about representing the natural variation that could occur in a project. By adopting this approach, not only will you remove the notion of 'exacts' but this will also give you the opportunity to highlight the risks and uncertainties with your client, right from the outset. In the process, the risks will be highlighted to the client and appropriately budgeted for. This process will also assist clients to carefully think through their objectives and how important different aspects of the project are to them.

In part 2, I'll explore how we can incorporate range estimation into Agile planning, but I would like to finish off by highlighting a point observed by Mike Cohn in his book 'Agile Estimating and Planning' ( Chapter 17), that the greater the spread between two estimates, the greater the uncertainty, and the lower the spread, the more confidence and less variability there will be. 

Further Reading:

Agile Estimating and Planning by Mike Cohn

The Hidden Traps in Decision Making by John S. Hammond, Ralph L. Keeney, and Howard Raiffa