Technology disputes are governance disputes in an IT disguise

Technology disputes rarely begin when a system fails or a supplier relationship breaks down. When a disagreement emerges, it usually exposes governance problems that have been festering for much longer.  

For boards, the important questions are not simply what failed but what they can do to avoid the immediate issue getting worse, why the organisation allowed a manageable problem to become a strategic one, and how they can avoid similar obstacles occurring again.  

Technology risk has moved beyond the IT department  

Businesses increasingly depend on cloud providers, system integrators, managed service providers, cyber security specialists and AI vendors, connected through separate contracts, responsibilities and liability arrangements. The result is a delivery chain that many organisations neither own nor fully control.  

The increasing power and complexity of technology creates opportunity, but it also changes the nature of technology risk. As many business teams are now involved in acquiring technology, the risk of incoherent governance and contract management has increased. A marketing director approving a customer experience tool, a leadership team adopting an AI-enabled workflow, a procurement team selecting a new supplier, each is making a technology decision without necessarily seeing it that way.   

When something goes wrong, the dispute may not turn on whether a server or application failed. It is more likely to turn on who was responsible for preventing the failure, identifying warning signs and acting before the consequences spread. That makes technology governance a board issue and an IT issue.  

Most disputes begin with a mismatch

Disputes often arise more from mismatched expectations than from technical failure. Businesses may misunderstand the contract, neglect supplier management after signing, or leave key responsibilities unclear. Suppliers may misjudge their own technical or contractual capacity, obligations or resourcing. The result is a gap between what the business expected and what the supplier believed it agreed to deliver. 

A good contract is a structure for managing the supplier relationship and anticipating problems before they arise. But even a good contract is only as useful as the people managing the relationship’s understanding of it, their rights to require performance and how to use change management and dispute resolution options when issues arise. 

When a critical implementation fails, organisations often discover they don't have the clarity they expected about the responsibilities and obligations of the software provider, implementation partner and managed service provider. Each has different responsibilities and different limitations of liability than the board might have expected and different explanations for what went wrong. The business may still be pinned into the underlying vendor licence and continue to owe licence fees even though the integration has failed, while each supplier points towards another part of the delivery chain or back at the customer. By that stage, the board is unlikely to be concerned principally with contractual interpretation. Its immediate concerns will be keeping the business running, not who breached what.  

Supplier governance cannot end when the contract is signed. Throughout the relationship, the business needs to test the assumptions underpinning the arrangement, understand which risks it has accepted and why, and maintain credible exit options. It should also know what would happen if a critical supplier disappeared tomorrow, or if the business's needs or structure changes. Most importantly, someone must remain responsible for checking that the organisation’s understanding of the arrangement still matches how it operates in practice.  

Organisational overconfidence is the hidden risk

A recurring problem is that businesses assess the supplier, but not themselves. They assume they have the governance capability, contractual sophistication and project management discipline required for success. Only later do they discover they treated a strategic transformation programme like a routine supplier purchase.  

Before approving a significant investment, boards should test the organisation's capability: does it understand what it's buying, does it have the expertise to evaluate it properly, and does it know how emerging risks will be challenged and escalated.  

These questions should be answered before the contract is signed. Proper scoping, benchmarking and an honest assessment of organisational capability are often treated as obstacles on the way to a deadline. They are usually the safeguards that matter most.  

The supplier may focus on being paid and completing its contractual work, while the client is focused on receiving a system that works. Without governance that keeps both parties directed towards the same outcome, that divergence is where the risk of dispute becomes greatest.  

AI is widening the accountability gap  

AI makes this issue more urgent. Much of the current discussion is about capability, but boards should be equally interested in consequences. As organisations move from using AI to retrieve information towards using it to generate insight, influence decisions and shape customer interactions, the need for clear accountability increases.  

Many organisations are still applying governance designed for conventional software to systems that influence decisions and customer outcomes. The practical test is straightforward: if an AI-generated output causes financial loss, regulatory scrutiny, customer detriment or reputational damage, who owns the outcome? If nobody can answer clearly, adoption has moved faster than governance.  

Boards do not need to become AI specialists. They do need assurance that someone understands how the system works, what data it relies on, where human oversight sits and how material outputs are challenged.  

Contracts and insurance are not substitutes for control  

Businesses often overestimate the protection in supplier contracts and insurance because the question, 'what happens if this fails?', has not been asked precisely enough.  

A contract may determine which party carries a particular risk, but that does not prevent the risk from materialising or protect the business from the operational consequences. Boards should distinguish between allocating risk on paper and building the practical resilience needed to manage it.  

Supply-chain risk becomes more difficult to control with every additional supplier introducing new data access points, subcontractors and liability arrangements. Without scrutiny, businesses can lose sight of where responsibility starts and ends. The thrust of regulation is towards imposing greater obligation on businesses to have proper oversight of technology supply chain participants. This is becoming a board level obligation.   

Good governance also means controlling how problems are reported and who makes decisions on project trajectory, not letting a vendor set the terms of governance on its own project. 

Clear reporting that identifies the issue and the action required, rather than a volume of information that obscures both is essential. The culture supporting that structure matters just as much. Problems will occur, but concealing or delaying bad news can turn a manageable error into a governance failure.  

Build checkpoints before the crisis  

Take a moment to consider the technology provider lifecycle and how the business has managed technology over time. Look at the software and systems used today. Are they the same as five or 10 years ago? What has it cost to sign up to systems that were never fully implemented, or to hold licences beyond their useful life? A fraction of that spend would likely have paid for better governance and the expertise to manage technology change properly. 

Acquiring new technology and managing it effectively through a lifecycle is not just a technical issue, it is a governance issue and a team game.  

The Horizon scandal is a reminder that serious harm rarely begins with a single dramatic decision. It can develop through a chain of smaller errors, weak challenges and missed opportunities to intervene. The purpose of governance is to create genuine checkpoints at which someone sufficiently independent of the original decision can review the evidence, challenge the assumptions and intervene before the consequences become irreversible.  

Boards should agree what information they will receive if implementation begins to drift, who is responsible for escalating it and what threshold will trigger intervention. The purpose is not to expose directors to every technical detail, but to ensure that material risks reach the people able to act before the dispute becomes the only available response.  

Recognise the decision before it becomes a dispute  

Technology can assist analysis, automate a process or accelerate a decision. Responsibility remains human.   

Boards need to recognise when they should be involved in ensuring good governance. They should be clear that the strategy adopted takes account of the full technology lifecycle and is reflected in good process in the business.  

By the time parties are arguing about a contract, many of the decisions shaping the outcome have already been made. The businesses that avoid the worst of this aren't the ones with the most sophisticated technology. They're the ones who stopped treating governance as separate from it.