What is Digg?Sponsored by Travelzoo
Take Advantage of Ridiculously Low Holiday Airfares view!
travelzoo.com - Flights $52 and up for Thanksgiving, Christmas & New Year. But move on it now.
24 Comments
- jggube, on 06/11/2009, -0/+20This happens in project-based work, regardless of whether it's design, development, or building a house. The main reason, to me personally, is lack of requirements-gathering and seeing what the actual project will entail and the fear that you might lose a contract because your competitors will quote a lower time than you (or lower costs).
- nourayehia, on 06/11/2009, -1/+8Underestimating web project is so common due to many factors. Methods described in this post is helpful and new.
- chadsmith729, on 06/11/2009, -0/+5Here's what I do and it seems to work a lot (seeming I have a lot of jobs on my plate at the moment):
1.) Define with the customer what they want to do. Don't have to be over sensitive here, just a ball park like "Add administration panel that does x,y,z"
2.) For every "unknown" then multiply your estimate for that part by: 1.75
3.) Know how long it takes you to do the simple things: Admin panel login, Product page, cart functions, ect
4.) When talking to the client never mention how many hours you think it's going to take, unless you bill per hour not by quote.
5.) Whenever possible have the buyer sign a document that outlines the scope of the work, with the price you are quoting. This should only take a few minutes to draw up, have the buyer fax you back a signed copy. This helps you and them out knowing what is to be expected and when the work is considered done.
6.) 50% up front and 50% when it's finished is not unreasonable.
7.) Timelines are important to include in #5, without them you have no grounds to say "You are holding the project up and we need to continue." Don't just bull ***** them either, look at a calendar, factor in other projects that you have on deck, factor in kids, and other variables.
At the very end of going through hour by hour on each section that you defined in #1, multiply the entire project by 1.5. Say you think it's going to take 8 hours to complete, then really you quote for 12.
It's not hard to get good at quoting a project, I have been doing it for about 6 years now. At my job that's what I am asked to do, and typically am not off by more than 1-2 hours in either direction. - bradleyland, on 06/11/2009, -0/+5The hard part is balance. Often times, you can spend almost half the estimated project time on estimation. When you start drilling down in to detail, you have conversations with the client that can consume hours and hours. Some people simply aren't willing to spend that amount of time with you. Actually *most* people simply aren't willing to spend that amount of time with you.
You have to reach a balance, and my experience has been that you can never get enough detail from a client. Incongruence in thought is an accepted part of web development, you just have to account for a "reasonable" amount in your quote, and learn to wrangle a client when they get out of hand. Milestone payments are also helpful, so that you're not left holding the bag when the client realizes they've bitten off more than they can chew. - mtnboy, on 06/11/2009, -1/+6It is almost impossible to estimate accurately, but if you want a good ball park these are good tricks.
- protogenxl, on 06/11/2009, -0/+5Lt. Commander Geordi La Forge: Look, Mr. Scott, I'd love to explain everything to you. But the captain wants this spectrographic analysis done by 1300 hours.
Scotty: [thinks about it some time] You mind a little advice? Starfleet captains are like children. They want everything right now and they want it their way. But the secret is to give them only what they need, not what they want.
Lt. Commander Geordi La Forge: Yeah. Well, I told the captain I'd have this analysis done in an hour.
Scotty: How long would it really take?
Lt. Commander Geordi La Forge: [annoyed] An hour!
Scotty: [looks unbelieving] Oh. You didn't tell him how long it would REALLY take, did you?
Lt. Commander Geordi La Forge: Of course I did.
Scotty: Oh, laddie. You've got a lot to learn if you want people to think of you as a miracle worker. - bradleyland, on 06/11/2009, -0/+5"Negotiate a paid for functional specification phase as a first step"
We can dream, can't we?
I can count on one hand the number of people I've worked with who I could talk in to paying me to build a functional specification BEFORE we start the actual estimating and that is after years of working with them and establishing a strong trust in our relationship.
I've tried this many times. My usual pitch is that I will sign a release giving them permission to provide the functional spec to any other bidders, so that they're not locked in to using us after they've paid for the spec. Then the inevitable question comes: what's the functional spec going to cost me? So you end up estimating the time required to build the unknown functional spec for the project you're trying to estimate. It's cyclical. - DBrez8, on 06/11/2009, -0/+4Agreed. Unfortunately it's often better to underestimate the time needed for a project when quoting a customer, and winning the deal, then losing the deal all together by providing a time line slightly longer than your competition's (who is probably also underestimating).
- jimfeet, on 06/11/2009, -0/+4Unfortunately, bradleyland and DBrez are both correct in their assertions.
Trouble is, needs assessments take time -- time during which needs often change and evolve at the speed of internet. If they don't change DURING the needs assessment period, they almost certainly will during the development and deployment phases. Moreover, many clients simply don't want to pay for this crucial process.
We tend to provide honest estimates for our work -- and as a result we are often underbid. Checking back later reveals that final costs often equal or exceed our estimates as the winning developer blows past their original low-bid estimate. But they got the work and we got only the satisfaction in saying, "I told you so." - xCIone, on 06/11/2009, -1/+4Great post. very useful.
- booyahbitch, on 06/11/2009, -0/+3If I could give you 20 thumbs up, I certainly would! You hit the proverbial nail on the head!
- Wuss, on 06/11/2009, -0/+2Am I the only one that charges according what I want/need to get paid?
I know this isn't exactly scientific, but what I usually charge depend on 3 main factors, none I believe were mentioned in the article or the comments.
1. What I need to get paid to pay bills and feed myself and my family.
2. What I believe the client is capable/willing to afford.
3. What I think the best figure is to stay competitive, but simultaneously make it worth my while.
Of course I have an hourly rate for small jobs, but when putting in bids for projects, I almost always go off these 3 criteria. As a freelancer, my life's activities are constantly changing. Sometimes I have lots of time, sometimes I don't. For instance, if some interface design project comes to me, but I have a 4 day weekend planned right in the middle of the deadline, you better believe I'll be charging a premium over the same project at a different time, because that's what I think I'm worth at the time. Factor in points 2 and 3, and that's how I come to a number.
Granted, economies like this really strain these criteria, because alot of us need every little bit, but with a 1 month old baby at home, my time premium has gone up, and sometimes a job is just not worth it no matter how you cut it. The best skill I've acquired over the years in this aspect of the business, is learning to walk away. Put value on your own "life hours" so to speak. If you're just looking at the final dollar amount of each job, you'll eventually get burned out. - Calchet, on 06/11/2009, -0/+2Causal version of estimating time spent:
Make an estimate that sounds about right to you, double it, raise it to the next higher unit.
"I can do that in two hours." -> Four hours -> Four days -> "That will take four days."
"That's a five-minute job." -> Ten minutes -> Ten hours -> "That'll take ten hours."
"Three weeks should see it done." -> Six weeks -> Six months -> "That's a major job, count on six months." - lisafeel, on 06/11/2009, -1/+3Great, a lot of good advices there.
- Ommatidia, on 06/11/2009, -0/+2New? You're kidding, right?
More like: "Welcome to the first day of your 'Systems Analysis and Design' course".
This is textbook stuff, literally. - crunchdigg, on 06/11/2009, -0/+1This is the formula that my first boss out of college taught me.
It has served me well. - strictnein, on 06/11/2009, -0/+1Interesting note: Web Designers don't take "Systems Analysis and Design" courses like us fancy CS majoring web developers. And, actually, a lot of very good Web Developers aren't CS majors.
- MWeather, on 06/11/2009, -0/+1Being a good coder is not the same as being a good developer.
- Lynxist, on 06/11/2009, -0/+1Estimation's fine, can you help me stop undercharging?
- Eorster, on 06/11/2009, -0/+1Can you speak or is it just using hand gestures?
- 2experts, on 06/14/2009, -0/+1Fantastic article! Great advise for PMs like me as well as Freelancers!
- Eorster, on 06/11/2009, -0/+1Akin to doubling your original estimate but using units, nice.
- inactive, on 06/11/2009, -1/+1Fantastic article. I'm just starting out as a freelancer and have had already had problems estimating project lengths.
- Spirckle, on 06/11/2009, -1/+1Fun at estimating. Strategies for multiple developer estimations.
Most fun I've had while estimating is to hand each developer a stack of cards. All developers discuss what the implementation of a particular feature might look like and then each developer flashes a card with a number representing the number of days/hours whatever. Outliers get to explain why their estimate is so different from others. Then everybody revotes.
The idea is that different developers have areas of expertise that they are most qualified to estimate and the estimation does not rely on the biggest bully or the loudest complainer, instead, by the vote/justification process, results in the most expert estimation possible for that group.
Of course, if you are a single developer estimating then you have to rely on your own gut.
© Digg Inc. 2009
— Content created and posted by Digg users is