

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

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.<p>If you overestimate, you may not get the contract,  if you underestimate,  you end up working for peanuts to get the thing done.<p>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?<p>thanks in advance,  and apologies if this has already been asked.<p>Paul
======
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.

------
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...](http://jacquesmattheij.com/How+to+get+better+at+estimating+software+projects%2C+for+freelancers+and+teams)

~~~
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.

------
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.

------
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.

------
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>

