Nobody has ever failed a project because they didn’t know how to build a Gantt chart. However some failed because nobody taught them who was allowed to say no.

I have sat in quite a number of programme inductions, and every one of them covers the same ground. Scheduling. Budgeting. Risk logs. RAID templates. Reporting cadence. Then, somewhere around the second afternoon, someone puts up a slide about governance and the room’s attention visibly leaves the building. It is treated as the compliance module, the thing you sit through before you get to the real work. Nobody walks out able to say, with any confidence, who actually owns the call when a decision does not fit neatly on a template.

That gap is not an oversight. It is a choice organisations keep making, year after year, without ever naming it as one.

The curriculum has a hole in it

Ask a newly promoted programme manager to explain their RAID log and they will do it fluently. Ask them who has the authority to accept a risk above a certain threshold without escalating it, and watch the pause. That pause is the sound of someone realising they were never actually taught the answer, only ever expected to absorb it by watching more senior people long enough.

A 2026 AI Governance Gap Report surveying more than 500 HR professionals found that only 45 per cent of organisations provide AI literacy training to all employees, one concrete, measurable instance of the broader governance-literacy gap this piece is about. Two-thirds of HR teams are already using AI to shape compliance and policy decisions, and the same report found fewer than half have given employees even that AI-specific literacy training to keep pace. The gap shows up well beyond HR too, in every function that has ever built a decision-rights framework, filed it in a folder, and assumed the document itself did the teaching.

Documents do not teach. People do, and usually only the ones who were already senior enough to have picked it up somewhere else.

Decision rights are treated like folklore

Most organisations do not lack a governance framework. They have one, usually a good one, sitting in a policy library that almost nobody outside the PMO has opened. What they lack is a mechanism for turning that document into instinct.

The result is a workforce that learns decision rights the hard way: by guessing wrong in front of a steering committee, by escalating something trivial and being quietly told off for wasting everyone’s time, or by not escalating something serious and finding out only when it has become a crisis. Every one of those is an expensive way to teach a lesson that could have been taught in an afternoon.

This is where the “knowing-doing” research cited by Harvard Business Review becomes uncomfortable reading for anyone who runs a training budget. Two out of three managers say they are still uncomfortable having accountability conversations with their own people, despite most of them having sat through the leadership training designed to prepare them for exactly that. The problem was never a shortage of content. Knowing a framework exists and being able to act on it under pressure are two entirely different skills, and organisations keep training the first while assuming it produces the second.

Governance training suffers from the same fault line. Knowing there is an escalation policy is not the same as recognising, in the middle of a stressful Tuesday, that the decision in front of you is the one the policy was written for.

The training everyone skips because it looks obvious

There is a reason this particular gap survives budget reviews when almost nothing else does. Governance training looks like it should be simple, so nobody prioritises building it properly. Everyone assumes the framework document is self-explanatory, right up until the moment someone makes the wrong call and the post-incident review discovers that three different people had three different understandings of who was supposed to decide.

I have run those reviews. The finding is almost never “the framework was wrong.” Almost always, nobody had ever been walked through what the framework meant in a live situation, so everyone applied their own version of common sense, and common sense is not actually common.

What actually needs teaching

A longer policy document will not fix this. Longer documents get read less, not more. The fix is teaching people to recognise a decision point before it arrives, not after.

That means running people through real scenarios instead of abstract categories, trading “what is your escalation threshold” for “here is a supplier problem that looks small and is not, what do you do in the next ten minutes.” It means naming, out loud and often, the handful of decisions in your organisation that carry disproportionate weight, so people learn to feel the shape of one before it is labelled for them. And it means treating governance literacy the way you would treat safety training: refreshed, tested, and taken seriously enough that senior leaders visibly participate in it themselves, rather than left as a one-off induction module.

The organisations that get this right build fewer, better decision-makers rather than thicker governance frameworks: people at every level who can spot a genuine decision point on instinct, the same way an experienced engineer can hear an engine fault before the dashboard lights up.

You cannot budget for the crisis a decision creates and then refuse to budget for teaching people to see it coming.

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.

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.