The logic of estimating
At work, we estimate all of our projects and the process never seems to work that well. We break things up into features and then to requirements and then sort them into iterations and then break them apart further into tasks and then try to estimate the tasks. It all takes a long time and I don’t think the estimates are much better than making a gut call. I’d say its a 4 to 6 month project.
As I have been thinking of the problem I had a realization. Estimating is a problem.
Assumptions:
- If a range of time is given for a project, the project will not be completed until the far end of that range has been reached. E.g. If I say the project will take 4 to 6 months, then the project will most likely take 6 months.
- When asked to estimate, it is human nature to give higher estimates than the actual time it will take to complete. This is particularly true if there are issues with missing your estimates. E.g. If a task takes one day, we estimate its completion at two days.
Problem:
- x = the actual time it will take to complete a project
- y = the time to estimate a project
- z = the estimated time to complete a project
- x < z
How much longer will it take to complete the project if it is estimated?
- x = 5 months
- y = 1 month
- z = 7 months
If it is not estimated, the time it will take to complete is x or 5 months. If the project is estimated, it will take the time to estimate + the estimated time (y + z). It will take 8 months to complete the estimated project. The estimated project will take 3 months longer to complete than the unestimated project.
This can’t always be the case, right. Right. Some people underestimate. I have worked with people where I ask for estimates and double them. Perhaps I am part of the problem. If you can do without estimates, do without estimate. More often than not, we need structure to help with planning, coordinating and resourcing our projects which means we need some estimates.
My suggestions are these:
- Only estimate if it is necessary.
- Stakeholders should encourage transparency by not punishing missed estimates, but
rather by helping teams become more accurate. - Teams should minimize the time it takes to estimate by estimating requirements or features rather than tasks. Keep the estimates simple and high-level.
What if we time-box the estimate time itself, allowing only 1 man hour of estimation per project, per man on project? The project manager could then have one hour to compile estimates into a working project plan.This plan would only be used for resource allocation. Assigned resources would meet (standing) for 15 minutes at the beginning of each week to decide who would actually work on what that week.