Technology projects rarely stay exactly as planned. Requirements evolve, priorities shift and businesses often need to adapt the scope, timing or delivery approach as a project develops. Most IT contracts recognise this and include a process for dealing with change. The difficulty comes when the project moves faster than the contract, and the parties stop following the process they agreed.

In major technology projects, a change request can feel like a practical delivery issue. In reality, it can have significant contractual consequences. If proposed changes are discussed informally, agreed in principle or acted on before they are properly approved, the parties may later disagree over what was agreed, who approved it, whether the work is payable and whether the contract has changed at all.

For in-house lawyers, commercial teams and those negotiating IT contracts, the challenge is not simply identifying when change is needed. It is ensuring that change is documented, approved and implemented in line with the contract.

This article explores where variation disputes typically arise, why informal change can create commercial and legal risk, and what organisations can do to manage contractual change more effectively.

Why does change control matter?

Most IT contracts include a change control process that sets out how changes should be requested, assessed, approved and documented.

That process can sometimes be seen as administrative. In practice, it serves an important purpose. It helps the parties understand whether a proposed change is genuinely a contractual change, what impact it will have and ensures that internal authorisations are respected.

This is particularly important in technology transformation projects which usually involve vast business and technical teams working over extended periods; change control is vital in maintaining governance and in keeping project budgets, timelines and business objectives aligned. A project team may change how it manages delivery without affecting the contract. However, where a change impacts price, scope, deliverables, timing or service levels, the contractual change process is likely to become important.

Problems often arise when project teams treat a change as agreed before the contractual process has been completed. That can create uncertainty during delivery and make later disagreements far more difficult to resolve.

Where do variation disputes arise?

Variation disputes often begin where the parties have different views on whether work is additional or already part of the original deal.

Scope is a common source of disagreement. A supplier may argue that new functionality sits outside the agreed scope and should be treated as a variation. A customer may believe it was always required to achieve the agreed outcome.

Requirements can create similar challenges. If they are vague, incomplete or inconsistent, disputes can arise over whether the contract still reflects what the parties intended.

Cost is another frequent pressure point. Even where both parties accept that a variation is required, they may not agree who should pay for it. Questions around authority can also emerge, particularly where a proposed change has been discussed or approved by someone who lacks contractual authority.

The common feature in many disputes is the growing gap between what the contract says should happen and what happens in practice.

Why informal change creates risk

Many disputes arise not because there is no change control process, but because the parties do not follow it.

In practice, problems rarely arise because the parties deliberately ignore the contract. More often, they emerge when delivery teams try to keep a project moving. Verbal instructions are given, changes are agreed in principle, or work begins before the necessary approvals have been obtained. By the time questions are raised about cost, scope or responsibility, the contractual position may be far less clear than either party assumed.

This approach may feel pragmatic at the time, particularly where teams are trying to maintain momentum. However, it can create significant uncertainty if the relationship later comes under pressure.

Without a clear record of what was agreed, who approved it and on what terms, the parties may find themselves arguing about whether the contract was varied at all, whether additional work is payable and who bears responsibility for delay or additional cost.

This is where No Oral Modification clauses ("NOM clauses"), often called NOM clauses, become important. These clauses generally require contractual changes to be documented and approved in a specified way. Their purpose is to create certainty and reduce the risk of informal or unintended variations.

What do recent cases tell us?

The Supreme Court's decision in Rock Advertising Ltd v MWB Business Exchange Centres Ltd confirmed that NOM clauses are legally effective. Where parties agree that contractual changes must be made in writing and signed by authorised representatives, they should expect the courts to enforce that requirement.

For organisations delivering major technology transformation programmes, this is an important reminder that discussions, emails and verbal agreements may not be enough if the contract requires a formal variation process.

The same theme can be seen in Tata Consultancy Services Ltd (TCS) v Disclosure and Barring Service (DBS). One of the key issues in that dispute was whether requests for change had altered the parties' obligations under the contract.

The court began with the contract itself. Until the agreed change control process had been completed, the existing contractual obligations remained in place.

The underlying lesson from both cases is that recognising the need for change is only the starting point. Unless the agreed process is followed, the contractual position may remain unchanged.

Our existing TCS v DBS series explores the judgment in more detail. The case highlights the risks that can arise when project delivery moves ahead of the contractual process used to approve and document change.

What happens while a change is being agreed?

One of the most difficult questions in practice is what happens during the period between identifying a change and formally approving it.

Change requests often take time to assess, price, negotiate and approve. In the meantime, project delivery continues.

From a supplier's perspective, starting work before approval may mean working at risk. From a customer's perspective, continuing with the existing scope may mean incurring costs on work that no longer reflects the project's objectives.

For that reason, organisations should think carefully about what the contract says happens while a proposed change is being considered. Does delivery continue as normal? Can work pause? Is there a faster route for lower-risk changes?

These questions are often easier to address during contract negotiations than during a live project.

How can organisations reduce variation risk?

There is no way to remove change from technology projects. The aim is to manage it in a way that supports delivery while protecting the contractual position.

Clear scope and requirements remain important. The parties should understand what the project is intended to achieve, what the solution must do and how success will be measured.

Project teams should also understand the change process. They do not need to know every contractual detail, but they should know what to do when change is required, who can approve it and what records need to be maintained.

Before acting on a proposed change, organisations should check what the contract requires. That means reviewing the change control mechanism, any variation wording and any NOM clause. Proposed changes should clearly explain what is changing, why it is needed and the likely impact on timing, cost and delivery.

Early communication also matters. Raising issues sooner gives the parties more opportunity to assess their impact before positions become entrenched.

Most importantly, organisations should remember that the change process exists for a reason. Following it may feel slower in the short term, but it can help avoid much larger problems later.

Getting IT contract variations right

Major technology programmes inevitably evolve over time. The question is whether contractual change keeps pace with changes to delivery, scope and business priorities.

Identifying the need for change is only part of the challenge. Ensuring that change is properly assessed, approved and documented is often what determines whether a project remains on track or becomes a source of dispute.

For more on the issues discussed in this article, and for tailored legal support on technology contracts, transformation programmes and managing variation risk, contact a member of our Tech team.

To receive future updates on technology contracts, digital transformation and the legal and commercial issues affecting technology projects, sign up to receive our latest insights.

FAQs

Why do change control procedures matter?

They create certainty around how contractual change should be managed.

A well-designed change control process helps the parties assess the impact of a proposed change, agree responsibilities and record decisions before the change is implemented. Without that process, disagreements can quickly emerge over what was agreed, on what terms and who is responsible for the consequences.

Can a request for change alter the contract?

Not necessarily.

In most cases, a request for change is simply the start of the process. Unless the agreed contractual procedure has been followed, the original obligations may continue to apply.

The key point: identifying the need for change is not the same as approving it.

What are the risks of agreeing changes informally?

Informal change can create uncertainty for both parties.

A supplier may begin work believing approval is a formality, while a customer may assume a new approach has already been agreed. If the agreed process is not followed, disputes can arise over cost, timing, responsibility and whether the contract changed at all.

What should organisations consider while a change is being agreed?

One of the most important questions is what happens in the meantime.

Does the supplier continue delivering under the existing scope? Who bears any additional cost? Can work begin before approval? These issues can have a significant commercial impact if they are not addressed early.

What happens if parties act on a change before it is formally approved?

The risks can be significant for both parties.

A supplier may be working at risk, while a customer may assume a change has been agreed when the contractual process has not been completed. If a dispute arises later, questions around payment, responsibility and contractual obligations can become much harder to resolve.