Web projects: how much fixed-price-ness?¶

When you're doing a web project, the customer often wants to have a fixed price. Tom Lazar now prefers to have

• a pay-per-hour specification stage;
• a fixed price and fixed date 1.0 implementation;
• a free of charge specification stage for 1.1, based on initial customer feedback on 1.0;
• and the final stage again a fixed price, fixed date 1.1. That 1.1 is really the final customer release.

To quote Tom: The key point here – and my lesson to take home – is to communicate this approach to the client from the start. As a developer you not only have to manage ressources and time but – perhaps first and foremost – expectations – i.e. tell the client clearly that the "1.0" will be a "rough diamond" – valuable but not necessarily pretty, yet.

Hm. Those four stages don't sound so great to me, at least compared to what I saw till now at Zest software, where I work. We've practically tried to abolish fixed price contracts as they - in our experience - tend to be a source of frustration. Many clients have wishes that they consider part of the contract when we think they're late additions or change requests. With fixed price contracts, the risk is at the programmer.

Tom's solution has two stages in there, which looks like it takes care of some of the issues.

But a customer doesn't like it when we would present them with a choice between "fixed price is our estimate plus 30% safety margin" and "pay per hour". Our solution is to use extreme programming and, Tom is very right about that, explain it to the customer. Our proposition with it is basically:

• You get a fixed deadline and a fixed price, as you get to choose how many iterations (2 weeks long) you want to fund.
• You get to steer the project every two weeks, by choosing what we have to implement or change in the next two weeks.
• You have to trust us to do a very good job in the time we spend on your project. There's really no substitute for this.
• At the end of each iteration, we present you with a working system which you get to test and abuse. So you know exactly what happens, what works, what doesn't. And if you get the idea that it's all no good or that we are no good: don't do any more iterations.
• Not everything you're going to want is going to fit into your chosen number of iterations. That's life. You get to choose the points that are most important for you, though. You get the best value for money. The best value as you get just the most important features. The best value as you don't pay for that 30% safety margin we have to put on fixed price contracts :-)

It probably depends on your clients. Can they look at early revisions of the website without panicking? Tom warns: *most clients find it hard to provide specific and valuable feedback on beta stages of a site. I found that I’m doing nobody a favor when submitting half-finished inbetween-versions of a product for customer review*. We've been blessed with good customers till now. But the latest projects have all been multi-month projects and in my opinion you can't just code away for 3 months without intermediary feedback. It all depends :-)