In this series of articles, we overview some of the issues that we addressed at the New Zealand Law Society’s May 2015 IT and Online Law Conference.
In Part 6, we finish by discussing what is important in ICT B2B contracts, as the devil is often in the detail, and the all-important detail is often in the schedules. We provide various examples of some of the issues to watch out for.
We’ve also collated a bibliography of our most relevant articles for this series.
What is important in ICT B2B contracts?
When we advise clients on what to do when their ICT contracts turn pear shaped, often the big issues aren’t around what we lawyers might naturally navigate to, such as the limitation of liability and ways to defend it (or crack it).
For example, most customers want to get the job finished, one way or another, far ahead of recouping losses. Maybe they want to ensure that the supplier finishes it, or maybe they want the supplier to help in transitioning to a new provider (which is an area rich with problems and difficulties).
Often, they wish they’d had some things better stated from the outset. For the lawyers, there is no substitute for understanding what the project is about, and figuring out what is important from that. Looking at boilerplate features, such as LOL, often misses the point. The devil is often in the detail and the all-important detail is often in the schedules.
We can’t really summarise all of the points to watch out for, as the issues can be quite fact-specific, but they can include:
- For a long time, the ICT industry has used a so-called “waterfall methodology,” picked up from bricks and mortar building contracts. The contract starts with detailed requirements and trickles down the waterfall through specifications, statements of work, implementation, and so on. The trouble is that in a high- rise building, from the outset the architect knows exactly where the loos on the 8th floor will go, but the zeros and ones equivalent of the loo rarely end up in the same place. Thus, waterfall ICT contracts that purport to cast in stone the way that things will go, can be illusory and will mostly change. It is good to know this when drafting and reviewing the terms. Assume that change, and likely big change, is probable. Hence, a major trend to other ways of contracting and developing, such as agile. See our article, Legal insight: the wrong development contract.
- As noted above, having robust transition arrangements that require suppliers to help a move to a new supplier will be valuable for customers. Often though, these arrangements will be recorded too briefly to be workable in practice. This is an area to focus upon.See our article, AstraZeneca and IBM show the way on transitional obligations in ICT contracts.
- A priority clause, by which the boilerplate trumps the schedules, should not be relied upon in isolation, for most issues in the schedules are stand-alone and no priority and uncertainty issues arise, a point well made in a recent UK case; see our article, Unexpected trap in contract terms prioritising contract.
- SLAs, especially those with payments to be made, are mainly tools that limit the suppliers’ exposure; the payments to be made for breach are typically miniscule, and they can cap the liability on the particular issue. However, customers often see them as tools to strengthen their positions.
They can be, and they can have a coercive effect, whatever the legal position, but they are usually not overly customer friendly. For more detail see our article: Service Level Agreements – are they worth it?
- Cyber-security and related issues such as privacy are increasingly central to organisations’ risks, and such issues should be contractually addressed. This is a big contractual issue, in addition to raising other issues. All ICT contract reviews should consider cyber-security issues, including as to data protection and privacy. We’ve recently written on the role of General Counsel, CEOs and boards in this regard:
Click here to view image.
Click here to view image.
- The dispute resolution mechanisms can be more powerful than they appear at first sight, both informally (e.g. escalation paths during BAU to the right people in the supplier’s organisation) and after a dispute arises (such as a phased process starting with a project managers meeting, then CEOs, then mediation, etc.) There is emerging law by which dispute resolution and escalation clauses can be made to be more legally enforceable, as we explain in our article, Making contractual ADR clauses work: a new judgment. Essentially, the more detailed the regime in the contract, the more likely that it will be enforceable. However, even if unenforceable, such provisions can be powerful in inducing negotiation of disputes, which is a good thing for all.
- New developments, like cloud based services, are calling for new ways of thinking on contracts and they also illustrate the multi- jurisdictional nature of where ICT is going.
- How the parties describe their relationship often doesn’t reflect the reality. It would be unusual, for example, for there to be a true, equal-standing partnering agreement, that creature so often used these days in the industry. One party will typically dominate: see for example our article, Fujitsu’s problems with partnering agreements – it ain’t all it seems.
To close: limitation of liability
LOL clauses still are important even though at the start of this series we suggested other issues may be more critical to parties. Off-the-rack best practice clauses are a good place to start, taking into account the latest developments. We still see plenty of clauses that don’t work well for suppliers, which makes the life of a litigator acting for customers that much easier. For an example of a high profile dispute where the vendor didn’t have a tight LOL provision, see our article, Novopay limitation of liability: valuable insights.
The specifics of each situation should be considered, as there is no ideal one-size- fits-all.
Crystal ball gazing can be difficult to predict exactly what situations will crop up, and, just as much, how judges will react. Assume some hostility to LOL, despite any rhetoric in the cases around a more neutral, rather than contra, proferentem approach.
For an example of how hard this is, take these two articles, where in similar situations, judges came to different outcomes: Limitation of liability, Houdini and the Court of Appeal and Fujitsu’s own goal on limitation of liability – spooky stuff. In the last case, a supplier was not able to recover fees, due to the wording of a LOL provision, aimed at capping liability for breach of contract. This shows the kind of problem to watch out for when drafting and reviewing ICT contracts; unintended consequences.