The theme of my lecture was change – but while I also looked then at change in technology and change in legal practice I want to focus now on changes in IT contracting. Of course, those changes are the product of other changes – and especially changes in the technology which they address.
I characterise IT technology as complex, swiftly changing – it is changing all the time – and extraordinary. It is extraordinary in a way that many of the other technologies that we have nowadays are not. Of course there have been changes in other forms of technology but those changes are largely evolutionary, from technology established in the first industrial revolution. Information technology is something completely different.
From Rarity to Ubiquity
The principal change in IT technology is from rarity to ubiquity. Computers are everywhere nowadays. Even up to 1974 when the Society started, we were mainly looking at mainframes. Cumbersome animals compared to what we have nowadays as mainframes, with very much lower capacity. 1975, of course, is when Microsoft started and, in 1976 Apple; so it is from those times that you can see the start of distributed systems. In the 1990s, networks took off and led to the Internet. In the new century we have the growth of mobility – I think we’re only now seeing what mobility can do for us. And the important thing to remember is each stage was additive. All of the previous ones are still around – for example, we still rely on mainframes to a huge extent, no matter what people tell you about client/server. All of these things – mobile, client/server, mainframe – are interacting together and that makes for a very complex environment.
In 1974, we had scarce technology, supplied by experts to experts, and used by experts. There was a close link between the IT vendor and the IT department. Whatever they used to get up to, nobody else really understood what was going on. The vendor would go in and deal with the IT department (the people in white coats behind the closed door) and the rest of the organisation had to hope that somehow it would all work out. The change in technology has driven the change in contracting. Today we have ubiquitous technology, many different channels of supply and many different ways that it is procured. But the most important change is that this technology is used by everybody in their everyday life at home and at work.
In 1974, you were looking at single-vendor proprietary systems, hardware and operating systems, with support probably bundled at the beginning. There were not many proprietary application packages in the sense we see them nowadays. Any proprietary package was likely to be tied to the particular mainframe technology. A lot of applications were developed in-house by in-house IT departments in organisations such as large government departments and the large banks. Computing was an elite profession, something completely separate. Even the users were a breed apart – specially trained and understanding things that, frankly, were not user-friendly in the terms that we think of them today.
Computing and computer purchasing was something completely different to what we’re used to today. Most of the contracts were by product description on standard terms and conditions. It was almost impossible to change one word of the standard terms and conditions. Negotiation was basically about price or forms of financing, or both, and people did not really understand the concept of total cost of ownership. There was very little visibility on this. You simply bought the equipment for a price and then, whatever it cost, you paid the in-house IT department to run it. Little thought was given to how much value was added to the business. People talked about efficiency or cost saving but it was not really added value that was in people’s minds.
In 2004 a lot has changed. First of all, I think there’s been a division in the different ways one contracts. I divide this into large-scale contracts, contracts for the small and medium-sized enterprise and the middle market, and then contracts affecting consumers or home office users – mainly very small single users.
Large-scale Contracts
In large-scale contracting, the purchasers have certainly become more sophisticated. I think that, simply by the passage of time, people have understood more about what computer contracting is all about.
Mix and Match
One of the big changes is this business of best of breed, or mix and match, which was coming into contracts probably from the late 1980s and onwards. ‘Proprietary’ became a dirty word, along with bundling, and people really felt it was synonymous with ‘rip-off’: “We don’t want proprietary systems, we want to be able to mix and match, pick our own things, deal with the components”. I do not think it was always justified but there was a general perception that the proprietary vendors had ripped off people for many years and the chance to get revenge was there for the purchasers when open systems arrived.
It is debatable whether the technology came first or the desire for it came first; but, however it worked, you can see in the 1980s all of these niche companies emerging which enabled people to mix and match. If those companies had not come along, open systems would not have become the fashion.
But, as all in the business know, open systems are never actually quite so open as they are advertised to be. Because of that it is not easy to put all these components together and end up with a system that is as efficient as a proprietary system. They may give you more freedom of choice but it is more difficult to integrate and because of that we now see the rise of the system integrator or the solution provider: “If it’s too difficult for you, I’ll take responsibility and put all the bits together”. This led to two modes of contracting. One is where the system integrator supplies the solution and puts it all together. The second, which still exists but certainly existed to a much greater extent in the past, is where the purchaser deals with system integration itself via its internal IT department; these purchasers still largely buy on product description.
The big question in this sort of contract is: who takes the system risk? If you don’t know that, you’re headed for disaster and many of the large contracts that I have seen go wrong have a kind of hybrid nature – and it is a dangerous hybrid.
You start off with the supplier saying, “I’m the system integrator and I’ll do it all” but gradually, whether written into the contract or not, you see the purchaser taking over by a kind of almost creeping extension into the contract. First of all they say, “Well, let’s have a look at the design”. Then they want to give some comments on the architecture, then they’d like to check whether your components or the elements of the system are really up to it. Finally, they want to break it all down and look at the pricing and tell you what the specification should be; by the time you’ve finished, you’ve got split responsibility. So, the IT department ends up telling the supplier what to do but the supplier has the responsibility if it goes wrong. Now, I’m not saying that all contracts of a hybrid nature are like that but that to me is the root cause of many of the disasters that we’ve seen. Split responsibility is a bad thing.
I would maintain that, if we’re going to have two good modes of contracting, we either need to stick to the system integrator outsourcer, who delivers the solution, or we go to the old-style product procurement and let the purchaser do it, in which case the purchaser with a large internal IT department takes the system risk. The latter is still more fashionable in the private sector (particularly with large financial services institutions) than it is in the public sector. That seems to me to be the way large contracts are going, but I think there are some current trends that I would like to draw to your attention.
Output Contracting and Business Change
First of all, this system integration game is becoming more and more complex and difficult to do properly, particularly when you add bespoke software on top of it. Purchasers are finding it more difficult, even if they have large IT departments, to cope with system integration. They do not have the breadth of experience in many cases. Purchasers, partly because they’re waking up to what’s important but also partly because they can’t handle the system integration risk, start to become concerned with outputs. I think we are moving towards output contracting.
Purchasers worry about total cost of ownership. They want business change out of these contracts – they’re not content to computerise existing processes. One of the symptoms of poor contracts is contracts which simply computerise what you are already doing instead of looking at what you ought to be doing and then working from there as to how you computerise it. Cost reduction has not become less important – cost reduction is taken as a given. The purchasers want more for less in the current environment but that is not the primary purpose of the contract.
Now, the consequence of this – which I have observed over the last couple of years – is that purchasers are becoming less concerned about vendor independence. If you don’t worry about the components of the system, why do you necessarily care where the components are sourced from? You may say, “Well, I want to be sure that they’re cheap” but as long as the total cost of ownership of the whole system is cheap and you can work out what you think it should cost, just as much public sector contracting is done on the basis of a should-cost model, why does it matter? This is something that the system integrators should be left to deal with by themselves.
The purchasers should be concentrating on the real issues: Will the solution work? Will it be flexible enough to deal with the future problems that may happen? Will it deliver on my change agenda – the way in which I want to change my business processes? If you go down this route, it imposes a great deal of responsibility on system integrators or outsourcers to deliver. The response of purchasers – and those of you who act for purchasers will be either instructed by them on this or even aiding and abetting them with this – is to impose increasingly harsh contract terms to punish vendors for failure. You may say that, given my point of view, this is special pleading but I genuinely believe that it is no use the purchaser loading all the risk onto the supplier and having horrendous penalty or damages clauses (strictly penalties may not be enforceable – I have to say some of the damages clauses look like penalties to me) and sitting back, hoping that somehow it is all going to be all right and the supplier will deliver – if not, “well, we’ve got the damages”. The usual result of such an approach is long and costly disputes with uncertain outcomes; nobody wins at the end of these disputes.
I do not believe that these harsh clauses are necessarily an incentive to deliver, because many of the people who are actually delivering, the people on the ground, don’t understand the consequences of these clauses. Furthermore, damages are no substitute for having an effective system. The opportunity cost of the failure cannot in most cases, particularly in the public sector, be compensated for by damages.
Recipe for Good Contracting
So, what is my recipe for good contracting?
First, you must clarify the output required at the beginning. People often rush into contracts without actually deciding what the output is that they want, and very often they do this without knowing whether the output that they want can actually be achieved. More time spent on feasibility studies and pilots up front, even if it delays the end delivery date, is time and money well spent. I am very keen on adequate preparation before you get to final contract.
Second, allocate the risk to the party that is best able to manage it – and different risks are best managed by different parties – and then leave that party to manage that risk without interference. Make sure that the contract is flexible enough to allow changes to be baked into it as the contract progresses. This is particularly true with multi-year contracts. I characterise this as the virtuous circle.
If you think about business processes and technology supporting them, it is clear that there’s an interaction between business process and technology. As the technology changes, it can either force business processes to change or it can open up opportunities for business process to change, and this goes both ways. So, if I want to change my business process, I can go to the information system provider and say, “Please change it in a way that supports a different process”. Alternatively, if I – as the infrastructure provider – have new technologies, new things that I can do, I can go to the process owner and say, “Look, this is what my technology can do, is it useful to you?” Or, if I understand the business sufficiently, “This is what my technology can do, you should change your processes to take advantage of it because there is this added value coming out of it”. This exchange goes round and round between the business process owner and the IT infrastructure supplier in a kind of virtuous circle. The result should be that the contract changes as business needs change and as the capability of technology changes. You need to be able to have mechanisms in the contract that enable you to take advantage of this virtuous circle, because that is how added value is delivered to the business of your clients.
Now, that’s idealistic stuff but if you want to get down to real mechanics one of the most important things is frequent monitoring of progress. You need milestones of some sort and you need to monitor as you go along. You cannot leave it until the end. Frequently – not as a lawyer but as a chief executive – I get hauled up in front of customers and they fix me with a steely gaze and they say to me, “Are you committed to this contract?” I say to them, “Yes, sure I’m committed but don’t ring me up the day before it’s due to deliver and tell me that the whole thing has failed. Nothing is going to happen because it’s too late for me to fix it”. So, what I normally do in those circumstances is I say, “That’s fine, let’s have regular reviews of milestones so that we both know in advance whether something is going wrong and we’ve both got time to do something about it”.
Another thing that I require – and this is something which I would recommend that you have in your contracts from the beginning – is an end-to-end programme plan. This may sound like a matter only of concern to a project manager and nothing to do with lawyers, but it is a lawyer’s concern. End-to-end programme planning is a listing of both customer and supplier dependencies – what actions has the customer got to deliver, what actions has the supplier got to deliver. Both sides have to be contractually committed to deliver the things that are required for successful delivery of the project. If only the poor supplier is nailed down and the customer has no commitment to deliver on the things the supplier needs, the supplier will not be able to deliver anything. Similarly, if the supplier is only loosely tied down, the customer has got no means of dealing with creeping delay effectively because the supplier will not be in breach until you get to the end date. Customers might worry about it but they can’t do very much about it. End-to-end programme planning baked into the contract with the dependencies on both sides is thus very, very valuable in my view.
My final recipe ingredient has got nothing to do with the law. But take it from me – strong project managers on both sides are absolutely vital if you’re going to get these contracts delivered. You cannot do it without them.
Middle Market and SMEs
I do not think there’s been a lot of change in this area, except that the middle market has appeared. But in a sense it has taken over the ground vacated by the large-scale contracting market. We have packaged solutions or systems, often quite small, usually with proprietary software for common business applications, accounting packages, HR, databases, word processing, e-mails and so on. These normally sit on standard hardware. You can do a little bit of networking to link them together in your office and they are sold very often on standard terms and conditions.
I do not think it is a market that is properly addressed either by IT suppliers or by the customers in the market. I think that at the lower end the customers in that market are not properly exploiting the opportunities that are available for IT to add value to their businesses. I think it is a difficult market and there are suggestions that things like utility computing or grid computing will come along and make a difference. I think it will, in due course, but we have to see exactly when that’s likely to happen.
Small-scale Contracts
Consumers are still pretty unsophisticated in many ways in what they buy – but they are growing in understanding. The European Commission decision (Re IBM PC) in 1984 allowed a selective distribution system for computers – strange new consumer goods – based on the need to have really carefully trained technical staff who could explain everything about PCs to consumers. Now you go into X, the shop shall be nameless, and you’re lucky to find an assistant. You have to fend for yourself and really, as far as I can tell, selective distribution systems for the lower end of the market really don’t exist any more. Anybody who fancies can sign up as a distributor.
Two Closing Reminders
Let me conclude with two reminders that are central to effective contracting.
My first concerns the importance of understanding user needs. What you have nowadays is a kind of eternal triangle, particularly in large contracts. The vendors are at one apex, IT procurement are at another and at the third are the users. These users are no longer a secret branch of the profession trained in its mysteries, they are you and I and everybody else who works in the organisation who has a PC on their desk. They have expectations, which sometimes the vendors and the IT department don’t understand or can’t deliver on under the terms of the contract. When these three drift apart then you start to get the problems. It is very important for purchasers to understand what the users want, and to make sure that vendors understand it too, and it is important to ensure that users are part of the “contract constituency”.
Another factor is the importance of user training. Everybody here thinks they know how to use a PC, including me. The truth is that nobody in this room uses anything like the full capacity of their PC. That may be because you don’t need to but in many cases it will be because you don’t know how to. Formal training, particularly when putting in large new applications, is something that should be part of every contract – that’s very important.
Question Response
In response to a question from the meeting’s Chairman, John Yates, about what advice Richard Christou would give to lawyers on avoiding the trap of producing contracts which are over-engineered.
Partly, as lawyers, you are bound to the instructions of your client. So if your client insists on a particular course you can advise against it, but at the end of the day you either have to implement it or decide that you don’t want to represent them. I can understand that. But you should not regard yourself – and this is true for any contract, it is not just about IT – as a kind of hired gun. Lawyers shouldn’t think of themselves as going in to drive the hardest possible bargain for whatever side they are on.
I think of lawyers almost as ambassadors. Their purpose is to get the two sides to an agreement which is workable for both sides – a treaty, if you like. The only agreements that survive the test of time are those agreements which benefit both sides. If you forget that then you’re actually not doing your client a service. Now, it doesn’t mean that you’re soft on the other side but you have to realise that there is very often a middle way in some of these areas.
The other thing that arises is something I can mention because in my new role I get impatient. If you look at the process from outside, it seems to involve focussing on minutiae – on many things that most people who aren’t legally qualified wouldn’t understand.
You sit round the table and turn the pages and somebody argues about this word or this comma or whatever. It is important to get the drafting right, nobody would say that more than I would, but I do think that sometimes lawyers concentrate too much on the form as opposed to the substance. Tackle the most important issues – and perhaps don’t be like a dog with a bone over some of these things that really don’t matter. If you can’t do it because you’re worried about the professional indemnity policy – and I can understand that too – then it is important to give advice to the client in a way that allows them to grasp what the essentials are.
Don’t make every negotiation adversarial. The purpose is to get an agreement signed, not to have a fight.
Extraordinary IT Lawyers
Elsewhere in his lecture, Richard Christou sought to identify IT law and reflected on the qualities and role of the IT lawyer.
The real thing that is special about IT law and IT lawyers is that if you don’t understand this extraordinary technology you can’t apply the law to it and you can’t see how to deal with the various issues. I’ll give you three examples. Lawyers and judges in the Technology & Construction Court can’t deal with the dispute if they don’t understand what the expert witnesses are saying (and some of the things that they say are pretty opaque if you’re not familiar with the technology). You can’t draft licences if you don’t understand the capabilities of software, particularly how easy it is to copy it, transfer it and so on
You can’t deal with licensing on the Internet if you don’t understand how the Internet works. For instance, it’s all right to forbid reverse engineering but if you don’t understand what it means in the context of a software programme, it’s not easy to write the proper clauses. Third, how can you draft an outsourcing contract if you don’t actually understand the technology being outsourced – the pitfalls, the risks, the exposures and the desired outcome?
My idea of an IT lawyer is a technically-knowledgeable lawyer who can apply ordinary law with some – admittedly some – computer law in a practical, commercial way to this extraordinary technology.
You need extraordinary lawyers who can understand the technology, and thus apply the law to it correctly. That is the strength of this profession of IT lawyer. Both customers and suppliers need people like you to bridge the gap between them and to help them to realise the benefits of this technology. I do not minimise the importance of your role because if you do it well and properly understand exactly what this technology can do and how the law should apply to it, you can make the difference, in many cases, between success and failure in these projects.
