On 14 October 2016, the Society for Computers and Law held its inaugural event in Singapore at the heart of her Central Business District. Very kindly hosted by Rajah & Tann LLP, an enthusiastic group that included practitioners and in-house counsel gathered at the firm’s Sky Garden to hear about some of the challenges that arise when negotiating technology and telecommunications projects, and how well certain terms measure up when the project goes wrong and litigation ensues.
The Honourable Justice Vivian Ramsey, International Judge of the Singapore International Commercial Court, chaired a panel of four practitioners:
· Mr Rajesh Sreenivasan, Head, Technology, Media and Communications, Rajah & Tann LLP,
· Mr Matthew Lavy, Barrister, 4 Pump Court,
· Mr Jonathan Choo, Partner, Bird & Bird LLP, and
· Mr Alex Charlton, QC, Barrister, 4 Pump Court.
Introduction by Sir Vivian Ramsey
Sir Vivian had noticed during his time on the bench that sometimes the parties to a technology project did not really know what they wanted or what the other party was going to give them, and it was a developmental journey for both parties. This uncertainty was sometimes reflected in the contract. For example, one clause that Sir Vivian had come across read: ‘The solution shall be designed with the following requirements in mind: 100% availability, massive scalability, open modular and flexible architecture, and proven technology.’ Another read: ‘Milestone plan showing key commitment and decision dates and detail within each key project phase will be developed before work begins.’
Sir Vivian’s view was that IT payment milestones or deliverables were a very flexible concept and difficult to define. He noted that, in the construction industry, an arbiter such as an architect or engineer was normally used to bring certainty to the contract by certifying stages of completion. In contrast, that rarely occurred in IT contracts. Sir Vivian said that with IT contracts, ‘very often, there’s a sort of “we’ll pay you the money, but we don’t think you’ve got completion – just to get on with the work”‘.
Another difference Sir Vivian noticed between the IT and construction industries related to the manner in which disputes were handled. Whilst litigation and arbitration were used mainly to resolve IT disputes, the construction industry was increasingly turning to dispute adjudication boards, endeavouring to smooth out issues and help the parties move on before the issues turned into deep-heated disputes.
Payment clauses, change control, backup and disaster recovery, termination rights, exit plans, intelligent contracts
In Mr Sreenivasan’s view, lawyers often overlooked the issue of withholding tax when structuring payment clauses in cross-border IT contracts. Vendors would want to recognize as much revenue as possible, and would want the entire amount owing up-front. Customers would want to pay what is owing but less any tax they have a right to withhold. Mr Sreenivasan suggested that the commercial approach to resolving this was to ask at the negotiations stage if the amount being withheld could be made up by way of other forms of up-front payment.
Another contentious clause was the benchmarking clause. Such a clause gives the client the right to review the vendor’s costs as against its competitors’, and Mr Sreenivasan pointed out that benchmarking cannot be achieved unless a third party can assess the technology and provide a report. During negotiations, the parties’ attention might be focussed on getting or preventing such a clause from getting in to the contract. But customers should in addition look out for confidentiality clauses preventing a third party from assessing the technology, thereby preventing benchmarking from being achieved.
With regard to change control, Mr Sreenivasan expressed concern at the outset about customers letting vendors take complete responsibility for it, because ‘the vendors are effectively assessing themselves based on parameters that they set for themselves.’ He emphasized the importance of setting out a clear procedure for change control, particularly with respect to time and when change control occurs. This would prevent the parties from abusing the process, for example by the vendor invoking change control to delay termination, or by the client invoking it to delay payment.
On a more general level, Mr Sreenivasan questioned whether, when the parties accept that there is going to be change throughout the project, they should move away from the Waterfall Methodology and change control, and instead adopt the Agile Methodology.
Defects and damage
Mr Matthew Lavy’s experience was that defects and damages were quite often overlooked or misunderstood. He gave the example of off-the-shelf software often being required to work ‘materially in accordance’ with the supplier’s documentation. The problem with such a standard was that it was tied to the quality of the supplier’s documentation – the worse the supplier’s documentation, the easier it would be for the supplier to claim that the software did work ‘materially in accordance’ with the documentation.
Defect density (ie the number of defects in a given amount of code) was another area that was often overlooked. Mr Lavy said:
Sometimes you can get around ludicrously limited warranties by asking yourself whether there are too many defects and whether that actually reveals not simply that the software is defective, but that something has gone horribly wrong with the development process and you start to engage warranties such as reasonable care and skill [on the part of the vendor]. Has this thing been built to an appropriate standard?
The rigour demanded would of course depend on the kind of software being built, the environment it was for, and defect tolerance.
In respect of damages, Matthew Lavy said that the basic measure of loss on the client’s side was the cost of rectification. But, often after major project failure, the client would lose the appetite to try again and would just want its money back. How can the client get its money back when the supplier has given something of value and there is no total failure of consideration?
Mr Lavy suggested analysing the IT contract and its payment structures to see if they could be broken down into components such as phases delivered and not delivered, software licences, and hardware. Where for example a milestone payment was made or partly made but nothing was delivered, the client might have a restitutionary claim for the amount paid. If the contract is severable, money spent could be claimed back as wasted costs, for example where licence fees were paid for software licences and the supplier failed to deliver.
What if the contract is not severable or not easily severable? What if the customer orders a ‘Ferrari’ but gets a ‘Mini’? The customer would not have a claim for partial failure of consideration but may be able to get damages if it can establish that there is a difference between the price it paid or the market value of what was contracted for (whichever is lower), and the market value of what it received.
Common areas of dispute in technology contracts, exit strategy
In Mr Jonathan Choo’s experience, one area that commonly gave rise to disputes was user acceptance testing (UAT). UAT might sound simple conceptually but, in reality, defining the actual process and requirements can be challenging. When drafting UAT provisions, some matters that should be considered are:
· who is to design and implement UAT – the client or vendor?
· who should be testing the technology?
· when does testing begin and end?
· when can you say the technology has met user requirements and is ready to be released?
· are there alternatives to UAT, some other types of testing?
Another area that commonly gave rise to disputes – in fact 90% of disputes that Mr Choo had encountered in practice – was change control. Jonathan Choo said that the change control provisions he had came across in contracts were usually well-drafted. The problem was that the parties to the contract simply would not follow the change control process provided for.
Nevertheless, some matters that Mr Choo suggested should be considered when drafting change control provisions are:
· who is to log the request or change?
· where do you log the request or change?
· who has the authority to decide?
· what if there is disagreement? Is there a mechanism for the resolution of the disagreement?
In Mr Choo’s experience, multi-tier dispute resolution clauses were becoming fashionable in technology contracts. In a conversation with him after the event about such clauses, he said that Arb-Med-Arb was a useful dispute resolution option. He said that sometimes, parties are not very enthusiastic about mediation because they feel that it is too fluid and there is no clock ticking in the background, no sword hanging over the parties’ heads. In Arb-Med-Arb, the dispute is referred to arbitration before mediation is attempted. If the dispute can be settled at mediation, the settlement agreement may be recorded as a consent award at arbitration. If the parties are unable to settle at mediation, they can continue with arbitration.
Limitation and exclusion of liability clauses
The final panellist for the evening was Mr Alex Charlton, QC. With the Singapore Flyer (Asia’s largest observation wheel) already glowing against the dark evening sky, Mr Charlton gave a ‘whistle-stop presentation’ on limitation of liability.
Liability caps can be fixed as a lump sum, or by reference to value of the contract (which may go up or down with change of control and any additional functionality required). Wording that Mr Charlton had also come across was a cap based on an amount ‘paid or payable under the contract’ or ‘within a contract year’. Claimants should be cautious of such wording because of its arbitrariness. Mr Charlton gave the example of a client paying $30 million in the first contract year, a milestone date passing, and the figure dropping to $3 million the next contract year. If the client discovers then that the system does not work, it will be stuck with a relatively small amount of money that is recoverable.
What if the project fails? What if rights of termination arise but no right is executed, there is re-negotiation, the timeline gets extended, and the client has to spend more money? How effective would the liability cap be? Can the liability cap be re-negotiated?
Whether it can may depend on whether the contract allows for an increase in the limit on recoverable damages. But Mr Charlton said that he had never come across a contract with a clause permitting for such an increase, and had never come across a situation where the liability cap was re-negotiated to take account of the revised and increased costs to the customer of completing and implementing the system.
In a conversation with Alex Charlton after the event, he had some advice for customers and vendors:
‘The key for customers is twofold: firstly, to ensure that when IT contracts are negotiated, the [liability] cap is sufficiently high at the outset to ensure that they get their money back from the contractor together with damages for their own wasted effort and wasted expenditure; secondly, if the contract does go wrong, to leverage any rights of termination in the negotiation to increase the liability cap to ensure that, if the project goes wrong a second time, they are not left holding losses that they cannot recover. If a contractor is confident of its ability to complete a project successfully, it is difficult to understand why it would not be willing to increase the liability cap after an initial failure.
From the contractor’s perspective, it is vital to ensure that any liability cap reflects the level of insurance that it enjoys. Of course, it would be legitimate for a contractor to resist an increase in the cap if the customer was partly to blame for the initial failure.’
Comparing IT contracts with construction contracts – adjudication and certification
Speaking with Alex Charlton QC after the event, he said that adjudication was increasingly included in dispute resolution clauses in IT contracts. Mr Charlton’s view was that adjudication is essential in any complex or medium to long-term IT project. He was very keen on it in large IT projects because it provides a quick, effective and reasonably inexpensive means of resolving disputes (in 28 days) and allows the parties to get on with the contract without being distracted and having their relationship soured by a dispute.
Mr Choo’s opinion on that topic was that it would probably take a very large IT contract for dispute adjudication boards to be used. He doubted that the parties in run-of-the-mill IT contracts would be that sophisticated or would want to go through the process of setting up a dispute adjudication board.
In respect of the certification of stages of completion, Mr Charlton said that he had not come across any IT contracts providing for such certification by an independent third party. Customers sometimes retained external consultants to review the vendor’s deliverables, and in most large IT projects, the customers would have their own well-qualified and experienced IT personnel to assess whether the deliverable is complete and of sufficient quality.
In any event, there might in the first place be practical difficulties in specifying precisely what the certifier would be certifying. Mr Charlton pointed out that in a construction project, the certifier is able to see and measure the work done and assess its quality because it is ‘physical’. In an IT project, the milestone to be certified may be a document or a software build. In his view, it would not make sense for someone to certify that a document or software build has been produced when that fact is obvious. The critical thing is whether the document or software build works as required.
Darren Grayson Chng is a lawyer qualified in Australia and Singapore, with interests in IT and medical law.
