Who's liable when complex projects go wrong?

Over the past couple of years we have seen a number of disputes involving complex implementation projects. These disputes often involve losses in the millions.

Over the past couple of years we have seen a number of disputes involving complex implementation projects. These disputes often involve losses in the millions and include the cost of business disruption, lost earnings and consultants that have been brought in for damage control.

Why is there such a high failure rate? Implementation of enterprise resource planning (ERP) systems, for example, requires the involvement and commitment of both the ERP vendor and the customer as partners. After signing the contract the customer is required to commit resources and to ensure that its business is completely immersed in the ERP implementation.

It is often this partnership of responsibility that leads to project failure. EB Baatz of CIO magazine has written that “the software, it seems, does work but that enthusiasm … sours in some cases because implementing the software requires people and processes to follow the ERP mandate – to integrate all of the major business functions – no easy, or inexpensive task.”

When implementations go wrong, the customer first looks at the contract they have with their ERP vendor. However, it is common practice for the vendor to exclude liability in certain circumstances and to limit the total amount that they can be held liable for to the customer. For this reason, customers have been looking outside their contracts for claims that they can make against their vendor.

The most common "outside contract" claim that we have seen is a claim for misleading and deceptive conduct under in the Fair Trading Act 1986. The way that a Fair Trading Act claim works can be illustrated with an example.

The customer tells the vendor what their requirements are for an ERP system in a request for proposal (RFP). The vendor answers the RFP by issuing a proposal that confirms that they can meet the customer’s requirements. The customer’s project manager then independently researches the vendor’s product and comes to the conclusion that the vendor’s product will meet their requirements. The customer then accepts the vendor’s proposal and the implementation commences.

During the implementation it becomes apparent that the vendor’s representation in the proposal was not correct.

Case law has established that for the customer to succeed in a Fair Trading Act they will have to prove:

1. that the vendor engaged in misleading or deceptive conduct

2. that the customer was actually misled by the relevant conduct

3. that it was reasonable for the customer to have been misled.

In the above example, step 1 is established because the vendor represented to the customer that they could meet their requirements. Step 3 is established as it was reasonable for the customer to believe that the vendor’s statement as to the functionality of the software was accurate.

The issue that the customer has with its Fair Trading Act claim is with step 2 above. The customer has not actually been misled by the vendor’s representation in the proposal. After the vendor made the representation, the customer conducted its own independent research and based on that research they decided to accept the vendor’s proposal. The Fair Trading Act claim therefore fails.

Another example where a Fair Trading Act claim can fail is where, in response to the customer’s RFP, the vendor’s proposal states that they do not currently have the functionality to meet the customer’s requirements but that the particular functionality is scheduled to be included in the next version of software. The next version is later released without the functionality.

In this second example, a Fair Trading Act claim will fail step 1 above because, at the time the vendor made the representation in the proposal, the vendor honestly believed on reasonable grounds that the representation was true. The vendor could only be held liable for a statement about a future state of affairs where the vendor knew that the functionality was not going to be included in the next version of software.

Although we have yet to see a successful Fair Trading Act claim for a complex implementation project that has gone wrong, we have seen a lot of activity in this area. We caution vendors to be careful about the statements that they make in their proposals to minimise the risk of being exposed to such a claim. One thing that is certain is that, despite the difficulty in proving a Fair Trading Act claim, customers will continue to pursue them.

Averill Parkinson is a partner and Emily Fuller is a solicitor in Clendon Feeney’s technology law team. This article, together with further background comments and links to other web sites, can be downloaded from www.clendons.co.nz. Questions and comments are welcome to averill.parkinson@clendons.co.nz.

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.
Show Comments