Key learning points for IT projects from the High Court – Topalsson v Rolls-Royce.

It’s relatively unusual for a major IT project to be dissected by the UK courts.  So the judgement of Mrs Justice O’Farrell in Topalsson GmbH v Rolls-Royce Motor Cars Limited [2023] EWHC 1765 (TCC) is important because of the way a number of common IT project issues were interpreted and dealt with by the court.

The background was briefly as follows.  Rolls-Royce appointed Topalsson to develop a web-based visualisation tool which customers could use to create realistic renderings of Rolls-Royce cars with different customisations prior to purchase. The full contract value was approximately €15 million.  Topalsson entered into an agreement whereby it undertook to meet dates set out in a high-level implementation plan (the “Original Implementation Plan”) and then a further project plan drawn up by Topalsson (the “December Plan”). When it became clear that the dates set out in the December Plan could not be met a revised plan was agreed with new milestone dates. When Topalsson failed to meet these timelines, Rolls-Royce served a termination notice claiming repudiatory breach and breach of condition.  Topalsson rejected this notice and claimed Rolls-Royce were in repudiatory breach of the agreement.

In the High Court, the judge found in favour of Rolls-Royce on nearly all points of contention.  With the parties’ liability under the agreement capped at €5 million in aggregate, Rolls-Royce was awarded damages of €5 million plus interest.

Implementation plans and bar charts.

Rolls-Royce claimed that Topalsson were obliged to comply with the Original Implementation Plan.  The latter was a bar chart (similar to a Gantt chart) showing in “high level” the phases that were to be completed by reference to calendar quarters. While such an approach is not normal, it’s certainly not unknown in IT projects.  In theory a date can be attributed to the end of each bar by reference to the ending of the relevant calendar quarter. The difficulty here was that bars ended between quarter dates. As a result the judge held that the Original Implementation Plan was not binding.

·       The ending of a bar on the chart could not be linked to any specific date with any degree of certainty.

·       The parties described the timeline as “anticipated timeline” and “high level” with detail to be agreed later.

Key learning: if you use bar or gantt charts, make sure they align to specific dates and, if you want the chart to be binding, avoid any reference to it being “high level” or “anticipated”.  This means also ensuring that other people involved in drafting documents that may be incorporated by reference are consistent with this approach.  If you don’t use bar or gantt charts, specific dates for milestones are the way to go.

Failure to define acceptance

The agreement envisaged that Topalsson had to meet “Technical acceptance” by specified dates. But the parties had not defined “technical acceptance”.  As a result, technical experts wrote papers to the court and the court had to construe the term by reference to the rest of the agreement. The result was that the court held Topalsson had to achieve UAT (which would normally be outside its control) in order to meet the relevant milestone.

Key learning: If you want to avoid unexpected consequences, specify what acceptance means.  If, as is normal in IT projects, there are several types of acceptance, which one do you intend to refer to? Is it the systems integration test or UAT or is it something different?  Also, as a supplier, is this something you have full control of?

Time of the essence

Most suppliers will fight tooth and nail to avoid being subject to a time of the essence obligation, so it’s a mystery as to why Topalsson agreed to such a clause. That said, the judge’s interpretation of the clause is curious.

“Time shall be of the essence regarding any date for delivery by the Supplier of any good or service specified in this agreement and the Completion Date.”

Topalsson pushed for a literal interpretation of the clause. It argued that it was the date for delivery, as specified in the agreement that was caught.  Because there were no such dates (all milestone dates being agreed subsequent to the agreement), the clause did not apply.

The judge however, referring to the usual canons of interpretation (in particular, the intention of the parties when entering into the agreement), held it was clear that the agreement envisaged dates to be agreed as part of the first milestone.  As a result the time of the essence obligation applied to all the dates that were agreed by the parties after the contract came into existence.

It’s also interesting to note that the contract contained an express obligation on Topalsson to meet milestone dates set out in the contract “on time and in full and by any applicable milestone date or delivery date”. But the judge appeared to consider that this was not enough to make time of the essence.

This confirms the approach over recent years to require time clauses to be specifically stated to amount to time of the essence and ignoring earlier case law which presumed that time clauses in mercantile contracts would normally constitute conditions. (eg See Lord Wilberforce in Bunge Corporation v Tradax Export SA [1981]: “But I do not doubt that, in suitable cases, the courts should not be reluctant, if the intentions of the parties as shown by the contract so indicate, to hold that an obligation has the force of a condition, and that indeed they should usually do so in the case of time clauses in mercantile contracts”).

Key learning:  Clauses can be construed broadly in light of the judge’s interpretation of the parties’ intention. If time is to be of the essence, it’s not enough just to state that the supplier must meet certain specified timelines; you must expressly state that time is of the essence or that you record that the supplier’s compliance with milestones “is a condition of our ongoing contractual relationship”.

Using agile for a waterfall project

Topalsson worked using agile.  But the agreement they entered into was based on a traditional waterfall development. This meant that Topalsson had to convert the requirements document into user stories and led them to claim, without any foundation, that the process of agreeing the user stories involved scope creep.  The judge gave short shrift to this argument.  No formal changes were raised, therefore there was no scope creep.

Topalsson more generally claimed that it was hampered by Rolls-Royce’s insistence on use of waterfall. Upon examination, that was not strictly true.  The contract did not mandate waterfall but did provide that either agile or waterfall could be used so long as the requirements and acceptance provisions were met and payment would be tied to set milestones. Effectively therefore a hybrid approach was adopted – Topalsson used agile development, but was tied into to fixed milestones and payment.

Key learning:  as a supplier, you need to call out contract changes.  You shouldn’t sign up to an agreement with sub-optimal provisions merely with a view to getting the agreement signed. Arguing after the event and without any documentary support that there has been scope creep is likely to fail. Also, trying to argue after the event that delivery could have been quicker but for the rigidity of the contract and that a different development methodology would have been more appropriate, will also fail. As a supplier, you signed up to the terms and there is no getting away from that. From a customer’s perspective, the contract as drafted undoubtedly worked for Rolls-Royce when it came to litigation, but it may be worth asking whether the project would have functioned better if Topalsson had not felt forced into a hybrid agile/waterfall approach.

Delay due to customer failures

Topalsson claimed that if it failed to meet milestone dates, this was because of failures by Rolls-Royce. Unfortunately Topalsson was unable to justify these claims.

Key learning. If a supplier wishes to claim that it has been delayed by the customer, it needs to be able to prove that fault was with the customer.  In this case, the judge held that the real reason for delay was that Topalsson was under resourced and committed itself to an ambitious project it was unable to meet.