RSS feedsIT projects often go wrong. On many occasions, the causes of the problems are misunderstandings between the vendor and purchaser over how the purchaser expected the system to operate.
The good news is that the law gives buyers of IT systems a good deal of protection. Expert IT professionals have a legal duty to provide their clients with good advice and, if they fail, they have to make good the difference out of their own pocket.
Unfortunately, these legal duties, known as ‘implied obligations’ aren’t always in writing, and so many buying organisations are not aware of the protection they have.
The way the purchaser specifies the system, undertakes the testing, constructs the implementation plan and negotiates the contract can have an effect on whether the legal protection applies to them or not.
The problem is magnified by the fact that vendors under pressure to close a deal can be tempted to leave certain things out of their pitch to a client. As Allan Watton, managing director of IT advisory firm Best Practice Group says: “The vendor will explain what it is going to do, but not point out what it is not going to do.”
For example, purchasers may not realise that there are things their existing system does that a new one may not. These typically surface six months into an implementation when the vendor could say that you hadn’t specifically asked for those things.
But as the law stands, the vendor is under a legal duty to anticipate problems and make the buyer aware of the consequences of decisions they do not even know they are making. “Where the vendor has expertise in a particular field, the vendor has a duty to warn the purchaser,” says Watton.
“Say a financial system arrived and it didn’t have a facility to produce a trial balance. In fairness, you might not put that requirement in your invitation to tender (ITT) because you would naturally expect it. A financial system cannot operate without one. It would be like buying a car and not specifying that you wanted wheels on it,” he says.
The vendor might argue that it sees a trial balance facility as an extra feature, for which it might charge. But if the vendor doesn’t tell you before signing the contract that it won’t include one and let you know how that will affect the system as a whole, it has a duty to provide one at its own expense - even if it wasn’t specified in the original ITT.
Case studies
This duty of care has been outlined in more than a hundred cases, but it was consolidated by one case in 1992 - Stephenson Blake vs Streets Heaver.
Stephenson Blake, a family firm whose managers had little familiarity with computers, was looking to upgrade its accounting systems. IT consultancy, Streets Heaver, made assumptions about Stephenson Blake’s business, which turned out to be wrong and the resulting system turned out to be unfit for purpose, even though it met the requirements set out in the original specification.
Streets Heaver argued that Stephenson Blake should have anticipated the problems, or, if it didn’t understand them, should have queried them before the contract was signed. It argued that Stephenson Blake, and not them, had responsibility for getting the system into working order.
The judge, however, disagreed. He felt that Streets Heaver was an expert in the field, and had a duty to “think ahead” and “think for” its client.
A similar case ten years ago -St Albans District Council vs ICL- closed a legal loophole and extended the law regarding contracts to cover IT vendors too. This law has been around for more than ten years, but companies still aren’t fully aware of it.
“The majority of purchasers aren’t aware of the duties of IT vendors,” says Watton. “Some IT lawyers are aware of them, but have never implemented an IT system themselves. So the advice they are getting may be good from a general co ntractual point of view, but it isn’t going to help the system go in on time and on budget.”
The implications for a vendor or contractor are obvious -assume nothing and make sure you make your customer aware of likely issues and the consequences these will have on the operation of the system.
For a purchaser there are many implications to be aware of, but the two which stand out are:
• Specify your business objectives and operational processes accurately. Although it is the duty of the vendor to think about what questions to ask, as a buyer, your answers have to be accurate;
• Specify your needs in business terms and in quantifiable objectives, not technology terms. Then, the vendor is obliged to make it work, not just to put in the software and equipment they proposed.
Bearing these in mind should help a project run smoothly enough that lawyers will never have to get involved. But if they do, at least the law will be on your side.
