In the quest for a better way of putting together outsourcing agreements, much attention has been given to "risk and reward" contracts, where part of the outsourcer's remuneration comes from the savings or business benefits they make possible. Conversely, if they fail to deliver, they lose part of their fee.
In practice, imprecise contracts and a lack of properly agreed metrics for success or failure have often turned risk-and-reward into a blame game in which lawyers are the only winners.
Last year, four years into a 10-year risk-and-reward contract, Airtours took EDS to court, claiming that it had failed to fulfil its side of the agreement. EDS had undertaken to re-engineer and manage Airtours systems, and its fees were supposed to depend on Airtours business performance. EDS counter-sued, each party claiming breach of contract.
According to AMR Research analyst Kate Murphy, "Risk and reward is not widely adopted as the sole form of payment because both sides do not easily agree on terms and metrics. When clients see the amount they could ultimately pay, many back out. This type of contract is just plain difficult to administer."
Mary Lacity and Leslie Willcocks, writing on the Templeton College, Oxford Institute of Information Management Web site, www.templeton. ox.ac.uk, comment, "Sometimes the innovation expected from the supplier is not forthcoming. In others, the risk-reward element is too marginal to the overall deal to affect behaviours, and a more traditional fee-for-service arrangement becomes the basis."
However, according to Cap Gemini Ernst & Young executive director Duncan Aitchison, risk and reward models are increasing in popularity. He says that where an outsourcer can directly influence a business outcome, as in areas like customer relationship management, supply chain management and business process re-engineering, this may be an appropriate arrangement. Cap Gemini Ernst & Young's £400m contract with British Steel (now Corus), signed in 1997, involved not just running the existing systems, but also making much wider improvements to business processes.
Willcocks and Lacity use the term "co-sourcing" for performance-based contracts where the supplier is rewarded for helping to meet the client's business, as well as IT, goals. "Such deals work well when the supplier's core capabilities are contractually structured to complement customer needs. However, despite claims, not all suppliers have the necessary business know-how of a client's core business. Moreover, many suppliers are not really geared up to deliver this type of arrangement, as opposed to fee-for-service contracts."
Vague terms like "improving business processes" and "increasing overall business performance" will not do for a contract. Some way needs to be found of measuring end-user satisfaction, or the contribution the outsourcer has made to increased profits. According to Dun & Bradstreet, "Too often, vague non-quantifiable guidelines are developed. They are subject to countless interpretations leading to disagreements and dissatisfaction."
So what do you measure? Dun & Bradstreet give some examples, such as reducing the length of time goods spend in the warehouse, with a quantifiable projected saving which can be split between customer and outsourcer; or improving customer retention, by reducing the time taken to answer enquiries beyond the point where a known proportion of callers grow impatient and hang up. Once the objectives have been established, performance needs to be monitored by means of shared scorecards, with periodic reviews.
Another way of sharing rewards is to assign intellectual property rights for project deliverables to the outsourcer. This is fine in theory: the customer gets a lower price, while the outsourcer gets the chance to sell the technology elsewhere. But leaving aside the possibility that the customer will go through all the pain of bespoke system development, only to see the software delivered pain-free to a competitor, the long-term costs of leasing back the technology may be far more onerous than paying in full.
According to the Cabinet Office, "Under some recent procurement contracts, intellectual property rights for the software developed remain with the supplier, and are licensed back. However, this may not be the most cost-effective solution where subsequent changes of use are envisaged, and this is increasingly likely to be the case as departments and agencies modify their systems to improve interoperability across government."
Lacity and Willcocks also looked into "value-added" outsourcing arrangements, where supplier and customer set out to market the software and services their pooled skills have created.
"Too often the added value service part of the contract is marginal to the major client-vendor focus. It is also rendered less attractive when participants discover that it requires up to nine times the initial development cost to transform a home-grown application into a commercial one."
And of course, even when you have got a commercial product, you need a sales and marketing function capable of making an impact in the intensely competitive software and services market - with no track record to demonstrate your capabilities. And what happens if the demands of your business start to compete for resources with your customers?
One "reward" which suppliers have been cheerfully pocketing is the difference between what the customer agrees in advance to pay for hardware and software, and the actual cost, which has been falling sharply in recent years. Gartner Group says this is "a major area of discontent" for US outsourcing customers. And last year, the House of Commons Public Accounts Committee insisted that EDS share more of the savings it was making on hardware in its contract with the Inland Revenue.
When contracts are too restrictive, users not only lose the ability to shop around - they are often denied the opportunity to examine the supplier's books, to find what they are actually paying. "Open book accounting", where both partners have access to relevant financial information, is essential to a real risk and reward contract.
So much for potential rewards. What about the risks? Neil Carey, an audit manager at the National Audit Office, says risks are often identified at the outset, but too little time is spent evaluating how likely they are to happen, or the consequences if they do.
"Too often," he says, "customers and suppliers have sheltered behind their contractual defences in case of failure, rather than working together to pre-empt problems and to identify remedies. More transparent risk management, shared understanding of definitions and milestones, and rewards for honesty and realism, would all reduce exposure to risk."
Among the reasons for project failures, Carey identifies "unhelpfully legalistic relationships between purchasers and their suppliers".
The prospect of things ending up in court hangs over contracts like a bad smell, leading suppliers to attempt to include clauses that are over-protective of their own interests. But customers who have followed the progress of court actions know that, if it comes to it, such clauses are likely to be overturned in their favour.
In one of the landmark cases of the mid-1990s - which established for the first time that software had to be fit for the purpose for which it was sold - St Albans City & District Council sued ICL for supplying faulty community charge software. The software had overstated the number of people liable for community charge by 2,966. St Albans used this figure in calculating the charge, with the result that receipts for the year were nearly £500,000 down. Adding precept payments to the county council, the total loss was over £1m.
St Albans sued for £1.5m in damages. ICL tried to rely on a contract clause which limited its liability to £100,000 but the High Court ruled that the liability limitation clause was unfair - a decision later upheld by the Court of Appeal.
According to the legal and contracts special interest group of the Computer Services & Software Association (CSSA), most disputes in IT revolve around complicated contracts involving bespoke software solutions, and not standard contracts. In the CSSA's view, there seems to be a general tendency for judges to resolve such disputes in favour of the customer.
The CSSA feels that suppliers are often seen to rely far too heavily on exclusion clauses. "The court has discretion towards the matter of exclusion clauses, but will often err in favour of the buyer, as exclusion clauses are considered to be far too numerous. Exclusion clauses in contracts should be reassessed, as their current ability to protect the supplier is patently not working."
Given the statistics for outsourcing failure, every contract needs to include an exit strategy. Without this, problems are almost certain to arise, according to IT legal specialists Field Fisher Waterhouse, who say that companies approaching outsourcing for the second time are doing so very cautiously.
Customers need to begin preparing a new invitation to tender at least a year before the contract ends. "In order to issue an invitation to tender to potential service providers, the user will need access to all relevant information about the assets and services which potential new suppliers would inherit," the lawyers point out. If customers cannot provide this, potential bidders may be reluctant to commit to service levels - or may underbid, with disastrous consequences when they find they can not make money from the contract.
All CSSA members undertake to provide help with the transfer, as stated in the association's IT outsourcing code of practice. It obviously would not be reasonable for the supplier to take bat, ball, stumps and team home the instant the contract expires. There is usually an overlap period of six months or more as the contract is handed over. On the other hand, outsourcers may be reluctant to provide sensitive information to competitors, and may try to protect it on grounds of commercial confidentiality. This could result in the customer getting locked in to the contract.
Commercial confidentiality makes it equally difficult to get hold of meaningful data about the performance of potential suppliers. It makes benchmarking a supplier's relative performance difficult. The Inland Revenue told the Public Accounts Committee that it expected "to end up benchmarking something of the order of 50% of the contract" with EDS.
A contract also needs to make it clear who pays for terminating and transferring an agreement that has broken down. The assumption is that whoever is in breach of the contract will have to find the money, but things are rarely so clear cut. The supplier's apparent failure may actually be the result of the customer failing to manage its share of responsibilities.
As the CSSA puts it, "While the supplier is responsible for delivering the agreed services, the client retains the ultimate responsibility for ensuring that the service supplied to his users is satisfactory and in accordance with the agreement."
Or as Willcocks and Lacity put it, "Organisations still expect too much from suppliers and not enough from themselves, or put another way, suppliers are still much better at selling IT services than their clients are at buying them."
Making the contract work
- Risk and reward contracts need to be based on precise, agreed metrics. These are tricky to establish - a traditional fee-for-service is a much simpler approach
- Customers should make sure they share savings that suppliers make as the price of hardware and software falls
- Both partners should have access to all relevant financial information - "open book accounting" is essential if costs and benefits are to be shared
- The contract needs to take account of future business changes, and how the costs will be shared
- Granting intellectual property rights for deliverables to the supplier, and leasing them back, can bring upfront savings, but can be more expensive in the long run
- Outsourcing relationships can be overly-legalistic - suppliers make too much use of exclusion clauses to limit their liability and customers know they can often get these overturned in court
- Make sure the team you meet in negotiations is the team you get once you've signed the contract
- Every contract needs an exit strategy, making clear who pays for what if things break down
- Ensure that you have the right to access information any new bidder will need
- Don't expect too much from your supplier - customers have responsibilities too, especially in risk and reward contracts.