Add a bookmark to get started

Website_Hero_Abstract_Architectural_Shapes_P_0034_Mono
21 March 20229 minute read

Managing technology contracts to deliver good outcomes: Written guide

This article complements the second episode in a six part podcast series “Navigating Technology Disputes: Get IT Right!” where we look at how to use some of the tools in the contractual toolbox to best effect and so help deliver successful projects.

In large technology projects, the contracts underpinning them are usually equally large and complex. It can be tempting to see the contract as yet another hurdle to overcome in getting to a successful outcome, whether that is as regards a digital transformation, outsourcing or ongoing managed service. The adage is that the contract is often ‘put in a drawer’ after the significant investment in negotiating it and is only then pulled out of the drawer and looked at once things have already started to go awry, at which point it may already be too late to save the project.

In truth, the contract should be viewed as a very important tool, not just for when things go wrong, but also in keeping the project on track and delivering a successful outcome.

This doesn’t just mean that it can be used as a lever to the benefit of a purchaser or a supplier, although that may often be the case; rather, the structures and processes set out in a technology contract, when used properly, can create the optimum framework for both parties working together in partnership and for mutual gain.

We set out below some practical pointers for using those structures and processes to optimum effect.

Getting contract savvy

This is about ensuring that the right people have the necessary level of understanding of what the contract says and means, as well as the original intention behind the contractual terms, in order that they can fulfil their respective roles and deliver the project. Where there is not continuity or a proper handover as between the bid team and contract management, there is a risk that the team managing the contract will not have the necessary familiarity with its terms. Those responsible for the day-to-day operation of the contract need to understand its key terms and what is expected of both parties.

There are practical tools which can be used to translate the complexity of the contract into something more user-friendly. For example:

  • excel spreadsheets designed to log change requests and automatically calculate timescales for next steps;
  • user guides summarising key aspects of the contract;
  • flowcharts showing the headline process in certain common scenarios; and
  • dashboards, tailored to ensure key information can be accessed at a glance, to determine what is going right and on track and what is not and so what may need to be improved.

For key contracts with a number of moving parts, such tools can be an invaluable way of bridging the gap between the complex legal drafting and the reality of proactive contract management.

It is also vital to be aware of and understand the various contractual obligations and any limits on them. Otherwise, there is a risk in deliberately or inadvertently inheriting (in whole or in part) the other party's obligations, in the event that things go wrong. Disentangling what has happened and where responsibility lies in those circumstances can be very difficult.

Managing communications effectively

Crucial to the success of any technology project is effective communication. The lack of, or poor, communication sits at the heart of most disputes. In the first episode of this series, we discussed the “people” aspect of large IT projects which plays a key part in how good the parties are in communicating.

There are naturally numerous layers of dialogue which take place within a technology project, with differing formality and importance attaching to each of them.

Most contracts will include a governance framework set up to provide for some form of escalation process and the first episode of this series explained the benefits of this approach. Careful thought should be given to the most appropriate attendees at these meetings. There is little to be gained in sending people who do not have sufficient knowledge or authority to be able to properly air and resolve issues swiftly. Equally, ensuring that there is regular attendance at these meetings, so that there is continuity and relevant stakeholder participation, is key.

Where any issues with contract performance have been discussed at those meetings, the minutes should reflect that, including:

  • details of the issue in question;
  • the actions needed to resolve the issue, who is responsible for taking them and by when they must be taken;
  • the consequences, if the actions are not carried out; and
  • (if the situation is on-going) an update on progress since the last meeting.

Don’t fall into the trap of thinking that not minuting meetings may diffuse a difficult situation. That will just provide more scope for argument about what did, or did not, happen at a particular meeting.

If there is a dispute about exactly what was said on a particular issue, the minutes should, at the very least, record the differences between the parties. If the parties get into a regular habit of doing this where there are differences, this will become “business as usual” and hopefully mean that the heat is taken out of these situations.

These mechanisms should encourage timely escalation of any issues which arise, thus providing the opportunity for early intervention and remedial action, meaning the parties have a better chance of keeping the project on track and avoiding a formal dispute arising.

If, despite best efforts, a formal dispute arises, there should also be a good set of records evidencing what took place and when.

Contract change

This is the area which is most commonly used to maximise revenue generation from a supplier’s perspective. If both customers and suppliers have a good understanding upfront of the contract's scope and the provision for contingencies, particularly in agile contracts, this ought to ensure a more effective process for change.

There is a difference between project change and contractual change; therefore, having a good understanding of which is which will allow you to consistently enforce and negotiate what is contractual change and its financial implications. Where there is such a genuine contract change, there needs to be a clear agreement on what the financial and other implications of that change will be.

If contractual provisions are not working in practice, the parties should not be afraid to negotiate their amendment to ensure certainty and clarity going forward, rather than allowing the change to happen informally and “by stealth”. Consideration should also be given to getting legal support to do this, to ensure that any consequential changes in the contract are also made.

Using the tools provided in the contract

There can sometimes be a reluctance to invoke the contractual mechanisms at the parties’ disposal. This can sometimes be because it may be seen to be contrary to the collaborative partnering that is needed in day-to-day dealings on a long-term technology project, or because there is the hope that things will quickly get back on track, so it is not worth making waves. It may simply be (and often is!) that the situation is very complicated, with both parties being partly at fault, such that neither party has the inclination to unpick the intertwined threads of a tangled web of events.

However, not insisting on one’s contractual rights may result in a party being deemed to have waived them, meaning they may then be unable to take the necessary steps to protect their position and interests in the future.

In long-term contracts, contractual mechanisms relating to underperformance are often designed to help the parties to get the contract back on track, rather than to take what might be considered as more adversarial action. If compliance with contractual procedures is insisted on from the outset, and applied consistently throughout, this will educate the both parties as to their respective legal expectations – hopefully, leading to fewer, unhelpful surprises.

For example, many technology contracts will include early warning mechanisms for when delays start to occur, which is the traditional hallmark of underperformance and problems in a technology contract. Suppliers need to understand their obligations and ensure that the process is followed correctly to ensure that rights are preserved in relation to claiming relief.

However, that doesn’t inevitably need to lead to a dispute. These mechanisms are in place to drive effective behaviours and ensure that both purchasers and suppliers are living up to expectations, providing a means by which to nip issues in the bud quickly through mitigation measures on both sides. One way in which the adversarial nature of these procedures can also be “softened” is by using without prejudice communications in parallel with the deployment of formal contractual notices. This will allow full and frank discussion, either in parallel with, or after pressing “pause” on, the contractual process, if that is required.

In the first article we briefly discussed the importance of including effective dispute resolution provisions within the contract. Dispute resolution provisions are there for a reason – to allow the parties to seek to resolve disputes, ideally swiftly, and then to allow the parties to get on with delivering the project. Obviously, every dispute is different, but where there are disputes which are causing a block on progress and where the parties have reached a stalemate, the parties should not be afraid to use the dispute resolution mechanism to resolve the issue and move on. This will be particularly important in long running IT projects where inevitably there is a need to consider the long term, as well as the short term, relationship.

Print