UK: IT System Sales & Purchases: A Pretty Important Update

Plumchit Plc were sold on IT. They were convinced that a vast upgrade to their systems could integrate all their sites around the country into one centrally controlled administrative unit. That was well over a year ago. Now that installation is over budget and behind schedule. Plumchit’s Managing Director, is under pressure from his board, and he’s just been informed that, because of basic incompatibility problems, the whole thing will be delayed by at least another month.

After a heated conversation with his IT director, the MD’s patience is at an end. In a fit of fury, he reaches for his dictaphone…

Every major supplier of IT systems has been at the wrong end of a letter seeking to terminate an installation contract at one time or other. Every company that has overhauled its systems will have experienced frustration and difficulties, especially if they are replacing an old computer system that has suffered from years of abuse and mismanagement. But when things go badly wrong, 3 questions must be asked:

1. How can you prevent a complete breakdown in relations?
2. What can you do if the relationship does break down?
3. If you have to litigate, how do you win?

In the last year or so, the courts have considered a number of cases about installations, large and small. Whether you’re a buyer or supplier of IT, here’s how they affect you…

The recent case of Comyn Ching Ltd ("CC") v Radius plc ("R") involved the installation of integrated IT systems at a number of sites and covering several different businesses. CC realised that they did not know enough to choose a network themselves, but they decided not to employ an independent specialist to advise them. Instead they issued an invitation to tender describing their businesses and what they thought they needed. In their response, R offered to carry out a feasibility study, so that they could assess CC’s needs precisely. In fact they made this offer twice. Both times it was declined.

CC claimed that they contracted with R on the basis of statements made in R’s promotional literature concerning their expertise and experience, submitted with their response to the invitation. There was no written contract. A system was installed at one of CC’s subsidiaries. It was paid for and used for some time. Further systems were installed. It became clear that the new systems were not going to be integrated as CC had intended. CC felt that the whole point of the upgrade had been missed. They blamed R for not knowing exactly what was required and sued for breach of contract.

The Court found that there was no obligation on R to carry out what would effectively be a free feasibility study prior to the installation, particularly when they had offered to do so for a price. The Court expressly rejected CC’s contention that there was a duty on R to carry out such a study because they were bidding for a contract from which they would be well remunerated. It also found that the statements in R’s promotional literature were no more than "puff" which did not place on R any greater duty of care to carry out a study and produce a system design that would satisfy CC’s needs without reward.

The respective lessons are:

Are you sure that your customers know what they want when they ask you to carry out a major installation? Remember, they may have little or no familiarity with IT.

Have they made their needs clear? If they have not been advised by an expert on their requirements and passed that advice on to you, make sure you include a feasibility study as an option to your bid. At least if that offer is rejected they won’t be able to say you were to blame for failing to analyse their needs as a constituent part of your bid.

Above all, beware of overstepping the mark when bidding for the contract. There is a fine line between trade puff and overselling. If you cross it, you will find that the Courts have little sympathy for you.

Above all, make sure you know what you want. Your suppliers may be experts but they are not mind readers. If necessary hire an independent and experienced IT consultant to analyse and define your needs, then approach a number of suppliers and ask for firm bids.

Using IT jargon is dangerous The Court will assume that if you use IT terminology, you know what you are talking about. Recently we have seen such basic definitions as millennium compliance completely misconstrued in negotiations.

If necessary, pay a supplier to carry out a feasibility study, and tell them what you want in layman’s terms. Make sure in so doing, you do not tie yourself to that supplier.

The High Court laid down a number of implied duties in the seminal case of Winther Browne ("WB") v Anglo Group plc and others. It is likely that the courts will see these duties as fundamental in all future installations. The facts of the case are echoed in IT disputes around the country.

WB contracted with BML (Office Computers) Ltd for the supply of a comprehensive IT system, including hardware and networking, together with integrated ordering, invoicing and accounts software. The installation fell behind schedule, and there were a number of software problems. Confusion between the parties led to further difficulties. Eventually, WB decided that they had had enough. They terminated the contract. The installation having been mostly completed, WB went on to use the new system for some time until it was replaced by another supplier. WB stopped paying the instalments and when the finance company sued, WB blamed BML. WB also sued BML for losses arising out of the failed installation.

The Court decided that WB had not done enough to try to make the new system work. It laid down a list of duties to be applied to both parties which, if followed, should ensure the resolution of the problems that arise during an installation, save where the supplied system is really not up to the job. In applying those duties to this case, the Court came to the conclusion that WB had no grounds for repudiation, as it had not been deprived of the substantial benefit of the contract. It decided that WB had not clearly indicated its particular needs to BML, or made sure that BML understood those needs. WB had not devoted reasonable time and patience to learning to use the system, nor had they co-operated with BML to ensure that the problems experienced were overcome.

Reports suggest that the Australian taxpayer has footed a bill of Aus$17.5 million after a coalition of 19 universities (collectively known as "Unipower") terminated a contract unlawfully in similar circumstances.

Winther Browne raises the following points:

Make sure you know what your duties are, both expressly under the contract, and by implication under statute or caselaw. The Winther Browne duties are not one-way traffic. You must indicate clearly to the buyers whether your system can meet their needs in words they can understand. If there are problems, lay out constructive solutions as soon as they are available.

You must also make sure that the buyers are fully trained in how to use the system. This means the supply of the necessary training programmes both immediately and over the long term.

You must co-operate with the buyers in solving the bugs that arise – it is essential good practice to have buyers keep a log of all errors encountered, which you can then explain and update as those bugs are ironed out.

Most IT suppliers do not have to be told that computers are untrustworthy. One of our clients places more trust in his classic Mercedes than his systems. Take this to heart when embarking on a major project. Arrange regular minuted project management meetings with the buyers and keep full notes of events as they happen, particularly if the specifications ordered start to creep. These documents can prove very useful later.

Stockpile all the documentation produced, even though it might run into boxes. This doesn’t mean just the contractual documents and the spec sheets. Keep hard copies of just about everything, including e-mails. Such records will be essential in showing you are not at fault if it all goes pear-shaped.

Consider using a service level agreement. Negotiating such a contract will help the customer understand that there may be problems but that they can be reserved. Of course if the client is demanding, the price of the project may rise.

Stay on the ball. If the project is falling behind schedule, let the buyers know why, and what the revised timetable is. Most of all, don’t get distracted and let things slip when there really isn’t any technical reason for it. If there are problems, let the buyers know their nature. If they are serious, the buyers need to hear alternatives. If they are not, the buyers need to know that they can be fixed and when they can be fixed.

Are you sure they understand your needs? They may have technical expertise, but you are the leading expert on your company. Do not rely on drafting descriptions prior to any contact with an IT supplier, no matter how detailed they might be. Remember that when you are selecting a supplier, you may be dealing with a salesman. When you have bought into a package, you will be dealing with the technical people. You wouldn’t expect a GP’s receptionist to prescribe you antibiotics, so don’t expect a salesman to have all the answers, no matter how confident and experienced he sounds.

Do you understand what you are getting? It is all too easy to be blinded by IT jargon and led into thinking that the new system will put you on Easy Street. It won’t. You will still be working just as hard, there will still be IT problems, and you will still have to pay someone to sort them out.

Have you seen the proposed system working? Obviously there can be problems with this if you are working on a bespoke system, but seeing the package up and running makes all the difference. Bespoke system purchases should be broken down into contingent phases, using trials and pilot schemes. Learn from CC’s mistake. They thought they could reject the system if it failed to match their expectations when up and running. There is no substitute for spending an afternoon playing with the demonstration, and comparing it to others before making any commitments.

Do not skimp on the training. There is a great temptation to think ‘we can do without this expense if we muddle along for a couple of months’. The greater the change, the more essential the training.

Most importantly, things are going to go wrong – be patient! It sounds pessimistic, but there is a reason why programmers believe in chaos theory. Modern computers are so complex that an insignificant change to a seemingly harmless part can completely throw the ‘mission critical’ software. There will always be bugs after the installation. You are expected to co-operate while they are ironed out. Record the problems and correspond quickly. Don’t let the trail go cold. Point out the errors but avoid apportioning blame. If you are still unhappy, take independent technical advice and consult a lawyer before repudiating. If you think that’s expensive, ask Unipower.

Things haven’t been all good for the IT companies recently. The case of Pegler Ltd v Wang (UK) Ltd recently highlighted the importance of a carefully drafted contract. Wang were unable to deliver what they had promised so utterly that at trial there was no argument on the subject, and the failure was admitted. The argument settled upon the exclusion and limitation clauses contained in Wang’s standard terms and conditions.

In a two pronged attack on those clauses, the Judge first applied them strictly on their wording. Wang sought to exclude liability for consequential loss arising out of the supply or use of the software or services. No supply had been made, so the clause could not apply. A second clause imposed a 2 year limitation period, but the Judge dismissed this because the failure to supply was continuous. Wang were in breach at the time of the judgment as much as they were when the contractual completion date passed.

In the second prong, the Judge made a persuasive argument for the rejection of the clauses altogether. Wang had been guilty of substantially overselling their ability to satisfy the needs of Pegler. The nature of these misrepresentations was such that they must have known when signing the contract that there was a good chance they were not going to be able to come up with the goods. The Judge reached the conclusion that it was fair to restrict liability where the loss was unforeseeable, but to do so when those losses were likely was unfair.

On the other hand, it is dangerous to rely too heavily on the Court for protection from apparently unfair exclusion clauses. In the recent case of Watford Electronics Ltd v Sanderson CFL Ltd the Court of Appeal overturned the High Court’s decision that a term excluding indirect and consequential loss and subjecting all other loss to the amount of the price (conditional on a best endeavours clause) was unreasonable.

In Watford Electronics, the Court of Appeal restated the general approach to be adopted to these clauses as they appear in contracts between commercial parties. Where experienced operators of equal bargaining power negotiate an agreement, they should be taken as knowing what they are getting themselves into. Such business people are the best arbiters of what is reasonable. Lord Chadwick stated "Unless [the court is] satisfied that one party has, in effect, taken advantage of the other – or that a term is so unreasonable that it cannot properly have been understood or considered – the court should not interfere."

Learn the following lessons:

Things are going to go wrong, but it is usually impossible to tell just what the cause of the problems will be when entering in to the contract. It is only sensible to protect yourself with sensible exclusion and limitation clauses.

Make sure you know what your exclusion clauses mean. In all industries, rugs have been pulled from under feet by courts that have found these terms unreasonable. There is nothing to be achieved by sitting back smugly should things go wrong. These clauses are a last resort, not a fallback position.

Be aware of the consequences of overselling. If you doubt that you are capable of supplying as promised, the Court will reject your exclusion clauses. Overselling is rife in the IT industry, perhaps more than any other. But it is no good saying that everyone else does it so if you didn’t, you wouldn’t get the contract. A contract is personal to you and your buyer. If you can’t supply what you have contracted to supply, you will be at fault, regardless of your competitors’ abilities.

Have you read their standard terms? Do you understand the exclusion and limitation clauses? Blindly stumbling into a contract thinking you have found a bargain won’t appease your shareholders when you have to explain 2 months of lost production.

Take advice before you accept. You have to know where you stand should your supplier fail to deliver. If the contract is one of any weight, there will be an alternative, and even if there isn’t, it’s better to know where you stand should it all go south. At least then you will know what sort of contingency plans to make.

Get them to put their representations in writing and expressly incorporate them into the contract if possible. This is the best way to establish that the supplier has overstretched itself if need be. Draw out the specifics. Use layman’s language to be clear about what you require, and have your supplier commit to those requirements unequivocally.

Never, ever, enter a contract without anything in writing. Contracts negotiated through exchange of correspondence leave far too much room for doubt for such an important project. Consider also the use of service level agreements to govern the maintenance and performance of the new systems post completion. Finally ask yourself whether a supplier that won’t budge on strict exclusion clauses is really showing confidence in its abilities to satisfy your requirements.

The law is now clear on what it expects from both parties to an IT contract. If you take these lessons to heart you should find it possible to avoid aggravation. If the project still fails, these cases will at least help you identify where the fault lies, and all may not be lost.