HN Explorer

Ask HN: How do you estimate a project timescale and negotiate with a customer?

37 points by paulnelligan ↗ HN
I've been in the situation recently where I've been asked to estimate a project for contract work. I know my hourly rate, no problems there, but I have huge difficulty estimating how long something will take.

If you overestimate, you may not get the contract, if you underestimate, you end up working for peanuts to get the thing done.

So my question to you is; how do you estimate a project's timescale/cost?, and how do you negotiate with the customer to protect yourself in the event that the project runs over time budget, as they generally tend to?

thanks in advance, and apologies if this has already been asked.

Paul

16 comments

[ 3.2 ms ] story [ 55.3 ms ] thread
jacquesm
Hey Paul,

I wrote a pretty long blog post on that a while ago, maybe it is of use to you:

http://jacquesmattheij.com/How+to+get+better+at+estimating+s...

olegp
Good advice. I'd go further and say that you should charge the customer for putting the spec together.
jacquesm
Sometimes you can, sometimes you can't. If the customer has no clear idea of what it is they want and if you are (at the moment) the only bidder for the job, then that's a possibility. But if you are bidding against other companies then this is usually not an option.
[dead] lionshare
Prepare a very accurate estimate. Now double it. Now add 50%. Add a clause that meetings will be billed according to hours actually taken.
ggruschow
Idealist: Explain to the customer that nobody knows how long it'll take, and then sit down with them to work out a deal that balance both of your interests. Odds are they need some portion of the project done, so focus on how to deliver it incrementally to reduce risk.

Suit: Don't waste your time trying to work out what you expect the schedule to look like. Figure out what they can bear, and negotiate a deal that guarantees you get most of the money they can spend with the least risk to you. Your liability is in what you promise contractually, so hire a good lawyer to help you minimize your legal liability.

Me: Race to do the project before negotiations need to wrap up. Then write a beautifully detailed schedule with visible checkpoints, negotiate with confidence, and deliver checkpoints slightly a head of time on average. Use a little of your spare time to meet their mid-project change requests and build in a feature that tickles your interest and will delight them.

Coder: Negotiating a schedule is like negotiating how long it'll take to produce a baby. It'll be done when it's done, but if you get me a girlfriend I'll get it done faster.

Software Engineer: Charge your customer a standard hourly rate to record their requirements and break them down into function points. Estimate function point complexity and risk based upon your organizations prior prior projects function point productivity. Schedule a week with the customer 3 months from now to present your analysis and estimates including confidence intervals and costs in each scenario.

jacquesm
> Me: Race to do the project before negotiations need to wrap up. Then write a brilliant looking schedule and negotiate with confidence.

Then find that someone else has you beaten on the estimate (because they don't know how to estimate!) and gets the job.

That's happened to me once when I tried that trick, better make sure you're the only bidder :)

ggruschow
I didn't say it was a smart way to go, just that it's my way.

Taking the risk before knowing there's a reward is probably the riskiest way to go. For me though, it's fun.

To be fair, that was my way 5 years ago. I guess now I try to make sure everyone's working together with similar risks and rewards. I work better with people than against them.

My present way isn't necessarily the smartest or most profitable way to go either.

jacquesm
Ok, thanks for clearing that up, I though the way you wrote your initial comment indicated that was how you did things today.
swombat
I wrote this article some time ago.

http://inter-sections.net/2007/11/10/easy-estimates

This technique is used by large corporations but can also be adapted to smaller pieces of work quite easily.

One important aspect of this method is that it looks very credible, which comes in very handy when discussing estimates with the customer. The argument shifts from "this shouldn't take that long" to "ok, let's not do this bit because it's too expensive".

It's much healthier for your client relationship to be having arguments about scope than about your estimates' reliability.

Also, I've found this technique to be quite accurate on the whole, so it is actually better than gut feeling estimates on both the social side and the technical side.

rmah
All estimation techniques follow the same pattern:

1) list all the components and tasks that need to be completed,

2) assign an estimated duration (hours or days) to each task,

3) add them all up and multiply by a fudge factor.

The problem is that none of these are easily done. Step #1 requires a detailed understanding of what you're going to build. Obviously, this is often impossible, but you'll just have to guess. Be sure not to forget categories such as testing, debugging, meetings, etc.

Step #2 relies on experience and your assessment of the client's quality/time trade-off threshold. If you don't have much experience, just guess and then track your time so you can go back and compare reality to your guesses.

The "fudge factor" in step #3 can either be hidden from the client or called "integration phase" or some such. Basically, it is the process of ensuring that all the components are working smoothly together.

Entire books have been written on project planning and estimation. There is no shortcut to doing it well, only experience through the school of hard knocks.

Good luck.

paulnelligan
much thanks. I suppose the answer is to break it into the smallest chunks possible when making an estimation.
rmah
The problem with too much granularity is that you will miss more tasks. This is, of course, offset by each task being easier to estimate. The general rule I use is that the more detailed the requirements/spec and the more static they are, the more granular you make the task list. The more vague everything is, the less granular you make the task list.
exline
If you know yourself, you can find the optimal fudge factor. On projects that I've managed before and currently, I've found 2X is the right multiplier to great developers. The major issue is to a great developer, everything is easy. But its the few tasks that for some reason take up a huge amount of time when they shouldn't. Over time, I've learned to increase my estimated times and decrease my fudge factor because I've done enough estimates. Its always better to under promise and over deliver even if you loose out on a contract now and then. In the long run your reputation will make up for a slightly higher price if people know that you will never go over that price.

The major problem is defining the full requirements. Your estimate could be perfect, but it could be an estimate for what the client said, but not what he wants.

chrisbennet
I too have great difficulty estimating how long something will take. Whatever you do, don't work for a fixed price unless you've pretty much already written the software and know you have a big safety/profit margin. I found the video on this page very helpful in articulating the reasons not to agree to a fixed price contract. http://unspace.ca/innovation/speak

-Chris

kylecordes
There are actually two separate questions here:

1) How long will this project take? The answer to this question is called an estimate, and there is a huge body of work about it.

2) Should I offer to do this project for a fixed-bid / quoted / whatever price?

I think you've already assumed the answers to the second is "yes"; and perhaps you were right for the situation in front of you. Beware the "winner's curse", though: http://en.wikipedia.org/wiki/Winners_curse which will quite commonly occur in a fixed-bid situation where some of the bidders are inexperienced with fixed bidding.

My nitpick, though, it that is unhelpful to call this fixed-bid price an "estimate". I wrote (and recorded a short video) about that a couple months ago:

http://kylecordes.com/2010/estimates-and-promises