ITP Techblog

In recent years we've been involved in resolving a number of tricky disputes arising from ICT project failures - usually acting for the customer. It's unsurprising really - ICT projects have a pretty high rate of failure in terms of the customer getting what they are expecting, on budget and on time. These projects are often complex and costly, can involve lengthy procurement processes and implementations, and can have significant business impacts if the project goes off the rails.

Much has been written about what causes ICT project failure. Many frequently identified causes relate to early stages of projects e.g. ill-conceived business cases, rushed procurement processes, poor vendor selection and insufficient allocation of customer and/or supplier resources. However, identifying these causes after a project is already failing is not necessarily very helpful to people who find themselves having to manage the failure (often not the same people who began the project).  

That's not to say that if you find yourself having to manage a project veering off course there aren't things you can do (or avoid doing) to better protect your position from a legal perspective. We regularly see these common mistakes:

1. Ignoring the contract:  This can begin before the project starts to fail. It isn't uncommon for parties to sign a contract and then put it in a drawer and ignore it. The parties do this at their peril. If you don't exercise your contractual rights, you risk losing them and it can be really difficult to identify what the parties agreed if they've behaved as if the written contract doesn't exist. Provisions requiring contract variations or waivers of rights to be agreed in writing won't always be effective, so you may not be able to fall back on "but the written contract says…" if you've acted inconsistently with the written terms. If the written contract doesn't fit the way the project actually is going to run (e.g. it reflects a waterfall development but everyone then decides to use agile), it's worth taking the time to vary the contract in writing at the time you start to veer away. If disputes then arise, you're likely to be better off if you adhere to the contractual processes.
2. Lack of transparency: When a customer is unhappy about supplier performance, there can be a tendency not to "rock the boat" until it is obvious that the project is not going to be delivered according to the contract. By the time the parties start discussing the problems, the customer may have already lost confidence in the supplier. The supplier may be genuinely surprised or may have a very different view on why the project is failing. This can make resolving disputes much harder. A "softly, softly" approach is sometimes sensible but it needs to be balanced against ensuring that the supplier has a clear understanding of the customer's concerns and the contractual steps the customer may take if matters don't improve.
3. Failure to identify customer actions: Sometimes projects fail because the supplier simply isn't up to the task. Often the reality is more complicated and both parties could have performed their obligations better. Being unhappy with your supplier doesn't always equal a breach of contract.  Even if the customer has met all its contractual obligations, there may be actions that a customer can take to pull the project back on track that are less costly than simply leaving the supplier to do it alone. Identifying what the customer can do is important from a legal perspective - in most cases the customer will be under a legal obligation to mitigate its own losses and sometimes in practice it will need information from the supplier to identify what the best mitigation steps are. The trick is how to identify the right steps without accepting accountability or liability and without waiving the customer's existing contractual rights. This is one of the reasons why it is useful to get a lawyer involved early on; customer "mitigations" can then be accompanied by appropriate reservations of the customer's rights.
4. Rushing to a resolution:  It can be tempting to rush to sign a new or amended agreement to get a failing project moving again as quickly as possible. We see short letter agreements, email exchanges, or high-level principles documents - often well after they have already been agreed and sometimes part-performed. We also see disputes where the parties have changed course but nothing has been agreed in writing at all to reflect the change (see above). The parties have simply had a meeting and noted a series of actions in the minutes. It's important that important oral conversations are recorded in writing and any written record is well-drafted and signed. If this doesn't happen, there is a real risk of simply adding to contractual uncertainty - particularly if the parties are already in dispute about the scope of their respective contractual obligations. 
5. Not knowing when to cut your losses:  Sometimes failing projects can't or shouldn't be resurrected. Recognising when to persevere and when to terminate is a challenge. If the parties do agree a set of actions to deal with a failure but can't be certain they are going to work, the customer should preserve rights to terminate and have a plan about when and how the effectiveness of those actions will be tested and, if the actions aren't working, how an exit would then proceed. 

Even with the best intentions, some projects go off the rails. Involving a lawyer relatively early on and treating the parties' contract as a meaningful project document may help to get through the tough patches.

Amy Ryburn is a partner in Buddle Findlay's ICT practice. She really loves her job. When Amy's not at work, she can generally be found hanging out with her husband and trying to keep up with her three small children.