Securing the right IT contract

IT 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.