Category Archives: Leadership

The PMO Evolves From Reporting to Enablement Engine

Posted on by

Most PMOs are still optimised for a question that stopped mattering years ago: is the project on time.

That question still matters. It has just stopped being the question that decides whether the PMO survives.

Clarkston Consulting’s 2026 programme management research puts the shift plainly: leading PMOs are moving beyond reporting to serve as enterprise enablement engines, connecting strategy to execution, building readiness into delivery from the start, and treating benefits realisation as a core discipline with clear ownership and early indicators of whether value is actually being created. A better dashboard will not get you there. This is a different function entirely.

 

The Reporting Function Was Never the Point

A PMO built around status reporting produces a specific kind of artefact: a red, amber, or green rating, a variance against plan, a risk log updated on schedule. Useful, in a narrow sense. None of it tells an executive whether the portfolio is creating value, whether the organisation’s capacity to change is being spent well, or whether the thing being delivered still matches the strategy that funded it eighteen months ago.

Wellingtone’s PMO research this year makes a related but sharper point: the inconsistency that plagues portfolio reporting, different teams defining “green” differently, decisions made on opinion rather than evidence, is a data problem before it is a reporting problem. Standardise the definitions and data model underneath the reporting, and AI can act as an assistant that takes a defined goal such as producing this week’s portfolio report or re-planning a delayed project, and coordinates the steps across your tools, removing low-value work rather than just colouring in a status field faster.

That distinction matters because AI is already acting as that assistant. It is already running in PMOs now.

 

Where the Real Shift Is Happening

House of PMO’s 2026 trends names the structural change underneath the tooling change: PMOs are increasingly being embedded into business areas rather than operating as a distant central function. This proximity builds trust, improves understanding, and allows PMOs to influence decisions earlier, where they can actually make a difference. The PMO becomes a connector between strategy and delivery, between different delivery models, and between governance and pace, rather than a function three steps removed from where the decisions get made.

Put those two shifts together: the data foundation improving enough for AI to generate real insight, and the PMO physically and organisationally closer to where decisions happen. The reporting function stops being the PMO’s reason to exist. It becomes infrastructure, while the enablement work, the strategic conversation, the early warning that changes a decision before it becomes a recovery programme, is where the value actually sits.

 

The Question Every Sponsor Should Be Asking

For anyone accountable for a large programme or portfolio, there is one question worth asking about the PMO function right now: has it been designed for accountability, or for assurance.

An assurance PMO produces reports that document what happened. It is useful for the audit trail and largely irrelevant to the decisions that mattered, because by the time the report lands, the decision has already been made without it. That is not a project management decision. It is a leadership decision about what the function is actually for, and most organisations have never asked it directly. They inherited a PMO structure built around reporting cadence and have never revisited whether reporting cadence was ever the point.

 

Why the Clock Is Actually Running

The reason this stops being an optional repositioning is straightforward. AI is already absorbing the administrative core of traditional PMO work: status compilation, report drafting, risk-log maintenance, the tasks that used to justify a PMO analyst’s headcount. A PMO whose value proposition is still “we produce the reports” is competing against a capability that produces the same reports faster, more consistently, and without a salary.

Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027, mostly because organisations deployed the technology without redesigning the governance and decision rights around it. That is precisely the work a repositioned PMO is suited to do, and precisely the work a reporting-only PMO has no mandate to touch.

 

What This Looks Like in Practice

The organisations getting this right are not adding an AI tool to the existing PMO operating model. They are redesigning what the PMO is accountable for first, then deciding what gets automated underneath that redesign. That means fewer metrics, chosen because they connect directly to financial outcomes, risk reduction, or strategic alignment, not because they are easy to collect. It means a PMO embedded close enough to the business to have the conversation before the decision, not after the variance report. And it means a governance model built to keep pace with AI and agentic deployments, not one still calibrated for a world where the only automation was a spreadsheet macro.

That happens by deciding, at leadership level, what the PMO is actually for, not by upgrading the reporting tool.

My own view is that this repositioning does not stop at a PMO with better metrics. Within a couple of years, the distinction between the PMO and whatever function owns strategy execution will start to disappear in the organisations doing this well, because once a function is genuinely accountable for whether strategy translates into delivered value, calling it a project management office undersells what it has become.

The PMOs still measuring themselves on whether the project shipped on time are answering a question that stopped being the one that mattered. The ones worth funding are the ones that can already tell you whether it was the right project.

Pre-Mortem: The UK’s Critical Third Party Regime

Posted on by

On 13 July 2026, Amazon Web Services, Google Cloud, Microsoft Azure, and Oracle became the first companies formally designated as Critical Third Parties to the UK financial system. The Bank of England, the Prudential Regulation Authority, and the Financial Conduct Authority now hold powers to gather information, assess resilience, and make enforceable rules against the four providers for the services they supply to the financial sector. A 2024 Bank of England and FCA survey found the top three cloud providers accounted for 73% of all cloud providers named by respondents across the UK financial sector. The designation names the risk. It does not resolve it.

This is the tenth piece in the Pre-Mortem series. Five questions, applied to the public record, before a programme has had the chance to succeed or fail.

 

The Bet

The UK is betting that direct regulatory oversight of four technology providers, applied specifically to their financial-sector services, will reduce the systemic risk from having most of the sector’s cloud infrastructure concentrated in three companies. The Financial Services and Markets Act 2023, which created the CTP regime, gives the Bank of England, PRA, and FCA powers to assess resilience and enforce CTP-specific rules. The designation is a supervisory relationship, not a structural remedy. If that supervisory relationship produces documented, published improvements in resilience before the first major cloud incident in UK financial services, the bet holds.

 

The Assumption

The regime’s credibility turns on one scoping decision: that overseeing four providers for the services they supply to the UK financial sector is sufficient to contain risks generated by four companies whose infrastructure decisions are made globally, across legal jurisdictions and customer bases far larger than the UK financial system. Microsoft Ireland Operations Limited is the designated entity. Its architecture decisions are made in Redmond. The supervisory perimeter covers the financial-sector slice. The concentration risk does not stop there.

 

The Sequence

The concentration risk pre-dated the regime by years. The Financial Services and Markets Act 2023 established the legislative basis for the CTP framework. A 2024 Bank of England and FCA survey confirmed the scale: three providers controlling the majority of UK financial-sector cloud infrastructure. HM Treasury announced the first four designations on 10 July 2026, effective 13 July. The sequence is legislation, then evidence, then designation. The risk was present throughout.

 

The Pager

Rachel Blake MP, Economic Secretary to the Treasury and City Minister, made the designation announcement. The Bank of England, PRA, and FCA share oversight of the four providers under the regime. Three regulators. Three separate mandates. No published document names which of the three leads incident coordination when a designated provider’s outage affects UK financial services. The CTP framework assigns supervisory responsibility. It does not assign the call.

 

The Proof

The measure that would settle this regime’s effectiveness is a published resilience outcome: a before-and-after comparison of systemic vulnerability at a named date after the CTP rules take effect. No such commitment has been published. The three regulators hold powers to gather information from the four providers. No public document names what information will be published, in what form, and by when. The first formal review cycle has no published date.

 

Verdict

If the three regulators jointly publish a named lead for CTP incident coordination and commit to a quantified resilience outcome before the first formal review cycle, the designation will stand as the most substantive step the UK has taken to address cloud concentration risk in its financial sector. Without that, four of the world’s most powerful technology companies have been formally named, and the framework that names them has not yet named who is in charge when one of them goes down.

Healthcare AI Enters Its Accountability Phase

Posted on by

Healthcare AI has stopped being an experiment. Holland & Knight, the US law firm, put it plainly in its mid-2026 healthcare report: the sector has entered a “recalibration phase,” where capital discipline and demonstrable return on investment have replaced the growth-first logic that funded the last five years of digital health.

That is a legal and investment framing, not a clinical one. But the clinical evidence backing it up is now specific enough to name.

Kaiser Permanente’s Permanente Medical Group rolled out ambient AI scribing to 7,260 physicians across more than 2.5 million patient encounters between October 2023 and December 2024. The result, confirmed by Kaiser’s own Division of Research: nearly 16,000 clinician-hours of documentation time saved. Not a pilot cohort. Not a vendor’s projection. A production deployment, measured after the fact, across a workforce large enough that the number means something.

Ambient documentation is also the part of healthcare AI with the least room left to argue about. A 2026 survey of 120 US health systems, run by the healthcare research firm Eliciting Insights, found clinical note-taking and ambient listening tools now sit at 68% adoption, up 62% year on year. Among the health systems able to quantify results, 61% report at least a 2x return specifically from ambient listening tools.

 

The $3.20 Figure Is Real, and Older Than It Looks

The oft-quoted “$3.20 return for every $1 invested in healthcare AI” is genuine, but it is worth knowing where it actually comes from before repeating it in a board pack. It traces to a Microsoft-sponsored IDC study published in late 2023 and reported in early 2024, not a fresh 2026 finding. It has simply become the industry’s standing benchmark figure, cited so often across 2025 and 2026 coverage that it now reads as current data. It is not wrong. It is just two years old and vendor-commissioned, which matters if you are the one deciding how much weight to put on it.

The Kaiser and adoption figures matter more, precisely because they are recent, specific, and independently reported rather than recycled.

 

What Actually Produced the Return

This ROI happened because of a specific programme design, not because someone bought a good tool, one that most other sectors experimenting with AI have not adopted.

Kaiser did not deploy ambient scribing and then discover the workflow around it. Clinical documentation workflow got redesigned first, and the AI tool was the mechanism, not the starting point. Accountability for the outcome, hours saved, adoption sustained, clinician trust maintained, was established before rollout, not retrofitted afterwards to justify the spend. And the whole exercise operated under exactly the capital discipline Holland & Knight describes: prove the return, or the funding does not continue.

That sequence, workflow redesign first, accountability from day one, capital discipline over growth optimism, is the actual explanation for why healthcare produced verifiable ROI while most other sectors are still producing pilot decks.

 

Healthcare Is Now the Benchmark, Not the Exception

Treat healthcare’s result as evidence that AI works and you will draw the wrong lesson. The technology was never really in question. What was in question, and what most other sectors are still failing to answer, is whether the organisation deploying it redesigned anything before switching it on.

Healthcare had no choice but to answer that question properly. Clinical documentation errors have consequences that show up in patient outcomes and malpractice exposure, not just quarterly numbers, so the sector could not afford the deploy-first governance-later approach that has quietly become normal everywhere else.

That is what other sectors should actually be benchmarking against: not whether their AI produces a return, but whether their programme was ever designed to make one provable.

 

The Question Worth Asking Before the Next AI Business Case

Before signing off the next AI investment, the question is not whether AI delivers value. Healthcare has already answered that question, under specific and now well-documented conditions.

The real question is whether your programme has been designed to match those conditions, workflow redesign before deployment, accountability defined from the outset, capital discipline over growth optimism, or whether it has been designed the way most digital health investment was designed before 2026: fund it, hope the outcomes show up eventually, and find out later whether anyone was ever going to check.

Healthcare already found out. That is the whole difference.

Pre-Mortem: The EU AI Act’s Accountability Gap

Posted on by


On 2 August 2026, the EU AI Act gives the EU AI Office the power to fine the developers of general-purpose AI models up to three per cent of global annual turnover, demand documentation, and commission independent access to source code. Three weeks before that date, the high-risk AI compliance deadline moved from August 2026 to December 2027, enacted as binding law on 29 June. The two facts share a date. They do not share a plan.

This is the ninth piece in the Pre-Mortem series. Five questions, applied to the public record, before a programme has had the chance to succeed or fail.

 

The Bet

The EU is betting that extending the deadline for high-risk AI compliance by 16 months, agreed in May 2026 and enacted on 29 June, produces better enforcement outcomes than a met deadline inside a half-prepared enforcement architecture. The logic holds. As of August 2026, only nine of 27 member states have shown advanced public implementation of enforcement infrastructure. Germany has designated the Bundesnetzagentur as its market surveillance authority and adopted draft transposition legislation. Spain built the AESIA, a dedicated supervisory agency, from scratch. Ireland deployed fifteen coordinated authorities under a central National AI Office. Those are genuine structural commitments. Eighteen member states have not reached that point. The extension gives them time. Whether they use it is the bet.

 

The Assumption

The entire framework rests on this: that national competent authorities, operating under 27 different legal frameworks, will converge on consistent enforcement before December 2027. The AI Act is a directly applicable regulation. Its enforcement infrastructure is not. The regulation sets the rules uniformly across the bloc. The authorities responsible for applying them have been built at very different speeds, under very different political conditions. That divergence is the risk the extension is buying time to close. There is no public commitment that the time is sufficient.

 

The Sequence

The AI Act entered into force in August 2024. Member states were required to designate their national competent authorities by August 2025. At least twelve missed that deadline. Seven months later, in May 2026, the Council and Parliament agreed to simplify the rules as part of the Digital Omnibus package. On 29 June, the high-risk AI deadline moved. What remains in force on 2 August is a narrower set: general-purpose AI model obligations and transparency requirements for new deployments. The high-risk AI rules, the Act’s original centre of gravity, are no longer in that set. Governance was adjusted to fit the readiness gap. That is not the order in which enforcement architecture is supposed to be built.

 

The Pager

Lucilla Sioli, Director of the EU AI Office, carries accountability for general-purpose AI enforcement from 2 August. For high-risk AI systems, including credit-scoring models, recruitment tools, and systems used in border control, healthcare, and law enforcement, accountability rests with national competent authorities. In 17 of 27 member states, no public designation exists. The Act names the category. Seventeen member states have yet to name the person.

 

The Proof

The measure that would settle this in 2028 is year-one enforcement consistency: the share of member states that have conducted at least one formal high-risk AI enforcement action, under the same evidentiary standard, in the first twelve months after the December 2027 deadline. No EU institution has publicly committed to publishing that figure. The AI Office’s annual progress reporting is the closest mechanism on the public record. It tracks activity. No published mechanism commits to measuring whether enforcement actions are consistent across member states.

 

Verdict

If the Commission designates a public accountability owner in each member state before December 2026 and commits to publishing year-one enforcement data by name, the 16-month extension holds up as a governance decision made under realistic conditions. Without that, a framework that took two years to reach enforcement hands itself an extension with nobody carrying it.

Plans Don’t Deliver Outcomes. Decisions Do.

Posted on by

The biggest myth in project management is not that it is only about schedules and budgets. That myth was debunked so long ago it barely warrants a mention.

The real myth is more dangerous: that a good plan delivers an outcome.

It does not.

A plan is the document everyone agrees on before the work starts. Delivery is determined by the thousand decisions that happen when that plan meets reality.

 

What a Plan Actually Is

A project plan is a structured expression of intent. It represents the best thinking of a group of people, at a specific point in time, about how they expect work to unfold.

The moment work starts, the plan begins diverging from reality. Not because the planning was poor. Because work is complex, environments shift, and the future is not fully knowable in advance.

The plan does not respond to those divergences. People do.

Someone decides what gets prioritised when two workstreams compete for the same resource. Someone decides what gets descoped when the timeline compresses. Someone decides what gets told to the sponsor and what gets managed quietly at team level. Someone decides whether to hold to the original scope or absorb a late change request that no one has formally costed.

These are not project management artefacts. They are leadership decisions. They happen every day, in every programme, at every level, and the cumulative quality of those decisions determines the outcome, not the quality of the plan that preceded them.

 

What the Data Shows About Plans and Outcomes

McKinsey’s research with Oxford’s Global Projects programme, originally published in 2012 and still McKinsey’s standing figure on its current insights page, based on more than 5,400 IT projects, found that just one in every 200 large IT projects meets all three basic measures of success: on time, on budget, and delivering intended benefits. The same research found that 17 per cent of large IT projects go so badly they threaten the very existence of the company delivering them. Bain’s January 2026 research on reorganisations, based on a survey of nearly 1,000 global executives and employees, found that 88 per cent of company leaders believe their new organisational structure will achieve its goals. Only 36 per cent of the employees actually working inside those structures agree.

These are organisations with project plans. Most of them had quite detailed ones.

The plan was not the variable that determined whether the transformation succeeded. The decisions made inside the transformation were.

McKinsey has been explicit on this, in its analysis of large technology programme management: traditional project management is not built for the complexity of managing a large number of interdependent workstreams. What that observation is really describing is a decision-making capacity problem, not a planning methodology problem.

When multiple workstreams intersect, when dependencies conflict, when assumptions that underpinned the plan prove false, the organisation needs fast, well-informed, appropriately escalated decisions. The project plan cannot make those decisions. A governance structure can enable them, but only if the people inside it are willing and able to act.

 

The Organisations That Deliver

I have worked across a wide range of organisations and programmes. The ones that consistently deliver are not the ones with the most sophisticated planning tools or the most comprehensive project documentation.

They are the ones with a leadership culture that makes fast, honest decisions when the plan diverges from reality.

That culture has specific characteristics. Issues get escalated without penalty. Status reporting reflects what is actually happening, not what the sponsor wants to hear. Scope changes get properly evaluated and decided, rather than quietly absorbed and then discovered six months later as the reason for a cost overrun.

Decisions about resources, priorities, scope, and timing get made by the right people at the right level, at the point when the decision matters, not deferred until the situation has become a crisis requiring emergency intervention.

This is not about removing the plan. A plan is genuinely useful. It creates shared understanding, allocates resources, sequences work, and provides a baseline against which reality can be measured. All of that matters.

But the plan is the starting point, not the delivery mechanism.

 

The Governance Gap Nobody Names

Most programme governance is designed to review progress against plan. Status reports, RAG ratings, milestone trackers, action logs. These are retrospective instruments. They tell you where you have been relative to where you intended to be.

They do not, by themselves, generate decisions.

A programme with robust governance can still fail because the governance structure reports on problems without resolving them. The issues log fills up. The risk register grows. The steering committee meetings run to time, and the programme slides, week by week, toward a late and over-budget delivery, or a cancellation that could have been a scope-reduced success.

The missing element is decision velocity, the willingness and authority to make the calls that change the trajectory, rather than the calls that record that the trajectory has changed.

 

What Good Actually Looks Like

The shift required is not from planning to improvisation. It is from planning-as-delivery to planning-as-baseline.

Build the plan. Use it. Measure against it. But invest as heavily in decision-making culture as in planning rigour. Who has authority to make what decision at what level? How fast can an escalation reach someone with genuine authority? What happens to the person who brings a difficult problem to the steering committee: are they received as someone providing valuable intelligence, or treated as someone who has failed to manage their workstream?

The organisations with the best project outcomes have thought hard about these questions. They are not the ones with the best plans.

They are the ones that can make the right call at 9am on a Tuesday when the plan says one thing and reality says another.

That capacity is the real delivery engine.

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.

Handling Stakeholder Expectations in Digital Transformation: The Honesty Problem

Posted on by

 

Most failed digital transformations were not derailed by technology.

They were derailed by a gap between what was promised at the start and what was achievable in reality. That gap existed from day one, embedded in the business case, and neither the sponsors nor the delivery team chose to address it directly until the programme was already in trouble.

The stakeholder expectation problem in digital transformation is routinely framed as a communication challenge. Better updates. More frequent steering committee engagement. Clearer reporting. These are sensible practices. They are also, in most cases, insufficient, because the problem is not that stakeholders were not kept informed. It is that they were kept informed using numbers and timelines that were not honest about the uncertainty behind them.

That is an honesty problem, not a communication problem. And the fix for it happens at the beginning, not during delivery.

 

The Business Case That Everyone Signed Off On

Digital transformation business cases are almost universally optimistic. Not because the people who write them are dishonest, but because the incentive structure in most organisations rewards ambition and penalises conservatism. A realistic business case, one that acknowledges uncertainty ranges, models downside scenarios, and commits to fewer benefits with higher confidence, is harder to get approved than an ambitious one. So the ambitious one gets written.

The consequence is that the business case becomes a set of commitments rather than a set of hypotheses. By the time the programme moves into delivery, the numbers in the original document are treated as targets rather than as estimates, even when the assumptions underlying them have already been revised. The expectation gap was always there. It was just papered over.

BCG’s analysis of more than 850 companies found that only 35% reach their stated digital transformation goals. Gartner’s October 2024 survey of more than 3,100 CIOs found only 48% of digital initiatives meet or exceed their business outcome targets. The gap is not primarily a delivery capability problem. It is a framing problem.

 

Scope at Altitude

The second structural cause of expectation gaps is scope defined at too high a level of abstraction. Transformation programmes are typically scoped during a phase when the delivery architecture is not yet understood, which means scope boundaries are drawn based on intent rather than on a detailed model of what delivery will actually require.

Both sides, sponsor and delivery team, leave the scoping phase with genuine but different understandings of what is included. Neither party is misrepresenting anything. They simply have not gone deep enough to discover the ambiguity. That ambiguity is then carried into the contract, into the programme plan, and eventually into the steering committee deck, where it will surface as a scope dispute at the moment least convenient for everyone involved.

The fix is not to define scope more tightly in the abstract. It is to define scope at a level of specificity that forces the ambiguity into the open before commitments are made. That is harder and slower than moving quickly to contract. It is also significantly less expensive than managing the dispute six months into delivery.

 

What the Programme Board Actually Hears

Stakeholder management, in practice, often means giving senior sponsors the confidence to remain supportive rather than giving them the information they need to make good decisions. Status reporting in large programmes tends to converge toward reassurance. RAG ratings stay amber longer than conditions warrant, because the consequences of going red feel disproportionate in the moment. Risks that have materialised are carried as risks rather than re-classified as issues. Forecasts are revised gradually rather than reset to reflect the actual picture.

This is not cynical. It is human. Nobody wants to be the person who delivers bad news. The programme team has worked hard. The delays feel temporary. There is always a reasonable argument for holding the line a little longer.

The problem is that by the time the gap between expectation and reality is reported honestly, it is too large to close without a significant reset. The reset conversation is much harder than it needed to be, because the sponsor was not kept informed of how the gap was developing.

 

The Expectation Reset Conversation

When the gap surfaces, and it always surfaces, the response that preserves the programme is not to defend the original business case. It is to reframe the conversation around what is still achievable, with what degree of confidence, on what timeline. That requires the delivery team to be willing to put a revised view in front of the sponsor, acknowledge that the original framing was overoptimistic, and propose a credible path forward.

That conversation is significantly easier when the relationship between sponsor and delivery has been built on honest reporting from the start. It is significantly harder when the sponsor has been receiving optimistic status updates and now feels misled, not because anyone intended to mislead them, but because the communication was shaped by the desire to maintain confidence rather than the obligation to maintain accuracy.

 

Less Ambiguity, Earlier

The conditions that produce the stakeholder expectation problem are well understood: optimistic business cases, scope defined at altitude, and status reporting shaped by the incentive to maintain confidence. None of these are inevitable.

The organisations that manage stakeholder expectations well are not the ones with the best communication strategies. They are the ones with the discipline to be specific about uncertainty before programmes begin, to define scope at a level of detail that surfaces ambiguity early, and to build reporting practices that give senior sponsors the information they need to make real decisions rather than the reassurance they want to maintain support.

Less ambiguity earlier. Fewer numbers presented as certain when they are estimated. Fewer commitments made before the delivery architecture is understood.

That is the fix. It is harder to sell at the outset and significantly easier to live with throughout delivery.

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.