Web Worker 101: Estimating Basics
As you enter a career of being an independent web worker, you can hardly avoid negotiating contracts with potential clients. Inevitably, the first questions that will come up are “how much is this going to cost?” and the closely-related “how long is it going to take?” Providing reasonable (and acceptable) answers to these questions is often the difference between a signed contract and an insincere commitment to call you back later. Whatever your skills as software developer or web designer (or whatever your web work career entails), you need to also understand the basics of estimating.
Unless you’re doing utterly routine piecework (data entry from paper forms or perhaps transcription), estimating is more art than science. But there are some things you can do to increase your chance of turning out a good estimate: one that ends up bearing some resemblance to the time it takes to do the actual work. Here are five tips to help you get started on refining your own time estimates.
1. Estimate in inch-pebbles, not milestones. When you’re faced with a large piece of work to estimate, don’t try to come up with a single number to cover the entire job all at once. Break it down into pieces, and then break those pieces down into pieces until the pieces are small enough that you can see how you would do each one and put a number on them. As a general rule of thumb, if the pieces take more than 4 to 8 hours, they’re not small enough yet. Most people have trouble guessing their time to perform any job that will take longer than that.
2. In estimating, 2 plus 2 doesn’t equal 4. After you’ve broken the job down into tiny pieces and estimated them all, the temptation is overwhelming to add up all the individual estimates and make that the estimate for the entire job. Don’t fall for this. The problem is that you won’t hit your estimates, and the variance is asymmetrical – if you estimate 4 hours for a task, you can’t take much less than 1 hour, but you could take 20 hours if you were wildly wrong. So 2 plus 2 might equal 4 – or it might equal 12. There are fancy applications to apply statistics to this problem, but as a rule of thumb, take your best total estimate and multiply by 2.5 to allow for this.
3. Don’t estimate by wishful thinking. You may know that the client only wants to spend $15,000 on a particular job. If your estimate comes in at $37,500, don’t let this fact pressure you into submitting a $14,900 number in its place. No good will come of not finishing the job or taking only half of the rate you need to live. You should estimate realistically and, if necessary, point out places where the work can be scaled back to fit within a lower budget.
4. Don’t estimate in a vacuum. To produce an accurate quote of hours or price, you need to know what you’re quoting on. If your potential customer didn’t provide a good spec up front, you need to call them, meet with them, or swap email until you really understand the work that you’re agreeing to do. The alternative is to try to move to a more agile approach, where you’re selling hours to be applied to whatever tasks are mutually agreed as the job proceeds – in which case it becomes impossible to estimate a total “finished” cost.
5. Track and correct. Make sure you track your time and, at the end of the job, compare it to your initial estimate. You can use this information to tell you whether your estimates are consistently low, high, or just right – and to adjust your next estimate accordingly. This won’t help on your first estimate, but down the road a year or two you’ll be glad for the increased accuracy, and so will your customers.
Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.
As a newbie freelancer, I NEEDED this. Sometimes, having a step-by-step guide is the best thing, especially when you’re faced with 150 “little things” that pile up quickly. Thank you so much!
Regarding the difference between a company’s expected budget and your expected costs: you’re right to advise NOT to lowball the estimate, because then it sets a precedent for willing to work for less than what you’re worth.
However, if bidding low means you get your foot in the door with a company that may give you more business down the road, consider whether a one-time loss is worth a long-term profit…
… unless that initial lowball (again) turns out to be all the client ever expects you’ll be worth. In that case, you’ve done yourself more harm than good.
thanks, very usefull!
I’d have to agree.
One thing that I’ve found out is to develop an a la cart menu. If you have a list that gives the price or estimates for web design, graphic design, photography, SEO, etc it keeps you from getting roped into doing something you didn’t originally planned on, and it gives you an out when the client asks about it. So you don’t start with designing a web page, and end up developing their entire brand for the same price.
Great article, I’ve written on this same topic myself. I honestly believe that being able to accurately estimate tasks you are given is a great way to prove your reliability and is a first step towards showing management how good you are. Nicely done, Mike.
Pete Johnson
HP.com Chief Architect
Personal blog: http://nerdguru.net
This is helpful – thank you. One of the GTD “holes” I’ve discovered is the lack of built-in planning, and the wonderful value of estimating work. This goes in my toolbox for clients.
I have heard MANY times that the best engineer is not the one that knows everything. Rather, he/she is the one that can estimate the answer quickly and closely. There is always a business driver under every project and if you can keep the money guys happy you will be a rock star even if you have to ask the newsgroups how to actually “do” the job. :)
One thing that I’ve learned over time from some smart folks is that it is VERY important to state your assumptions.
First, this puts your assumptions out there for others to say “yep, I agree, that’s the problem we are solving” OR “no no no!” and this gives you an opportunity to fix your assumptions and presumably your estimate before it is too late.
Secondly, assuming your assumptions are initially correct, but later, well into the project they become wrong (scope change/creep, discovery uncovers hidden things that we’re not initially thought of, etc.), you have a reason to reasonably adjust expectations … the project has “changed”!
Happy estimating!
Damn, I just re-read what I wrote a few hours ago (above) and I wrote “we’re” when I meant “were”. It bothers me when I see others flip-flop the apostrophe vs. no apostrophe thing … and I just did it!
Its a shame! <— did it again!
Your an idiot Rob <— did it again!
I would add that one of the biggest problems is that as project team members we’re giving estimates like “2 weeks”. “2 weeks” isn’t really an estimate, it’s a guess, a prediction.
An estimate is something like “1-4 weeks” or “3-5 days”. It really should be a range. One big downside of single-point guesses is that the guess is likely to be treated like a promise. On the other hand, giving a ranged estimate opens the discussion of what could happen (risks) that would push the effort towards the worst case end of the estimate or bring it in towards the best case end.
One of the primary problems is that project managers need a single number to plug into MS Project (or any number of similar tools). That coupled with the observation that these single-point guesses are treated as promises pretty much make a person want to give up on estimation altogether.
If you always give estimates in ranges (e.g. 4-6 person weeks, 1-3 days, 6-9 staff months, etc) it is quite clear that it is an estimate, not a prediction or a promise. Giving a range opens the discussion of what could happen (risks) that would push the effort towards the worst case end of the estimate or bring it in towards the best case end.
Another nice thing about ranged estimates is that when you are asked to estimate something with poorly defined requirements you can give wide ranges to communicate the uncertainty. Well defined, believable requirements get estimates like 5-7 weeks whereas poorly defined, nebulous requirements get estimates like 4-20 weeks.
There’s pretty much no way to get around doing estimates. Your business needs some idea of the investment required to complete a project in order to make trade-offs. Also folks in other departments (e.g. marketing, operations, manufacturing,…) need some idea of when they are likely to take delivery of the software. A team that can accurately (not precisely) estimate these things gives their company a real competitive advantage.