The fixed price contract has been discussed here at the Crisp blog by others. It is broken by design as it creates more problem than it fixes.
On the way from JAOO I talked to Udi Dahan and that made it fall into place in a different fashion. Not that this is what he said, this is what he sparked.
The fixed price contract is not necessarily fixed price, a contract or evil.
First of all, it is an excuse to get a budget. Let’s face it, your client on the other side of the desk, the man with the tie, has a boss. He wants to look good in front of his boss. So he needs a sum of money written down next to a promise of something. The sum must be big enough to justify him talking to the boss. The promise must sound like it has value and of course it does, you wrote a proposal full of great ideas.
Once the contract is approved, the fixed price changes as there are always change requests and they cost money. So the price is not really fixed.
But you know that is going to happen, so the proposal is gold plated with features that are not really necessary. When the client comes with a change, you suggest they trade it for something of that gold plated stuff. Of course they do. So you seem very agile as you take on a change request for practically nothing.
Best of all, if you trade something with higher risk for something with lower risk, you are better off than before.
In the end you deliver the product on time, different from what was in the contract and perhaps for a slightly higher price (not all changes can be traded for something else).
The project is a success and nobody cares about what was in the original contract.
You will get a request for a second version and this time you know the customer even better so the gold plating can be even more cunning *cough* clever.
Evil? Depends on how you see it. As long as the customer is happy and gets a return on their investment, all is well. After all, the value of something is what someone is willing to pay for it.
So the price changes and the scope changes. Why call it a fixed price contract?
Now, Udi may think I am madly misinterpreting him. So, I guess he is only responsible for the subject and not the content.
Interesting thoughts!
This is what I’ve heard call the exchange request approach. It’s a way to get some agility into fixed price contracts. Still, there’s waste; effort goes in defining a too detailed scope upfront; scope that may never be built.
It may well be the best solution in certain situations but see it as a step towards a real agile contract. Why not inspect and adapt contracts as you go through subsequent projects you do with your client and make your contracts more agile in every next project!
That’s the reason I recommend making the scope of your first project as small as possible. Build trust and follow up with a more agile project.
Good to know it has a name 🙂 I agree with you that you should try to avoid defining scope in detail up front. But for change to happen, there has to be a path that takes you there.