When I worked at a BigCo, we had what we called the engineering estimate multiplier
- Multiple the integer value by 2.
- Increment the type of time used in the estimate.
An example of the multiplier in use:
Joe Optimist says it will only take a 4 hours to implement the flibbertywidget feature. A smart engineering manager will take that estimate, apply the multiplier, and get a realistic estimate of 8 days.
Engineers will typically think of the simplest solution for a problem and think of how long that will take to implement without any thought to unexpected issues, bugs, etc. they may run into during implementation.
Successful senior engineers mitigate this much better than junior engineers. A good manager may apply a slightly different multiplier depending on who is providing the estimate. However, be assured a multiplier is always needed.
A real-world example:
I remember running over a feature list we had for an upcoming release. We had about 3 months of development time, and the three of us on the team thought we could definitely get everything done.
Our engineering manager then sat us down with a timeline, and started recording fairly detailed levels of effort (in hours) for the work on the feature list we thought we could complete. We ended up at 300+% utilization for each of us, including pulling in a few other resources for smaller bits.
Progress:
I’ve been getting better and better at this as I continue to work as an indy developer on various projects, including customizations for my own software. The good news is that this helps me manage my schedule and provide accurate estimates for my clients. The flip side of that is my estimates for projects have increased a fair amount.
Recommendation for anyone hiring a developer: beware the low estimate.
A friend of mine works on big coding projects. The other day he said: “Whenever we make a time estimation we always multiply it with pi.” I found that quite funny. đŸ™‚
I won’t even tell you what this looks like in manned spaceflight hardware. đŸ™‚
[…] On a similar note…I also read Alex King’s blog post today: The Ă¢â‚¬Å“Engineering EstimateĂ¢â‚¬? which was also worth taking a few minutes to check out. Just about a year ago today I gave a client a quote for a huge project which ended up being extremely low and cheap. Lesson learned. Now I getting better at giving more accurate quotes as well as making sure I have a statement in my contracts that basically says any work beyond my original quote will be billable so I am not stuck eating the time I failed to properly estimate. […]
Hey,
Thanks for the article. I was really underestimating my design charges. Have updated them.
I’m still not sure about picking hourly or projectwise charges, though I guess that will vary depending on the nature of the job.
[…] The first thing you have to do is be straight with your client. Tell them that you are in school and let them know when you are available. Most will be understanding of that. If they aren’t, they probably aren’t the greatest to work with anyway. Once you have done that, see what services you want and give yourself plenty of time to complete them. Over at AlexKing.Org Alex writes about The Engineering Estimate, which explains that engineers (programmers, etc.) usually grossly underestimate the time they need for a project. Alex says that you should take the estimate and: Multiple the integer value by two, Increment the type of time used in the estimate (IE 2 hours = 4 days). If you are doing this type of work in school, you should take that estimate and at least multiply the integer value by 4, along with increment the type of time. This allots you not only enough time for the project, but also unforeseen school work, study time, etc. […]
[…] As a result, I lost about 4 hours driving back and forth and delayed my potential data recovery by 3-4 days. I should have known better – beware the low estimate. […]