Category Archives: Digital Transformation

The UK Government Cannot Say What Its Own Digital Transformation Costs

Posted on by

Dame Chi Onwurah chairs the House of Commons Science and Technology Committee. In October 2026 she asked the government a question that should have a straightforward answer: how much is Whitehall spending on digital transformation. The government’s written response admitted its financial systems cannot produce that figure at all.

“The government cannot provide a clear picture of how much is being spent on digital transformation,” Onwurah said when the committee published the response on 22 October. “It’s concerning that they cannot show where the money is going or how value for money is being measured.” Her verdict: “This must be addressed as a matter of urgency.”

The admission landed five months after the committee’s own report, Rewiring the state: Delivering digital government, set out what better visibility should look like. That June report recommended a target of 75% of digital spending funded through departmental resource budgets rather than capital budgets, up from an estimated 43 to 46% in 2021. It proposed that the Government Digital Service and the Treasury take explicit, named responsibility for hitting that target, reporting on progress every year against a performance framework GDS would have to publish first.

The government’s October response agreed to consider improvements, “over time.” It did not agree to appoint a Government Chief Digital Officer at permanent secretary level, the single accountable owner the committee wanted for exactly this kind of visibility gap. It also declined to name which departments and public bodies have not adopted basic data hygiene practices, the groundwork any spending framework would need to rest on.

 

A Governance Structure Cannot Report What It Cannot See

A supportive PMO exists to do one job before any delivery decision gets made: show the people with authority to act what is actually happening, in numbers they can trust. That reporting function is not decorative. It is the mechanism that lets a steering committee catch an overrun before it becomes unrecoverable, lets a sponsor compare one programme’s return against another’s, and lets a board ask a specific, answerable question about where money went.

Remove that function, and every layer of governance built on top of it is reporting on a picture it cannot actually see. Whitehall’s own select committee just demonstrated this at national scale. It is not that ministers are hiding the number. The government’s own position is that its financial systems were not built to produce it. A structure cannot be held accountable to a figure that structure itself cannot generate, and no amount of escalation, dashboarding or steering committee attendance changes that while the underlying number stays unavailable.

Visibility failures rarely announce themselves. Nobody in Whitehall woke up one day and decided spending should be untrackable. It accumulated, system by system, department by department, each decision locally sensible and collectively opaque, until a select committee had to ask the obvious question out loud before anyone could confirm the answer did not exist.

 

The Same Pattern Shows Up in Supplier Risk

The committee’s related finding on vendor concentration makes the same point from a different angle. It called reliance on a small number of suppliers, Palantir chief among them, an “unacceptable point of weakness” in public sector data handling, and recommended the government trigger the break clause in the £330 million NHS Federated Data Platform contract when it becomes available in 2027. The government has neither committed to nor ruled that out. A spending framework that cannot track its own cost is unlikely to have tracked supplier dependency any better, because both are the same discipline applied to different data: knowing what you have committed to, and to whom, before someone outside the organisation has to ask.

 

What a PMO Should Take From This

None of this requires a government department’s budget to test. Any PMO can ask itself the same question Onwurah put to Whitehall: if a board member asked for the total current spend across every active transformation initiative today, could that number be produced within a day, with a source for every pound in it. Few organisations answer yes immediately. Fewer still have a named owner accountable for making that answer better next quarter, the way the committee wanted GDS and the Treasury to be.

Resistance Is the Data

Posted on by

When a technology programme meets resistance, the standard response is to escalate the change effort: more communications, more training sessions, more stakeholder workshops. The assumption underneath all of it is that resistance is the obstacle, something to be persuaded, equipped or managed past.

That assumption is usually wrong, and acting on it tends to make the programme worse. Resistance to a technology implementation is not noise in the signal. It is the signal.

 

What Resistance Is Actually Telling You

BCG’s 2020 survey of 825 senior executives found that 70 per cent of digital transformations fall short of their objectives. Bain’s 2024 Transformation and Change Survey of more than 400 executives put the figure higher still, at 88 per cent failing to achieve their original ambition. The two surveys measure different things, but both point the same way. Those programmes were rarely undone by stubborn employees. Their implementation drifted from operational reality, and the people doing the work could see it before the programme team could.

When a clinical team pushes back on a new patient records system, they are rarely resisting technology itself. They are reporting that the workflow design does not match how the ward runs at three in the morning, or that the training schedule assumes competencies the ward does not yet have. A finance team resisting a new reporting platform is often reporting that it strips out a nuance the team relies on daily, one the requirements process never surfaced.

The people closest to delivery are often the sharpest diagnosticians of implementation risk a programme has, and under schedule pressure, programme teams tend to receive that diagnosis as obstruction rather than intelligence.

 

The Stakeholder Management Euphemism

The phrase stakeholder management carries a weight of assumptions worth questioning. In practice, it frequently means: how do we get these people to comply?

The vocabulary gives it away: stakeholders segmented by resistance level, engagement plans that move people along an adoption curve, communications calibrated to reduce objections. The apparatus treats resistance as something to overcome rather than something to process.

Cornerstone OnDemand’s 2024 workforce readiness research found that 63 per cent of UK executives regard their own workforce as unprepared for change, and that employees without proper access to training were five times more likely to report difficulty adapting. That gap is a programme design failure. The workforce did not create it.

Whatfix’s survey of more than 1,100 software users found that 51 per cent had no role-based onboarding or support when a new system went live, and 78 per cent felt they lacked the expertise to use their daily tools properly. The investment did not happen. The resistance did.

 

What Good CIOs Do Differently

The best technology leaders share a habit: they treat early resistance as a discovery mechanism rather than a threat. When a pilot site pushes back, the first useful question is what the pilot site is seeing that the programme team is not, rather than how to handle the resistance.

That reframe slows the rollout and demands real engagement, but it catches design flaws at pilot cost instead of full-deployment cost. Decades of change research have produced one widely repeated adoption-failure statistic after another, none traceable to a verifiable source. The underlying point holds regardless: resistance is useful information, whatever number gets quoted beside it.

 

Change Fatigue and the Portfolio Problem

Reading resistance accurately gets harder inside an organisation running too many programmes at once. Prosci has benchmarked change saturation since 2007, and its latest research found 73 per cent of organisations near, at or past that point.

That is a portfolio problem wearing a change management label. Resistance to one programme, under those conditions, is often resistance to being asked to run faster on a track that is already full.

 

Reading the Room Before It Becomes a War Room

Before a programme leaves design, ask the people most affected a blunt question: what about this will not work? The phrasing matters. “What concerns do you have?” invites the polite version of resistance. “What will not work?” leaves no room for one.

Asked honestly, that question surfaces operational objections while they are still cheap to fix. Most of the time, the people who will resist a programme know it has problems before the programme team does. The only real question is whether the programme is structured to hear them, or finds out after go-live, when the resistance has nowhere left to go but into next year’s failure numbers.

EasyJet Fixed an Age Bias in Recruitment. Most Digital Transformation Teams Haven’t

Posted on by

 

The number of easyJet cabin crew aged over 50 has more than doubled since 2022, up 127 per cent, according to the airline’s own figures. EasyJet says crew aged over 60 have “almost quadrupled” over the same period, and the airline has opened a fresh recruitment drive for the 2027 flying season, with applications opening in September. Getting there took a deliberate campaign. A large share of potential applicants assumed cabin crew work was reserved for younger people, and easyJet’s Director of Cabin Services, Michael Brown, put the fix plainly: over-50s bring both the skills to do the job and “a wealth of life experience that is appreciated by our customers and colleagues alike.”

 

This Is a Bigger Problem Than One Airline

The Centre for Ageing Better’s State of Ageing 2025 report shows why that perception carries a cost well beyond one airline. The UK’s employment rate for 55 to 64 year olds sits at 65 per cent, against 75 per cent in the Netherlands and Switzerland and 81 per cent in Iceland. The wider 50 to 64 employment rate sits 14 percentage points below the 25 to 49 rate. Closing that gap by 2030 would add an estimated £9 billion a year to the UK economy and £1.6 billion in annual tax and National Insurance revenue, according to the same research. That is the scale of value sitting behind a single, correctable assumption about who is fit to do a job.

 

The Same Bias, Earlier and More Expensive

The same assumption shows up earlier, and more expensively, in technology. CWJobs, working with the Centre for Ageing Better, surveyed 2,000 UK workers plus 250 people in tech who had experienced age discrimination, and found that tech employees start experiencing age bias at 29 and are considered “too old” by 38, roughly a decade before most people reach senior delivery roles. Forty-one per cent of tech workers report observing ageism at work, against 27 per cent across other sectors. Forty-seven per cent say they weren’t offered a role because of their age, and 31 per cent say they were passed over for promotion for the same reason. “Digital skills shortages mean discriminatory attitudes against age makes no business sense,” CWJobs director Dominic Harvey said when the findings were published, a point that has only got truer as the skills shortage he was describing has continued.

 

The Bias Has Already Reached a Tribunal

In Selazar Limited v McCabe, a tech company’s 29-year-old founder was found to have instructed a recruitment consultant to find “a younger team member who was more in tune with a young tech start company” in place of the firm’s 55-year-old finance director. The tribunal awarded her £125,604.98, including £20,000 for injury to feelings, and heard evidence that the founder had also signalled to potential investors that she was “too old to understand” the business. The case puts a figure on the same instinct easyJet had to overcome in reverse: treating experience as a cultural mismatch with a “young”, “digital” or “agile” identity, rather than as a straightforward capability question.

 

What Transformation Programmes Are Actually Short Of

That instinct is expensive in a way that goes beyond tribunal awards. Transformation programmes run into trouble for reasons that have nothing to do with technical skill: unclear governance, resistance treated as a communications problem rather than early diagnostic information, decisions made by people who have never been accountable for the outcome. Institutional knowledge, stakeholder trust built over years, and the judgement to recognise when a plan won’t survive contact with how the organisation actually operates are not junior capabilities. Screening for “young and agile” screens that experience out at precisely the point a programme needs it most, and does so before anyone has assessed whether the person applying could actually do the job.

 

The Fix Was Never Complicated

EasyJet’s fix did not require lowering a bar. It named the specific bias, redesigned recruitment and onboarding around it, then published the retention data alongside the recruitment numbers rather than stopping at the headline. Technology employers already have research going back years, and a tribunal ruling now sitting on the public record, telling them the same bias exists inside their own hiring and promotion decisions.

 

The Question Worth Asking Before the Next Senior Hire

What’s missing isn’t evidence. It’s a leadership team willing to treat this as a workforce design problem rather than a hiring afterthought. Before the next transformation lead, architect, or programme director role goes out with language built around “energy” or “digital native” instincts, it is worth asking what specific capability that language is actually screening for, and whether the organisation can afford to keep losing the experience it screens out along with it.

Transformation Fatigue Is Not About the Number of Changes. It Is About the Absence of a Finish Line.

Posted on by

Most organisations diagnose change fatigue as a volume problem: too many initiatives running at once, too many change requests hitting the same team. The volume is real, but it isn’t the actual mechanism.

 

What the Volume Framing Gets Right, and Wrong

The average employee experienced ten planned enterprise changes in 2022, up from two in 2016, according to Gartner research reported in Harvard Business Review. Prosci’s long-running change-saturation research puts 73% of organisations near, at, or past the point where employees are running out of capacity to absorb more.

Those numbers are real, and the standard academic definition of change fatigue treats volume as the cause: “a perception that too much change is taking place.” A 2021 peer-reviewed study in Public Money & Management tested this directly across repeated public-sector reorganisations and found the number of prior changes predicted fatigue, mediated by uncertainty and workload.

That is the correct diagnosis for some organisations. It is an incomplete one for most.

 

The Mechanism That Volume Alone Doesn’t Explain

Deloitte’s 2026 Global Human Capital Trends research, covering 9,000 leaders across 76 countries, names the actual shift more precisely than a raw change count can. One-third of surveyed workers experienced 15 major changes in the past year alone, but only 27% of leaders say their organisation actually manages change well, and just 8% found their change and learning efforts highly effective. Deloitte’s own recommendation is a reframe, not a volume reduction: move from episodic “change management,” which assumes a start and a finish, toward continuous “changefulness,” because the assumption of a finish line no longer holds.

It is not just that there is more change. It is that employees no longer get the stabilisation phase that used to follow each change, the period where a new way of working became the way of working, before the next initiative started.

 

Why Closure Isn’t Optional

Kurt Lewin’s original change model, still the theoretical foundation for most modern frameworks, has three stages: unfreeze, change, refreeze. Refreeze is the stage where a new behaviour actually solidifies into habit, where people stop consciously managing the transition and start simply working the new way. Skip refreeze consistently enough, running one unfreeze-change cycle straight into the next, and nothing ever solidifies. Every process, every system, every way of working stays permanently provisional.

Psychologist Pauline Boss’s concept of ambiguous loss, a loss that is real but never gets acknowledgement or closure, was developed for grief, not transformation programmes. But the mechanism translates directly: what exhausts people is not the change itself, it is never getting to grieve the old way and fully arrive in the new one before being asked to leave that behind too.

 

What This Actually Means for Leaders Running Transformation

BCG’s own research on transformation puts a number on the stakes: only about one in four transformations succeeds in capturing both short-term and long-term value, while people-centred change management, done properly, increases the odds of sustained improvement by up to 90%. Most of that people-centred work gets spent managing the volume of change. Almost none of it gets spent deliberately building in stabilisation points, the moments where a team is told, explicitly, that this phase is genuinely done.

The fix is not necessarily fewer initiatives. Some organisations doing fine with a high change volume have simply built real closure into the cadence: a defined point where the previous change is declared stable, celebrated as finished, and left alone for long enough that people stop bracing for the next disruption to hit the same process again.

 

The Question Worth Asking Before the Next Initiative Launches

Before adding another initiative to the roadmap, the honest question is not whether the organisation can absorb one more change. It is whether the last one was ever actually declared finished, or whether it’s still technically in flight, quietly compounding on top of whatever comes next.

Most transformation fatigue comes down to a single sentence leaders rarely say out loud: this is done, and it is going to stay this way for a while.

The Programme Succeeded. That Was the Problem.

Posted on by

Most digital transformation programmes are designed to end.

That is the actual design flaw. Not the technology chosen, not the budget allocated, not even the ambition behind the initiative. The programme itself is structured around a finish line, a go-live date, a steering committee sign-off, a moment when the work is declared complete and the team disbands.

The problem is that the market, the technology, and the customer never agreed to stop moving at that point.

 

The Project Mindset Is the Actual Liability

Transformation programmes are built like construction projects. Define the scope, execute the plan, hand over the keys, move on to the next thing. That structure works well for building a bridge. It works badly for building an organisation’s capacity to keep adapting, because the moment the programme ends, so does the organisation’s active attention to the problem it was meant to solve.

A May 2026 Forbes Business Council analysis puts it plainly: treating digital transformation as a project sets the expectation that there is a finish line to cross. There is not. Markets keep moving. Customer expectations shift faster than any single programme can track. Data environments and operating models change shape well after the sign-off. A transformation programme with a defined end date is optimised for a world that stopped changing the day the programme closed, which is not the world any organisation actually operates in.

The Forbes analysis draws a comparison that holds up well: digital transformation works like fitness. When you stop, you atrophy. Nobody who has kept fit for a decade did it with a single twelve-week programme and then stopped. They built a habit that never formally ends.

 

What Continuous Capability Actually Looks Like

Tesla is the clearest large-scale example of what this looks like in practice. Tesla ships software improvements to vehicles already on the road through over-the-air updates, rather than treating the car’s capability as fixed at the point of sale. Autopilot and Full Self-Driving features are refined through frequent releases, often tested on a small subset of vehicles before wider rollout, rather than waiting for a full model cycle to bundle every improvement together. The car’s capability keeps changing for as long as the vehicle is on the road, never declared finished at any single point.

Most organisations do not need to ship software to a fleet of vehicles. But the underlying pattern is the same: small changes shipped continuously and tested before wide release, rather than large changes bundled into an infrequent big-bang release. That pattern is exactly what separates organisations still adapting years after their transformation programme closed from the ones still running the same processes the programme was meant to replace.

 

The Five Things That Actually Change

Shifting from a transformation mindset to a continuous one is not about abandoning structure. It requires deciding to do a small number of things differently, and doing them consistently.

Start with the conversation itself. The goal is not to convince stakeholders that transformation was wrong. It is to convince them that the current approach stops too early. Frame the shift as doing transformation properly, not as replacing it with something else.

Build modular, not monolithic. Large, all-or-nothing platform overhauls are exactly the kind of investment that locks an organisation into a single technology decision for a decade. Modular, scalable components can be replaced or upgraded individually as needs change, without requiring another multi-year programme to do it.

Treat learning as infrastructure, not an event. A single training push before go-live does not build a capability. Continuous training, embedded guidance, and space to experiment safely are what actually let people keep pace with a system that keeps changing.

Change what gets measured. Tracking project completion tells you the programme finished. It tells you nothing about whether the organisation can still adapt six months later. Track agility, the rate of continuous improvement, and customer outcomes instead, because those are the metrics that actually describe ongoing capability.

Build the feedback loop permanently. Regular input from employees and customers is not a phase of the programme. It is the mechanism that tells the organisation when the next adjustment is needed, and it only works if it never switches off.

 

The Question Worth Asking Before the Next Transformation Sign-Off

Before the next transformation programme gets a steering committee sign-off and a closing date, the honest question is whether the organisation’s capacity to keep adapting exists independently of the programme that is about to close, not whether the scope was delivered.

If the answer is no, the programme did not fail to transform the organisation. It succeeded at exactly what it was designed to do, and the design was the problem.

Your Transformation Programme Is Burning Out the People Who Are Supposed to Deliver It

Posted on by

Most digital transformation programmes are designed to transform the organisation. The people carrying that transformation are expected to adapt around it.

That sequencing is the problem.

The burnout, the disengagement, and the resistance that characterise most large transformation programmes trace back further than communication or change management execution. They are downstream consequences of decisions made at the very start of the programme, when the workforce was treated as a delivery resource rather than as the primary constraint to be understood before anything else was designed.

The result is predictable. BCG’s own analysis of digital transformations found that only 30% fully succeed, 44% create some value while missing their targets, and the remaining 26% deliver little or nothing. Bain’s most recent research goes further: 88% of leaders are confident their reorganisation will deliver, but only 36% of the employees actually working inside it agree. McKinsey’s analysis consistently identifies culture and people factors, not technology underperformance, as the primary driver of transformation failure. Its survey research puts a number on one specific piece of that: when senior leaders personally model the behavioural changes they are asking employees to make, the transformation is 5.3 times more likely to succeed.  And yet most programme designs continue to treat the technology as the dependent variable and the workforce as a constant.

The workforce is the one variable that determines everything else.

 

The Capacity Crisis That Everyone Can See and No-One Will Name

66% of American employees reported experiencing burnout in 2025, an all-time high. The rate is worse among the workers most exposed to change: 81% of those aged 18 to 24 and 83% of those aged 25 to 34 report burnout, against 49% of workers aged 55 and older, precisely the cohort most transformation programmes lean on hardest to adopt new systems and new processes.

Only 31% of US employees were actively engaged at work in 2024, the lowest rate recorded in a decade, and 17% were actively disengaged. Gallup’s mid-2025 data puts engagement at 32%, effectively flat rather than recovering.

These numbers describe the actual workforce that transformation programmes are asking to do additional, unfamiliar, and often stressful work on top of existing commitments, not some abstract backdrop to the real business of delivery.

Most large transformations run in parallel with business as usual. The assumption, rarely made explicit but almost always present in the programme design, is that the existing workforce will carry both. The system analyst who is supporting the live operation and attending the new system design workshop and completing their module in the learning platform and updating their change readiness survey: these activities all draw from the same finite capacity. And when that capacity is already under strain, the transformation gets what is left.

 

Where the Design Failure Actually Happens

The standard response to workforce resistance and burnout in transformation programmes is to commission more change management activity. More communication. More engagement events. More of the same interventions applied harder.

The reason this rarely resolves the problem is that it treats the symptom, disengagement, resistance, fatigue, as the cause. It does not address the underlying design decision that produced the symptom.

The design failure is earlier and more structural than change management can reach. It happens when the programme scope is defined before anyone has seriously assessed what the existing workforce is currently carrying, what discretionary capacity genuinely exists, and what the realistic absorption rate for change actually is in this organisation, at this time, in this context.

Prosci’s research on sponsorship effectiveness found that projects with highly effective executive sponsorship are almost 3.5 times more likely to meet or exceed their objectives than projects with weak sponsorship. That finding is routinely misquoted as being about change management activity in general, when it specifically measures the quality of sponsorship: the extent to which senior leaders visibly own the change, actively communicate its rationale, and stay engaged with it once the initial announcement has faded. Sponsorship of that kind is a design discipline applied from the beginning, shaping the scope, the pace, the sequencing, and the ask on the workforce before the business case is finalised, not a communications workstream bolted on afterwards.

 

The Three Decisions That Set the Conditions

There are three decisions made at the start of most transformation programmes that determine whether the workforce becomes an enabler or a constraint. All three are made before the first delivery milestone is reached. And in most programmes, all three are made in a way that prioritises ambition over capacity.

The first is scope. The scale of a transformation programme is typically determined by what the organisation wants to achieve and what the technology enables. The workforce’s current capacity, existing obligations, and realistic absorption rate are rarely weighted with the same rigour. A scope that is technically achievable but humanly unsustainable will fail through attrition, quality erosion, and the slow withdrawal of discretionary effort.

The second is sequencing. The order in which change is introduced to the workforce matters more than most programme designs acknowledge. Asking the same population to absorb multiple concurrent workstreams, new system, new process, new skills, new reporting lines, compounds the cognitive and emotional load in ways that tend to surface as resistance but originate as exhaustion.

The third is investment in workforce capacity before deployment. The organisations that sustain transformation over time do not wait for resistance to emerge and then address it. They assess the workforce’s capacity constraint honestly at the outset and make deliberate investments, in backfill, in reduced BAU commitments during peak change periods, in genuine relief on existing obligations, before the transformation work begins.

 

The Longer View

The organisations that sustain transformation over time are rarely the fastest movers in the first twelve months. They are the ones still moving in month thirty-six, because the workforce has not burned out, has not disengaged en masse, and has not lost the institutional confidence that the programme will actually deliver.

Disengaged employees cost the global economy an estimated $8.8 trillion annually, roughly 9% of global GDP. Most of that is preventable. Not by communicating more, but by designing better, starting with an honest understanding of what the workforce can actually carry, and building the programme around that constraint instead of ignoring it.

The people are not the risk to be managed. They are the foundation on which every transformation outcome rests.

Design around them first.

The NHS Just Handed Every Transformation Leader a Very Expensive Lesson

Posted on by

 

Four NHS trusts have now admitted their discharge delay figures were wrong. Not slightly wrong. The kind of wrong where numbers fall from the thousands to zero overnight, then climb straight back up within weeks, a pattern no functioning hospital produces naturally. Those figures sat underneath NHS England’s proudest claim about its £330 million Palantir contract: a 15 per cent fall in delayed discharges, held up as proof the Federated Data Platform was working.

A Financial Times investigation has now found irregularities in the discharge data of 42 per cent of all NHS trusts, across four years of records. The UK’s statistics regulator, the Office for Statistics Regulation, is investigating how the figures were used to justify the technology. A cross-party group of MPs has written to ministers urging the government to use the contract’s break clause, which the government can exercise from February 2027. And NHS England’s own chief executive, Sir Jim Mackey, told a select committee this week that he had personally challenged whether the benefits claims “have been objective and can be fully stood up if challenged.”

The person running the organisation just told Parliament, on the record, that he isn’t confident the headline number survives scrutiny. That’s a long way past a minor caveat.

It doesn’t stop at discharge delays either. A separate Freedom of Information request from the campaign group Foxglove found that close to a third of trusts using the platform’s scheduling tool carried out fewer procedures after adopting it than before, and that a single trust, Chelsea and Westminster, accounted for 84 per cent of the reported fall in outpatient waiting lists across the entire programme. One hospital’s good year, dressed up as a national result.

I’ve sat in enough steering committees to know exactly how this happens. And it isn’t really a story about Palantir.

 

The Data Was Never Built to Do This Job

Charles Tallack, formerly head of operational research and evaluation at NHS England, put it plainly: the evidence for the platform’s impact “looked increasingly flimsy.” His reasoning matters more than the headline. “The delayed discharge dataset may be suitable for day-to-day management purposes, but not for evaluation,” he said.

That’s the whole story in one sentence. NHS England’s own website admits the data undergoes only “minimal validation”, because the speed of collection doesn’t allow for more; it’s explicitly badged as “fit-for-purpose” for NHS management information.

It was built so ward managers could see who needs discharging today, not so a select committee could weigh whether a £330 million technology contract earned its keep. Those are two different jobs, needing two different levels of rigour. Somewhere along the way, one got quietly substituted for the other.

Every transformation leader has watched this substitution happen. Operational dashboards get repurposed as benefit trackers because they’re already there, already live, already familiar to the room. Nobody sits down and consciously decides to treat management data as evaluation-grade evidence. It just drifts that way, one board pack at a time, until a number designed to flag today’s bottleneck is being quoted as proof a nine-figure programme delivered its business case.

 

When the Numbers Look Too Clean, Get Suspicious

A drop from thousands of delayed discharges to zero, then straight back up, should never have made it into a report unchallenged. That’s not an improvement curve. That’s a data pipeline breaking.

I’d go further: any benefit metric that moves in a straight line, with no noise, no seasonality, no awkward months, should raise your suspicion before it raises your confidence. Real operational change is messy. It has plateaus, regressions, a bad winter, a strike, a system outage. A number that behaves too perfectly is usually telling you something broke upstream, not that something improved downstream. And a national result that traces back to one outperforming site, as the Foxglove data suggests happened here, is a local win being marketed as a systemic one.

 

Whoever Owns the Contract Shouldn’t Own the Evidence

The underlying dataset sits with NHS England, not Palantir. But that’s precisely the point worth stressing. The organisation whose reputation, and whose vendor relationship, depended on this figure looking good was also the organisation compiling it, with minimal quality checks, and no independent evaluation running alongside it until the regulator forced the question.

One NHS official told the FT that trusts “are being asked to put their name to statements about improvements before the tools are fully embedded and before the evaluations are done.” Read that twice. Governance failed here. Data quality is just where it happened to show up first, and I’ve seen it inside plenty of transformation programmes that had nothing to do with the NHS or with Palantir.

If the same team that needs the benefit case to land is also the team producing the evidence for it, the incentive to tell a good story will always beat the incentive to tell the true one.

 

Three Questions Worth Asking Before You Quote a Benefit Number Externally

Before any number from your programme reaches a board pack, a press release, or a select committee, it’s worth asking:

Was this dataset designed to answer the question I’m now asking of it, or was it designed for something else entirely and repurposed under pressure?

Who compiled this figure, and do they have a stake in it looking good?

Would this number survive an independent audit conducted by someone with no relationship to the programme?

If you can’t answer all three with confidence, what you’ve got is a hypothesis pretending to be a benefits case.

 

The Real Cost Isn’t the Contract

NHS England will likely survive this, whatever happens to the Palantir contract when the break clause opens in 2027. What’s harder to repair is trust in the next number this organisation, or any organisation, puts in front of Parliament, staff, or the public. Sir Jim Mackey said an objective review “would be helpful and necessary” but would take months. That’s months of every subsequent claim being read with one eyebrow raised.

Build your evaluation evidence with the same rigour you’d want turned on you, before someone else turns it on for you.

Your AI Initiative Isn’t Failing Because of the Technology

Posted on by

The technology works. That is almost never the problem.

Across most large organisations right now, AI pilots are running. Proof-of-concepts are producing results that make it into board presentations. Vendor demos are impressive. The innovation team is energised. And then, somewhere between the pilot environment and actual production, the whole thing quietly stops.

According to Deloitte’s 2026 State of AI report, drawn from more than 3,200 business leaders, only 25% of organisations have moved 40% or more of their AI experiments into live production. That number deserves to sit with you for a moment. Three in four organisations are running AI experiments that have not become operational capability. The technology is not the constraint. Something else is.

You Have Seen This Before

If you have been in transformation long enough, this pattern is not new. It is the same pattern from every large ERP programme that never fully went live. Every data platform that became a reporting tool rather than a decision-making engine. Every digital transformation that delivered a new front end while leaving the back-office processes unchanged.

The technology becomes the story because it is visible, measurable, and exciting to talk about. The execution conditions that determine whether the technology actually delivers are harder to photograph and harder to put in a slide: ownership, integration, adoption. So they get managed as a substream, treated as implementation detail, and quietly become the reason the initiative stalls.

This is not an AI problem. It is an execution problem that has found a new context.

Ownership Is Not a Committee

The single most common structural failure in AI deployments is diffuse accountability. Someone owns the technology. Someone owns the data. Someone owns the security review. Someone owns the business case. Nobody owns the outcome.

Committees do not drive production deployments. They review them, adjust them, query them, and occasionally approve them. The organisations that close the gap from pilot to production consistently have a single named individual who is accountable for whether the capability lands in the hands of users, works as intended, and is actually being used. Not a steering group. Not a centre of excellence. One person with the authority and the obligation to make it happen.

This is not a preference for a particular organisational design. It is what the evidence shows, consistently, across every transformation context where the accountability question has been seriously investigated. Singular ownership is not sufficient on its own. But its absence is almost always present when a deployment fails.

The Metric You Are Probably Not Tracking

Most AI initiatives are measured on model accuracy, inference speed, and technical performance. These are valid measures of whether the technology works. They are not measures of whether the initiative is delivering value.

The question that actually determines success is adoption. Is the tool being used? By how many people? How often? Has it changed the decision they were making, or is it an additional step they complete before making the same decision they always made?

Deloitte’s 2026 data found that despite AI tools being available to approximately 60% of the workforce in organisations surveyed, fewer than 60% of those workers actually use them regularly. Access is not adoption. Availability is not value. If you do not have an adoption metric from day one, not a plan to measure adoption eventually but an actual metric that someone is accountable for, you are measuring the wrong thing and you will find out too late.

Scope Is Your Production Variable

There is a reason pilots succeed and production deployments struggle. A pilot can be run by a small team, in a controlled environment, with curated data, limited integrations, and a sponsor who is personally invested in making it work. Production is fundamentally different. It requires integration with existing systems that were not designed for this. It requires security and compliance review. It requires monitoring, maintenance, and the ability to handle the variability of real-world use at scale.

The organisations that consistently move from pilot to production do one thing differently: they scope production more narrowly than they scoped the pilot. Not because they are being unambitious, but because a narrow, fully integrated, fully adopted capability that actually works is worth ten pilots that demonstrated potential and then stalled in the transition.

Start smaller in production than you think you need to. Prove the integration. Prove the adoption. Then expand. The ambition for scale is valid. The timing of it is where most programmes get it wrong.

The Pattern Closes the Same Way Every Time

The 54% of organisations that Deloitte found expecting to move the majority of their AI experiments to production within three to six months are not describing a plan. They are describing an aspiration. The organisations that will actually close that gap are the ones that address the execution conditions, not the technology stack.

Singular accountability. Adoption as the primary metric. Scope narrowed deliberately in production. None of these are technology decisions. They are leadership decisions, and they can be made before the next pilot is commissioned.

The technology is ready. The question is whether the organisation is.

 

The Problem With Your AI Strategy Is Not the AI

Posted on by

The boardroom conversation has shifted. Not to whether AI matters. That debate is over.

The new question is what to actually do with it. And the 2025 data suggests most organisations are answering it badly.

BCG’s research found that 60% of companies globally are generating no material value from AI despite significant investment. McKinsey’s 2025 State of AI survey found that nearly 80% of organisations are regularly using generative AI in at least one function, yet only around 5% are seeing substantial financial returns. The gap between AI as a boardroom announcement and AI as a functioning operational capability is the defining management challenge.

 

The pressure is real. The direction is not.

Executives are asking about AI. Vendors are selling it. Competitors are announcing it. Boards are expecting it.

And in the middle of all that noise, organisations are launching AI initiatives without defining what success looks like. That is not ambition. It is drift with a budget.

The fear of being left behind is understandable. But speed without clarity produces activity, not results. And activity without outcomes is expensive.

RAND Corporation’s 2025 research into AI project failure found that 80.3% of initiatives failed to deliver their intended business value. A third were abandoned before reaching production. A further 28% reached completion and still failed to deliver. The problem is not a lack of investment or effort. It is a lack of clarity about what the investment is actually for.

 

Most organisations are starting in the wrong place

The most common mistake in AI adoption is starting with the tool rather than the problem.

The conversation usually begins with: “What AI platform should we procure?” It should begin with: “What is broken and where?”

AI is not a business objective. It is a capability. And capabilities only create value when they are pointed at something real.

BCG’s research found something that cuts against the instinct of most organisations. The organisations generating real value from AI average 3.5 use cases. Those generating no value average 6.1. More is producing less.

The organisations getting results are not asking which platform to buy. They are asking where their people are losing time to work that should not exist. Where good decisions are being slowed down by fragmented information. Where a process that should take hours takes weeks because nobody has questioned whether it needed to be that way.

That is the right starting point. Not a procurement conversation. A diagnostic one.

 

AI exposes what you were already avoiding

Many leaders believe AI will fix their inefficiency problem. It will not. It will make it harder to ignore.

Unclear processes do not get fixed by AI. They get amplified by it. Poor data quality does not improve because a model has been deployed on top of it. Weak governance does not disappear. Siloed departments do not start collaborating because there is an AI tool in the mix.

The evidence on data readiness is striking. Cloudera and Harvard Business Review Analytic Services, surveying enterprise organisations in early 2026, found that only 7% said their data was completely ready for AI. More than a quarter said it was not ready at all. Gartner estimates that 60% of AI projects unsupported by AI-ready data will be abandoned through 2026.

The obstacle in most AI projects is not the technology. It is the organisation the technology is being asked to work inside. Not the model. Not the platform. Not the vendor. The organisation itself.

 

Fewer tools. More focus. Better results.

Buying advanced technology does not automatically create change. It creates the expectation of it.

Many organisations are deploying AI on top of environments defined by disconnected systems, inconsistent processes and poor data. They are not implementing AI. They are automating the same dysfunction at scale, with a larger budget attached to it.

The organisations getting real value are not the ones running the most pilots. They have chosen a small number of problems that matter, built the right foundations to address them, and stayed focused long enough to see results. They do not announce it. They build it.

They also understand something most organisations have not yet accepted. AI should work in service of a clear business direction. If that direction is unclear, AI will not provide it.

 

Stop performing AI and start implementing it

A significant portion of what organisations call an AI strategy is AI theatre. Presentations. Innovation labs. Pilot programmes. Strategy papers. Announcements. And very little operational change.

IDC’s 2025 research found that for every 33 AI proofs of concept an enterprise starts, only four reach production. A March 2026 survey of 650 enterprise technology leaders found that 78% of enterprises have AI agent pilots running but fewer than 15% have reached production deployment. The pilots do not fail because the technology is immature. They fail because the hard work of creating the conditions for success was never done.

That hard work is not glamorous. It is redesigning how work flows. Making difficult calls about what to stop doing. Getting data into a state a model can actually use. Bringing people along rather than announcing change at them. None of it photographs well for a board update.

But that is what transformation actually looks like. The rest is performance.

If your AI strategy looks like a series of well-designed slides with no corresponding change in how work gets done, you do not have an AI strategy. You have a communication exercise.

 

The question every organisation eventually has to answer

Every organisation reaches the same moment. The excitement fades. The pressure increases. The questions get harder. And someone in that room finally asks: “What exactly is this improving?”

The organisations with a clear answer will accelerate. The ones without one will keep funding a future they never properly defined.

The question is not whether your organisation is using AI. Most are. The question is whether you can name, in a single sentence, the operational problem your AI investment is solving, and how you will know when it is solved.

If you cannot, the technology is not the problem.

The Most Important Leadership Skill in 2026 is Knowing What NOT to Automate

Posted on by

 

Every company now has access to the same AI tools. The same large language models. The same automated workflows. Efficiency has moved from competitive advantage to baseline expectation. If your edge is speed and scale, it is an edge almost everyone has.

The leaders who are winning are not the ones who automated the most. They are the ones with the discipline to stay manual where it actually matters.

 

The efficiency trap

The logic is seductive. If a machine can do it 90% as well at a fraction of the cost, the decision seems obvious. So you automate the feedback loop. You automate the check-in with a direct report. You automate the client thank-you.

But when you automate a human connection, you do not save time. You delete the value. If a process is designed to build trust and you remove the person from it, you have removed the trust.

Efficiency is the right lens for a workflow. It is the wrong lens for a relationship.

 

Three things you should never automate

1. Contextual mentorship

An AI can give a junior team member the best-practice answer. It cannot tell them how that answer sits inside the specific, messy history of your organisation, why a certain stakeholder is sensitive about a particular decision, or what is actually at stake in the conversation they are about to have. Leadership provides the why. The model provides the what. Those are not the same job.

2. Hard conversations

Gallup’s 2025 State of the Global Workplace report records global employee engagement at its lowest level since 2020. The cost: $10 trillion in lost productivity. The primary driver of that collapse is not strategy, pay, or economic uncertainty. It is managers. Managers account for 70% of the variance in team engagement. And manager engagement itself has fallen nine points since 2022, the sharpest sustained decline in years. The quality of the manager’s hardest interactions determines the majority of how engaged a team is. The performance conversation. The difficult feedback. The call that someone is not right for the role.

Automated performance reviews. AI-generated feedback. Algorithmically produced bad news. These are not efficiency gains. They are abdications. If you are not willing to sit with someone through a difficult conversation, you have not earned the right to lead them. Automation of conflict is one of the fastest ways to destroy a culture, and it tends to do it quietly, one avoided interaction at a time.

3. Visionary intuition

Algorithms are retrospective. They look at what has happened to predict what might happen. Leadership is prospective. It requires the willingness to take a risk the data does not yet support, to make a call before the pattern is clear, to back a direction the model would not have recommended.

A BCG and Harvard Business School study of 758 consultants using GPT-4 found that when tasks fell outside the model’s capability, consultants using AI were 19 percentage points less likely to produce correct solutions than those working without it. AI makes experienced people wrong more often when the problem requires genuine judgment. That is precisely where leadership is most needed.

If the algorithm is making your strategic pivots, you are not leading. You are following a script.

 

The question to ask before you automate anything

Stop asking whether something can be automated. Most things can. Start asking:

If the recipient knew this was automated, would they feel less valued?

If the answer is yes, keep it manual. That is the test. Not cost. Not speed. Not capacity. Whether removing the person removes the point.

 

Presence is the advantage now

Gallup’s 2025 report is plain about what the solution is not. More software will not reverse a decline caused by managers becoming less human. More meaningful human connection will.

In a landscape where everything is optimised, the things that are not optimised stand out. The intentional choice to spend time where it is not scalable is increasingly rare. That rarity is the advantage.

Efficiency gets you into the room. Presence is what keeps you there.

Stop trying to be a more efficient machine. Start being a more present human.