Most large IT programmes don't fail in the delivery teams. They fail in the boardroom — in the governance structures meant to oversee them. Understanding why is the first step to fixing it.
When a large IT programme fails, the post-mortem almost always points to the same places: unclear requirements, poor vendor management, inadequate testing, or technical debt accumulated over years of underinvestment. These are real problems. But they are symptoms, not causes. The root cause of most large-scale IT programme failures sits two or three levels above the project office — in the governance structures that were supposed to provide strategic oversight and never did.
Board-level governance of IT is one of the least mature disciplines in large organisations. Boards that would never tolerate a capital investment project without rigorous stage-gate reviews, independent assurance, and clear KPIs routinely approve multi-million euro IT transformations on the basis of a fifty-slide presentation and a vendor reference from a company in a different industry. The asymmetry is striking — and costly.
The core problem is not that board members are unintelligent or incurious about technology. It is structural. Boards are designed to make decisions based on standardised financial and operational reporting — languages that have been refined over decades into forms that non-specialist directors can interrogate meaningfully. IT programme reporting has no equivalent standard. Every programme produces its own RAG status reports, its own milestone definitions, its own risk registers. The result is that board members cannot compare one programme to another, cannot benchmark a supplier's claims against market norms, and cannot tell whether a "green" status report reflects genuine health or optimistic framing by a programme team under pressure to perform.
This information asymmetry is compounded by the pace of technology change. A non-executive director who built their expertise in logistics, finance, or manufacturing has no particular reason to know that the cloud migration approach being proposed is three generations out of date, or that the systems integrator presenting to the audit committee has a documented history of underestimating integration complexity. Without that knowledge, meaningful challenge is impossible — and meaningful challenge is the entire point of board-level governance.
Boards that govern IT programmes well don't necessarily have more technical knowledge. They have better information structures — and the discipline to demand them.
Across the IT transformation programmes we have worked with, board-level governance failures cluster around five recurring patterns:
Organisations that govern IT programmes well share a common set of practices that have nothing to do with the technical sophistication of their board members. They are structural and procedural, not knowledge-based.
The first practice is outcome-based approval. Programmes are approved not on the basis of technical scope or vendor proposals, but on the basis of precisely defined business outcomes, with explicit measurement criteria. "Modernise the ERP system" is not an approvable business case. "Reduce order-to-cash cycle time by 30% and eliminate three manual reconciliation processes that currently require 14 FTE" is an approvable business case — because the board can measure whether it has been achieved.
The second practice is independent assurance at milestone gates. No large programme passes a major decision gate without an independent review — conducted by parties with no commercial interest in the programme's continuation. This is not the same as the programme's internal quality assurance function or the systems integrator's own quality team. Independence means independence. The assurance function reports to the board, not to the programme sponsor.
The third practice is active sponsor accountability. Every large programme has a named executive sponsor who is held personally accountable for business outcomes — not technical delivery milestones. The sponsor attends steering committee meetings, not just board updates. When the sponsor changes, there is a formal handover process that includes the board's sign-off on the incoming sponsor's understanding and commitment.
When a large IT programme has already drifted into difficulty, the realignment process at board level typically requires three actions in sequence.
First: establish the true picture. Commission an independent programme health assessment — not from the incumbent systems integrator, and not from the internal programme team. The assessment should cover technical health, commercial position, delivery risk, and strategic relevance. It should be presented directly to the board, without filtering by the programme leadership. Boards are often surprised by what an unfiltered assessment reveals — not because they were deceived, but because the information structures they relied on were inadequate.
Second: make an explicit decision about continuation. A programme in difficulty is not automatically a programme that should continue. The board must assess whether the business case remains valid, whether the strategic objective is still the right one, and whether the remaining investment required is justified by the expected outcomes. Continuation is a choice that should be made explicitly, not by inertia.
Third: redesign the governance structure before restarting or continuing. The same governance structure that allowed the programme to drift into difficulty will allow it to drift again. Realignment requires structural change: new milestone gates, new reporting standards, new independent assurance arrangements, and in many cases a new commercial relationship with the delivery partner.
The most important reframe for boards governing large IT programmes is this: your role is not to oversee the delivery of a technology project. Your role is to own a strategic investment and ensure it continues to serve the organisation's strategic objectives. Technology delivery is the mechanism, not the purpose.
When boards make that shift — from technical oversight to strategic ownership — everything else follows. The questions they ask change. The information they demand changes. The accountability structures they put in place change. And the programmes they govern have a meaningfully higher probability of delivering what was promised, on time, within budget, and for the right reasons.
We help organisations build governance structures that work — from steering committee design to independent programme assurance.
Talk to us