About once a year I have a big discussion with one of my colleagues about the concept of estimation. From a professional point of view, we come from different backgrounds. I am a developer and technical architect, and he comes from a background in project management and communication. This year we came to a conclusion that our disagreement is not in what the craft of estimation is or what an actual estimate is – but rather how to approach the common perception (or misperception) of an estimate.
Most people think of an estimate as the number of hours required to solve a given task. If we assume that this is the actual definition, we would have to assume that the task is well defined and completely fixed and this is always – yes, always – not the case. The Cone of Uncertainty (http://en.wikipedia.org/wiki/Cone_of_Uncertainty) states that an estimate is never precise (the uncertainty zero) until the task is complete – in other words: both the task at hand (scope, requirements, possibilities etc.) and the number of hours (or sum of money) required to solve it is nothing more than qualified guesswork. We all know this, right?
A fact of the matter is that quite a lot of our clients are not agile. In essence, they do not accept risk in an IT project, and trust us to carry that risk. This means that clients need to know the price of a given requirement before commencing on the work, which means that we have to estimate the “number of hours” required to solve “a given task” – and that the number of hours will not be flexible. Which bring me down to the greatest misconception of the above definition – that the “given task” is also not flexible.
For a great many years I have been one of the lucky developers attached to technical presales – and thereby responsible for estimation in the sales process. Now, if I had a penny for every receiving developer who has moaned about the “number of hours” on my estimate I would be a very rich man. In other words, it seems that many developers think that the “given task” is as fixed as the number of hours – why else would they moan about the hours instead of spending time on resolving how the solve the task within the timeframe? In these developers heads, there is only one solution to the task – and the problem is therefore the number of hours given to this solution. In my experience, there is never just one solution to a given task.
Coming back to my discussions with my colleague: What we agree, is that we need to emphasize – both to our developers and to our clients – is that in a fixed price project, the flexibility lies in the tasks, not in the number of hours. The disagreement is how we emphasize this to our clients and developers.
Call me an idealist or a dreamer, but I still think that key lies in communicating a broader definition of an “estimate”; something that makes it obvious that there is so much more to an estimate than a one-liner task description and a number.
I suggest the following definition of an estimate:
The assumed volume of a task with the knowledge of scope and value at a given time at with a given experience.
This definition emphasizes knowledge of scope and value, as well as context such as the time of estimation and the experience of the estimator. I know it’s not an easy definition, but I think the emphasis is important.
I know that I should probably back down and realize that the common misperception of an estimate is going to be dominating – but that would mean that I would have to let my colleague win the discussion. And I am just not ready for that…