When Technology Projects Go Wrong: Managing Contractual Risk

Key takeaways

• Prevention: Most technology disputes turn on scope, milestones, dependencies, change control and acceptance. Clear drafting of these provisions is the best protection against a dispute.
• Early action: When a project starts to slip, the contract, the project records and the way each party communicates will shape its legal position. Problems are easier to resolve before positions solidify.
• Termination risk: Terminating on the wrong ground, or too early, can itself be a breach. Termination notices should be checked carefully against the contract and the facts.
• Remedies: What can be recovered depends heavily on the contract’s liability, liquidated damages and termination provisions, which courts will apply according to their wording.

Technology projects fail for many reasons. Requirements change, timescales prove unrealistic, a supplier lacks the resources or expertise it claimed, a customer does not provide the data or decisions the project depends on, or the technology simply does not perform as expected. When this happens, both parties may face significant costs, and the relationship may break down.

Disputes over failed technology projects are often complex, expensive and slow to resolve. This article considers how businesses can reduce the risk of disputes when contracts are negotiated, how to protect their position when a project starts to go wrong, and the key legal issues that arise if the relationship breaks down. It draws on recent decisions of the English courts in technology disputes.

Why do technology project disputes arise?

Disputes typically centre on a small number of recurring issues:

• Scope: disagreement about what the supplier agreed to deliver, particularly where the specification was high level or evolved during the project.
• Delay: missed milestones and disputes about who caused the delay.
• Dependencies: the customer’s obligations to provide information, data, access, decisions or third-party cooperation, and the consequences of failing to do so.
• Change: additional or changed work that was requested or carried out without a formal variation, and disputes about who should pay for it.
• Acceptance: whether deliverables passed or failed testing, and whether acceptance was deemed.
• Performance: whether the technology meets the agreed functional and performance requirements.
• Payment and termination: withheld payments, and whether either party was entitled to terminate.

How can the contract reduce the risk of a dispute?

Scope and specification

The contract should describe what is to be delivered with as much precision as the project allows. Where the requirements will be developed during the project, for example under an agile methodology, the contract should explain how they will be agreed and documented, and what happens if they expand.

Milestones

If the customer needs delivery by particular dates, the contract should say which dates are binding and what the consequences of missing them are. In Topalsson GmbH v Rolls-Royce Motor Cars Ltd [2023] EWHC 1765 (TCC), the court held that a high-level “anticipated timeline” in the original contract did not create binding milestones, but that later implementation plans agreed by the parties did. Because the contract also made time of the essence, missing those later milestones entitled the customer to terminate. The case shows the importance of documenting revised plans clearly and of knowing which plan is contractually binding at any point.

Customer dependencies

Many projects depend on the customer. The contract should list the customer’s obligations and provide a mechanism for the supplier to notify the customer promptly of any failure, with relief from the consequences of resulting delay. Without this, suppliers may struggle to show that the customer caused a delay, and customers may be surprised by claims made late in the project.

Change control

A change control procedure should set out how changes are requested, assessed, priced and agreed. Where the contract requires variations to be agreed in writing, the courts will generally give effect to that requirement, as the Supreme Court confirmed in Rock Advertising Ltd v MWB Business Exchange Centres Ltd [2018] UKSC 24. In practice, changes are often agreed informally in project meetings, which can later make it difficult to establish what was agreed and who should bear the cost.

Acceptance

Acceptance provisions should set out the tests, the criteria for passing them, the timetable for testing and re-testing, and the consequences of repeated failure. Deemed acceptance on use or after a period of time is common, and customers should be aware of it.

Governance, escalation and exit

Regular project reporting, clear governance, and an escalation procedure that brings senior people together before a dispute is formalised can resolve many problems. The contract should also provide for what happens on termination, including handover of work in progress, code, documentation and data, transition assistance, and the customer’s right to use deliverables that have been paid for.

What should you do when a project starts to go wrong?

The steps taken in the early stages of a problem often shape the legal outcome. Businesses should consider the following:

• Review the contract. Identify the obligations in issue, the notice requirements, any time limits for raising claims, and the remedies available.
• Keep records. Make sure that project plans, change requests, test results, meeting minutes and correspondence are complete and preserved. Contemporaneous documents are usually decisive in technology disputes.
• Communicate carefully. Correspondence and project reports may be read by a court later. Avoid informal admissions, and consider when discussions should be conducted on a without prejudice basis.
• Follow the contract. Use the change control and notice provisions, even if the parties have not done so before. Failing to do so may weaken a later claim.
• Reserve your rights. Where the other party is in breach but you wish the project to continue, make clear that you are not waiving your rights, so that you are not treated as having affirmed the contract unconditionally.
• Escalate early. Use the governance and escalation procedures to try to resolve problems before they become entrenched.

Can you terminate?

A party may be entitled to terminate under an express right in the contract, such as for material breach or missed milestones, or at common law for repudiatory breach. The two routes have different requirements, and termination notices should state the grounds relied on accurately. Termination is a high-risk step: a party that terminates without being entitled to do so may itself be in repudiatory breach, exposing it to a claim for the other party’s lost profits.

In Topalsson, the customer’s first termination notice relied on milestone dates that had been replaced by a later plan and was not effective. The supplier rejected it and affirmed the contract. The customer then served a second notice, based on the correct milestones, which validly terminated the contract. The case illustrates the importance of checking termination notices carefully against the contract and the facts, and of considering whether the other party’s response affirms the contract.

Suspending performance or withholding payment can also carry risk. A supplier that stops work, or a customer that refuses to pay sums properly due, may be in breach unless the contract or the law entitles it to do so.

What can be recovered?

The remedies available will depend largely on the contract. Key issues include:

• Liquidated damages. Where the contract provides for liquidated damages for delay, they will generally accrue up to termination, as the Supreme Court held in Triple Point Technology Inc v PTT Public Company Ltd [2021] UKSC 29.
• Wasted expenditure and replacement costs. A customer may claim the cost of a failed project or of procuring a replacement system. Whether such claims are excluded depends on the precise wording of the exclusion clause, as illustrated by Soteria Insurance Ltd v IBM United Kingdom Ltd [2022] EWCA Civ 440.
• Caps. The cap will often determine the maximum recovery. In Drax Energy Solutions Ltd v Wipro Ltd [2023] EWHC 1342 (TCC), a claim of around £31 million was limited to about £11.5 million by a single aggregate cap, and in Topalsson v Rolls-Royce [2024] EWCA Civ 1330 the Court of Appeal held that the cap applied before set-off.
• Misrepresentation. Where a party was induced to enter the contract by statements about the other party’s experience or capability, it may have a claim for misrepresentation. Entire agreement and non-reliance clauses may affect such claims.
• Supplier claims. A supplier may claim unpaid charges, payment for additional work, and damages for wrongful termination.

We consider limitation of liability in more detail in our article on limitation of liability in technology contracts.

How are technology disputes resolved?

Many technology contracts contain a tiered dispute resolution clause, requiring escalation between the parties’ representatives and sometimes mediation before proceedings can be issued. Expert determination can be useful for technical questions, such as whether a system meets its specification. Where the dispute goes to court in England and Wales, technology disputes are usually heard in the Technology and Construction Court, and the parties are expected to comply with the court’s pre-action conduct requirements, including exchanging information and considering settlement before issuing proceedings. Some contracts provide for arbitration instead, which offers confidentiality.

Claims for breach of contract must generally be brought within six years of the breach, or twelve years for a contract executed as a deed, so the timing of any claim should be kept under review.

Litigation is not always the best outcome. Where the technology remains important to the customer’s business, a negotiated solution that allows the project to continue or to transition in an orderly way to a new supplier may better protect both parties’ commercial interests.

Managing technology project risk: a practical checklist

For businesses involved in technology projects, managing contractual risk is likely to involve:

• At the outset. Clear scope, binding milestones where needed, listed dependencies, a workable change control process and defined acceptance tests.
• During the project. Documenting revised plans and changes, keeping complete project records, and using the governance and escalation procedures.
• When problems arise. Reviewing the contract early, following notice and change procedures, communicating carefully and reserving rights.
• Before terminating. Confirming the grounds, checking the notice against the contract and the facts, and considering the risk of wrongful termination.
• Assessing the claim. Analysing the liability cap, exclusions, liquidated damages and limitation periods.
• Resolving the dispute. Considering escalation, mediation or expert determination, and whether a commercial solution is achievable.

At Maybrook Law, our commercial and disputes lawyers work together on technology projects, from negotiating development, implementation and services agreements to advising when projects run into difficulty. Because we understand how technology disputes arise, we can help clients reduce those risks at the contract stage and, where problems do arise, assess the contractual position quickly and develop a strategy that protects their commercial objectives. If you are involved in a technology project that is not going to plan, or would like to discuss any of the issues raised in this article, we would be pleased to advise on your position.

This article reflects the law as at 1 September 2026. Our insights, articles and guides do not, and are not intended to, constitute legal advice or be an exhaustive review of all legal developments. Although every effort is made to ensure that the information provided in this article is accurate as of the publication date, please be aware that this area of law is developing rapidly and may be subject to change. Please seek legal advice before applying the information provided to any specific circumstances, transactions or legal issues.