Free
Illusions in the Boardroom
The board-level diagnosis
Illusions of Work
The operator manual
Reference
Big IT projects fail for two reasons: they are big, and they are IT projects. The first creates coordination overhead. The second repackages a business redesign as a delivery exercise, guarantees failure, deposits legacy, and ensures IT absorbs the blame.
Big IT projects fail for two reasons: they are big, and they are IT projects.
When the programme fails, and it will, the label determines where the blame lands. Not on the executives who packaged business change as a technology delivery. Not on the governance that split authority from knowledge. On IT, the function that was handed a problem it was never equipped to solve and held accountable for an outcome it was never authorised to design.
The label is not incidental to the failure. The label is the mechanism.
The numbers are not in dispute. A McKinsey and University of Oxford study of 5,400 large IT projects found that the average project ran 45 percent over budget and delivered 56 percent less value than predicted. One in six was a black swan: a cost overrun of 200 percent or more. Seventeen percent went so badly they threatened the existence of the company. Flyvbjerg and Budzier’s analysis of 1,471 IT projects at Oxford’s Said Business School found the same fat tail: one in six projects exceeded its budget by 200 percent. The Standish Group’s CHAOS data, collected across decades, consistently shows that large projects succeed less than ten percent of the time, while small projects succeed around ninety percent.
Project management literature attributes these failures to poor requirements, lack of user involvement, scope creep, inadequate executive support, and communication breakdowns. These are accurate descriptions of what happens. They are not explanations of why it happens. Requirements are poor because the people who understand the process are not in the room where the requirements are written. Users are not involved because the label assigned the work to a separate function. Scope creeps because nobody defined the process the system was supposed to change. Executive support is inadequate because the executive sponsors a programme, not a process. Communication breaks down because the label created two sides that must communicate across a boundary that should not exist.
The proximate causes are real. The structural cause is the repackaging.
A company decides to change how it processes claims, or fulfils orders, or onboards customers. The change requires redesigning a business process: who decides what, in what sequence, using what information, with what authority. That is an operating decision. It belongs to the people who run the business.
Instead, the company packages the change as an IT project. This is only possible because the organisation already treats the people who build its systems as a separate function from the people who run its business. That separation, described in The Separation, is the precondition. The IT project label exploits it. Requirements are written by people who will not build the system and handed to people who will not use it. A programme is created. Workstreams are defined. Governance is established. The actual design question, how should this process work, is never asked in a room where both the authority and the knowledge are present, because the label has assigned them to separate functions with separate reporting lines.
The repackaging is not a management failure. It is a governance convenience, and it determines in advance who will be blamed when the change does not arrive.
“The business” avoids owning the redesign. Redesigning a business process means an executive must decide how work should flow, which roles are necessary, and what should be measured. Those decisions are specific, testable, and attributable. They carry career risk. “We gave IT our requirements” transfers that risk to a function whose failure the organisation already knows how to process. The executive who sponsors the programme is accountable for securing budget and attending steering committees, not for deciding how the process should work. When the programme fails, the sponsor’s narrative is ready: IT did not deliver against the requirements. The requirements were sound. The design was never the problem.
Programme governance gets funded. A programme management office, consulting firms, integration partners, testing specialists, change advisory boards: an entire apparatus is created because the repackaging produces complexity that requires management. Each participant has a rational interest in the continued existence of the complexity. “Improve cross-functional programme governance” is a sellable engagement. “Collapse the structure that makes the programme necessary” is not. The supply chain is self-reinforcing: the consultancy recommends, the agency delivers appearance of delivery, the consultancy returns to assess. No firm in that chain can sell a recommendation that removes the need for the rest of the chain. When the programme fails, the consulting firms are already positioned to diagnose the failure, which produces the next engagement.
Finance gets a budget line. IT projects have costs, timelines, and milestones. Business redesign is open-ended and harder to price. The IT label makes the change legible to the annual budget cycle, governable through instruments finance already controls: capital allocation, quarterly reviews, benefit realisation frameworks. None of those instruments can see whether the business process actually changed, and finance has no reason to ask. When the programme fails, finance attributes the write-down to technology investment. The decision to repackage business change as technology delivery does not appear in the post-mortem, because finance has no category for it.
The board gets a survivable story. “The IT project failed to deliver” is a sentence the board can process. It implies a fixable cause: better vendors, better methodology, better programme management next time. “We never designed the process change because nobody in the room had both the authority and the knowledge” is not a sentence any steering committee will produce, because the steering committee is the structure that prevents both from being in the same room. The board commissions a lessons-learned review. The review recommends stronger governance. The next programme begins.
Nobody is exposed, because the blame has designated absorbers. The CIO carries the executive accountability for a change the business refused to own. The systems integrator carries the delivery accountability for a design nobody specified. The consulting firm that ran QA carries the quality accountability for requirements that were never tested against the process they were supposed to change. The vendor carries the product accountability for a product that was selected to solve an organisational problem no product can solve. Each absorber is replaceable. When the programme fails, the CIO is moved on, the integrator is replaced, the consulting firm is rotated, the vendor is swapped. The structure that produced the failure remains untouched, because the structure was never blamed. IT absorbs the blame, because absorbing blame from the rest of the organisation is what IT was set up to do the moment the company decided that the people who build the systems are not part of “the business.”
Once the business change has been labelled an IT project, the organisation stops managing the change and starts managing the programme. Requirements documents, architecture diagrams, status reports, and RAG dashboards are produced with increasing sophistication. The programme’s success criteria are defined in terms of its own output: deliverables completed, environments provisioned, milestones achieved. The dashboard shows green because the programme is delivering what the programme was set up to deliver. The business process has not changed. The dashboard cannot see this, because the dashboard measures the programme, and the programme measures itself.
Scale reinforces the effect. Add a PMO to track status across workstreams. Add a steering committee to hear summaries of what the PMO has summarised. Add a change advisory board to govern what the steering committee has approved. Each layer is individually defensible. The cumulative effect is a structure whose primary output is the management of its own complexity. The larger the programme grows, the more it resembles real work. The resemblance is the problem.
What organisations call “legacy” has two layers, and neither is what the label implies.
The first layer is the original systems, often built in the 1980s and 1990s by analyst/programmers who sat inside the business and understood the processes they were automating. These systems frequently still work, because the people who built them had both the domain knowledge and the technical capability in the same role. When organisations split that role into “the business” on one side and “IT” on the other, they discarded the combined analyst/programmer without anyone realising what it had been doing. The code survived. The conditions that produced good code did not.
The second layer is the residue of every failed IT programme since: partially migrated databases, integration layers connecting old and new, services running alongside the systems they were supposed to replace, configuration that nobody fully understands because the team that built it was disbanded when the programme closed. Each failed programme deposits a layer on top of the original systems. Each layer makes the next change harder, because the next programme must navigate not only the original process but the accumulated debris of every previous attempt to change it. The system grows more complex with each failure, and the growing complexity is cited as evidence that the next programme needs to be bigger: more workstreams, more governance, more coordination. The cycle compounds.
The pattern scales. The UK’s National Programme for IT attempted to digitise the NHS from the centre: a single programme, centrally governed, with an initial budget of £6.2 billion. It was dismantled in 2011 after costs exceeded £12 billion, having delivered a fraction of its intended value. The Public Accounts Committee called it “one of the worst and most expensive contracting fiascos in the history of the public sector.” The programme failed not because the technology was wrong but because a centrally governed IT project was the wrong structure for changing how thousands of local clinical processes work. The business change belonged to the clinicians. The programme belonged to a central authority that had no mechanism for learning what the clinicians needed.
An organisation with three decades of “legacy IT” is not an organisation that failed to modernise. It is an organisation whose original systems were built by people who were part of the business, and whose every subsequent attempt to change those systems was packaged as an IT project and handed to people who were not. The legacy is the product of the separation, not the cause of it.
The trap is that the legacy cannot be modernised incrementally, because the conditions for incremental improvement do not exist. Nobody owns the legacy systems, because ownership was never assigned to a person or a process; it was assigned to a programme that was closed. The business processes the systems implement are not documented, because the programmes that built them documented requirements and deliverables, not the process itself. “The business” cannot improve the systems, because it does not consider them its responsibility. IT cannot improve the process, because it does not have the authority to change how the process works.
Incumbent vendors compound the trap. They operate in two modes, both rational, neither helpful. The first is to protect recurring revenue: managed service contracts, support agreements, and maintenance retainers scoped around the existing complexity. A vendor maintaining a partially migrated estate with three integration layers and two generations of middleware has no commercial interest in the structural simplification that would halve the scope of its own contract. The second is to sell the next big programme: a managed migration, phased over three years, governed through a joint steering committee, using the vendor’s own tooling. The recommendation is structurally identical to the programme that created the legacy in the first place. Neither mode produces incremental improvement, because simplification would reduce both the recurring revenue and the case for the next programme.
The only intervention that can get funded is a new programme: large enough to justify a business case, labelled as IT so it fits the budget model, governed through the same structures that failed last time. Building a business case for incremental modernisation is nearly impossible when nobody can describe what the system does, who depends on it, or what the process is supposed to achieve. The business case requires precisely the ownership and documentation that the organisation has never produced. So it produces another programme instead. The cycle does not repeat because organisations are slow to learn. It repeats because the structure that produces the failure also produces the only available response to it.
The IT project label has survived decades of evidence against it because the failure it produces is organisationally useful.
When business change fails, someone must explain why the process has not changed despite years of investment. That conversation is dangerous: it leads to questions about authority, ownership, and whether the people governing the change understood the thing they were changing. When an IT project fails, the conversation is contained: vendors underperformed, requirements were complex, integration was harder than expected. The vocabulary of IT failure is mature, familiar, and blame-absorbing. The vocabulary of business design failure does not exist in most organisations, because the organisations have never tried to have the conversation.
The label persists because it converts a structural failure into a delivery failure, and delivery failures have a known remediation path: try again, with better governance, a different methodology, and a new set of consultants. The structure that caused the failure is never examined, because the label has already explained the failure in terms the organisation can act on without changing anything.
Not every large change can be incremental. Regulatory mandates, mergers, and platform end-of-life sometimes force scale. Deep technical specialisation is genuinely hard to maintain inside every business unit. These are real constraints, and the argument here does not deny them. What the argument denies is that the constraints explain the failure rate. Organisations that must make large changes can still assign the business change to the people who own the process and give them the engineering capability to execute it. The constraint is scale, not the label.
The big IT project exists because the organisation has no mechanism for small change. The business cannot improve a process it considers IT’s problem. IT cannot redesign a process it has no authority over. The only thing that can cross the gap between them is a programme, and programmes are big by definition.
The alternative is a structure that does not need a programme. When a single unit owns a business process end to end, including the people, the systems, the data, and the authority to change how the process works, incremental improvement becomes routine. The unit does not need a business case to fix a broken notification workflow, because the unit owns the workflow. It does not need a programme to change a decision sequence, because the people who understand the decision and the people who can change the system sit in the same team. Change is small, continuous, and owned. There is nothing to repackage.
The companion volumes, Illusions of Work and Illusions in the Boardroom, describe this structure in detail: what makes the unit real, what governance it requires, and where the model is hardest.
The IT project label survived for two decades because checking whether the programme’s artefacts matched operational reality was expensive enough to defer. AI changes that cost. A machine that reads the programme’s deliverables alongside the codebase, the deployment history, and the operational metrics can produce a reconciliation in hours. The gap between what the programme claims and what the system does becomes visible and attributable.
The question that follows is not “why did the IT project fail?” It is “why did we call it an IT project?”
See also: All articles · Illusions in the Boardroom · Illusions of Work