Its easy to understand the appeal of a fixed price project from the client’s perspective: they can rest easy knowing they will get what they’ve purchased within their budget. There are good reasons for NOT entering into a fixed price arrangement, but with a few recent client encounters where fixed pricing arose as a topic, I’ve had the opportunity to revisit this pricing model.
Software is is easily malleable, largely invisble, and is hard to specify and measure. This makes it hard to estimate, so there is risk that it may cost more to deliver than a fixed price. A solution is to make the effort to specify the project precisely, so that the cost is understood before fixing the price.
There are two problems with this approach. First, it can take a lot of effort to gain a precise understanding, which results in additional cost and time added to the project. Second, business needs can change by the time the project is complete, resulting in wasted effort to understand the details and costs up front. It is more efficient to allow the details to be specified and delivered as the project proceeds.
The client may want a fixed price project because they have fixed budget to work with, or because we have not established a trusting relationship. I understand these reasons, and I’m happy to offer fixed price in these cases. To do so, I assume the risk that the project will cost more than anticipated, and therefore add some contingency to account for that risk. At the same time, I want to give as much value to client as possible, as their success is my success.
I then promise the essential features to be delivered. If it turns out we don’t use all the contingency, we have the opportunity to add some of the wish list features that are part of any project. Result – I’ve covered most of my risk, and the client gets as much value as their budget allows, and hopefully the client develops trust, which may allow leaving the fixed price model behind.