Suppliers are evil and their sales people are liars, making promises they can’t deliver so they can collect their big fat commission cheques. After all, suppliers have lost virtually every case that’s gone to court. Hardly surprising, when a judge is able to tell an audience of IT industry executives : “Do the Courts have it in for the IT industry? Yes. Because you deserve it.” How they lapped it up – treat them bad and they enjoy it all the more.
At the recent SCL 30th Anniversary Lecture, Richard Christou (Chief Executive of Fujitsu Services and himself a distinguished lawyer and author) advocated a positive recipe for IT contract negotiations. He told his audience that they should not regard themselves as hired guns, but should think of their role as ambassadors, negotiating a workable treaty that will benefit both sides. Christou went on to say that lawyers focus too much on form, and not enough on substance. His reasoned analysis met with no dissenting voices. It’s not very long since the author described a contract as being ‘fair and balanced’, only for the purchaser to take offence. They wanted a tough contract, negotiated by tough lawyers. This article examines the substantial gap between what lawyers say, and what they do.
A shift in the balance of power
Lawyers don’t work in a vacuum. We operate in a market that has changed out of all recognition in the last few decades. Technology is no longer a ‘black art’ – it impinges on every aspect of our working and domestic life. The recognition that technology is a foundation of modern business has led purchasers to take IT contracts more seriously. Purchasers have got smarter, and they’re not prepared to have sand kicked in their face by signing suppliers’ standard terms of business. In particular, the public sector has blazed a trail, committing billions of pounds of tax-payers’ money in pursuit of better public services. In return, they expect tougher contracts.
This points to an inexorable shift in power towards purchasers, aided and abetted by thousands of IT lawyers and purchasing professionals. Yet this shift creates a new danger of one-sided, unbalanced contracts. This makes the lawyer’s role critical.
The lawyer’s role – hired gun or ambassador?
Too many lawyers spend too much time on boilerplate, and too little time working on schedules. Is it a good use of our clients’ time and money that we can spend 3 hours debating the phrase ‘mutatis mutandis‘? That little debate put another £2,500 of professional fees on the meter, and left clients bemused and angry. Couple this with the dreaded page turn, and we begin the long descent into boilerplate hell, only to emerge in the last few days before contract signing to demand that our clients prepare several hundred pages of schedules. No wonder people hate us.
In truth, clients rarely litigate over boilerplate. They do litigate over missed deadlines, defective software, cost overruns, and poor project management. In other words, about what, how and when it was to be delivered, and how much it was going to cost. Where is all this described? In the schedules. Let’s examine the reality gap between many standard provisions and their usefulness in practice.
The requirements trap
“The Supplier agrees to provide the Developed Software so as to meet the Client’s requirements as set out in the Statement of Requirements.”
Good procurement practice dictates that potential purchasers produce a requirements specification, describing what system or service they need. These may run to dozens or even hundreds of pages. There are many benefits to writing a requirements specification, not the least being that it forces the buyer to think about what it wants, and to create a baseline against which potential suppliers can respond to an Invitation to Tender or Request for Proposals. Very often, the specification is presented as a table. This enables potential suppliers to respond against each requirement, indicating whether their proposed solution meets the requirement in full, partly, or not at all. There is also scope for suppliers to explain how the proposed solution meets the requirement. For example, there may be a requirement for ‘full management information’ to be available from the system; the supplier may indicate that the requirement is met by using a report writing tool such as Crystal Reports.
The problem arises when the purchaser insists on including the requirements specification in the contract. This is understandable when one considers the time and effort involved in writing it, and the fact that it played an essential part in the selection process. From the supplier’s perspective, it creates significant risk. Requirements are often broadly expressed, to avoid dictating the supplier’s solution. The supplier’s solution is typically based on a set of products where implementation could involve substantial changes to the purchaser’s current procedures. The supplier tries to exclude the requirements specification from the contract, and to have no specification at all, or to warrant that the products will meet their published specifications in all material respects.
There is no easy answer to this one. If the purchaser has sufficient understanding of the products as a result of demonstrations, site visits and inspection of the supplier’s documentation, then it may accept the supplier’s documentation as being the baseline against which the supplier must deliver. If that is not the case, then the alternative is to incorporate the requirements specification, together with a description of the supplier’s proposed solution.
The implementation black hole (aka the ‘happy project’)
How often are we asked to review a software licence and maintenance contract which makes only passing mention of implementation services? Lawyers often forget that many software products are useless without an implementation project. At the most basic level, this could involve no more than setting up user names, data entry, training, and creating reports. With more complex products, there could be man-months or man-years of project management, consultancy, data migration, product configuration and customisation, testing, and creating interfaces to other systems.
It seems odd that something so fundamental can be overlooked. One explanation is that suppliers rarely wish to highlight how difficult, time-consuming and expensive it is to implement their products. The author has fond memories of reviewing a £1 Million professional services contract. On querying the salesman about the one-line description of the services (“implement subscriber management system”), he was told: “What’s the problem? This is a happy project.” Reading between the lines, I was a sales prevention officer who stood in the way of him collecting a £70,000 commission cheque. This is where a customer is at a distinct disadvantage, as they may have little or no knowledge of how to implement the supplier’s products.
As a minimum, one would expect an outline project plan to be produced in time for contract signing (although this might need to be refined post-contract, in the light of more detailed discussions), together with a table showing the customer’s and supplier’s respective responsibilities. More sophisticated suppliers often have a standard implementation guide, which can be tailored to suit the needs of a particular customer.
Transferring the risk of wrong or incomplete information to the supplier
“The Supplier acknowledges that it has carried out a due diligence exercise to satisfy itself of the nature of the Customer’s requirements specified in the Service Description and that the Customer has relied on the Supplier’s expertise as an experienced provider of IT services in carrying out due diligence exercises. The Supplier has all information, rights, hardware, software and facilities necessary to enable it to agree the Charges for the Services. Accordingly, no additional charges may be made in relation to the Services other than in accordance with any express provision in this Agreement or through the Change Control Procedure.”
Worried that the supplier might come back and ask your client for more money when they find out that the information on which they based their price is inaccurate and incomplete? Then turn the tables on them, and get them to warrant that they have carried out due diligence.
There are two kinds of suppliers – the smart ones who try to cover the risk by building contingency into their price (but risk losing out to more stupid competitors), and the stupid ones who take the view that it will be all right on the night. As the stupid ones don’t have any contingency in their price, guess which one the customer is more likely to pick?
We can help our clients to get a better price by stressing the link between information and price – the better the quality of information provided by a purchaser (especially on outsourcing deals), the better the price. There’s also an opportunity for lawyers to generate extra fees by helping to construct data rooms which will be needed for due diligence.
Acceptance testing – boilerplate vs. reality
We are all familiar with boilerplate wording that provides for the customer to test the software, and to reject it if it fails repeat tests. But what are the criteria for acceptance? Will the testing merely cover function, ie does it function in accordance with an agreed specification (assuming there is one)? Or will it cover performance, such as transaction response times and batch run times? How will testing take place? Will the customer use tools, such as TestDirector, to create test scripts and to log the results? Will the customer use LoadRunner and WinRunner to simulate performance? Who prepares the test environment and test data?
In many cases, boilerplate creates the illusion of process where there is none. Or the boilerplate fails to take account of phased deliveries of software.
The answer is to spend more time discussing this aspect with the client, and to modify the boilerplate accordingly.
The gain share myth
“The Contractor and the Authority shall carry out their respective responsibilities for the sharing of gains as set out in Schedule 9 (Gain Sharing).”
Cost reduction remains the primary driver for the majority of outsourcing deals. Part of the supplier’s sales spiel may be to promise that the customer will share in the cost savings achieved by the supplier. Indeed, the supplier is often better placed to achieve economies of scale, by locating servers, help desk facilities and communications equipment at shared service centres from which they can provide services to many customers. They may introduce tools to enable them to manage the desktop environment remotely, cutting down on calls to the help desk (which in turn, allows them to reduce the number of people working on the help desk). Their size may give them unrivalled buying power when dealing with the likes of Microsoft, ORACLE and Computer Associates.
This type of provision only makes sense when there’s an agreed financial model against which savings can be measured. In most cases, the promise to share the savings is little more than an aspirational statement, as there is little or no way of measuring the savings. If it can’t be measured, what’s the point of including it?
The escrow myth
“The Contractor shall lodge a copy of the source code of the Software in escrow under standard terms with the National Computing Centre, and make new deposits of the source code as appropriate, to take account of new releases and versions of the Software.”
So now your client has got the million lines of source code out of escrow, what do they do with it? Answers on a post card, please.
The consequential loss myth
Professional indemnity insurance does not cover consequential loss, so suppliers exclude it because they don’t want to accept potential liability for uninsured losses. Wrong. In general, insurers require the insured to take reasonable steps to limit and exclude their liability. They review standard terms of business before granting cover, and expect the insured to check substantial changes before contract signing. In the author’s experience, insurers have a sophisticated understanding of the complex case law in this field, and appreciate that an absolute insistence on excluding consequential loss may be ineffective.
The way forward
How do we lawyers break out of the boilerplate mentality? We begin by educating clients about the lawyer’s role, which is to help our clients to craft deals that are workable for both sides. Certainly, advice on risk is part of our job description, but we’re missing the point if we think that the balance of risk can be managed through boilerplate clauses alone.
We can start by asking our clients the simple questions:
§ what are you buying?
§ why are you buying it?
§ how will it be delivered?
§ how will you measure whether delivery has taken place?
§ what do you perceive as the key risks?
§ how much will it cost?
§ when will it be delivered?
§ what do you perceive as your responsibilities?
§ how will you and the supplier work together?
These simple questions usually result in deceptively complex answers. Nevertheless, we need to make the effort to understand those answers. This may involve reading a business case or an Invitation to Tender, and the supplier’s tender or proposal. We might need to inspect project plans and specifications. We shouldn’t be embarrassed to ask for explanations. After all, the client’s staff may have been working on the project full time for many months.
We can check at the start of contract meetings that the supplier has the same understanding of the deal as we do. Whiteboards, flip charts and heads of agreement are all useful tools for establishing a common understanding of the fundamentals of the deal. We can also help to create a timetable and process for negotiating the contract, so that schedules are populated in good time.
And we should remember the wise words of John Paul Getty:
“My father said – You must never try to make all the money that’s in a deal. Let the other fellow make some money too, because if you have a reputation for always making all the money, you won’t have many deals.”
John Yates is the Chief Executive of v-lex limited, a niche technology law firm. John is also Joint Chair of SCL.
