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.

The Programme Succeeded. That Was the Problem.

Posted on by

Most digital transformation programmes are designed to end.

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

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

 

The Project Mindset Is the Actual Liability

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

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

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

 

What Continuous Capability Actually Looks Like

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

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

 

The Five Things That Actually Change

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

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

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

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

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

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

 

The Question Worth Asking Before the Next Transformation Sign-Off

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

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

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

Posted on by

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

That sequencing is the problem.

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

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

The workforce is the one variable that determines everything else.

 

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

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

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

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

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

 

Where the Design Failure Actually Happens

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

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

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

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

 

The Three Decisions That Set the Conditions

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

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

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

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

 

The Longer View

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

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

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

Design around them first.

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.

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.