Task Estimating Strategies for Producing Accurate Work Estimates

Challenging! Daunting! These are words many developers and project managers use to describe attempts to provide reasonable, let alone accurate, work estimates. And by work estimates, I mean trying to determine the number of ‘people-hours’ that will be required to successfully complete a given task or project. In my 25 years as a project manager, I’ve rarely come across anyone who could produce reasonably accurate work estimates. Most folks simply used the ‘SWAG’ method.

There are several strategies for becoming better at estimating. The first is the historical method. When employing this method, you simply look at historical data for similar projects.

Of course, this approach will only be as good as the records kept about past projects. Assuming you have adequate documentation, and if the project or task is more or less repetitive, then your estimating should improve with each new iteration.

A second strategy for producing accurate work estimates is to use the sub-task method. With this method, you divide the project or task into smaller bite-size sub-tasks. A sub-task can be defined as work that can be finished in less than 50 people-hours. Typically, the smaller the task, the easier it is to create an accurate work estimate. Now, it may be that the total project estimate will simply be the sum of all the sub-tasks. However, even if you included buffers (10%-20%) in each of the sub-tasks, I’d still recommend including a bit of a buffer (rule of thumb: 15%-20%) for the entire project.

When using the sub-task method, you have a secret built-in strategy that you can put to good effect. It is very likely that two or more of the sub-tasks can be worked on simultaneously. For example, a small project estimate breakdown might look like this when subdivided into smaller subtasks:

PROJECT or BIG TASK

Sub-task 1 = 10 hrs + 2 hrs (20%) = 12 hrs

Sub-task 2 = 7 hrs + 1 hr (14%) = 8 hrs

Sub-task 3 = 8 hrs + 1 hr (13%) = 9 hrs

Sub-task 4 = 15 hrs + 2 hrs (13%) = 17 hrs

Total = 40 hrs + 6 hrs (15%) = 46 hrs

So, if each task were in the same critical path, then you’d estimate the project to require approximately 40–46 hours to complete. However, suppose sub-tasks 2 and 3 could be completed simultaneously? While the same number of people-hours must still be logged (15–17 hours), the actual time needed to complete the work will be 7–8 hours less — an equivalent of one day. Of course, this assumes that you have sufficient resources to double-up. As a skilled Project Lead or Manager, you can keep the ‘bonus’ hours in your hip pocket, so to speak, as a contingency.

The larger the project or task, the greater the likelihood that you’ll need to involve two or more resources to provide estimates. Those who are more conservative by nature, or who are more detailed or thorough in their work habits will provide you with estimates that have plenty of buffer built in — they sort of consider a worst-case scenario. On the other hand, those who are quicker to produce an estimate or are more likely to SWAG an estimate or are less experienced or are generally more optimistic will produce estimates reflecting a best-case scenario. Given this reality, I recommend that, whenever possible, you get multiple estimates for the same unit of work; just like you’d get multiple quotes to have work done at your home.

Pitfall #1 — The Planning Fallacy

In 1977, psychologists Daniel Kahneman (Nobel Prize winner in Economics) and Amos Tversky first coined the phrase “The Planning Fallacy” (Thinking, Fast and Slow). The Planning Fallacy describes people’s tendency to underestimate the resources needed to complete a future task, despite knowing that previous tasks have also taken longer (or cost more) than planned. How common is TPF? It’s estimated that 85% of initiatives fail due to misjudging their feasibility within allocated timeframes and resources. This phenomenon can, and does, affect us all! The solution — awareness and trust your data.

Pitfall #2 — Didn’t Think of Everything

Here are several areas that are often overlooked when estimating time to complete a task or project: a) collecting user requirements, b) code review, c) quality assurance testing.

Pitfall #3 — Nobody Works 8 Hours a Day, Everyday

When estimating developer hours in particular, it’s a common practice to ascribe 8 hours a day for coding. Seriously? What about coffee breaks, bathroom breaks, lunch, personal internet surfing, etc. A good rule of thumb is to anticipate that for every 8 hours a developer is at work, he/she will devote at most 6 hours in their chair actually coding.