Have you ever had a client of manager that required you to predict how much time a project will take?
Well I think we all have and we all have failed. Sometimes miserably.
If a task takes a few hours for real. I’d estimate it as an one-hour task. If it takes two weeks I am pretty sure I’d estimate it as a few days at most. I thought it’s just me, but it’s not. It’s actually a part of reality for most people to be bad at estimating how much time things will take.
We all know deep (or not so deep) inside that we suck at estimating. If you are one of the rare cases who are able to predict future events don’t read any further, but if you’re like me – welcome to the club and keep reading for you are about to learn some very practical stuff right here.
Planning Fallacy (Time Estimates – Mission Impossible)
The term was proposed not so long ago – in 1979 by two psychologists. The two gentlemen observed that people are most likely to underestimate the time to complete a project.
The planning fallacy was actually discovered trough direct experience. If I remember correctly they were teaching at an university and at some point they wanted to write a schoolbook. Since psychologists love polls they asked their students and colleagues about how long they think it’s going to take to write and publish the book. All of the people including the dean and some of their colleagues who actually wrote books before estimated the project to take 1.5 to 2.5 years. Even the most pessimistic estimates did not go any further than this.
They started writing, time flew and they were at the 2nd year mark when they realized they will need at least twice the time to finish the project. They were puzzled since their more experienced colleagues have not made such estimations at all. So they went back to them and asked again how much does it take to write a book from their own experience. They said it takes between 7 and 10 years. So why did not their colleagues tell them that the first time?
How to Estimate Better (Time Estimates – Mission Possible)
It turned out that when people estimate a single project they tend to think of the best-case scenario, then they try to think of things that could go wrong but cannot really think of all the things that could require more time so they end up with a really optimistic estimate. This happens all over the place – in personal projects, business and even in state-level projects.
If we think of the project as only a single project we cannot correctly predict the time required. However if you think of the project as an instance of a class of projects: for example schoolbooks take 7 to 10 years to write and publish. Then you will have a much better estimate.
How time estimates ruin productivity
Easily. A study ran in software companies ended up some very strange results.
All of the projects where no estimates were prepared outperformed all of the other projects.
|Estimate prepared by||Productivity|
|Programmer & Supervisor||7.8|
Source: The “Peopleware” book
The hypothesis is that estimates were prepared, they have put time pressure on programmers and so they have decreased their productivity.
So if you can: do not put estimates on projects. They do decrease productivity by 1/3. If you have no choice but to estimate the time – try to think of how long does it take to build the average project of that type. Don’t ask how long will it will take to build your app. Ask how long does it take to build an app of that type. This will give you a much more realistic estimate.
I am eager to know your thoughts on the matter! What is your personal experience with estimates? How well you deal with those? Do you have any advice to share? Post in the comments below 🙂