Wednesday Work Tip #6: A Simple Way to Estimate Projects
I believe that one reason is because entrepreneurs are, by nature, optimistic. You almost have to be an optimist to be an entrepreneur. If you had listened to everyone who ever told you to "be realistic", you probably wouldn't be running your own business. That optimism carries over into our project estimates, where we tend to lean toward the best-case scenario.
A second reason is that we believe the optimistic estimate will help us get the deal: the client will hire the firm that can get it done sooner, the investors are more likely to invest if you get the product to market quicker, etc.
On the one hand, that's probably true. On the other hand, it doesn't create a sustainable business. What happens when you've bid something on a fixed price and you start going 25% or even 50% over your estimate? Your profit is gone and the customer becomes a liability. And how likely will they be to hire you for future work or refer you to others? What happens when it takes six months longer to get to market than you told the investors, and you need another $500,000 to get you there? They may see it as throwing good money after bad, whereas if you had given a realistic estimate in the first place, they very likely would have put up the money.
So knowing we're overly optimistic, how can we estimate projects realistically?
Here are two key techniques to making a realistic estimate:Weighted Average
As I said, entrepreneurs tend to lean towards the best-case scenario. Instead of just figuring a single number in your head, though, create three estimates:
- Best-Case estimate (BC)
- Most-Likely estimate (ML)
- Worst-Case estimate (WC)
(BC + (4 * ML) + WC) / 6Or, in plain English, best case plus worst case plus four times most likely, all divided by 6.
What this will usually do is create an estimate leaning slightly toward the worst case. Why? Because the difference between best case and most likely is usually much smaller than between most likely and worst case. Trust me on this one until you see it yourself in action.
Of course, your best case and worst case estimates need to be based on reasonable assumptions, i.e., your best case can't be based on you and your employees working 16 hours a day, 7 days a week, and your worst case shouldn't assume a natural disaster.
Make reasonable assumptions and calculated the average, and you've taken the first step toward a realistic estimate of the amount of work involved.
Factor Non-Project Time
When we make our estimates, we tend to estimate based on how quickly we could get it done if we worked full-time on it, with no distractions or other obligations whatsoever. We calculate based on the amount of work, but don't put it in the context of all of the other work that's going on. Unfortunately, that's just not very realistic, especially for business owners themselves. Everyone has non-project overhead time. The only way you can be "100% billable" is to work 125%, i.e., to bill 40 hours, you have to work at least 50.
So to create a realistic effort of duration (i.e., how many business days it will take) based upon our work estimate from the weighted average (i.e., how many hours of uninterrupted work), we need to add an overhead factor, which varies by role:
- Solo worker: +20-30%
- Team member: +30-50%
- Team lead, manager: +50-75%
- Business owner, executive: +75-100%
Combine these two techniques and you'll be able to make more realistic estimates. They may seem a little difficult to swallow at first, but they'll serve you better in the long run.
I have a huge tendency to underestimate. It’s a combination of a lot of things. Partly I’m psyched about building something new, and that’s compounded in cases where I have a good idea how to solve the core part of a problem.
Detail is critical though. While you can never capture everything that needs to be done up front (unless your doing something extremely similar to something that you’ve already done before), you can get within reasonable proximity. If asked on the spot to give a ballpark, I categorize a project as either small, medium, or large and explain the level of capitalization required based on that. If I have an hour, then I brainstorm what the biggest/hardest components seem to be and then haul out a template project that I keep with all the stuff I usually forget about. That gives me a ballpark-with-detail.
Beyond that it’s time for actual project work. In my case (software development) that’s the objective, vision, user stories, UI requirements, data model, processing components, deployment description and project plan, (within the context of marketing and business constraints). That usually takes at least 1-2 weeks to create. I charge half up front and half on acceptance for that work. Some payment up front prevents getting burned by people who aren’t serious. Remainder on acceptance shares the risk.
As you mention on your blog, it’s a delicate balance between the decision to do it, and whether you will come out at the end with a good recommendation and any amount of profit. It’s not easy.
I recommend maintaining a template of things you usually forget. Over time it becomes a valuable resource, and can even be a competitive advantage (”does their quote include…”). At any rate it has saved me from making a stupid mistake on several occasions.
Scott, What a thought provoking post!
Thanks for the comment on our site to a post which addresses a variation of project schedule risk for team projects caused by padding of schedules of individual tasks, Padding Your Project Timelines.
In the post, one our our Emerson technologists, Shenling Yang, argues to not pad the individual tasks, but apply and overall pad to the project, and clearly communicate this to all the project members.
Take it easy, Jim
Interesting formula. I think it could be simplified to ML + (WC-ML)*20%. This is because BC is going to be almost equal to ML, so forget about it. The rest is just rearranging the math.
A lot of times I find WC is going to be roughly twice ML, so that makes it even simpler: just add 20% to your ML estimate.
For small projects of a type that I’m used to, I find that if I have a good idea of how these projects are structured, how much each phase takes based on a basic idea of requirements, (for instance for a web project how many DB tables, how many fields, how many “screens” that access the database, how many static pages, how many logos, how many elements in the “skin” design) then I can give a decent quote (to be confirmed) over the phone in real time.
Small businesses with small projects tend to like that, and if I know my estimate is going to be competitive, then it helps prevent them looking elsewhere.
One of the best, most straightforward articles on this subject that I’ve seen.
I like the notion of using a “weighted average” method for figuring how long a project will take. You could then turn around and use the same formula to estimate cost by plugging in prices instead of hours or days.
The formula is well known in project management as the PERT formula (see for example http://en.wikipedia.org/wiki/PERT).
The ideas described in this post are certainly very important and useful. I have written about the issues of padding in my blog to. See http://mosgot.blogspot.com/2006/11/to-pad-or-not-to-pad.html