‘When I use a word,’ Humpty Dumpty said in rather a scornful tone, ‘it means just what I choose it to mean – neither more nor less.’[1] Unfortunately, many lawyers fall into the same trap as Humpty Dumpty when they interpret and draft contracts. We can all think of occasions in our social and professional lives when our words have conveyed a different meaning to our audience; this peril is magnified when we are dealing with contracts for technology and outsourcing, where the subject matter is inherently complex and the documents are substantial and created by many people. We begin by examining the law relating to contract interpretation (including recent IT cases), and then apply the lessons learned to draft effective technology contracts. Now that we all work from precedents, many lawyers have forgotten the importance of style, structure and content to producing effective technology contracts, so there is a timely reminder of the ‘old school’ rules.
Law relating to contract interpretation
The courts are only interested in establishing the meaning of contract documents as they would be understood by a reasonable person having all the background knowledge which would reasonably have been available to the parties in the situation in which they were at the time of the contract.[2] The judge functions as this hypothetical reasonable person when performing that analysis, taking into account evidence of the facts known to the parties at the time of contract (the factual matrix). But the judge isn’t interested in what either or both parties thought the contract means (the exclusionary rule). So evidence of pre-contractual negotiations is inadmissible for the purpose of interpreting the meaning of the contract.[3] However, such evidence may be relevant to establishing the factual matrix against which the contract is interpreted by the judge.[4]
The recent case of GB Gas Holdings v Accenture[5] shows the correct approach to interpretation. Centrica contracted with Accenture for the design, supply, installation and maintenance of a new IT system (‘Jupiter’) based on an SAP software package. Jupiter was to be delivered and implemented as a number of releases, with Release 3 being an automated billing system. Problems arose with the automated billing system, with many customers not receiving bills, and Centrica having to intervene manually to bill them, leading to a billing backlog and greater staff costs. One of the preliminary issues to be determined by the trial judge (and subsequently on appeal to the Court of Appeal) was whether the problems with Release 3B were ‘Fundamental Defects’ requiring a greater level of effort from Accenture than if they were merely ‘Material Defects’.
The case of De Beers UK v Atos Origin[6] also provides numerous examples of the factual matrix which the judge took into account when interpreting the contract : ‘In this case the parties would have been aware of the events leading up to the making of the contract including the tender process, the Best and Final Offer (‘BAFO’) made by Atos and the implementation of the IAP…In my judgment, Atos went into this contract with its eyes at least half open, in the sense that it knew or should have known that it had not acquired a good grasp of the detail of DB’s diamond sorting and aggregating processes and that consequently a great deal of work remained to be done in the way of gathering the detailed requirements, with consequent implications for the development of the design – both in terms of time and resources.’
Lawyers make the common mistake of interpreting words used in contracts in isolation, rather than ‘in the round’. The author recalls advising a supplier on whether it was required to migrate data from hundreds of legacy systems to its new solution as part of the core service (and therefore subject to the fixed annual service charge, rather than being a chargeable extra). The interpretation exercise involved reviewing thousands of pages of contract and checking hundreds of references to ‘data’, ‘data migration’, ‘data conversion’ and ‘data transformation’. Read in isolation, certain terms appeared to state that it was part of the core service; other terms suggested that it was the customer’s responsibility. Read in the round, it was clear from the contract that the customer was responsible for the main steps involved in data migration so that the data was available for loading into the supplier’s database in the format specified by the supplier.
In the well known case of St. Albans City and District Council v ICL,[7] the Court of Appeal reviewed the contract documents as a whole, and held that there was a breach of an express term of the contract based on the Council’s requirements specified in the ITT. The factual matrix included the introduction of new legislation relating to the new community charge and local government finance.
The correct approach is neatly illustrated by the recent case of BMS Computer Solutions v AB Agri.[8] In this case, the parties were subject to separate software licence and maintenance contracts, which had been amended. The licence granted by the amended licence was perpetual, although termination of the maintenance contract was stated to trigger termination of the licence. The licensee AB Agri had terminated the maintenance contract but wished to continue using the software on the basis that it had a perpetual licence. The judge said that the word ‘perpetual’ has different shades of meaning: it could be ‘never ending’ (in the sense of incapable of being brought to an end) or ‘operating without limit of time’ (to grant a licence of indefinite duration, but subject to any contractual provisions governing termination of the licence). Reviewing the contracts in the round, he concluded that the latter interpretation was correct.
Commercial relationships evolve and it is common for outsourcing contracts to be varied by change notes or more formal variation agreements, and there is a danger of inconsistency creeping into the contract as a result. This is precisely what happened in Ericsson v Hutchison 3 G UK[9]. The parties had agreed at least seven different formal contract variations, which resulted in some ambiguity about when Ericsson was required to start providing exit services: was it on 26th May 2010 when Hutchison served a notice terminating the contract (approximately 2 ½ years before the date that termination was to take effect at midnight on 11th December 2012), or was it on 12th December 2011 (12 months before midnight on 11th December 2012)? They ended up in court to sort out the muddle.
‘old school rules’ : the importance of style, structure and content
I spent my formative years at IBM before joining Theodore Goddard’s fledgling technology practice. Robin Preston, my new boss, took me aside after a few weeks and said ‘you’ve obviously never done any free drafting before’. And he was right. To his great credit, Robin taught me basic drafting skills which have stood the test of time. Robin explained that a contract is a set of rules (eg warranties, acceptance criteria & procedures, service levels & service credits) linked to a collection of information (eg specifications, project plans, prices, list of contracts to be novated). Lawyers tend to focus on the former to the detriment of the latter. It is important to bear three things in mind when preparing these rules and collections of information:
1. Style: the style of the contract needs to reflect the needs of the people who will be using it;
2. Structure: the architecture of the contract represented by defined terms, clause headings, sub-headings and schedules needs to follow a logical sequence (typically dictated by the order in which things will happen) and these individual components need to link together to create a working whole;
3. Content: the detailed rules and information should reflect the structure.
The aim is to produce a contract that can be understood by an intelligent reader with no background knowledge of the deal.
Contracts are not interpreted or drafted in a vacuum
We know that judges interpret contracts against the factual matrix. Yet time and again, lawyers are asked to review and draft contracts in a vacuum.
|
Case study: The Happy Project The customer was a new media start up launching a web based subscription service. It needed a system to support the service and approached a well known IT supplier for help. The lawyer was asked by the supplier’s legal department to review the standard consultancy contract (absent the scope of work) for use with this new customer. The sales person initially refused to show the lawyer the scope of work on the grounds that there was ‘no need to worry, it’s time & materials; it’s a no responsibility deal’. When pushed, he sent through the draft scope of work which said : ‘provision of project management, technical consultancy and programming resource to assist in the design and build of a subscriber management system’. The lawyer commented that this description seemed rather brief, to which the sales person retorted : ‘Isn’t it better not to have too much written down? That way, the customer can’t come back at us if things go wrong…don’t make trouble, this is a happy project.’ Further digging revealed that the supplier had agreed verbally to design and build a new system to manage subscriptions and billing for £1 million, and that the go live date was critical as the founders had promised investors that the service would be launched by that date in order to secure further funding. The lawyer made sure that the correct form of contract was used and created schedules to reflect what was intended to happen. |
So make sure that you collect the information you need and understand what it means.
The Emperor’s New Clothes
What if the information doesn’t make sense because it talks about ‘cloud services’, ‘software implementation’, ‘virtualised environments’, ‘agile methods, scrums and sprints’ and ‘data migration’ ? You will find that IT professionals use many expressions which are not terms of art and have different meanings. Don’t be afraid to ask the obvious question if you don’t understand. In short, keep an open mind.
Stating the obvious
Things that seem obvious to someone that has worked on a project for many months will be less obvious to the lawyer brought in to ‘paper the deal’.
|
Case study: can’t see the wood for the trees The lawyer was asked to review a contract for implementation of a software package for an airline, and hosting of that software in the supplier’s data centre. The contract for implementation services contained a lengthy description of the functionality of the software modules that made up the package. There were five modules, although it was impossible to determine this from reading the description. The customer’s project manager had worked on the project for many months, and knew each module intimately. He was surprised when the lawyer recommended that the schedule included a table of module names and version names on the first page. |
A lot of time and money is wasted in court trying to prove basic facts, such as the specification or project plan on which the contract is based: ‘the Specification’ means the specification attached at schedule 1; years later, when you and the project manager have moved on, the client and their advisers find that nothing is attached at schedule 1. There can be no debate if it states: ‘the Specification’ means the requirements specification for an XYZ system dated 4th April 2011 v4.0 reference ABC a copy of which is attached at schedule 1. And check that it is attached.
Keep it simple
Few of us enjoy reading small print on web sites and car rental forms. What makes us think that our clients enjoy reading hundreds or thousands of pages of turgid documents or can be bothered to understand them? The IT industry and its customers[10] don’t use model contracts, and the advent of PCs and Microsoft Word make it all too easy to recycle previous precedents, often with little thought as to their relevance or content. Imagine for one moment that your brief was to make the contract simple and easy to use. Apply lean thinking to every rule and piece of information, and ask yourself what purpose it serves. Why write: ‘In the event of’, when the word ‘If’ suffices? Is it really necessary to preface warranties and indemnities with the phrase ‘Subject to clause 10 (Limitation and Exclusion of Liability)’ or to state that if there is a dispute about change control, it will be dealt with using the dispute resolution procedure?
Keep it consistent
Have you reviewed a software contract where the subject matter is described variously as ‘the Software’, ‘the Programs’, ‘the software products’, and ‘the Solution’? Then the software is subject to ‘Support’, ‘the Maintenance Service’ and ‘Maintenance and Support’. Do these expressions mean the same thing ? What if the licence is expressed to terminate if the customer terminates ‘Support’ (instead of using the term ‘the Maintenance Service’)? And the supplier is stated to have a duty to prepare a ‘Detailed Implementation Plan’ but is paid for ‘Deployment Services’. Individual cosmetic defects can have knock on effects and become more material. There’s no excuse for not checking for consistent use of defined terms. And by the way, defined terms aren’t supposed to contain substantive rights and obligations!
Clients will often have a particular issue that they are worried about: ‘We’re very worried about interoperability of the new system that we’re buying from X and we want to make sure that it interfaces with our legacy systems’. In response, we might draft something like this into the contract[11] :
‘In respect of network, communications, computer or other equipment provided by a third party contractor that do or are required to interface with the Contractor System, the Contractor shall have primary management responsibility for incident or problem resolution, including: for ensuring that such requirement does not interfere with the provision of the Services in accordance with this Agreement; and for taking all necessary steps within its power to ensure that the interface is successfully achieved…’
Apart from struggling to understand what this means, isn’t this a requirement and should it not appear in the requirements specification or services description, preferably with a more accurate description of the interfaces which need to be achieved?
Be creative
It has been said, that a picture paints a thousand words. White boards and flip charts can be used in workshops to explain the proposed structure of a contract before spending hours or days turning it into drafting:
· ORACLE uses a diagram to explain the relationship between the different documents which make up a complex suite of contracts.
· Trade association Intellect’s standard escrow contract was developed using visual aids so that Intellect and its advisers could understand the processes leading up to making the contract – the original 20-page escrow contract was reduced to 1½ pages as a result. Intellect has seen a marked increase in the demand for its services since the contract was streamlined.
· The sales director of a supplier gave the author a comprehensive overview of a £400 million outsourcing deal in the course of an hour and using only a white board by drawing the contract as a collection of inter-connected blocks (each block representing a schedule such as service towers, charges & baseline volumes, people, etc). This gave the author an understanding of how the structure of the contract should work, which was different to how it been drafted. We were able to make the necessary structural changes before the contract was signed.
|
Case study: creating a menu based contract An insurer regulated by the FSA had an existing business process outsourcing contract for document scanning, archiving and retrieval which was based on the supplier recovering its costs plus a profit margin. There were a number of issues with the contract : (1) there was no incentive for the supplier to minimise the costs and make the services more efficient, (2) the insurer’s business was facing complex and unpredictable changes as a result of potential reorganisations, disposals, acquisitions and mergers, and the existing contract made it difficult to allocate the supplier’s charges to different business units or to model the effect of changes to its business, (3) FSA rules required the insurer to demonstrate greater transparency and control over outsourcing contracts. Like many outsourcing contracts, the service descriptions, service levels, charges, baseline volumes and management processes were scattered across many schedules. Changing these schedules was a nightmare if there was a change to the insurer’s business. Using workshops, flip charts and slide sets, the answer was to create a new menu based contract, so that each business unit could see what it was buying in one document. There was a menu for each service containing: · description of that particular service (eg scanning) · service charge, baseline volumes & impact on price for increase or reduction in volumes · key supplier processes which could not be changed without the insurer’s permission · service levels & reporting · service credits As a result, the insurer was able to add new business units or dispose of them, flex the demand for the services up or down, model the effect of changes to its business, and have greater transparency and control over the contract. The contract was also much easier for the procurement professionals to manage. |
Summary
Judges don’t interpret a contract in a vacuum, and nor should you. Make sure you understand the big picture before reviewing or drafting contracts. The contract should be capable of being understood by an intelligent reader with no background knowledge.
Test this using a few simple questions:
· what does the customer think it is buying?
· why is the customer buying it?
· what does the supplier think it is selling, and does this match the customer’s expectations?
· where is the thing that you are buying or selling described?
· what standards of performance is this thing expected to meet?
· when and how is it to be delivered?
· how much does it cost?
· how is it to be paid for?
· are there any things that aren’t in the price or budget (for example, things that the customer is expected to do as customer responsibilities) or which could cause the price to change (such as pricing assumptions)?
Remember the ‘old school’ rules about style, structure and content: the contract needs to reflect the needs of the people who will be using it, follow a logical structure, and contain content reflecting that structure. And be guided by the cautionary words of philosopher John Locke: ‘[Men content] themselves with the same words as other people use, as if their very sound necessarily carried with it constantly the same meaning’.
John Yates runs consulting business v-lex, specialising in complex technology and outsourcing contracts. He is a Fellow and past Chair of SCL. John started his career with IBM.
[1] Through the Looking Glass, Lewis Carroll.
[2] Lord Hoffman in Investors Compensation Scheme v West Bromwich Building Society [1998] 1 WLR 896, HL.
[3] Prenn v Simmonds [1971] 1 WLR 1381, HL. Lord Hoffman had this to say in Investors Compensation Scheme v West Bromwich Building Society: ‘The law excludes from the admissible background the previous negotiations of the parties and their declarations of subjective intent.’
[4] Chartbrook v Persimmon Homes [2009] UKHL 38.
[5] [2010] EWCA Civ 912.
[6] [2010] EWHC 3276 (TCC).
[7] [2000] EWCA Civ 1296 (the Court of Appeal decision actually dates back to 1996). This decision is best known for determining that a contract for the supply of software contained an implied term that software should be reasonably fit for achieving the purpose specified in the ‘Statement of User Requirements’ in the St. Albans Invitation to Tender.
[8] [2010] EWHC 464 (Ch).
[9] [2010] EWHC 2525 (TCC).
[10] Central government departments do use the OGC model ICT services agreement, although it is often modified heavily by the departments and their advisers.
[11] Extract from clause 44.2 of the OGC model ICT services agreement version 2.3.
