Skip to main content

Broken promises — how IT projects can lead to disputes all too often

Disputes arising from misunderstanding the aims of both parties are unlikely to be fixed by switching it off and on again. So, what can you do?

When a company purchases a new IT system, or new software, it often has certain expectations about what it is buying. Expectations may exist around functionality, cost and timescales, all or some of which are likely to be shaped during the pre-contract phase of the project. That may be through a formal tender process or through direct discussions with the vendor, when statements may be made that ultimately induce the customer into proceeding with its purchase.

In many projects, however, until the parties have gone through a detailed scoping exercise, IT contractors can only ever give indicative estimates about how much an IT system will cost or how long it will take to implement. Frequently that detailed scoping exercise can throw up a whole host of issues. For example, it might transpire that a company’s legacy system (which is to be replaced) is far more complex than originally anticipated, or perhaps a customer’s detailed requirements are going to require significantly more development work than anyone first appreciated.  

As the IT project continues, and as delays creep in and costs start to escalate, this mismatch between the parties’ expectations can create an inevitable tension between:

  • on the one hand, a customer who is becoming increasingly frustrated by an IT contractor that seems unable to deliver the functionality that was promised on time and within budget; and
  • on the other hand, an IT contractor that is becoming increasingly frustrated by a customer who has unrealistic expectations and who keeps changing its mind about exactly what it wants.  

All too often this tension can spill over into full-blown disputes, leaving the customer feeling like it hasn’t got what it paid for; and the IT contractor feeling like it has a customer who is impossible to work with. 

Types of claim

When a distressed IT project ends up in a typical dispute scenario like this, the most common type of allegation to be raised is one of breach of contract. Depending on the precise scenario at hand, it might be the customer complaining that the IT contractor is in breach, or vice versa. Sometimes both parties might be making breach allegations at one another. Either way though, there is no denying that the strict wording of the contract between the parties will be highly material. Not only will it specify the express contractual obligations which the parties are under, but it can also:

  • clarify which pre-contract representations have become terms of the contract;
  • set out how the parties have attempted to limit or exclude any liability they may face, including liability for any representations which didn’t make it into the contract;
  • cater for the consequences of any breaches, including setting out grounds for termination; and  
  • provide a contractual mechanism for the early resolution of disputes.

It is often not until a dispute actually arises though that the parties take the time to consider the contract in detail. However, that is a practice that rarely stands either party in good stead. It is far better to maintain a good understanding of the contract and to seek to work within its terms, right from the outset of the project. 

Allegations of misrepresentation may also surface in an IT project dispute. This is where one party alleges that the other party has made certain statements that were relied upon when entering into the contract, but which then turn out to be untrue. For example, they may have been told that their new software will integrate seamlessly with their existing systems and processes, only to be told that, in fact, some of the functionality of their old software is proving impossible to replicate. Or they may have been told that the project was anticipated to take 30 weeks to complete, but then find themselves two years down the line with a project that is still some way from completion.  

Whether or not IT contractors will face liability for misrepresentation will often depend on exactly what was said before the contract was entered into, as well as how successfully the contract excludes liability for those pre-contract statements. In some cases, the clauses which are designed to exclude such liability are not as effective as the parties had hoped. However, much will turn on the precise facts at hand and also the precise drafting of the clauses in question.     


Sometimes relationships in an IT project can break down to such an extent that one party feels that the only viable solution is to terminate the contract and to start again. However, such a step is often likely to lead to a dispute escalating, rather than bringing it to a conclusion. 

In particular, real caution should be exercised before anyone takes the step of terminating a contract for breach, since it can be a legal minefield. For example, if one party elects to terminate under a contractual power in circumstances where there were no valid grounds for termination, they can open themselves up to a claim coming back the other way. That’s because the other party can then argue that the contract has been terminated wrongfully, which itself constitutes an actionable “repudiatory” breach entitling them to sue for damages.

Another question may arise as to whether the terminating party should terminate under the terms of the contract itself, or under the common law. Each route could have very different consequences, including the scale of damages that may be available.  

The short point to note is that terminating contracts for fault can be a dangerous game to play and if you get it wrong, it could be a game in which you score a serious own goal. 

How can disputes be avoided?

Whilst there can be no guarantees that disputes won’t arise in your IT project, the following guidance may nonetheless help to minimise the scope for fall-out.

  • IT contractors should ensure that statements made during the pre-contract phase are either properly supportable or suitably caveated. In particular, if your technical personnel who will actually be running the project are different to the sales personnel who are trying to win the contract, you should ensure that those two teams are communicating effectively. This will ensure that the customer is not sold something that simply cannot be delivered, either at the price quoted or in the timescales agreed.
  • Suitable effort should go into agreeing and signing off on a detailed scope of works at the outset of the project. Doing so will force the customer to be clear about its detailed requirements from inception and the IT contractor will also be clear about what it is working towards. Any deviations from that scope (which will likely impact on cost and timescale) should be carefully logged and dealt with in accordance with any agreed contract change mechanism.
  • The parties should maintain a good working knowledge of the contract during the life of the project. It is often too late to start looking at the contract only once a dispute arises.
  • Make use of any agreed dispute resolution mechanisms in the contract. They can often be helpful in resolving disputes before they escalate. Even if there are no such provisions in the contract, you should consider using alternative dispute resolution mechanisms anyway. You might save yourself a lot of time and money by doing so.

If things really have gone past the point of no return, consider matters very carefully before seeking to terminate the contract. It is also often very sensible to take specialist legal advice before you take any steps towards termination that may be irreversible.

For further information and expert advice get in touch with one of our leading cyber risks and disputes solicitors.