In the last few years, I have seen the problems this question poses, both from the point of view of a worker and a supervisor. It is surprising how difficult giving accurate time estimates can be when your job is quite mechanical. While my experience is based on the development of IT products, the fundamentals of how to give a good estimate are valid for any task, and they are based on three simple concepts: analyzing, measuring and learning.
But let’s start with something simple: Is it OK to take three days on a task, or is that too long? The most obvious answer is “it depends on what the task is,” right? Wrong! Regardless of the task, it is only acceptable if we have estimated that it would take 3-4 days to complete; but it is unacceptable if our estimate was 1-2 days. It is important to understand that the perception that something has been resolved in a short or a long time comes from the expectations we create. Obviously, the solution is not to say that it will take you a month to complete a 2-day job. If you did that, our supervisor would “perceive” that we are cheating.
The best alternative is to estimate the shortest possible time we are 99% sure that we can complete the task. Let’s see how we can proceed.
First, we break down the task into subtasks of two hours at most. Short subtasks will surely resemble the subtasks in previous jobs. That will allow us to make as accurate an estimate as possible. In estimating each subtask you must take into account the time of “expected unexpected events”, i.e. whatever challenges we know we could face when doing a task. For example, if our task is to make a scraping of a website, we can consider the possibility of using anti-bot protection, including a powerful firewall, or have dynamic content. Moreover, we always work during office time, not during production time. That is, if we know that we are going to be constantly interrupted, and that we will spend half the time in resolving other issues, we have to estimate a one-hour task as a two-hour task.
That gives us a partial estimate. That is what we believe it will take and therefore, that is the estimate we will work with. However, before giving an estimate to our supervisor, we will add extra time to deal with real contingencies. As these unforeseen events can happen during any subtask, what we will do is calculate it as an additional percentage of time. This percentage is not universal and it depends a lot on how predictable your job is, and on the amount of experience you have in that type of work. At first, we use a high percentage and then we try to lower it as we meet our expectations. I usually use 20-30% for layout tasks and 80-120% for R & D tasks.
Once we have given our estimate, we have to get working. It is important to record the actual time each sub-task takes, and compare it to our schedule. When an estimate fails, we must assume that the other time estimates are correct. In other words, if you have taken six hours to do a two-hours task, do not assume that you will be able to recover those four hours working faster (the other tasks already have their set time). As soon as you know you are not going to meet a deadline, report it to your supervisor. It is far better to warn them a week before something becomes overdue, than getting to the agreed date and telling them that it is not finished.
Well, we finished the task, is the job is over? No! Now comes the most important part: learning. Review your estimate and the actual time it took you to do each subtask. Did it take you longer than you expected? Did you do it faster than other times? Did a new “unexpected” happen? Would it take you less time to do the same task again?
Being able to measure our work and our efficiency is what really opens the door for improvement. It is most likely that your next task will share many subtasks with this one. Learn how long you have taken and what has given you the most trouble.
Your next estimate will be more realistic.