In my consulting experience I've done exactly what you describe (pick an hourly rate and multiply by the estimated number of [man-] hours), but with an extra buffer to mitigate my risk.

In a fixed-price project the risk of blowing the budget is largely shifted from the customer to the consultant. As the consultant, your friend has the responsibility to mitigate his risk by building a reasonable buffer into the estimate. He should not disclose to the client the size of this buffer.

When comparing the price of a pay-by-the-hour project in which everything "goes right" to the price of the same project at a fixed price, the fixed price should always be higher. The customer pays for the peace of mind of knowing that the project won't go over budget.

Of course, even a fixed-price project *can* go over budget. In drafting the contract, you need to allow for this by ensuring each change to the project requirements is documented, including the change's impact on the budget. Just because the price is fixed doesn't mean the consultant has to absorb the costs when the customer changes his mind.

Well I'm not a terribly experienced fixed price person, but that is how I do all my work. An old friend of mine (a painter) told me you should figure out how long you think it should take you, how much you want to make per hour, then double that. He also said make a contract and make sure everyone sticks to it. His advice has been good to me, while I still go over budget it doesn't hurt as much as it might without this rule

Basically agree with sean here, however it is vital that the fixed price is reflected by fixed requirements. Fixed price for fixed workload as it were. As long as the agreements made reflect this, and the customer is aware that n+1 features is _more_ work than n features, and that any changes down the line will have to cost more, then everything should be fine.

We used to do a fair amount of fixed price work; the customer is paying for risk protection so rightly so the work estimate must have a fair amount of contingency built into it.

The contractor is best served by having a very well project scope and specification agreed upon before agreeing to the project. Often we'd sell time and materials project to do that scoping work - usually that's not a big cost relative to a project, and then both client and consultant can rest easy knowing that they both had a hand in agreeing upon what the project will entail.

Some clients insist on having some other party do this scoping work; wherever possible (its not always advisable to push your client hard but we tried and were successful more often than not) we would try to insist that we did the work, explaining that if the teaming of client and consultant were to be successful in the long run, both needed to be intimately involved in scoping out the project.

Introducing a third party into that mix just creates opportunity for dissent and problems, including communications issues "he said she said no I did not...".

So to net it out, don't sign a fixed price contract unless:

+ a decent contract is in place, supported by:
- a well thought out project scope including roles and responsibilities
- a spec sufficient to drive the project and make it possible to delinate where scope creep may set in
- an agreed upon change management process, where project additions will be done on a time and materials basis, or by extentions to the fixed price contract which will of course have to be estimated and priced and agreed upon.

Keep everything, do much by email if possible, document everything.

I think some aspects of a typical job are unreasonable to do fixed price. Stuff like deployment, if that applies, or some kinds of integration. I think it's fair to do a fixed price on the stuff that's well understood and where the goals are clear -- it's fair that the person doing the work take on some risk as it relates to their ability to do the work, but it's not fair if they take on the risk that the project scope or requirements will change. At the same time you don't want to disallow changes, as you want to give the customer what they want.

So by splitting off parts of the project that are likely to change (or are not yet well understood) into time-and-materials you really protect both sides -- the customer gets what they want, and you don't have to swallow the cost of their decisions.

I think doubling the cost based on (hourly rate x expected time) is a reasonable standard.

I typically make a plan by itemizing all pieces of software I will have to write (e.g. front end, DSP processor), all documentation to read (arkane OS API) and write (User's manual), all assumptions to test (e.g. Apache ver. X and MySQL ver. Y are compatible). Then I assign time to each item. The more detailed the better.

If doing something I have done before, I multiply the estimated time by 2. If embarking on a new technology, I multiply the time by 4. Otherwise, I multiply the time by PI=3.141... (a good friend's advice that works great).

One thing that helps is to split the project into phases, and estimate (and bill) each one separately.

Only the current phase gets a firm quote.

So, the first phase is requirements gathering. After an initial discussion with the customer, you should have a rough idea of how extensive this phase should be. Estimate this phase, do the work, write up the requirements, and bill the customer.

The customer now has a requirements document that scopes out the work to be done, *which they've signed off on*, and which *you've been paid* to produce.

Lather-rinse-repeat for each subsequent phase: design, multiple delivery phases, change requests, etc.

At any point between phases, the customer can choose to take the work done so far and switch vendors if they are not happy.

Yes, this process is more cumbersome than Agile proccesses such as XP, but remember that those require a large degree of trust, which is *exactly* what fixed price bids do *not* presuppose.

it's not fair if they take on the risk that the project scope or requirements will change.

In a fixed price contract you never do this; that's why a decent scope document and spec are so critical. If its loose, then most clients - honestly or other wise, and especially in a longer project - will consciously or unconsciously introduce scope creep.

At the same time you don't want to disallow changes, as you want to give the customer what they want.

Of course... and again that's why a clear understanding of what was agreed to is so critical; everything else can be managed by simple change management procedures. Client wants a change, consultant provides an estimate for that change, client decides if the change was really worth it after all...

So by splitting off parts of the project that are likely to change (or are not yet well understood) into time-and-materials you really protect both sides -- the customer gets what they want, and you don't have to swallow the cost of their decisions.

I also agree with Michael Bernstein about splitting the project up into phases, but often in larger projects the client won't sign off on starting until there is a reasonable expectation of what total project work effort will look like.

However when a project is too big and complex to properly estimate up front, there's no alternative. If the client can't see that, they are probably not worth having as a client... that's been my experience.

Fix-pricingly-yours... Mike

So by splitting off parts of the project that are likely to change (or are not yet well understood) into time-and-materials you really protect both sides -- the customer gets what they want, and you don't have to swallow the cost of their decisions.

Somehow I managed to paste part of Ian's reply into mine without quoting it... I think the only disagreement I was going to raise was that the consultant should never allow him/herself to get into the position where they may have to swallow the cost of their decisions. If proper, realistic scope and estimates can't be agreed upon, what's the point of starting.

I found that all my "grown up" clients well understood this... it was in their interest to be sure the relationship worked well on both sides. As a result I got stuck in some rather profitable multi-year contracts that just never ended... beneficial for all involved.

Except for my family who were one plane ride away all the time :-(

Many sensible comments above.

1/ Insist on a design phase that includes a prototype. Get actual users involved with it. Quote separately for this.
2/ Fixed price = fixed spec + change process BUT without a realistic design you are SOL.
3/ Split into as many small pieces as you can, each of which provides an objectively judgeable capability
4/ Time & Materials can easily make everyone hate each other - use sparingly

HTH

Andy

Ned, things are going to change they always do. Perhaps your friend can use an Agile approach where the customer specifies the requirements (stories) and their priority. Then fix a completion date. Then your buddy estimates what can probably be done by the completion date (in priority order). Following agile, the customer would see working code very quickly and features may be considered complete before all the requested items are actually 'done'.

See also this note (Estimating Fixed-Price Projects) that points to an article by Martin Fowler.

Fixed-price contracts are problematic - they turn the development phase into a zero-sum game where the client is always trying to get features into scope, and the developer is trying to get them out. It can make the whole thing quite unpleasant, because the party that pulls the hardest makes the most profit on the deal, and everyone tends to lose sight of the fact that the project is being done to provide business value, not as an end in itself.

Something I've seen in a consultancy I used to work with was what they called target pricing (I'm not sure how widely this term for it is used):
* An quote is produced for the specification, and a target price is set.
* A price cap is set at a higher price (how much higher depends on the risk involved; it might be 150 - 170% of the target price, or much less).
* If the project goes over the target price, the customer pays the target price plus half of the overrun, up to the price cap.
* If the project is completed under the target price, the customer pays the target price minus half of the underrun.

This structure means that everyone has incentive to make the project come in at or under the target price, and can make the relationship with the customer much less adversarial.

It can be hard to sell (probably between fixed-price and something more agile), but the logic is sound, and customers who've been through the frustrations of a fixed-price development are often happy to try something new to mitigate that pain.

I'm not sure whether your friend is in a position to propose something like this, but if he is I'd strongly recommend it.

I have done 4 or 5 fix bid large scale projects. The keys are determining how much work is required. If it is ambigous going in to the project it is a loser from the start. Give up a week of free time to do more discovery, start a prototype, build better requirements. Give it to the customer for free so you can better understand what the underlying issues are. Do your standard estimating then add in the risk factor. Gut feel should tell you it is 50%, 100% or 200%. Then once the project begins you have to control change to the scope which means you ned a non fixed way to charge per hour for changes. Last but not least in a fixed bid environment either you or the customer loses, make sure it is the customer. I told every fixed bid exactly that it would be cheaper to do it by the hour but fixed bid removes the risk from their side. The consulting firm takes on the risk and their is a premium for that. Good Luck!

I'll just echo what a couple of other people have noted: it's really, really important that the project scope, feature requirements, and support/revision responsibilities be documented (perhaps, say, in a signed document) before starting on a fixed price project.

The place that I've seen these situations get ugly is the 11th hour "oh, now that we see it, we also need X feature for it to work the way we need," where X is something requiring many days or weeks of work. If your contract says you'll deliver "a widget tracking system" and nothing else, you're probably screwed, as the client may well view feature X as essential to the system. On the other hand, if your contract refers to "a widget tracking system with the features and functionality defined in attachment A," you've got a fighting chance of either refusing the request or getting additional payment for it.

Rather than going fixed price, try this approach:

$X per hour for the first $Y hours.

$0.25 X per hour for all hours past that number.

This pricing scheme protects your clients in much the same way as a fixed price contract does - it greatly reduces their exposure and risk - and furthermore, it aligns your interests and theirs.

In a fixed bid situation, their interest is to get as many features crammed under that bid as possible, as they don't have to pay for them. This leads to all kinds of problems in the specification and acceptance phases of the gig in many cases.

In the hourly rate situation, they are afraid of lollygagging and overcomplexification on the part of the programmer, and it is in the programmer's interest to go in with a a poorly defined specification and clarify it on the client's dime.

The scheme I'm proposing helps to bridge this conflict of interest: it's in the interests of both sides to have a good idea of the work to be done, because the client is still paying for over-runs, even if at a discounted rate, and why would the programmer want to work for such a reduced rate if they didn't have to???

Of course, 0.25 of the hourly rate is simply a "for example", but:

$100 per hour for the first 40 hours and
$25 an hour for ever hour thereafter

sure does seem like an easy way to do business, doesn't it?

This is how the Shuttle guys and girls do it:

http://www1.jsc.nasa.gov/bu2/NCEH/index.htm

Heavy-duty stuff, but lots of good points.

Martin