"There is nothing to be learned from the second kick of a mule." — usually credited to Mark Twain
I've spent around three decades leading technology-driven change, and I've been writing about why it's so difficult for 10 years. This piece is about one stubborn pattern that we all keep seeing, and why I'm now building Synapsefy, an organisational memory for project risk and learnings, to do something about it.
Organisations tend to operate in between two states. In 'Business as Usual (BAU)', the system is in equilibrium, and the goal is to keep it there. In 'Change', the goal is to move it to somewhere new, to meet a new regulation or simply to stay competitive. Through a systems-thinking lens, the problem is fairly clear. The feedback loops, structures and incentives that make BAU work are the same ones that resist change. That's why change so often stalls or fails outright.
There's an associated cost of getting it wrong.
In the UK, failing to change effectively is one of the most expensive problems that organisations face, and one of the least discussed.
In the public sector, NISTA's latest Major Projects Annual Report rates 18% of the Government Major Projects Portfolio as "red", meaning successful delivery appears unachievable. Those projects account for £244bn of whole-life cost, and the red-rated share has roughly doubled in two years. This follows a long line of write-offs, from the £11bn NHS National Programme for IT to the £469m FiReControl project. The National Audit Office has described "a consistent pattern of underperformance" spanning 25 years.
The private sector fares little better. Recent research from Emergn estimates that large UK businesses lose around £67bn a year on transformation and AI initiatives that fail to deliver.
Technology adoption has accelerated over the last 20 years, and again since GenAI went mainstream in late 2022. But while the technology changes, the causes of failure don't. Sponsors, the C-suite and delivery teams make the same mistakes. Organisational memory is short: the reasons for failure have usually occurred before, in similar circumstances, in the same industry, chasing the same end objective — and yet we repeat them. That's the second kick.
Three root causes
Our research points to three root causes that reinforce one another.
Cultural. Sponsors and stakeholders rarely prioritise strategic foresight. Even when a project carries significant risk of failure, behaviours tend to stay the same, and many senior stakeholders are unaware of their own responsibilities. Project managers are left isolated and overburdened: accountable for risk, but without the authority to enforce the actions that would avoid it. High staff turnover and heavy reliance on outside consultants or contractors exacerbate the problem — they take the learnings with them. What the organisation knows about its risks, and how it treated them, is routinely lost and then painfully rediscovered.
Procedural. The processes that are meant to counter this are weak. Failure avoidance is often confined to a small group inside the project team rather than shared across stakeholders. Projects and programmes are often initiated before anyone has considered the lessons from previous failures. Real learnings are rarely captured, and even more rarely applied as the work goes on, so the same issues resurface project after project.
Technological. Underpinning both is a tooling gap. In our survey, 97% of organisations relied on office productivity tools such as spreadsheets, which were never designed for this work. They encourage subjective scoring, give organisational learning nowhere to accumulate, and offer no way to carry risks and mitigations forward into the next project. Existing risk tools are good at recording risk. What's missing is something that carries the learning forward from one project to the next.
None of this is down to carelessness. In my experience the people involved are conscientious, busy and under real pressure. The lesson exists; it just isn't there at the moment it would help. As organisations, we're rather good at writing lessons down and not nearly so good at learning them, whether they're our own or someone else's.
The hot stove
Twain had a second observation that I think matters just as much:
"We should be careful to get out of an experience only the wisdom that is in it — and stop there; lest we be like the cat that sits down on a hot stove-lid. She will never sit down on a hot stove-lid again — and that is well; but also she will never sit down on a cold one anymore." — Following the Equator (1897)
Once bitten, twice shy. When organisations do learn from a failure, they often learn too much. One bad experience with a supplier, a technology or a way of working, and it becomes "we don't do that here", long after the reasons have gone. Nobody remembers why; everyone remembers to be wary. The hot stove becomes every stove.
So, there are two ways to get it wrong: not learning at all, or learning the wrong lesson so firmly that we stop taking sensible, calculated risks. The goal isn't to take less risk. It's to take the right risks, knowingly. When it's a hospital system, a public infrastructure project or a major change programme, we all pick up the bill, in money, in time and in public trust.
What Synapsefy does
That's what I'm building Synapsefy, here in Northern Ireland, to help with. In plain terms, it's an organisational memory for risk. When a new project starts, it flags the likely risks based on what didn't work previously and then ensures 'ownership'. Each project then adds to that memory, so the next team starts a little better informed than the last. Crucially, it carries the reasons, the mitigations, as well as the warnings, so a team can tell a hot stove from a cold one.
Synapsefy learns from the organisation's own project history, and pooled dataset, whilst ensuring that organisational confidential project data is protected.
As a solid 'tech optimist', I'm fairly sure this isn't mainly a technology problem. It's a human one. Most of us ignore advice that feels like being told off, and act on advice that feels like a word from a helpful colleague. So, we're designing Synapsefy with behavioural science in mind: suggestions rather than instructions, always open about why something has been flagged, and always the team's call in the end.
Where we are, and what I'm asking
I should be honest about where we are. Synapsefy is at proof-of-concept stage, there's a great deal still to learn, and no doubt we'll make a few mistakes of our own. I'll share those too; it would be an irony not to.
We're building it with and for the people who carry change risk: Project & Programme Managers, PMOs and portfolio leads, transformation directors, programme sponsors, SMEs and risk owners.
If you've ever sat in a lessons-learned session thinking "we've been here before", I'd be very glad to hear from you. I'm looking for a small number of volunteer organisations to help shape Synapsefy on real projects. If you are responsible for change in your organisation, via programme/projects, and failure keeps you up at night, please get in touch. A coffee and a conversation would be a great place to start.
References: Highways Magazine: NISTA major projects rated unachievable; BCIS: NISTA report findings; Civil Service World: Red-rated schemes now worth £198bn; The Register: NAO on 25 years of government IT; The Register: NHS IT failures; Parliament: Failure of FiReControl; IT Brief UK: £67bn on failed AI work; Management Today: Axelos £250bn; Global Security Mag: Fujitsu Digital PACT; BetaNews: 6point6 agile report; Pinsent Masons Out-Law: KPMG survey.








