Every firm has one. Sometimes they have several.
It starts with a genuine problem, fragmented systems, degrading workflows, mounting technical debt, a competitive disadvantage that's becoming impossible to ignore. The decision gets made: this needs a real solution. Something comprehensive. A programme that addresses the problem at scale rather than patching around it.
The scope gets defined. The budget gets approved. A delivery partner gets selected. The kickoff happens. There are decks.
Eighteen months later, the programme has delivered something. Whether that something is what was needed is a different question. Whether the original problem has been solved is often the question nobody is asking anymore, because by the time the programme ends, the organisation has moved on, the people who commissioned it have been reorganised or have left, and the scope has been so extensively adjusted that the original intent is barely recognisable.
This is not a failure mode. It's the standard outcome.
Why scale creates its own failure conditions
The appeal of a large-scale transformation programme is that it promises to solve the problem completely. No more incremental patches. No more workarounds. A clean, coherent architecture that actually reflects the way the business operates.
The problem is that this promise rests on an assumption: that you can know, at the beginning of an eighteen-month programme, what the end state should look like in sufficient detail to build to it.
In capital markets, this assumption is almost never valid.
The business is not static during the build. Market conditions change. Regulatory requirements evolve. The trading strategy shifts. People move. The desk that was the primary user of the new system looks different by go-live from how it looked at kickoff.
Technology is also not static. The platforms that were considered best-in-class when the programme was scoped have sometimes been partially superseded by better options by the time the implementation completes. Integration patterns that seemed straightforward in the architecture phase reveal unexpected complexity in the build phase.
Large programmes create a compounding problem: the longer they run, the more the assumptions that underpinned the original scope diverge from reality. By the time go-live arrives, the team is delivering against a specification that was written for a version of the business that no longer quite exists.
The sunk cost trap
What makes big-bang failure particularly difficult to address is the sunk cost dynamic that develops during a long programme.
By month twelve, a significant amount of capital has been committed. Career investments have been made, people have staked their professional credibility on the programme's success. The political energy required to challenge the scope, acknowledge the drift, and reset the direction becomes enormous.
So, the programme continues. Scope gets quietly adjusted, usually downward. The original ambitions get reframed as "phase two." The go-live happens and gets declared a success, even if the original problem hasn't been fully addressed. The team moves on. And some months later, someone notices that the workarounds are back.
I've watched this cycle play out in organisations that are sophisticated, well-resourced, and led by people who understood the risks going in. The issue isn't capability or intent. The issue is the fundamental unsuitability of the big-bang model for problems that are inherently dynamic.
What works instead
The firms that have genuinely improved their operational architecture, the ones where the transformation actually stuck, share a structural characteristic: they didn't try to solve everything at once.
They identified the specific points of friction that were most expensive, most risky, or most strategically significant. They addressed those first, with precision, at a scale that allowed them to move quickly and validate their assumptions before committing to the next step. Each improvement became the foundation for the next.
This approach is less dramatic. There's no kickoff champagne. There's no single programme to celebrate. There's just a series of targeted, well-executed improvements that compound over time into something that resembles the coherent architecture the big-bang programme was supposed to deliver.
The commercial discipline required for this approach is significant. It means resisting the temptation to scope everything simultaneously, which feels like progress but often isn't. It means accepting that the first improvement won't solve the whole problem, and that the whole problem will be solved through a series of steps rather than a single leap.
The question worth asking before you commit
If you're contemplating a large-scale technology programme, one question is worth sitting with before the scope gets locked and the budget gets approved: have you invested the same rigour in understanding the problem that you're planning to invest in building the solution?
Most firms spend months on architecture, vendor selection, and delivery planning. They spend weeks and sometimes days on diagnosis. The assumption is that the problem is obvious enough that it doesn't require the same level of investment as the solution.
That assumption is almost always wrong. And the cost of getting it wrong shows up, reliably, somewhere between months twelve and eighteen.