First published in the Computers & Law Focus on Outsourcing issue December 2022 and scl.org
It is not new for outsourcing projects to run into problems and for contracting parties to end up in dispute. However, outsourcing projects designed to achieve digital transformation of the customer’s business are creating more complexity in contracting, project delivery and dispute resolution. The failure rate is high and problems often arise due to the particular features of the digital transformation in question. The case between a Co-operative Group entity, CIS General Insurance Limited (CISGIL), and IBM[1] earlier this year, based on a contract to digitally transform the systems supporting CISGIL’s home and motor insurance business, is the latest high profile example.
This new wave of troubled projects means it is a good time to revisit this topic. In this article, we set out how digital transformation can drive complexity and risk, why market norm outsourcing contracts might hinder rather than help, how fresh thinking when setting up contracts can improve the chances of success, and how parties can exercise the contract smartly to get projects back on track when problems do arise.
What are the digital transformation trends increasing the risk of failure?
Agile methodologies. Leveraging out-of-the box functionality. Cloud and “as-a-service” delivery models. New technologies like AI and automation. Contracts with multiple specialist suppliers who collaborate, rather than a single behemoth. These are some of the trends being adopted by businesses seeking to achieve digital transformation through outsourcing. For outsourcing lawyers, they make for an exciting time to be working in the sector as they require us to advise our clients on interesting issues like emerging tech, sophisticated delivery models and complex risk allocation.
The flip side is that complex digital transformation projects are becoming increasingly difficult to deliver. The CISGIL v IBM case involved many of the most troublesome elements. A desire to leverage out-of-the-box functionality was ignored by business users piling in a wish list of new requirements. Customer delays in producing user stories. Poor attendance by the customer at agile sprints and workshops. Under-resourced sub-contractors. Lack of prime contractor management and oversight. Questionable code quality. Release milestones missed by a year. Souring relations. Termination for an unpaid invoice. £128 million claimed as wasted expenditure. The result: a failed digital transformation project.
While digital transformation projects can fail for a variety of reasons, we have noticed some particular features that increase risk and complexity:
- Business change – outsourcing is still often associated with the IT department but this wave of projects has business transformation at its core. They require the customer CEO or COO to spearhead the project, but when this level of engagement is lacking, the envisaged change is harder to implement. Also, if the business sponsor does not have a good understanding of the project, they may commit insufficient time or resources to it at the outset. Covid has accelerated the need for businesses to transform themselves, which has put yet greater demands on projects to be completed quicker than may be feasible.
- Evolved customer role – in traditional outsourcing the IT or business function is often transferred, redeployed or made redundant. In the new wave of projects (especially agile), the customer team often remains heavily involved and must retain or hire talented people. This ongoing challenge has been exacerbated by aggressive hiring by the big tech companies and mobility issues following Brexit. Without the right people, the customer is more likely to miss gaps in requirements or to fail dependencies the supplier imposes on it, causing project delay or failure, and disputes with the supplier(s) as to who is responsible.
- Complex ecosystems – in a continuation of multi-source and SIAM trends, digital transformation projects often involve multiple supplier contracts. It can be difficult to define and manage the parameters of, and handoffs and interconnections between, the suppliers’ respective scope and responsibilities, with gaps only becoming apparent near the “go live” date, by which time the project may be delayed or failing, with the finger of blame pointing in a number of directions.
- Emerging tech – many projects focus solely on the enabling technology itself and not the purpose it is meant to fulfil. This can lead to disappointment when the technology implementation does not deliver any real business change. This approach can cause other issues: for example, a heavily regulated customer implementing a new communications system may not think through compliance implications of new types of data collection or the need for new security architecture, requiring a rethink of the project mid-flight.
Does the typical outsourcing contract help or hinder digital transformation?
While the contract terms are not usually themselves the cause of failure, market norm outsourcing contracts are not always a good fit for the new wave of digital transformation focused projects we see coming through.
Consider:
- Do outsourcing contracts sometimes drive the wrong behaviours between the parties, seeking to dictate how the service should operate rather than reflect how the parties think it will operate? Do we properly involve delivery teams to help ensure the contract reflects how the project can most effectively be implemented in practice? For example, a contractual agile process that is never looked at by the product owner or followed by the agile teams. Or contracting for a series of phased transition milestones when the delivery teams prefer parallel waves of migration.
- Do contracts help the parties manage the uncertainty that is common at the outset of a project? Digital transformation projects often require a period of post-signing requirements-gathering or diligence to better understand the change that needs to be delivered. Do contracts too often fail to make provision for these steps, and instead put the risk on one party for what is really a joint risk?
- Are the governance and reporting terms focused on issue-spotting and early warning of problems before they happen? Or are suppliers and their sub-contractors reluctant to be transparent for fear of being alleged to be in breach, resulting in ‘green dashboard’ reports which obscure an impending delay?
- Is the formal change process always appropriate for all types of change? On digital transformation projects, the parties may wish to leverage changes in technology or realign to address the evolving business environment. But too often the change process is drafted in a way that has negative consequences for time and cost, which drives defensive behaviour at a time when a change is necessary to get the project back on track.
Setting up the contract to deliver a successful digital transformation
The particular challenges of keeping digital transformation projects on track mean that parties should consider fresh approaches to the standard form when negotiating the contract with a view to improving the chances of success – or at least makes problems easier to manage when they inevitably arise. Here are our examples below:
- Cultural fit and team-building – agile projects, in particular, often fail due to the parties being the “wrong fit” for each other. It is hard to get this right during the procurement phase given its focus on evaluation of and negotiation with the supplier. To counter this, we could refocus the early stages of the contract (or a short term enabling contract) on team alignment and culture, incorporating time for the cross-party team-building and creation of a shared vision and direction that is imperative to a successful delivery. If they do not work well together, the parties could walk away without penalty, knowing they have avoided the prospect of failure due to cultural misalignment. If it works well, the parties have a solid basis and shared understanding on which to work together over the rest of the contract. Contrast this with the common approach of requiring substantive work to progress immediately upon (or even before) signature without these necessary human elements first being in place.
- Managing uncertainty – parties are often under pressure from senior executives to sign the contract before the project scope and requirements are fully understood. The customer fears allowing assumptions that could mean the time and cost it wants will not be met. The supplier fears its bid estimates will not be deliverable. To address this, the contract could build in an initial process for the parties to co-operatively finalise requirements based on pre-agreed pricing principles. Or a short-term discovery contract could enable further diligence before a full-length contract is executed. While still rare, when adopted we find these approaches can allow senior stakeholder commitments to be met while reducing the risk of uncertainty about scope or requirements. On managing change during the term, while some process is justified to maintain control, change procedures should be set up and exercised in a way that recognises that change is inevitable on complex transformations.
- Incentivisation – digital transformation is often done to improve the customer’s bottom line and many customers want their suppliers to have “skin in the game”. Often this involves the supplier taking on obligations to achieve (in whole or in part) the customer’s business outcomes. As this is heavily negotiated (and resisted by suppliers), genuine “win-wins” are rare. We can rethink contracts so as to genuinely incentivise each party. A pricing model that rewards a supplier where it has meaningful influence over business outcomes (for example, reduced time-to-serve achieved through the use of automation tools). An innovation fund that allows a supplier to invest its people’s time through agile sprints, rather than real money, reducing its risk but giving the customer a tangible benefit (after all, engineers want to solve problems). An IP regime that encourages information and innovation sharing, rather than risks the supplier losing valuable IP investments.
- Proactive remedies – we spend significant time negotiating the ‘hard’ remedies that would only be invoked in the event of a systemic or relationship-ending failure. The reality of digital transformation projects is that lower-level problems do arise and need to be dealt with before they snowball. We could spend more time on the mechanisms that can help get the project back on track (which is what the parties usually want), like early warning systems, fix-first settle-later, smarter reporting templates encouraging transparency, enhanced information provision, and multi-vendor issue resolution forums. In order to avoid their use accelerating a dispute, triggering these mechanisms could be decoupled from the need to show a contractual breach (for example, a likely upcoming delay or an incorrect scoping of requirements).
- Operationalising contracts – outsourcing contracts are not delivery manuals. We see good practices in parties creating post-signing contract guides and joint dependencies trackers, and holding workshops to train project delivery people in how the contract works. These tools make it more likely that the contract will be followed in practice and disputes are less likely to arise. The appointment of contract managers throughout the life of the contract is key, as is an executive team member accountable for ensuring contractual procedures are followed and contractual rights are exercised at the appropriate times. Using the contract smartly and effectively Even with effective terms and practical processes in place, problems cannot always be averted or readily resolved. The waters are often muddied where the parties have not exercised available contract rights in the interests of preserving the commercial relationship or failed to record project changes in accordance with the contract change process which often makes the factual matrix of a digital transformation dispute difficult to unpick. For digital transformation projects in particular, the diversity of the supplier ecosystem, complexity of the tech, collaborative processes (e.g. agile), enhanced customer role in delivery (compared to a traditional outsource), significant volumes of emails and instant messages, and high turnover of staff where the project is longer term, also create further challenges where disputes arise.
Parties frequently agree contractual processes and measures with the intention that they be exercised to assist with the resolution of disputes but are nevertheless often reluctant to utilise them to address problems for fear of souring relations. However, if the parties get culturally aligned (see above) that those contractual mechanisms and remedies can be an aid to project delivery rather than a pre cursor to a dispute in every instance, it may increase both parties’ willingness to exercise and engage with them. For example:
- Contract managers should be charged with monitoring performance under the contract, tackling issues and pursuing them to resolution, even if that means difficult conversations early on in the relationship. If issues are allowed to accumulate they become more difficult to unravel and resolve.
- Record compromises and changes in accordance with the change procedure. These procedures can be difficult to use given the range of exclusions and layers of bureaucracy. However, if set up so that they can be used proactively and regularly to course-correct projects and catch up with the evolving needs of the project, it is more likely the parties will agree changes rather than let the project fester and issue significant change requests as a last resort or defensive measure.
- Use the contractual delay / dependencies / relief mechanisms to manage delay.[2] The complexity of digital transformation projects often means there is not a single cause of delay (e.g. overlapping issues attributable to both customer and a web of suppliers) or at least not one that is easy to identify (e.g. ‘black box’ technology and processes masking root causes). When relief mechanisms are exercised the other party’s instinctive reaction is defensive. However, left unaddressed, delay issues are notoriously difficult to unravel later down the line. Triggering a contractual delay mechanism can be an effective way of drawing out the parties’ positions, including the underlying cause of the delay, allowing the parties to better understand what may have gone wrong, put corrective measures in place and reorient the project, potentially avoiding further delay or failure.
- Trigger governance and dispute resolution procedures. While this can be perceived as an aggressive move, these procedures can often be highly effective as they force the parties to take objective advice on their position, and mean significant issues are put in front of appropriately senior personnel. Where the escalation and dispute resolution procedures are sufficiently flexible, they can be a particularly good way of bringing multiple parties together in digital transformation disputes.
- Rights like audit and benchmarking can be seen as a precursor to a formal dispute, but again, they are there to be used to enhance the overall project. If the customer feels it needs more oversight of the service (e.g. because of the complexity of the service or ecosystem delivering it), or is concerned about issues like data security (e.g. because of new technology or use cases), exercising audit rights can give it the comfort it needs to continue. Similarly, where the customer expects innovation and new technology to provide price efficiencies, a benchmarking process can ensure ongoing value for the customer; if there is price protection for the supplier, effective use of benchmarking could actually sustain the commercial relationship for the long term.
As we hope to have shown in this article, the new wave of challenges posed by digital transformation outsourcing projects may require a fresh approach to the procurement, drafting and negotiation, and execution of outsourcing contracts to ensure that the contract enables – or at least does not hinder – the chances of a successful project outcome.
Referemces
[1] CIS General Insurance v IBM United Kingdom Limited (2021) EWHC 347 (TCC).
[2] In the CISGIL case, IBM did not exercise the relief clause, and the court rejected its case for an implied term that it was not responsible for delays caused by CISGIL because that clause provided a “complete code”
