You know it happens all the time. You know you’ve done it yourself. Indeed, I’ve done it too: Underestimated a story or task that is. This may seem like an innocuous thing at the time it happens, but of course it can have pretty dire consequences.
In my experience, people tend to underestimate tasks for a whole range of reasons. It easily happens in groups or teams where the members aren’t fully secure where they stand on a professional level compared to the other members. Many people hesitate to tell a room full of new acquaintances that their estimate is way off target, and fail to realize that precisely that may be the ‘senior’ thing to do. Obviously, newly created teams are prone to this issue.
There’s also the issue of pressure on developers to ignore risks in certain situations. When your estimates decide whether your company will get that ‘fat’ contract – a job you, as a developer, are desperate to land due to the nature, size, importance or technical aspects of the project – it may feel like the most natural thing in the world to underestimate. Pressure can also come from management or from expectations on a person elevated to ‘architect’ status to perform miracles in no-time.
Yet another another underestimation trap to fall into is our tendency of pure wishful thinking. Nothing bad could possibly happen to my progress when using this pre-alpha document database, I promise!
I’m not talking about zen agile projects that have the same team running for years, in a business area where the money is flowing and everything is hunky-dory. The software world is not that perfect, and the above mentioned constellations of new teams, short-term projects and up-front estimates are not uncommon.
Anyway, there’s a scientific term for this, namely ‘Planning Fallacy‘, which automatically makes it more comfortable; we know others are experiencing the same thing. Unfortunately that doesn’t mean we want this ever to happen.
Thinking back, I remember a smaller contract project that a client requested offers for. I estimated the total effort to something like 50% more than the winning bidder. The project was supposed to run for about two to three months for a couple of developers. A year later the client had finally received an acceptable delivery. However, the code base of the product was not in a fully coherent state and thus my company got the chance to continue development. In the end, it would probably have been more profitable for the client to scrap the code base and restart from scratch.
If I would list a few recommendations to alleviate the problems, it would look something like this:
- Management and project leaders or other stakeholders should try and conceal any preliminary budgets or estimates to the team. Otherwise developers could easily be influenced.
- Architects and senior developers must take responsibility of having the mature view of the estimation of tasks. They should have the best apprehension of risk, and should try not to jump to conclusions.
- The team should learn and use available estimation techniques, such as Planning Poker.
- Everyone involved should be aware of that in the long term, it’s more profitable both for the client and the contractor, to cancel work that have very little chance of being completed within the given budgets.
- It’s very hard to overestimate things by a large margin – stay on the safe side. Even if you manage to meet your daredevil estimates, will you be comfortable with the delivered code quality?
It’s not easy being a client; it’s hard to know which contractors can be trusted and which cannot. If you’re a manager looking at budgets there is an immediate pressure to find bargains. Developers also have a hard time, contractor or not, with the issues described above. But the next time you estimate something, anything, do our business a favour and don’t underestimate the cost of developing working software.