Estimating projects is a pain. It also happens to be one of the most important things everyone wants to know. How much? How long? It’s a dark art that’s difficult to master, especially for anything remotely technical, and it’s easy to get an estimate wildly wrong. In fact, I’d estimate that 50% of all estimations are just utter nonsense.
A little research and my pun above doesn’t actually seem so far fetched. Via LinkedIn, an article in the Economist from a few years ago revealed that only 29% of IT projects ‘succeeded’. On average, costs over-ran by 56% of original budgets and projects took 84% more time than originally scheduled. Eye-opening statistics that, in a weird schadenfreuden way, make me feel a little better about myself. Cue vigorous nodding from everyone on the planet who’s ever worked in a service industry before.
Web wise, if you’ve ever crossed paths with a developer, you’ll know that estimating is a contentious topic indeed. My poor kindred fellows often get the blame for being unable to work to the timescales they picked off the top of their head months ago and, whilst I do believe that working to a timescale is an acquirable (and highly useful) skill, the real issue often lies in the original estimation to being with. Turns out, giving accurate time estimates for development is very, very, very difficult (who’da thunk?) – a fantastic response by Michael Wolfe to this very question on Quora last year helps explain why.
Aside from the unpredictable nature of development, however, a more fundamental issue with estimation lies in our social programming: simply put, our optimism is skewing our estimation. The UK Government has a fancy name for this phenomena, calling it ‘optimism bias’, and even published a white paper on the subject with details on how to mathematically adjust estimations based on project type in order to try and negate it. Apparently not enough Project Managers are miserable, pessimistic sods.
Whilst looking on the bright side of life may be the cause of most our estimation woes, I feel a more likely cause for it is our innate desire to please others. Sales staff want to paint the best picture possible, developers wanting a pat on their back from their boss instead of a scowl, account managers want to make clients happy… the spiral continues as we keep trading smaller points of pain at the start of projects for larger, inescapable, ones towards the end. I know, I’ve been there.
Regardless, estimation is still essential in order to give product owners guidance on what can be achieved with what means in what timeframes. It doesn’t matter if you follow an agile process or a waterfall one, one needs to be able to give reasonable estimations up front of what a product owner (internal or external) can expect. Without this, nothing can ever progress as no one in their right mind would embark on a project without a good inclination of what it’s going to involve (no matter how foolish our original plans might appear in hindsight). Sticking to budgets and timescales and managing project scope and implementation along the way is whole other blog post though.
There isn’t a clear cut answer to estimating and, failing to come up with anything better, all I can personally suggest is that trying to generate more accurate ones boils down to experience, realism and honesty. The former two are no-brainers but the latter is often under-appreciated and undervalued. Being brutally honest to bosses, peers or clients – and more importantly, oneself – as soon as possible is a hard thing to do. Postponing difficult decisions to a later date combined with the fear of what the reaction to undesirable news will be can result in a deadly brew for things slipping away uncontrollably.
So optimism is to blame for a good chunk of our estimation failures. I guess we just like positive reactions far too much for our own good. Unless you’re a sociopath. In which case you’re probably already a great project manager.
Image credit: Chris Zielecki