This is a common question in my own field of software development. There are traditionally two ways you can approach a contract - with a third variation now emerging which might solve some of the traditional conflicts between client and supplier.
The old-fashioned approach - which I believe is still used in many military contracts - is that the supplier bills on a time and materials basis. This reduces the risk for the supplier and places it all on the client. This may well be appropriate if the client is responsible for specification and design - if that is the case, the supplier might not be able to estimate the timescale accurately enough, and many overruns are caused either by incomplete specifications or faulty designs.
The appeal of this approach is that you can get started quickly, and - politically - that nobody in the client organisation has to take responsibility for signing off a definitive specification in advance.
However, it does not incentivise the supplier to deliver quickly or accurately - indeed they have an incentive to spin the project out for as long as possible. Only professional ethics prevent them from padding out the project, and even if they do, they have a valid defense that they just wanted to ensure the highest possible quality and safest outcome.
The second approach, which is the one that Inon has traditionally followed, is to agree a specification up front and then offer a fixed price and timescale for the work. This gives the supplier an incentive to complete the work as quickly as possible - but the client's and supplier's interests are still not completely in line. The client now has an incentive to interpret the specification as broadly as possible, to try to include more and more functionality. Often this becomes a contest between the two parties - the supplier trying to restrict the scope of the product and the client trying to expand it.
It is rarely possible to define the specification tightly enough in advance to avoid these battles - and even if you can, then you end up with an ossified specification that never evolves in line with new business opportunities or constraints.
What happens then? The client realises six months later that they actually want something extra, they raise a change order and the supplier has to charge extra. This is likely to be what has happened with the aircraft carriers Robert Peston mentions in today's news item. Sometimes the client will refuse to pay extra if they think the specification has not changed after all.
We sometimes try to allow for this by including a contingency element in the price, but the drawbacks are:
- if you separately itemise the contingency fee, the client rarely accepts that it is needed - they usually want to cut costs and ask you to remove it, believing that the specification covers everything they could possibly want
- if you do not itemise it, your prices may be uncompetitive compared with a supplier who does not include the contingency. Whether your competitor genuinely believes it won't be needed, or is gaming the system by underbidding and expecting to make up the difference on change orders, does not matter. They are more likely to win the contract and the contingency element will not be accounted for up front.
What is the alternative? A contract method which aligns the interests of client and supplier such as structured pricing. This sets out business objectives for the client and pays the supplier for achieving them.
In a business environment this is usually a goal such as winning more customers or increasing staff productivity. We therefore tend to agree a fee per new client (or a percentage revenue share) or else a value per hour saved, which means if we achieve more then the client is happy to pay more.
There are challenges in such contracts: we need to agree how to measure whether the new clients or the extra productivity actually result from our software or not; but we can usually work out a reasonable way to determine that. We also need to have enough capital to finance the project delivery before the results have some in - often this will be done by an advance payment from the client. And finally we need to have enough understanding of the client's business to produce flexible and creative ways to achieve to their goals.
When we do, the rewards for both parties can be immense. Instead of delivering a project and walking away, we stick around to keep improving it and we are rewarded automatically for every improvement we make. There is no need to negotiate in advance before making changes: we describe our idea and if the client agrees it will be beneficial, we implement it.
Usually we would expect to achieve at least 50% better results for a client, and because the client is protected from the risk of failure they are willing to pay more per unit achieved - resulting in perhaps double the revenue for us with only a third more effort; and higher profits for the client because the increased results more than outweigh the extra money they pay.
Now could this be applied in the military environment? The business objectives are not so obvious - I would hope that nothing so crude as "number of enemies killed" would be adopted, but instead an externally judged measure of security goals achieved, number of square miles protected or average response times to incidents. Client and supplier both benefit and costs are only increased if performance is improved.
Incidentally, will this kind of contract stimulate the economy? President Obama has been criticised for commenting approvingly on cost savings in the stimulus spending; because less spending of course means less stimulus. On the other hand, getting the same output for cheaper leaves more money to spend on other things, and if the amount of money spent is fixed then we should try to get as much as possible in return for it. Generally a structured pricing approach is fine for the economy if the total amount of spend is fixed, and even better if spending is allowed to rise when more output is achieved.
Oddly enough, UK governments (both Labour and Conservative) have tried something quite like a structured pricing approach before. Once in pay-for-services market reforms in the health service, and once in the construction of PFI contracts. Both times they were excoriated for it. Some of this criticism was fair - where contracts have been structured to keep all of the risk in the public sector and not to encourage the delivery of better results. But some criticism was purely based on the fact that these policies might cost the government more money. This is the whole point, though - it does cost more money but only if more results are delivered. We want more results to be delivered and we should be willing to pay for them.