Category Archives: Management

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.

Deploy Now, Govern Later as a Strategy Just Expired

Posted on by

.

Nearly three-quarters of companies are planning to deploy agentic AI within two years. Only 21% of them report having a mature model to govern it.

That gap, not a headline percentage on its own, is the structural condition enterprise AI now operates under, according to Deloitte’s 2026 State of AI in the Enterprise report. The same report found that sanctioned AI tool access has grown 50% in a single year, from under 40% to around 60% of workers. Read those two findings together and the picture is not ambiguous: deployment is accelerating faster than governance can follow, and roughly four in ten workers still operate without any sanctioned AI tool at all, which is exactly the population most likely to reach for something unapproved.

Framing this as a planning problem, something to address in the next cycle, stopped being an accurate read of the situation in the first week of July 2026.

 

Why the Timing Changed, Not the Substance

The EU AI Act’s Article 50 transparency obligations take effect on 2 August 2026. The Five Eyes intelligence alliance issued a joint statement on 29 June warning that frontier AI could transform both cyber offence and defence “in months, not years,” with attackers already moving from initial access to data theft in under 72 minutes. Available coverage of the statement does not indicate that it singles out enterprise AI tools by name as an attack surface. What both point to is the same underlying condition: the assumptions organisations built their cyber-risk models on are ageing out faster than those models are being revised, and AI deployment is a large part of why.

None of these three developments is new information arriving out of nowhere. Article 50 was always coming, and its requirements have been public for months. What changed is the simultaneity: a regulatory deadline with a fixed date, an intelligence community warning about compressed attack timelines, and a governance maturity figure that puts a number on the gap between what is deployed and what is actually controlled. Those pressures used to arrive on separate timelines. In July 2026 they are concurrent.

 

The Decision Behind the Gap Was Rational

The governance gap did not happen through neglect. Most organisations deploying agentic AI without a mature governance model made a deliberate trade-off: move now, build the governance model once the technology and the internal use cases stabilise. That calculation made sense through most of 2025. Early movers captured a real advantage, and governance frameworks built around technology that was still changing weekly risked being obsolete before they were finished.

That trade-off does not survive contact with August 2026 intact. The regulatory deadline is fixed. The security environment has compressed. And the governance figure, 21% with a mature model against a 75% deployment intention, is no longer a benchmark to compare against competitors. It is a description of where the exposure actually sits inside your own organisation.

 

What Actually Needs to Happen Now

For transformation leaders, this does not resolve into a disclosure for the board. It resolves into a specific, immediate piece of work: an accurate inventory of what AI is actually running across the organisation, not what was approved on a policy document, but what is deployed and in active use. The distance between those two lists is precisely the exposure that Article 50 and the current threat environment are now positioned to surface.

That inventory has to happen before the governance model gets built, not alongside it. You cannot govern a system whose actual footprint your organisation has not yet measured, and by the time an auditor, a regulator, or an attacker measures it for you, the cost of closing the gap has already changed.

The deployment number will keep climbing. The governance number moves only when someone decides to move it. Right now, for most organisations, no one has.

The AI Model Was Never the Hard Part

Posted on by

Three of the world’s largest AI vendors have spent the past ten days admitting something enterprise buyers have suspected for a while: the model was never the hard part.

On 30 June 2026, AWS committed $1 billion to a new Forward Deployed Engineering unit, sending pods of engineers directly into customer organisations to build and deploy agentic AI systems on-site. Three days later, Microsoft answered with Microsoft Frontier Company, a $2.5 billion commitment embedding 6,000 industry and engineering experts inside client organisations to co-design, deploy, and run AI systems against measured business outcomes. Combined, that is 3.5 billion dollars committed by two vendors in under two weeks, and neither of them spent a cent of it on a better model.

They spent it on people, sent to sit inside your organisation and do the work your own team was supposed to already be doing.

 

This Is Not Two Companies. It Is a Pattern.

Treat this as an isolated Microsoft-versus-Amazon story and you miss what is actually happening. Both moves followed a pattern already set earlier in 2026 by the AI labs themselves. Anthropic and OpenAI both launched joint ventures for enterprise AI deployment on the same day, 4 May 2026. Anthropic’s is a $1.5 billion venture backed by Blackstone, Hellman & Friedman, and Goldman Sachs. OpenAI’s is The Deployment Company, a $10 billion vehicle anchored by TPG. The technique itself, forward-deployed engineering, sending a vendor’s own technical staff to embed inside a customer’s operations rather than selling software and walking away, was not invented in 2026 either. Palantir built its entire early growth on exactly this model more than a decade ago.

What changed in the space of two months is who is now doing it. Every major AI vendor, model builders and cloud hyperscalers alike, has independently reached the same conclusion at the same time: licensing the technology and leaving customers to figure out deployment is no longer a viable strategy for demonstrating that AI investment produces returns.

 

Why Now, and Why All at Once

The timing is not a coincidence, and the reason is uncomfortable for anyone who has spent the last two years running an internal AI programme on the assumption that the tooling was the hard part.

MIT’s Project NANDA research, based on 150 leadership interviews, a survey of 350 employees, and an analysis of 300 public AI deployments, found that 95% of organisations deploying generative AI saw zero measurable business return, despite an estimated 30 to 40 billion dollars in enterprise investment. The same research found that internal builds succeed at roughly a third of the rate of purchased tools paired with a genuine implementation partnership, and that the deployments which did work shared one trait: ownership sat with the domain leaders actually running the process, not with a centralised AI lab several layers removed from where the work happens.

That is the number every AI vendor is now responding to. A 95% pilot failure rate cannot be fixed by shipping a better model. It is an execution problem, and for the first time, the vendors are the ones saying so, with their own balance sheets rather than a slide in a sales deck.

 

What 3.5 Billion Dollars of Vendor Behaviour Actually Tells You

If AWS and Microsoft believed their own customers could close this gap with the tools already on the market, they would not be spending a combined 3.5 billion dollars putting engineers on the ground to do it for them. Vendors do not fund headcount at this scale to solve a problem their existing product already solves.

That is the signal worth sitting with if you are running, sponsoring, or governing an AI programme right now. The two organisations with the clearest commercial incentive to tell you that your existing licence is sufficient are instead telling you, with 3.5 billion dollars of capital allocation, that it is not.

 

What This Means for Your Own Programme

None of this means the answer is to wait for a vendor’s forward-deployed team to arrive and do the work instead of building the capability internally. Vendor-embedded engineers close the gap for as long as they are in the building, and then they leave, taking the capability with them unless the organisation has built something durable underneath it.

What it does mean is that the excuse most transformation programmes have been running on, that the tooling was not yet mature enough to deliver value, is no longer available. The vendors have just spent 3.5 billion dollars telling the market that the tooling works. The 95% failure rate MIT documented was never about the model. It was about exactly the things forward-deployed engineering exists to fix: ownership sitting in the wrong place, workflows that were never redesigned around the tool, and outcomes that were never defined before the build started.

Those are governance problems, sitting inside the organisation rather than inside the platform, and vendors were never going to be the ones to fix them permanently. They can staff their way around the symptoms for the length of an engagement. Your organisation has to solve the underlying problem itself, and the sooner that distinction is made explicit at the programme level, the less it will cost to fix later.

The model was never the hard part. The vendors just spent 3.5 billion dollars confirming it.

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.

The AI Infrastructure Race Has Already Been Decided, Just Not Where You’re Looking

Posted on by

 

Four companies have committed more capital to a single region’s AI infrastructure than most countries spend on national defence in a year.

AWS, Google, Microsoft, and Oracle have collectively committed more than 160 billion US dollars to building AI infrastructure across Asia-Pacific between January 2024 and May 2026, according to McKinsey’s analysis of the region’s data centre demand. That is not a forecast or an aspiration. It is capital already committed, over a 28-month window, by the four organisations best positioned in the world to judge where AI compute demand is actually heading.

Most enterprise conversations about AI strategy still treat the geography of AI capability as fixed, anchored in North America and Europe. That assumption stopped being accurate somewhere in the last two years, and the redrawing is happening in Asia-Pacific, largely unnoticed by the boardrooms it will eventually affect.

 

The “Follower” Narrative Was Already Wrong

The conventional framing of AI outside North America and Europe has always been one of catching up, adopting capability built elsewhere, closing a gap set by others. That framing was already inaccurate before this capital started moving, and the UAE is the sharpest evidence of it. Microsoft’s AI Economy Institute put the UAE’s working-age AI adoption at 70.1 per cent in its Q1 2026 diffusion report, the highest of any economy measured, against a global average of 17.8 per cent. Abu Dhabi is also home to Stargate UAE, a 5-gigawatt AI campus built with OpenAI, Oracle, and Nvidia that is now the largest AI infrastructure deployment outside the United States. Neither of those is a country catching up. That is a country leading.

The hyperscaler capital now moving into Asia-Pacific specifically, the $160 billion figure McKinsey tracks across AWS, Google, Microsoft, and Oracle, sits in a different regional bucket to the UAE in most analysts’ own classifications, McKinsey included, which places the Gulf within EMEA rather than APAC. But read together, the pattern is bigger than either region’s infrastructure story on its own. AI leadership has already decentralised away from North America and Europe in adoption terms. The capital now following it into Asia-Pacific is the same shift playing out in infrastructure terms, just in a different part of the map. The four largest cloud infrastructure providers on earth are not building in Asia-Pacific because the region is catching up. They are building there because the assumption that AI capability originates in the West and diffuses outward has already been disproven elsewhere, and they are positioning for where demand actually sits next.

That distinction matters for anyone making a ten-year technology strategy decision today. Compute infrastructure built now does not simply serve current workloads. It becomes the physical foundation that shapes what is commercially viable to build on top of it for the following decade. The parallel worth drawing is North American cloud infrastructure investment around 2015, which quietly determined which companies had a structural cost and latency advantage for the cloud-native decade that followed. Most of those advantages were locked in years before most executives recognised the pattern.

 

Building Faster Than Anyone Can Govern

What makes this moment genuinely worth attention is not just the scale of the capital commitment. It is the gap between that commitment and what has followed it.

The physical infrastructure, the data centres, the compute capacity, the power agreements, is being built at a pace the market has not seen before. The governance, integration, and organisational capability needed to actually use that infrastructure well has not kept pace at anything like the same speed. This is the same structural gap showing up across every AI signal this year: deployment and physical capacity moving faster than the organisational readiness required to extract value from either.

For enterprises operating in or adjacent to Asia-Pacific markets, this creates a specific and immediate strategic question, not a hypothetical one for next year’s planning cycle. The infrastructure being built now will define whose AI workloads run cheaply, quickly, and reliably in the region from 2027 onwards. Enterprises without a considered position on that infrastructure are not neutral bystanders. They are watching the operating environment for their future competitors being constructed, largely without their input.

 

What This Actually Requires From Leadership

Chasing every regional infrastructure headline is not the answer. Two things are.

The first is a straightforward board-level question that most technology strategy committees have never actually asked: does our AI roadmap account for where the compute capacity underneath it is being built, and by whom? Most enterprises with APAC exposure have not asked this, because compute geography has always been treated as an IT procurement detail rather than a strategic input.

The second is timing discipline. The infrastructure decisions with the longest shelf life, cloud provider selection, data residency architecture, regional partnership structures, are being made now, this year, by enterprises that recognise the window. Wait for the 2027 competitive gap to become visible and the decision will already have been made, by whichever provider has the compute capacity and the customer relationship in the region first.

The infrastructure race rarely announces itself as urgent while it is still open to influence. It only looks urgent in hindsight, once the capital is spent and the advantage is locked in. Right now, for Asia-Pacific, it is still open.

Your Enterprise Architecture Is Built on a Map That No Longer Exists

Posted on by

Most enterprise technology decisions are made on a map that no longer reflects the territory. Vendors occupy defined positions. ERP here, CRM there, ITSM in its lane, workflow tooling beneath. Procurement, architecture, and integration planning all proceed on the assumption that those positions are reasonably stable.

Two announcements made within days of each other in May 2026 did not just shift those positions. They rendered the map itself unreliable.

At Knowledge 2026, ServiceNow unveiled Autonomous CRM, covering sales, service, quoting, order fulfilment, invoice disputes, renewals, and the full customer lifecycle. A direct entry into Salesforce’s core market from a vendor whose identity has been workflow and ITSM. At Sapphire 2026, SAP declared itself a business AI company, launched its Autonomous Enterprise vision, in which AI agents execute end-to-end business processes, with humans directing strategy rather than managing individual steps, and acquired Reltio to make enterprise data AI-ready. An ERP vendor positioning as an AI orchestration layer across the entire enterprise.

Most commentary has treated these as two separate vendor stories. They are not.

 

Two Announcements. One Signal.

What ServiceNow and SAP announced is not primarily about features. It is about boundaries, and the dissolution of them.

For the past decade, enterprise technology portfolios have been built on a category model. You choose an ERP, a CRM, an ITSM platform, a workflow layer, and you integrate them. Vendors in each category compete within it. The architecture question is mostly about how the categories connect, not whether the categories themselves hold.

That model has broken. ServiceNow is not extending into adjacent territory around the edges. It is standing directly in Salesforce’s most defensible ground, covering sales pipeline, quoting, order management, and customer lifecycle, with AI as the differentiator. SAP is not adding AI features to its ERP. It is repositioning as the orchestration intelligence for the entire autonomous enterprise, with a master data acquisition to back it.

The category model that procurement teams, architecture boards, and technology roadmaps are built on is now operating on assumptions that neither vendor supports.

 

The Roadmap Problem

This matters less as a vendor story and more as a planning problem.

Enterprise technology decisions have long lag times. A CRM strategy agreed in 2023 reflects assumptions about what Salesforce competes with and how. An ERP consolidation approved in 2024 was scoped against SAP doing one thing and other vendors doing adjacent things. Integration architectures designed eighteen months ago were designed for a world where the platforms stayed in their lanes.

None of those assumptions survived May 2026. And the organisations currently finalising multi-year enterprise software contracts, negotiating renewal terms, or approving architecture blueprints need to know that before they sign.

The problem is not that ServiceNow and SAP have made bold moves. Vendors always make bold moves. The problem is that decisions downstream of those moves, about what to buy, what to build, what to integrate, and which vendor relationships to deepen, are still being made against the old map.

Two specific conversations are worth having before any major enterprise software decision closes in the next twelve months.

The first is the vendor dependency audit. When your workflow vendor is also your CRM, and your ERP vendor is also your AI orchestration layer, the concentration risk in your technology portfolio changes. So does the negotiating leverage. So does the cost and complexity of exit if you need it later. These are not hypothetical concerns. They are the direct consequence of vendors collapsing categories.

The second is the integration investment review. Integration work designed to connect cleanly bounded platforms does not simply carry across when those platforms expand into each other’s territory. Some of it becomes redundant. Some of it creates conflict. Some of it was justified by a separation of function that no longer exists. If your architecture team has not reviewed integration design against what ServiceNow and SAP announced in May 2026, that is a gap worth closing quickly.

 

What the Briefing Should Have Said

Technology updates for executive teams and programme boards tend to cover vendor announcements as market news. ServiceNow does this, SAP does that, here is what it means for the industry. That framing is too distant to be useful.

The briefing transformation leaders needed, and in most cases did not receive, is this: the vendor categories on which your enterprise architecture is built are collapsing. Two of the largest platform vendors are now competing directly across the boundaries that your current roadmap treats as fixed. The decisions you need to revisit are specific, and the window before contracts close is finite.

That is a different conversation from a product announcement. It requires someone in the organisation to have read the news, synthesised its implications, and brought it to the table as a strategy question rather than a technology update.

Most organisations are not structured for that kind of synthesis. Technology teams report on what vendors do. Strategy functions rarely track vendor positioning in this level of detail. The CIO’s office is often the only place where the two sets of knowledge meet, and it is frequently operating at capacity on current programmes rather than monitoring future architecture exposure.

The gap this creates is real, and it has a cost. Not immediately, but at contract renewal, at architecture review, at the moment an integration investment turns out to have been built against a boundary that no longer exists.

The ServiceNow and SAP announcements are not the story. The story is that the category model your technology decisions are built on changed, and most of the people who need to know have not been briefed. That is an organisational problem, not a technology one, and the organisations that address it before the next contract closes will be in a materially different position from the ones that address it after.

Your AI Risk Register Does Not Reflect Your Actual Risk

Posted on by

 

On 22 June 2026, the intelligence agencies of the United States, United Kingdom, Australia, Canada, and New Zealand spoke in a single voice about enterprise AI risk, and what they said demands attention.

The Five Eyes cybersecurity agencies issued a joint statement warning that frontier AI models are improving at a pace that will allow them to bypass prevailing enterprise cybersecurity defences within months. Not within years. Not in the next planning cycle. Within months. The statement’s own language: “The timeline is not years, it is months.”

 

This Is Not an Abstract Warning

Joint statements from the Five Eyes agencies carry a different category of authority than vendor advisories or consultancy threat reports. These are national intelligence services with access to classified threat intelligence, speaking to government and enterprise leaders simultaneously. When they frame a risk as both imminent and enterprise-specific, take it at face value.

What sets this advisory apart from every AI security conversation most enterprises have been having is one thing: specificity. The Five Eyes statement does not describe abstract AI risks. It specifically names the enterprise AI tools deployed at scale in the last 18 months: copilots, AI assistants, browser-connected agents, and systems with access to operational and customer data. The primary attack mechanism, developed across Five Eyes guidance published earlier this year, is prompt injection: an adversary embeds hidden instructions in content the AI system processes, causing it to act outside its intended scope.

That specificity matters. It means the tools that most large enterprises have already deployed are the attack surface being described.

 

The Threat Moved Faster Than Your Review

Most organisations that have rolled out AI copilots, enterprise agents, or browser-integrated assistants have conducted security reviews of those deployments. The Five Eyes advisory is not questioning whether those reviews happened. It is saying that the threat has moved faster than the defences, and that a review conducted six months ago may no longer accurately reflect the risk profile today. The gap is not in intent. It is in elapsed time against a threat that has not stood still.

The advisory is explicit that this is not solely a security-team problem. The statement directs its recommendations at leadership, framing AI-driven cyber risk as a governance and board-level accountability question. The statement’s own title: “The AI shift in cyber risk: why leaders must act now.” That framing has direct implications for how risk registers are built and how AI deployment decisions are reported to boards.

 

Three Things Worth Doing Before Your Next Board Meeting

The advisory points to three things transformation leaders should act on before their next board meeting.

The first is a current security review. Every AI deployment connected to operational data, whether customer records, financial systems, or internal communications, needs a review that specifically addresses prompt injection risk. Not the review conducted at go-live. A current one, calibrated to the threat capability the Five Eyes describe as arriving within months.

The second is an updated risk register. Most enterprise risk frameworks assessed AI security risk at the point of initial deployment. The Five Eyes advisory says the threat environment has changed materially in the months since, and the assessment needs to reflect current threat capability rather than historical assumptions. An outdated risk assessment is not a minor administrative gap at this point. It is a governance exposure.

The third is using the advisory to reframe the conversation at board level. Six cybersecurity agencies from five countries issued this statement with an explicit focus on business leadership. That gives transformation leaders the instrument they need to move boards that have been treating AI security as an implementation detail. The Five Eyes advisory makes it a governance question. Use it as one.

The AI deployment decisions taken in the last 18 months created an attack surface. Most enterprise risk registers have not yet priced what that surface is worth to an adversary with AI-powered attack tools that are months from bypassing prevailing defences. That gap needs to close, and it closes with a current assessment, not one accurate at the time of go-live.

The EU AI Deadline Your Compliance Team Probably Missed

Posted on by

The EU AI Act enforcement date most organisations have been tracking is not 2 August 2026. They have been watching the high-risk provisions, the conformity assessments, the prohibited applications. Those timelines stretch into 2027 and beyond, and enterprise compliance teams have planned accordingly.

Article 50 has a different clock. It takes effect in 31 days, it applies to a far wider population of organisations than most realise, and for most of its obligations there is no grace period.

 

Not the Regulation You Were Watching

For the past two years, enterprise AI governance conversations have centred on the Act’s high-risk classifications. Which systems require conformity assessments? Which use cases are prohibited outright? The questions were legitimate, and the extended timelines attached to those provisions created a reasonable sense of runway.

That runway does not apply to Article 50.

Article 50 covers transparency obligations, and it lands on 2 August 2026. It requires any organisation deploying customer-facing AI systems to disclose to users that they are interacting with an AI. It requires providers of generative content tools to implement machine-readable marking on AI-generated outputs. Operators running emotion recognition or biometric categorisation systems must notify the individuals affected. And for any new system entering the EU market on or after 2 August, compliance is required from day one.

One aspect of the regulation that most compliance programmes have not fully processed: Article 50 is not jurisdictional. Article 50 follows the user, not the provider. That is how the Act defines its own scope. A company headquartered in Dubai, Singapore, or New York that deploys AI-generated content visible to EU users is in scope. Where the output lands determines the obligation. The practical consequence is that Article 50 applies to any organisation with a customer base that includes EU residents, regardless of where that organisation is incorporated or where its AI systems are built and operated.

The organisations that will be caught short are not the ones building prohibited systems. They are the ones that assumed the regulation was still in the planning stage, or that it would only apply to organisations based in Europe.

 

The GDPR Comparison That Matters

GDPR was announced in 2016 and took effect in 2018. Two years of awareness campaigns, legal seminars, board-level briefings, and vendor remediation work. The compliance industry built an entire ecosystem around it. Privacy officers were hired. Data mapping exercises ran for months. By the time enforcement began, organisations at least understood what was expected of them, even if some were still catching up.

GDPR also reached beyond EU borders from the start. Any organisation processing the personal data of EU residents was in scope, regardless of where it was based. Article 50 operates on the same principle: it reaches wherever EU residents are on the receiving end of AI-generated content or AI-driven interactions.

Article 50 does not have that context. Most enterprise compliance functions have been tracking the Act’s overall timeline without separating out which provisions take effect when. The transparency obligations were not deferred. They were always scheduled for August 2026. But because the high-risk provisions dominated the conversation, the transparency rules arrived quietly, and they arrive soon.

Thirty-one days is not a planning horizon. It is an implementation sprint, or it is already a compliance gap.

 

What Article 50 Actually Requires

The obligations are more specific than the general framing of “AI transparency” suggests, and that specificity matters for scoping the work.

The most broadly applicable obligation is disclosure. If a user is interacting with a chatbot, a virtual assistant, or any automated system capable of conversation or personalised response generation, they must be told. The requirement is not a buried terms-and-conditions clause. It is a functional disclosure at the point of interaction. This applies from 2 August, to all systems, with no transitional provisions.

Generative content carries a second obligation. Organisations using generative AI to produce content distributed in EU-market contexts must ensure outputs carry machine-readable markers indicating AI generation. This applies to text, images, audio, and video. The AI Omnibus agreement provisionally agreed in May 2026 and expected to be formally adopted before 2 August extends this specific requirement to 2 December 2026 for systems already on the market before 2 August. For any new system entering the market from that date, the obligation is immediate. The extension is not a signal to deprioritise: December 2026 is not far away, and the technical implementation is not trivial.

Emotion recognition and biometric categorisation carry a third obligation, active from 2 August with no transitional period. Individuals must be informed when these systems are operating on them.

None of these obligations are complex in isolation. The difficulty is that most organisations have not mapped which of their current systems fall within scope, and that mapping exercise takes longer than 31 days when it is starting from scratch.

 

What to Do in the Next 31 Days

Non-compliance carries fines of up to €15 million or 3% of global annual turnover, whichever is higher. This is not a planning conversation. It is a board conversation.

Article 50 requires operational change: disclosure mechanisms built into interfaces, technical markers implemented in content pipelines, notification processes embedded in operational workflows. A policy document does not close this gap.

The practical starting point is a scoping exercise, and it needs to happen this week, not at the end of July. Three questions define the scope: Which customer-facing systems use AI in any form of interaction or response generation? Which content production workflows use generative AI to produce material distributed in EU-market contexts? Are any systems using emotion recognition or biometric categorisation?

If the answer to any of those questions is yes and the disclosure or notification mechanism is not already live, that is an Article 50 compliance gap.

Once the scope is clear, triage by exposure. Not every system carries the same risk. Externally facing consumer products in regulated sectors carry a different risk profile than internal productivity tools. Sequence the remediation by audience, jurisdiction, and volume of interaction.

Confirming the mechanisms actually work is where most programmes get caught. A disclosure notice that technically exists but is not surfaced at the point of interaction does not satisfy the requirement. The same applies to machine-readable markers that are added to some content outputs but not systematically applied across all generative workflows. Implementation is not the same as compliance.

 

31 Days Is Not a Problem. 32 Days Is.

There is still time to close this gap for organisations that act now. August 2026 is not GDPR day one, when regulators were finding their feet. It is an enforcement event in a regulatory framework that has had two years of published timelines. Regulators will not be looking the other way.

The organisations that treated the high-risk provisions as the whole story now have 31 days to correct that assumption. Wherever they are based.

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 Dashboard Won’t Save Your Project. Your People Will

Posted on by

We have built an entire industry around the wrong obsession.

Walk into any project or programme environment today and tell me what you see. Dashboards. RAG statuses. KPI scorecards. Burndown charts. Milestone trackers. Automated reports that nobody reads in full but everyone references in meetings as though they tell the complete story.

We have convinced ourselves that if we can measure it, visualise it, and put it on a screen, we are in control.

We are not in control. We are comfortable. And those are not the same thing.

Because the thing that actually determines whether your project succeeds or fails, the thing that has always determined it, is not sitting in any dashboard. It is sitting at a desk, joining a call, navigating a problem at 4pm on a Friday when the system throws an error nobody anticipated and the go-live is Monday morning.

It is your people.

And most leaders have quietly forgotten that.

How We Got Here

The shift happened gradually, and it happened with good intentions.

Technology gave us visibility we never had before. We could track progress in real time, surface risks earlier, and report upward with confidence. That was genuinely valuable. Nobody is arguing for less information.

But somewhere along the way, the tool became the answer. The dashboard became the proxy for understanding. The metric became the substitute for the conversation. And the leader who once walked the floor, read the room, and sensed the real mood of a programme started trusting the green status on a screen instead.

The result is a generation of project environments where the reporting is polished and the delivery is fragile. Where everything looks healthy until it suddenly is not. Where nobody saw it coming, except the people closest to the work, who saw it coming for weeks and had nowhere safe to say so.

That is not a data problem. That is a leadership problem.

 

What the Software Cannot Tell You

Your project management software does not know that your lead developer has been quietly updating her CV for three weeks because she feels invisible on this programme.

Your dashboard does not know that the business analyst who owns the most critical workstream is running on empty and has been covering for a colleague who disengaged two months ago.

Your RAG status does not know that the reason everything is green is because the project manager is too afraid to report amber. Because the last time someone reported amber, the steering committee treated it as a personal failure rather than useful information.

Your metrics do not know that the vendor’s implementation team has internally deprioritised your programme because a larger client demanded more of their attention, and your account manager has been managing that fact rather than disclosing it.

None of this shows up in the data. All of it will show up in the outcome.

Professor Bent Flyvbjerg’s research on major project delivery, one of the most comprehensive analyses of project outcomes conducted, found that 91.5% of major projects experience cost overruns, schedule delays, or both. The primary driver is not technical failure. It is optimism bias: the structural human tendency to underestimate problems, which reporting cultures then amplify. A team that does not feel safe surfacing bad news will report optimistically. And the gap between what is reported and what is real compounds week by week until it cannot be managed.

This is the gap that leaders who have outsourced their judgement to software cannot see. The human information. The signals that travel through relationships, not reporting lines. The early warnings that only surface when people feel safe enough, and trusted enough, to tell you the truth.

People Deliver. Not Platforms

Let me be direct about something that gets lost in every technology conversation.

The software does not write the requirements. A person does. The platform does not manage the stakeholder who keeps changing scope. A person does. The dashboard does not have the difficult conversation with the supplier who is underperforming. A person does. The metric does not hold the team together at the point when the pressure peaks and the temptation to cut corners becomes real.

A person does.

Every single meaningful act in the delivery of a project or programme is a human act. The technology supports it, documents it, and reports on it. But it does not do it.

This sounds obvious. And yet the way most organisations invest their leadership attention, their development budget, and their improvement energy tells a completely different story. They upgrade the tools before they develop the people. They add another dashboard before they ask whether their team leaders have the skills to have honest conversations. They buy new software to solve problems that are fundamentally about trust, capability, and culture.

And they wonder why the new system does not fix the delivery problem.

The People Who Confirm Success

Here is the other half of the equation that rarely gets enough attention.

It is not just the people who deliver the project that matter. It is the people who decide whether it worked.

The clinician who was supposed to use the new system and quietly reverted to the old one because nobody involved her in the design. The frontline manager who was presented with a new process in a one-hour training session and had nowhere to raise the fact that it does not reflect how the work actually happens. The customer who was told the transformation would make their experience better and is still waiting.

These people are the real success criteria. Not the go-live date. Not the project closure report. Not the benefits case that was written eighteen months before anyone understood what was actually being built.

Transformation succeeds when the people it was designed for adopt it, use it, and tell you it made a difference. And they will only do that if they were treated as participants in the process, not recipients of its output.

What Recalibration Actually Looks Like

Leaders who get this right do not look fundamentally different from the outside. They attend the same meetings. They review the same reports. But they do something that most of their peers have quietly stopped doing.

They go to where the work is.

Not to check on it. Not to apply pressure. To understand it. To ask the questions that the dashboard cannot answer. How are you actually finding this? What is slowing you down that is not on the risk register? What do you know that I should know?

Google’s Project Aristotle, an internal study of more than 180 Google teams, found that psychological safety was the single strongest predictor of team effectiveness, above individual talent, structure, and every other measurable factor. Amy Edmondson’s research at Harvard Business School reinforces this from a delivery perspective: teams where people feel safe to raise problems surface them earlier, when they are still recoverable. When people do not feel safe, the information gets filtered. And filtered information is what produces the green dashboard above the failing project.

They treat their team’s energy as a delivery asset, because it is. They notice when someone has gone quiet. They notice when the language in status reports starts becoming defensive rather than informative. They notice when the optimism of the first month has been replaced by the grinding compliance of a team that no longer believes the work matters.

And they act on what they notice. Not with a new metric. With a conversation.

They invest in the human layer of delivery the way that most organisations invest in the technical layer. Deliberately. Consistently. Not as a soft add-on to the real work, but as the foundation of it.

The Investment Gap

The question is not whether your tools are good enough.

For most organisations, the tools are fine. In many cases, the tools are excellent. The dashboards are sophisticated. The reporting is comprehensive. The project management frameworks are mature.

And yet the delivery outcomes have not improved at the rate the technology investment suggested they should. PMI’s research, tracking project performance across thousands of organisations globally, found that communication failure contributes to one in three project failures. The gap between organisations that invest seriously in the human and communication layer of delivery and those that do not is measurable, consistent, and significantly larger than most leaders assume.

The gap is not in the software. It is in the leadership attention.

What would change if you spent the same energy on understanding your people that you currently spend on reviewing your reports? What would surface if your team genuinely believed that telling you the truth was safer than protecting the status? What decisions would you make differently if you had the human information as clearly as you have the data?

Those are not rhetorical questions. They are the questions that separate the programmes that deliver from the ones that drift.

The Skill No Platform Replaces

Every programme failure I have ever been close to had warning signs that the data did not capture. The signs were there in the people. In the energy levels. In the conversations that stopped happening. In the problems that got managed rather than solved.

And in almost every case, the leaders were looking at a screen when they should have been reading a room.

The software is not the problem. The hardware is not the problem. The metrics and the dashboards are not the problem.

The problem is that we have allowed them to replace the most important leadership skill there is.

The ability to understand people. To create the conditions where they do their best work. To recognise when they are struggling before it shows up in a project status. To build the kind of trust that means the real information travels fast enough to matter.

No platform does that. No tool does that.

Only you do that.

And the projects that remember it are the ones worth talking about.