Estimating Work Time
It’s very difficult to estimate time to complete work even for experienced people. As a project manager, I often have to rely on developers and designers to provide estimates on how long it will take them to complete their assigned tasks. I am surprised at the inaccuracy of the results, but have found some commonalities.
People usually underestimate time required to complete work, and not just by a little, often as much as 50%. After some discussion with team members, it became apparent that unless people had a previous example on which to base their estimating, they had difficulty imagining how the new work will happen. People generally just run through the core activity and estimate how long it should take, not would take.
Rework is also not considered. Sometimes it is because they assume it will make them look bad when they have to justify their estimate if they have included rework. Other times it is because they think they won’t make mistakes this time. Having an inaccurate estimate is far worse than doing something twice. Nothing is accomplished in a straight line.
Start-up time and close time are also not included. Discussing issues, looking for resources, reading documentation, configuring software, installing updates, obtaining permissions, refreshing one’s memory and getting “in the zone” are all part of the task at hand and must be included.
One technique I use that has been very successful is to estimate how long it will take to do the core task with no rework, then double it.
Another situation that adds complexity to estimating time is when the person who will actually end up doing the work is not the one estimating the time to do it. Even two people with comparable skill sets may take quite a different amount of time to complete the same work. Some people are more detailed and double-check everything; some are more organized and have less start-up time, while others are just faster. If the lowest common denominator is used there is risk of the estimate being excessive. How does one find the average or better yet a weighted average? I’ve used:
Weighted Average = (longest time estimate * .75) * 2
I like to err on the high side.
A project I’m working on now requires an accurate time estimate. To achieve the desired level of accuracy I’m going to try a few techniques.
Bottom Up - Considered an accurate method, bottom up sums small activities into larger units of work. Risks here are bad estimating of activities and too small of activities causing bloat.
Top Down - Estimate time for larger units of work, divide the time into the smaller activities that make up the larger units, and make any adjustments.
Analogous - Compare the Bottom Up and the Top Down estimate to completed, similar projects for accuracy. Risks here are differences in teams and forgotten issues that affected the project.
Hopefully by approaching the estimating process using three techniques accuracy will improve and validate the results. We’ll see. Project Management
|