Black Swans and Revelations: A Delivery Problem

Sit in enough steering committee meetings, in enough businesses, in enough countries, and you notice the same pattern everywhere. A transformation programme launches with real energy. A vision document, a kick-off event, potentially even a slide with a bold new operating model on it. Eighteen months later, a lot of that energy has gone into meetings, workstream trackers and status reports, and a smaller share of it than anyone expected has gone into anything a customer, employee or citizen can actually feel the benefit of.

No country, and no business, is short of ambition, strategy, or investment. What is far scarcer, everywhere, is the unglamorous discipline that turns any of that into something that actually lands with the outcomes intended and in the timescales promised to the board.

That is not a technology problem, it's a delivery problem and it shows up in businesses and organisations of every size, in every sector, in every country that has ever tried to modernise anything.

The numbers are bigger than most boards realise

This is not an issue affecting a handful of unlucky companies, when you step back and look at the bigger picture, its a scarily consistent view that comes into focus.

One UK-wide study, spanning banking, IT, manufacturing, engineering, construction, marketing and health, found that 31% of projects were considered at risk of failure at any given time, with the potential lost turnover to UK business running into the hundreds of billions of pounds. The Association for Project Management's most recent Business Leader Index, tracking 500 CEOs and managing directors across the UK, found delivery confidence had fallen sharply within a matter of months, varying enormously by sector. Whatever is driving that, is not a shortage of strategy documents or glossy slide-ware painting an appealing vision of the future. Boards do not lose confidence in a PowerPoint, they lose confidence in delivery and the people driving the change they seek.

The UK Government audits and publishes this more thoroughly than most, which is why its failures tend to make the papers. The National Audit Office has tracked the UK government's digital strategies since 1999, and its own analysis is blunt that the same transformation drivers of modernising legacy systems and joining up data keep showing up every time, which it treats as evidence of how hard delivery has proved rather than any shortage of strategy. That in itself is a useful public data point.

Black Swans, a weekend in April, and a morning in October

The private sector's version of this failure is just as dramatic. In April 2018, TSB Bank moved roughly five million customer accounts onto a new banking platform in a single weekend, a "big bang" cutover with everything switched at once rather than tested and implemented incrementally. The migration failed within hours. Customers were locked out of their accounts, some could see strangers' balances, and fraud attempts spiked to seventy times their normal level.

It took eight months to fully resolve.

TSB's chief executive resigned, its own chief information officer was personally fined by the regulator, and the total cost of the episode ran to roughly £330m, plus a further £48.7m fine from the regulators for failing to properly organise and control the programme. I genuinely feel for both the programme teams involved who had clearly been poorly managed / led and TSBs customers alike in that situation!

Six months earlier across the pond, the United States had run into an identical situation. HealthCare.gov, the online insurance marketplace at the heart of the Affordable Care Act, launched in October 2013 after being built and tested as one monolithic architecture, with no working version ever exposed to real users until the day it had to handle all of them at once. It collapsed within hours under a fraction of its expected traffic. A bank and a national government, on opposite sides of the Atlantic made the same decision and got the same result. The lesson has nothing to do with banking or healthcare, or with the UK or the USA. It is what happens whenever an organisation stakes everything on a single, untested moment of truth.

The private sector's version of the evidence is bigger in scale too, not just in a handful of famous cases. McKinsey and the University of Oxford studied more than 5,400 large technology projects across industries and geographies worldwide, overwhelmingly in the private sector. They found that, on average, large IT projects run 45% over budget and deliver 56% less value than originally promised and around 17% become what the researchers called black swans, cost overruns severe enough to threaten the future of the organisation running them.

It looks smaller in the mid-market. It isn't.

Across retail, FMCG, manufacturing, real estate and utilities, the businesses I have spent most of my time with rarely make the news when a project goes wrong. The same disease is there just as often, and it's more dangerous for being invisible, not less.

It shows up as the warehouse management system that has been "nearly finished" for two years. The EPOS rollout that made it to sixty stores and stalled. The CRM a consultant configured that half the sales team quietly avoids because it doesn't help, it only hinders. The platform that replaces forty spreadsheets, only for the data migration to fall apart against real-world edge cases nobody tested for, leaving multiple teams manually reconciling two systems for the next eighteen months. None of these make a regulator's press release, but I've walked into companies over the last twenty years or so and found exactly these circumstances waiting for me.

Add up the licence fees for tools nobody fully uses, the SaaS subscriptions already being paid for on top, the manual workaround still running in parallel because the new system was never quite trusted, the years of drift and the bill is every bit as real as TSB's. It's just spread thin enough, across enough small decisions, that nobody is ever asked to explain the total. TSB's failure was expensive, but it was visible, priced and eventually put right under real regulatory scrutiny. A mid-market business that loses a year and a seven-figure sum to a failed system change simply absorbs it and the story never leaves the building. That means the entire burden of pricing the risk and learning the lesson falls on a board that, as this blog has argued before, usually isn't set up to do either.

Mid-market businesses actually have an advantage here, if they choose to use it. TSB had five million customer accounts to move at once, across a web of interdependent systems. HealthCare.gov had to plug into the IRS, the Social Security Administration and over 300 insurance companies, all on day one. That scale is exactly what pushes big organisations towards one enormous, high-stakes launch instead of a series of smaller, safer steps.

Scale explains the temptation. It doesn't fully explain why organisations actually give in to it. Underneath most of these decisions sit a handful of very specific, very human failures:

• The sponsor isn't shown a real alternative. Whoever signs off the programme is often given a single plan and a deadline, or at best one option thats had the most attention given to it (as the preference) and a couple of poorly thought through options, not a genuine choice between a big-bang launch and a phased one, with the risks of each set out honestly alongside the obvious benefits.

• Decisions are made at the wrong level. A call involving this much risk needs someone senior enough to be able to say no. Too often it gets confirmed several layers down, by people without the authority to challenge it and only reaches the top as a status update rather than a decision.

• The wrong people are holding the pen. Plans at this scale are frequently written by people who have never personally delivered a complex system change. The phased, lower-risk option is never seriously considered, because nobody drafting the plan has lived through what happens when it isn't there.

• Nobody owns the whole thing. HealthCare.gov had 55 separate contractors and no single person accountable for how the pieces fit together. Split delivery across enough suppliers and everyone can honestly say their part worked, right up until the moment the whole system doesn't.

• The deadline is fixed before the plan is. A launch date chosen for political or commercial reasons, before anyone has properly scoped the work, removes the option to slow down long before anyone gets the chance to recommend it.

None of this is an argument against outsourcing. Plenty of the businesses I work with rely on outsourced technology partners very successfully. These failures weren't caused by using suppliers. They were caused by nobody with enough experience and expertise being clearly accountable for the whole picture, which happens just as easily with an all in-house team.

A business with a few hundred stores or a few thousand customers doesn't carry TSB or HealthCare.gov's scale and complexity. There is far less excuse for it to fall into the same traps, when the safer, phased approach is so much easier to run at that size in the first place. A business turning over a few hundred million pounds does not have that bureaucracy to fight in the first place. When delivery still goes wrong at that scale, the cause is usually plainer and more fixable.

Proof it doesn't have to be this way

The most useful proof isn't that a different approach exists somewhere. It's that the same broken system, HealthCare.gov itself, was fixed within weeks using exactly the method this blog keeps coming back to. In the aftermath of the October 2013 collapse, a small emergency team, dubbed the "tech surge," took over the rescue rather than the original web of 55 contractors. Within two months they had fixed around 400 defects, taken the site's capacity from 500 concurrent users to 50,000 and cut downtime from 57% to 5%. Enrolments went from roughly 26,000 in October to 975,000 in December, and by the end of the first open enrolment period the following March, over 8 million Americans had successfully signed up.

Nothing about the underlying policy or the technology changed. What changed was the team; small, senior, empowered, working in short cycles against real usage data instead of a plan. That result was convincing enough that the White House created the US Digital Service the following year specifically to apply the same method elsewhere in government.

The UK reached a similar conclusion by a different route. The Government Digital Service, created in 2011, built GOV.UK the same way; small teams, working software judged on real use, published in the open. It became a reference point other countries' own digital service units have explicitly modelled themselves on. Two governments, on opposite sides of the Atlantic, arrived at the identical fix independently.

TSB drew a version of the same lesson, though its own turnaround was slower and far less visible than a public "tech surge." It built an IT function in-house from 2019 taking direct control over the third parties it depended on, rather than continuing to manage a critical system at arm's length through its parent company's supplier.

The lesson is not that better delivery requires a bigger budget or a more finely tuned strategy.

What delivery capability actually looks like

The organisations that reliably close the gap between ambition and outcome, whichever sector, size or country they sit in, tend to share a small number of habits.

• Small, experienced and empowered teams over grand programmes. A handful of accountable people who can actually make decisions consistently outperform a large programme structured mainly to manage risk and stakeholders.

• Phased delivery over a single cutover. Break deliverables down into the smallest possible component parts, test them rigorously and deliver them into a live environment incrementally.

• Named ownership of the outcome, not the announcement. Success should be measured in what changed for the customer or employee, not in whether the launch event happened on schedule.

• Strong sponsorship. The right decisions being made by the acocuntable leaders of the organsation, with more than status updates reaching those at the top.

• Working software over polished strategy. A service used by real people, however narrow, teaches you more in a month than another year of design workshops.

• Continuity of leadership and team. Delivery capability is built by people who stay long enough to be accountable for what they shipped, not rotated onto the next initiative before the consequences of a decision arrive.

None of these require a bigger budget or a bolder strategy. They require choosing delivery discipline over the comfort of another announcement, for long enough that it becomes how the organisation works rather than an exception to it.

The real cost of this pattern

This matters for the same reason inertia matters anywhere else.

An organisation that keeps announcing transformation without achieving it is not standing still. Somewhere else, a competitor is still moving, investing the same ambition into changes that actually ship.

The gap that results is exactly the kind this blog has described before: diffuse, deferred, never quite traceable to one decision and therefore the cost is never fully understood by anyone with the authority to fix it. For the mid-market business with no regulator watching, that gap is even easier to leave unpriced which makes it more dangerous, not less.

The uncomfortable conclusion is also the hopeful one. If this were a technology problem, it would need a technology solution: more investment, better tools, cleverer systems. It is not, and it never was. It is a delivery problem, which means it is a solvable one, and enough organisations (businesses and governments) have already proven exactly how to solve it.

Most organisations do not need their next strategy, they need the discipline to finish the ones they have already written down.