Web Worker 101: Estimating Basics
September 28th, 2007 (11:00am) Mike Gunderloy 32 Comments
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.
32 Comments Post your own comment
Geethebluesky says: September 28th, 2007 1:40pm
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!
Justin Kownacki says: September 28th, 2007 1:45pm
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.
Geekularity » Magnolia Bookmarks says: September 29th, 2007 12:02am
[...] Web Worker 101: Estimating Basics « Web Worker Daily [...]
slipe says: September 29th, 2007 2:35am
thanks, very usefull!
Web Worker 101: Estimating Basics says: September 29th, 2007 5:19am
[...] You can read the rest of this blog post by going to the original source, here [...]
Eric says: September 29th, 2007 8:14am
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.
Pete Johnson says: September 29th, 2007 1:54pm
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
Quick Links: Estimating Tips on WebWorker Daily says: September 29th, 2007 2:54pm
[...] post on WebWorker Daily, titled Web Worker 101: Estimating Basics hits the primary suggestions that I encourage consultants and freelancers to follow, like [...]
Morning Brew #79 says: September 29th, 2007 3:58pm
[...] Web Worker 101: Estimating Basics. [...]
Matthew Cornell says: September 30th, 2007 4:48am
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.
Brian Kronberg says: September 30th, 2007 11:40am
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. :)
Rob Lambert says: September 30th, 2007 8:09pm
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!
Rob Lambert says: September 30th, 2007 10:42pm
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!
The How To Do Things Blog says: October 1st, 2007 1:31am
How To Prepare Time And Money Estimates When Taking Up New Projects
As a freelance professional, preparing quotes and time and money estimates is often a big part of your work. This is more so important when projects are big and contain many smaller parts that may span many work-hours. Avoid the tendency to offer a lu…
Bruce P. Henry says: October 1st, 2007 4:56pm
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.
jk says: October 2nd, 2007 2:02am
What kind of calculations do you all do?
My old calculation for small web apps was: (# pages + # tables + approx # of queries ) * 3 = # of hours to complete and release. The number always seemed large, but this number included debugging, phone calls, a meeting or two, and sparse docs. Obviously, to get this number, I had to spend time working on the design of the application, so there is also some heavy up-front cost to making this estimate.
The estimate stopped working on mid-sized and large projects, because the communication needs of team programming add overhead, and not everyone works at the same speed.
Business How-To: Learn the Basics of Good Estimating | Tolagomi News says: October 2nd, 2007 6:46am
[...] the estimation tips and tricks that keep you stress-free and productive in the comments. Web Worker 101: Estimating Basics [Web Worker [...]
the jackol’s den » Web Worker 101: Estimating Basics - Mikhail Esteves says: October 3rd, 2007 6:55am
[...] Read more [...]
bsurfkid21 says: October 3rd, 2007 11:24am
So when you are estimating, how do you account for the things you just couldn’t have foreseen? Or account for the things that you have no way of knowing how long it might take? Do you ever just add in time due to the size of the project, like an ‘x’ factor?
engtech says: October 3rd, 2007 11:40am
@bsurfkid21:
you add buffer time.
at work I know that 2 out of 5 days will be taken by meetings/interrupts. I need to account for that in my schedule.
Web 2.0 Announcer says: October 6th, 2007 3:54am
Web Worker 101: Estimating Basics Web Worker Daily
[...][...]
Best of Feeds - 34 links - programming, google, lifehacks, ruby, funny « Internet Duct Tape says: October 7th, 2007 8:46am
[...] [ESTIMATION] Web Worker 101: Estimating Basics [...]
Getting Things Done « Voir Dire says: October 7th, 2007 7:53pm
[...] How to estimate. Hat tip to [...]
47 Hats » Blog Archive » links for 2007-10-08 says: October 8th, 2007 2:23am
[...] Web Worker 101: Estimating Basics « Web Worker Daily A good primer on estimating software tasks - be they for The Man or for your microISV (tags: microISV estimates) [...]
Efetividade.net » Não faça suas estimativas no vácuo says: October 8th, 2007 7:05am
[...] associada aos resultados obtidos por diversos profissionais. E neste sentido, o artigo “Web Worker 101: Estimating Basics” é um achado, porque traz uma série de dicas práticas para quem precisa realizar [...]
Undocumented Features » Blog Archive » Estimating 101 says: October 14th, 2007 8:33pm
[...] Here’s another good article supporting the same theory- Web Worker Daily posts on Estimating 101, and recommends that to provide good estimate you need to break the work down into its most basic [...]
Eric says: November 8th, 2007 8:49am
I agree with point #3. One thing I have found to be really effective is to provide options for the project. Typically there is one option for all the features, and then some others that have some features scaled back which reduce the work needed (and the price).
Web Worker 101: Estimating Basics « Graphicmotion’s Weblog says: November 11th, 2007 2:50pm
[...] Fuente: http://webworkerdaily.com/2007/09/28/web-worker-101-estimating-basics/ [...]
Web Worker Daily » Archive 5 Rules of Thumb for Web Workers « says: July 6th, 2008 10:04am
[...] how long their next project will take. If you have problems with estimates, take a look at our Web Worker 101 article on the [...]
5 Rules of Thumb for Web Workers | Mostly Related. says: July 6th, 2008 4:00pm
[...] how long their next project will take. If you have problems with estimates, take a look at our Web Worker 101 article on the [...]
Ace says: July 7th, 2008 11:07pm
The rule of thumb of multiplying the estimate time by three seems to apply more specifically to tasks that produce a somewhat unique product. For example, if a contractor is building the same tract housing, and has done so dozens of times before, I think that his/her initial time estimate would be sound. The same goes for web designers who use templates and plug in pre-determined content.
Deadlines & Estimates: Part 1 : [ mkhairul.com ] says: July 10th, 2008 8:15am
[...] Web Worker 101: Estimating Basics [...]