InfoCat has been implementing budgeting, planning and analysis solutions for over 20 years. When we talk to prospective customers about consultancy projects/implementation costs they sometimes ask about fixed-price contracts, believing this will give them certainty and remove any risk associated with the project.
This approach appears particularly popular in the public sector but, as we frequently see in the newspapers, even fixed-price contracts can end up costing far more than expected. Why is this?
Well, if you are considering a fixed-price contract, ask yourself the following questions:
- Do my users know exactly what they want from the system
- Am I sure there will be no changes during the course of the project to user requirements, external infrastructure or the organisation itself
- Is there a document specifying all the users’ requirements unambiguously and in precise detail
- Have I prepared a list of acceptance criteria that will guarantee the system will perform fully as expected (not just what it does but how it does it)
- Does my internal team have the experience and resource (including legal) to manage the project, the supplier and the contract
- Am I 100% sure the supplier has resources, capability and experience to deliver a workable solution and do I trust them enough to make a fixed commitment
- Am I happy for development to be carried out without any interaction with the users until it is delivered (after all, we don't want the users to ask for changes because the system is not delivering what they were expecting but which they hadn't explained to us)
- Is the budget large enough to cover the extra costs of a fixed-price contract e.g. internal and external management and the risk premium added by the supplier
- Do I have extra budget for any changed or new requirements; you are likely to be committed to the supplier by this stage so these could be considerable!
If you can answer yes to all these questions then maybe a fixed-price contract will work. However, in most of the projects we are involved with this is very unlikely. In these cases we strongly believe a time and materials basis using an agile methodology provides a much better outcome for the customer in terms of both the quality of the system and the cost.
This approach does not mean the customer providing a blank cheque; we use our experience to provide budget estimates which are updated and refined as the project progresses. If the estimates exceed the customer’s budget we work with them to decide how best to resolve this; for example we can simplify requirements, the customer may develop some parts themselves or leave less critical parts of the system for a later phase.
In summary, a time and materials approach gives us much greater flexibility to respond to changes and feedback and work closely with the customer to ensure we deliver a system that meets their real needs and performs well.