The subject of estimating certainly provokes passionate reactions among people.  I remember at a previous company we were having a few quiet and well-mannered drinks after work, and once someone raised the question of estimating, the whole affair turned into a hard-drinking drama – something out of a western.  At one point a fairly senior manager stormed out…  Only to return a few minutes later with ‘and another thing about estimating…’ – and ended up staying the whole evening.

It was 6:45PM.

So it’s one of those subjects where there are strong views.  It’s also an area where there isn’t a single solution – or even a single definition of the problem.  It also leads you into some quite revealing insights into the workings of your own organisation.  There certainly more facets to cover in later posts.

“Estmates are estimates – they are not quotes.  A quote is something you get on your car insurance”.  It was the mid 90s when I first said this to someone.     It’s interesting also, that over the years, you tend to get embroiled in similar debates are different companies.

When approaching estimating, there are it seems to me, two basic approaches you can take. There is also a third line of enquiry which leads you into questioning what the estimate represents, where it goes, and what people eventually do with it.  This third area is, in some senses, more interesting – but we’ll come back to that.  Lets start with the two basic approaches:

Approach 1) - ’Get better at it’ 

I once had a manager who said ‘we need to get better at estimating – we just aren’t very good’.  Come to think of it, I have had few managers who haven’t said that.  In most organisations the ‘getting better at it’ follows projects that have gone wrong for some reason and are accompanied by much soul searching, brain storming, workshops, training etc. etc. 

‘Getting better at it’ is part of the human condition:  We want to improve the things we do, and just as you aspire to be a better tennis player, or a better cook, we can get better at estimating, right?  Well… perhaps. 

When someone says ‘we need to get better at estimating’ what they really mean is: ‘Can I have an estimate that is so good it will cover all the things than can possibly happen on the project, irrespective of their cause, so there is never a cost overrun’.

To use our tennis and cooking examples, that is like expecting to become so good that you get to Roger Federer’s level, or that of Gary Rhodes.  Is this possible?  No…    but the notion that it might be possible to get this good,  is a problem.  That is not to say you can’t improve – clearly you can, but that isn’t really the point.  You’re never going to become good enough. There is also the problem that you run the risk of humanising the estimates. ‘Oh – this project will be fine because so-and-so is doing the estimates, and hes good at doing estimates’.  This might be down to greater experience – clearly a good thing – but the personal and emotional involvement in estimating, rather like using ‘gut feel’ can be a problem if it goes wrong.  On the other hand, it might be better next time.  All this perpetuates the delusion that the perfect ‘quote’ is achievable – it just needs you to work at it a bit more.

So ‘Getting better at it’ can be a problem. It sets aspirations on you and expectations from the customer that are impossible to live up to. It also assumes that the present is always in some way wiser, and better informed than the past.  This is debatable.

Approach 2) – Mechanistic or Formulatic approaches

This covers alot of topics – which I won’t go into here – but basically the notion is that there is some form of ‘system’ or mechanism one goes through to arrive at the estimates. It removes the human/personal/emotional involvement in favour of a party line, a consensus.  On an agile project you might estimates stories by the usual ‘T-shirt sizes’ – small, medium, large etc.  Or you might have something more complex.  What matters here is that you have something provable and demonstrable that your estimate is based on.  ‘We have our system – the cleaner could use it and end up with pretty much the same result if they followed it’ was the view of an ex-boss of mine.

Why is this important?  It’s important because by removing the human involvement you are recognising and accepting up front that an estimate isn’t ever going to be perfect. You aren’t going to be the Roger Federer of estimating, and think otherwise you are deluding yourself and setting the customer expectations that will be impssible to deliver.  It’s fine to not be perfect:  The interesting question is, why are we being forced into a situation we know is wrong? The orgnisation isn’t out to deliberately sabotage itself, so why are we being asked to produce ‘perfect’ estimates when everyone knows we can’t?  Who is forcing us into this? Why? 

Where does it all go?

What happens to your estimate once you’ve produced it is one of the mysteries that it is not always possible to crack.  Usually you find that any caveats, rationale, footnotes and explation gets forgotten once the finance people get at it.  If your estimate is going outside to a customer, it might well be you have the ability to insert a clause along the lines of ‘this work is conducted on a best endeavours basis’, but come to think of it, all work is generally conducted along these lines.  Why is our estimate translated into carved into stone number?  I have often referred to this as the ‘Purchase Order Culture’:  People funding their IT projects as if they are buying paper clips and desks. A terrible simplification.

But that is another article…


I think the main issue about estimating is simply that people expect far to much of it.  This is driven by the fact that far from being more flexible and adaptable to change, organisations seem to be getting more rigid and beauracratic – at least when finances are concerned.  This leads to an expectation that everything can be predicted in advance, and we know that this simply isn’t possible. If a project goes slightly awry and new requirements or better ways of doing things are uncovered during the project why cant we adapt and get funding for it?   Why are we continually painting ourselves into a corner?  More importantly, why does the IT profession have to carry the can for such nonsenses when it all goes wrong?

« »