Fixed price work is all the rage with IT finance departments and senior managers, even in this age of moving towards Agile methodologies and incremental delivery.
There’s definitely a big dichotomy between agile and fixed price, with the former based on flexible scope, frequent delivery and frequent business led prioritisation, and the later fixed scope, large delivery milestones and fixed priorities.
What I’ve found in a number of projects that attempted to be fixed price but flexible is that it leads to a large number of change requests. In itself this isn’t necessarily a bad thing – it’s surely better to have a change request than deliver the incorrect or out-of-date functionality. However, I’ve also observed that the cost of the change requests tends to increase, and frequently make the project overall uncompetitive compared to a regular non-fixed delivery.
I believe the reason for this is that the quotes for change requests build in an increasing risk premium. The logic for this is fairly simple:
- Project is priced based on assumed perfect knowledge of the requirements, with a contingency.
- Change request comes along, so the confidence about the overall requirements falls and a risk premium is added to cover assumed increased contingency requirements.
- Another change request comes along, so the confidence falls further and the risk premium increases further.
- etc etc
You can’t really blame the delivery team for this – it may be a bit naive to assume the requirements are clear/perfect at the start, but you have to work on some assumptions. Change requests typically mean that either the business are moving the requirements, or worse for existing systems that difficult parts of code/functionality are being uncovered; denying this increases the risk and the cost would be foolish.
I’m not sure there’s a good solution to this, but there are a couple of things I’ve seen.
Have a limit on change requests, either numeric or in percentage of cost terms.
This has a number of implications. For the delivery team, it means they have confidence the scope won’t keep changing, so the risk premium is lower. For the business, it means they have to think very clearly about changes and prioritise them properly.
Encourage a larger contingency, but allow use of it for small changes.
This means that a small amount of change is accepted and accounted for, so giving both sides more flexibility in how to manage it.
Overall I don’t believe fixed price is typically the right approach except for items which can be very clearly packaged (e.g. upgrades, migrations, modules linked by defined API), in most cases Agile will deliver a better solution more reliably. However, if you are using fixed price, perhaps the idea of a risk premium is useful.