There is a paradox at the heart of many technology contracts:
- a customer rarely knows what it wants until it sees or experiences it
- a customer rarely needs the “best” solution, but only something that is “good enough” to enable it to get on with business.
It is in the interests of both the customer and the supplier to make sure that the customer has a good understanding of the systems or services that it requires. This is because, in the absence of such an understanding, both parties will strive to achieve the “best” solution, which is likely to be a waste of time and effort.
This problem is illustrated by the drafting used in many large-scale services or outsourcing contracts. Customers try, on the one hand, to impose tough obligations on the supplier to deliver “best practice” whilst, on the other, avoiding a commitment to change (in case this is onerous). However, because it is unusual for these contracts to define how particular services are to be performed, the meaning of “best practice” is often unclear. This forces the parties into regular renegotiations (and disputes) during the life of the contract.
It is particularly difficult to define the standards required for services that cannot be measured and quantified. For example, the handling of help-desk calls is highly subjective and often specific to a particular business. Although it is possible to set service levels to ensure that calls are picked up by the help-desk within a particular period of time, individual users will still be frustrated if they feel that their problem is not being adequately prioritised. In fact, customer satisfaction in this situation might best be measured by an absence of complaints rather than by any positive criteria.
The solution found in government contracts (such as the Office of Government Commerce model agreements) is that the supplier is responsible for ensuring that the solution meets the customer’s expectations, even if these are intangible or are not fully defined. However, not every customer is in the same bargaining position as the government. In the private sector, there may be some lessons to learn from recent progress in software development projects.
Software development
Most people have difficulty in describing a software system, whether in terms of functionality, technical capability, service, output or design. Similarly, it is very difficult to “imagine” a fully operating system based on a written specification.
Software development projects used to be blighted by the fact that, although the customer had agreed a written specification, it rarely knew what it wanted until it actually saw the software. After the customer realised the full capabilities of the software (or the shortcomings of the specification), it sometimes sought to change or to enhance the specification. Many disputes arose as a result because, without careful management, these late changes could significantly affect the quality of the software, performance and overall design.
Such disputes are less common than they used to be. Part of the reason for this is that most customers purchase new systems that are “good enough” to meet most requirements. Such “packaged” systems are designed to be configured for different purposes and to be implemented with a relatively small amount of development and integration. As part of this process, the customer also adopts the supplier’s choice of business processes rather than trying to create a system that fits its existing (unique) processes.
This approach is successful because the customer is also purchasing the benefit of the supplier’s expertise in a particular process or business sector. There is less risk of project failure because, if the new system matches most of the customer’s requirements, this may prove to be “good enough”. Further, the implementation should be less complex and risky because usually the software is already mature and there are existing procedures for support.
Another possible reason for the reduction in the number of software development disputes is the fact that suppliers have embraced “prototyping” methodologies. These methodologies allow the customer to see early versions of the software and to visualise how the software might work in its business. This is a way to ensure that the software fits the customer’s expectations and requirements.
How can this be applied to a services or outsourcing contract?
The customer’s rationale for entering into a services contract is often to save costs and to obtain benefit from the supplier’s expertise. However, these objectives are less likely to be fulfilled if the services are not defined or if the quality of the services is open for debate.
We have considered the example of a customer who buys “packaged” software which is “good enough” to meet most of its requirements, rather than a fully bespoke system. This may entail a compromise on the part of the customer if it has to adopt the supplier’s business processes. However, the “packaged” solution is likely to be cheaper than a bespoke solution, and the customer still gets the benefit of the supplier’s experience and expertise.
In an outsourcing contract, it may not be possible for a supplier to provide a “bespoke” service to its customers, to impart the benefit of its experience and still to save costs. This is a tall order! However, if the service is not fully defined, there is a risk that the customer will expect a “bespoke” solution, especially if it has transferred its staff and assets to the supplier. In fact, the customer will probably expect a solution that matches the service that was provided in-house, even if these expectations are not reflected in the contract. This is often a source of conflict.
It is likely that, if a customer were offered a “generic package” instead of a bespoke service, in many cases this would be “good enough” to fulfill most of its requirements. Although this might force the customer to adopt the supplier’s processes, it is more likely to bring greater clarity to the contract and perhaps to secure the customer’s two objectives – saving money and obtaining the benefit of the supplier’s expertise.
If the customer does require a unique service, the “prototyping” example might also be useful to assist the parties to define what services are required. If the parties could be persuaded to try out the services, perhaps incrementally, before making any irrevocable commitments, it is likely that many mistakes could be avoided. This would also assist the customer to understand how to make the services work for its business.
Conclusion
It is most unwise for a customer to pay for services that have not been fully defined. If the services cannot be properly described in the contract, then there is a risk that substantial parts of the contract will not be enforceable, as “agreements to agree”. This leaves the parties in an impasse.
Even though a more cautious, incremental approach lacks the drama of a big contract award, it is more likely to ensure that the customer gets what it wants. It is in the interests of both parties to ensure that the services are well understood and to avoid the renegotiation and repositioning that characterises many large-scale projects.
Anna Cook is a partner specialising in IT and dispute resolution at Wedlake Bell: acook@wedlakebell.com
