Analysis: How to reject unfit software

A case study in why you should document supplier promises.

CIOs need to document the promises and representations made by IT vendors during the sales process, according to a legal analysis of a recent dispute in the UK.

In 2010, central London hotel Kingsway Hall successfully argued in court that an off-the-shelf hotel booking system it was sold by IT supplier Red Sky was not fit-for-purpose, and that it was within the hotel's rights to reject and replace it.

As one of only a handful of IT failures to not only end up in court, but also progress to hearings rather than being settled early in the piece, the Kingsway Hall case provides a rare - albeit incomplete - glimpse of where contracts can go wrong and what lessons can be learned.

The technical problems began a fortnight after Kingsway installed the booking software, recurring and escalating to the point where they eroded trust in the system’s outputs and the advantages the new system was supposed to deliver.

Months of conference calls and promised fixes did not eventuate. It ended with a solicitors letter rejecting the software and mounting a claim for losses that landed in court.

Baker & McKenzie special counsel Anne Petterd says the Kingsway case highlights the importance of clearly documenting representations made by an IT supplier and communicating them back to the supplier.

The judgment itself surfaces reams of documented references to faults and meeting minutes made by Kingsway.

“It’s [about] who has the documentation that they have kept from the tendering process to show that clear link between what representations were made [and] what was relied upon to enter into the contract,” she said.

Petterd presented the case study at the NSW Society for Computers and the Law last night.

Acceptance

The case raises questions about when a customer is deemed to have accepted a piece of software.

In Kingsway, the system went live in October 2006 but wasn’t formally rejected as unfit for purpose until mid-April the following year.

Petterd is unable to give a single answer on what stage of the software implementation cycle constitutes “acceptance”.

“To give you the unhelpful lawyer answer: it depends on what the contract says,” she notes.

“But that is the point, particularly when you’re buying off-the-shelf software - you need to be very careful about what is in the contract terms.

“In [Kingsway] there were formal provisions in the contract for the customer [to] accept. The customer seemed to be quite diligent in saying, ‘There are these problems and these problems. We haven’t accepted it yet’.”

Don’t ask...

Although the Kingsway judgment surfaces some evidence that the hotel sought product documentation for the system to be turned over once problems developed, a key issue in the case is that documents mentioned in the contract were never turned over to the customer.

A clause in the contract provided an express warranty that "the programmes will in all material respects provide the facilities and functions set out in the Operating Documents.”

However, these documents were never supplied before the contract was signed. The judge ruled they did not form part of the materials that Kingsway relied on when entering a contract.

“Without the manuals being supplied before the contract was entered into, it was not possible for potential customers to understand this and to make up their minds whether or not the system would be suitable for their needs,” the judge wrote.

While the omission undoubtedly assisted Kingsway in winning the case, the fact Kingsway did not ask for copies of the documents - despite the reference in the contract - sits uncomfortably with Petterd.

“Of the decision, it’s the bit that you’d really like to have been dealt with in some detail in the judgment,” she says.

Petterd sees this as a lesson for customers and suppliers.

“If something is referred to in the contract terms, customers need to chase it down. They need to ask,” she says.

“If it’s not clear from the contract what is being warranted, the customer needs to investigate further and check that their specific requirements are in there.

“Suppliers [also] need to be very careful if they are only warranting that their system will perform in accordance with operating documents or other documents. Then they need to be very careful assessing whether those standard documents match up to what the customer thinks is being represented as part of the sales process.

“They also need to give the customer the opportunity to review those documents prior to contract.”

Ironing out tensions

Petterd recommends resolving potential “tensions” around expectations early in the piece.

“We often have this issue with a customer saying, ‘This is what I wanted it to do’ and the supplier saying, ‘I told you it would work in accordance with the operating documents and you, the customer, needed to inform yourself about whether it met those requirements or not,” she says.

“But the customer might say, ‘I’m relying on you [the supplier] as the expert to tell me whether or not it will meet my business requirements’.

“You often have this tension between the expertise the customer is expecting the supplier to have, and the supplier saying, ‘I don’t fully know every aspect of your business. I’m an expert in my product but I still need you to take some responsibility’.

“A good practice message I’d be taking away from that is the parties need to engage on these issues prior to contract and make sure they have a clear meeting of the minds on what the customer expects the software to do and what the supplier expects the software to be able to deliver.

“If they are not able to do that prior to the contract, then they need to think about whether they build in a process to test that more after they’ve signed the contract.

“A bit more preparation activity early on might save them time later.”

Copyright © iTnews.com.au . All rights reserved.