Most digital transformations are not killed by bad technology. They are killed by conversations that did not happen and decisions that sat on someone’s desk until they became unmanageable.

BCG’s 2020 study of 825 senior executives found that 70 per cent of digital transformations fall short of their objectives, with only 30 per cent in its “win zone” (If Failure Is Not an Option, Why Is Success So Rare?). McKinsey’s own survey found that just 16 per cent of organisations both improved performance and sustained the change (Unlocking success in digital transformations). The pattern repeats across both studies: the technology rarely breaks the programme. The leadership and governance around it does.

A PMO operating inside a transformation works a contested space. The business wants to move faster than governance allows, technology teams hold constraints that executives would rather not hear, and competing interests across the organisation sit in genuine, structural tension with each other.

A PMO that understands this role becomes one of the most valuable functions in the transformation. A PMO that misreads it adds to the friction it was built to manage.

Three tensions, not three personality clashes

Speed sits against governance. Every programme carries pressure to deliver, and delivery needs decisions; governance exists to give those decisions the right information, sign-off and an accountability trail. The two pull against each other permanently: the same structure that blocks a bad decision slows down a good one too. A PMO’s task is to tell the two apart, building a framework that routes low-risk calls fast and sends high-stakes, irreversible ones through full governance.

IT sits against the business. Technology teams know what a system can and cannot do; business leaders know what the organisation needs to achieve. Left unmanaged, the divide gets settled by whichever group has more momentum that week, which has nothing to do with which group holds the right answer.

Central control sits against local agility. Large transformations need coherence; individual business units need room to respond to their own operating realities. Centralise everything and the programme slows to a crawl, disconnected from delivery. Localise everything and it loses the consistency that makes it one programme rather than twelve.

Where the PMO earns its place

The PMO’s most valuable function in a transformation is translation. It turns a technology team’s constraint language into business decision language, so executives choose rather than absorb data. It turns programme strategy into the operational detail a delivery team needs. It turns tension between competing leadership factions into a structured choice, with a named owner and a deadline, so friction becomes a decision rather than a stalemate.

Simard and Aubry’s six-year study of a PMO inside a Canadian bank’s digital transformation, published in Project Management Journal in 2025, traced exactly this kind of shifting role (The Project Management Office’s Active Participation in a Digital Transformation: A Trajectory Full of Twists and Turns). Its path moved through five phases, lost strategic standing at points, rebuilt it through governance layers it had built, and never settled into a fixed, administrative shape. A role this adaptive does not fit an operating model built for a stable programme.

When the PMO loses the room

There’s a recognisable failure pattern. Decisions start happening outside the steering committee. Status reports read clean while everyone in the room knows the programme is not. The real conversations about programme health move into corridors and side calls instead of the forums built for them.

By the time that pattern sets in, the PMO is the last function to know what is actually happening inside the programme it is meant to govern, and the tensions that should have surfaced months earlier have compounded into something the organisation now has to fight rather than manage.

Build the PMO that changes the outcome

A transformation needs a PMO that creates the conditions for leaders to make the decision they have been avoiding. Structured forums with the right people and the right information. Escalation routes that do not need a crisis to trigger them. Reporting that reflects programme health honestly rather than managing the politics of the steering committee. And leadership with enough standing to say that the current trajectory will not deliver what the programme set out to achieve.

Most transformations already contain the information needed to course-correct before it is too late. Whether the PMO sees it, names it and gets leadership to act on it depends on how seriously the organisation treats the function in the first place.

Every governance failure gets the same response: add a committee. Nobody ever asks which of the five committees already in the room should be deleted.

I have watched this play out on the same programme, twice, thirteen months apart. An incident happens. A review is commissioned. The review recommends a new gate, a new sign-off, a new board with a name that sounds important. Nobody asks whether the five existing boards had already covered this ground and simply were not being used properly. The new layer gets built. The old layers stay exactly where they were, because retiring a control is a much harder conversation than adding one, and nobody wants to be the person who removed the safeguard right before something went wrong.

Multiply that pattern across a few years of incidents, mergers, audits and regulatory nudges, and you get an organisation with more governance than anyone can actually operate.

The sprawl nobody planned and everybody built

Governance frameworks get bloated one reasonable-sounding addition at a time, not in a single decision. A near-miss produces a new checkpoint. An audit finding produces a new form. A departing executive leaves behind a committee that made sense under their sponsorship and none under anyone else’s. Each addition was defensible in isolation. Nobody ever sat down and asked what the whole structure looked like once you added them all together.

The organisations most proud of their governance maturity are often the ones carrying the heaviest version of this problem. More boards. More gates. More documented sign-offs. It reads as rigour on an org chart and feels like wading through treacle to anyone actually trying to get something delivered.

Fatigue looks like silence, not rebellion

The expensive part is what people do once the meetings stop making sense to them, not the extra meetings. They do not object. They do not escalate the absurdity of an ninth sign-off. They quietly learn which boxes can be ticked without real scrutiny, which approvals are theatre, and which route gets something through fastest regardless of whether it is the correct one.

That is governance fatigue, and it is far more dangerous than having too little governance in the first place. An organisation with no controls at least knows it is exposed. An organisation with too many controls believes it is protected, right up until the one decision that actually mattered slipped through a gate everyone had stopped taking seriously.

Clarity beats volume, every time

The research on decision rights backs this up more directly than most governance debates acknowledge. Itonics’s analysis of partner and programme governance found that organisations using a properly maintained RACI framework report 70 per cent fewer “who decides” disputes and 25 per cent faster decision cycle times. RACI works by replacing ambiguity with a single, shared answer to a question that used to require a meeting to resolve, not by adding another layer. The gain comes from governance that is unambiguous enough that people stop needing to ask, rather than from adding more of it.

That is the distinction most organisations miss when they respond to a failure by adding structure. The problem was usually oversight so diffuse that nobody could say, without checking three separate documents, who actually held the decision.

The discipline of taking something away

Fixing this requires a habit most organisations have never built: retiring governance on purpose. Every new control should come with an audit of what it is replacing, not just what it is adding. Every steering board should have to justify its existence against a simple test: if this group disappeared tomorrow, what decision would genuinely not get made anywhere else? If the answer is “nothing, it would just move up a level,” that board is inertia with a calendar invite, not governance.

The organisations that manage this well treat their governance structure the way a good engineer treats a system under load, asking what is carrying weight it no longer needs to carry and taking it out, rather than just adding capacity when something breaks.

Governance was never supposed to be heavy. It was supposed to be clear. Somewhere along the way, most organisations mistook the two for the same thing.

A go live report is easy to write. Every site is on the new system, every licence is issued, every training session delivered on schedule. Three months later, the usage dashboard tells a different story, and it is the dashboard nobody puts in front of the steering committee.

The Metric Everyone Reports

Deployment is countable in a way adoption never is. Percentage of sites migrated, number of licences activated, hours of training delivered, these are the figures that go into a programme status report because they can be measured on the day the rollout finishes. None of them says whether anyone is still using the system a quarter later, or whether they have quietly gone back to the spreadsheet it was meant to replace.

The Number Nobody Puts in the Steering Deck

IBM’s 2026 Global CEO Study, based on more than 2,000 chief executives surveyed worldwide by the IBM Institute for Business Value, found that only 25 per cent of workers use AI regularly in their jobs, even though 86 per cent of CEOs believe their workforce already has the skills to do so. Eighty three per cent of the same CEOs said AI’s success depends more on people’s adoption than on the technology itself. The rollout finished on schedule. The adoption did not follow.

What Poor Adoption Actually Costs

A Forrester Consulting study commissioned by Whatfix, surveying 335 senior decision makers at large organisations across North America, Europe, APAC and India, put a figure on what that gap costs a mid-sized enterprise, $10.9 million a year, plus 728 hours lost per employee navigating systems that were rolled out but never properly embedded. That is not a training budget line. It is the ongoing cost of a deployment nobody followed up on. The same research found a wide gap between organisations with adoption maturity and those without, 53 per cent of mature adopters reported improved user experience against 28 per cent of the rest, and 56 per cent reported stronger return on investment against 28 per cent.

Why Deployment Metrics Miss This

Programme reporting is built around milestones a PMO can close off: go live achieved, training complete, licences distributed. Adoption behaves more like a curve than a milestone, one that keeps moving long after the project has been marked complete and the team has moved on to the next initiative. By the time low usage shows up in a satisfaction survey or a renewal conversation, the people who owned the rollout are three programmes further down the roadmap.

Part of the reason adoption rarely gets measured is that almost nothing in a typical programme is set up to reward it. Vendor contracts are frequently structured around go live milestones rather than usage thresholds, so the commercial incentive to keep measuring stops the day the system switches on. Programme teams are resourced to deliver a rollout, not to own what happens to it afterwards, and by the time adoption data would be available, the team has usually been reallocated to the next initiative. None of this is deliberate. It simply reflects a reporting structure and an ownership structure that both end at the same milestone.

What We Started Measuring Instead

On some programmes I have run, the fix had less to do with better software and more to do with what the steering committee agreed to look at. We started tracking active usage at 30, 60 and 90 days after go live, alongside a simple drop off rate, how many people who logged in during week one had stopped logging in by week twelve. We also moved benefits realisation sign off away from the go live date and tied it to a usage threshold instead, so a project could not be closed as successful until people were actually using what had been built. It is a small governance change, and it surfaces problems a deployment report never will.

Rollout dates and licence counts still matter, deployment discipline was never the issue. What most programmes are missing is a second dashboard sitting next to the first one, what deployment made possible, and what adoption is showing three months after anyone stopped watching. The programmes that quietly fail are rarely the ones that missed a go live date. They are the ones that hit it, reported it as a win, and never checked what happened next.

Nobody sets out to build a bureaucracy. Every heavy stage-gate process started as three good intentions: get bad projects killed early, get good projects through fast, and keep a clean record of why each call was made. Then it grew a review board nobody remembers approving, and the good projects started waiting as long as the bad ones.

That is the actual failure. Not that gates exist. That almost nobody still measures them against the job they were built to do.

The Test a Stage Gate Was Actually Built to Pass

Governance run properly delivers three things, and nothing else matters as much as these: faster decisions, so a good project stops waiting weeks for a yes. Earlier kills, so a weak one frees up capital instead of quietly draining it for another two quarters. And a clean audit trail, so nobody has to reconstruct the reasoning after the fact. Get those three right and a stage gate speeds decisions. Miss them and it slows every decision down, good and bad alike, because the mechanism has stopped doing the job it was built for.

Someone genuinely has to decide which projects live, which pivot, and which ones are quietly draining the business. That much was never in question.

Why the Mechanism Rots

Four patterns do most of the damage, and each one accumulates quietly rather than arriving as a single bad decision. Entry gates get heavy while exit and kill discipline stay weak or disappear entirely, so zombie projects clog the funnel and starve the strong ones of attention. Panels grow larger and meetings grow longer until authority is spread across so many people that nothing actually gets decided. Reviews turn into theatre, rubber-stamping or deferring rather than choosing, and momentum dies in the gap between gates. And decision rights stay ambiguous enough that nobody is the clear owner of the yes or the no, so everything escalates and stalls at once.

Each of those four is a governance design that stopped serving the teams running through it and started serving itself, not a process flaw you fix by adding another step. The entry gate feels productive, so it keeps growing. The exit gate feels harsh, so nobody wants to own it, and that imbalance is where most of the trouble actually starts.

The Numbers Behind the Frustration

The frustration shows up in real operating numbers, not just complaints. At Vivix Vidros Planos, a Brazilian flat-glass manufacturer, resolving a customer complaint used to take weeks, long enough for a buyer to lose patience and take the next contract elsewhere. After building an AI-powered chatbot into its existing production and quality data, that shrank to minutes, an 80% reduction in complaint resolution time. Responses to production-line issues sped up by a further 85%. Both figures come from Vivix’s own case study, published jointly by Siemens and AWS. The underlying pattern holds regardless of the exact numbers: the real cost of a slow gate shows up as lost trust and lost contracts, not just lost hours.

What Minimum Viable Governance Actually Looks Like

The fix is sizing each gate to the actual risk in front of it, rather than running every decision through the same heavy process regardless of what it actually requires. A low-risk process tweak does not need the same panel as a bet-the-quarter platform launch, and treating both the same is exactly how standing committees fill up with work they should never see in the first place. High-risk decisions keep full board review, because that rigor is proportionate there. Mid-tier decisions get a lightweight gate with a single accountable owner. Low-risk work proceeds by default through a simple intake form, with oversight applied only if something in it actually warrants it.

The useful design target sits between two failure modes: above a ceiling, controls become bottlenecks and teams quietly route around them; below a floor, real risk creeps in unmanaged. Getting that band right is not abstract. One organisation that tightened its policy down to the minimum viable version halved the time complex decisions took and surfaced three times more opportunities than peers still running the heavier version.

The Test Most Gates Would Fail

Pick the last three projects your organisation killed at a gate, and the last three it approved. If the kills took longer to reach than the approvals, the gate is not protecting the business from bad decisions. It is protecting itself from having to make any decision at all.

Why Traditional Project Management Is Failing Modern Teams

Most project failures get blamed on execution. A missed deadline. A stakeholder who went quiet at the wrong moment. A scope that crept until nobody could point to when it happened.

Look earlier and the failure was already built in before a single sprint started.

A Forbes Technology Council analysis makes the point directly: misalignment gets embedded into the foundation long before execution begins, not manufactured somewhere in the middle. The team that won the deal rarely stays involved in delivery. The customer’s actual operating mindset only reveals itself once work is already moving. The incentives written into the contract often point delivery and client in different directions before day one. Teams execute a plan that was already structurally unsound before the first sprint started.

Traditional project management was never built to catch that kind of problem. Waterfall assumes you can define requirements fully upfront, lock them, and deliver against a fixed spec months later. That assumption survives about as long as the first change request. Priorities that shift inside a six-week planning cycle, which describes most programmes now, make a locked spec obsolete before it has even shipped.

Rigidity Is the Symptom. Something Else Is the Disease.

Here’s the twist most framework debates miss. Methodology by itself isn’t what separates the teams that deliver from the ones that don’t. PMI’s most recent Pulse of the Profession research found project performance sits at roughly 73.8% whether a team runs predictive, hybrid, or agile delivery, and whether people work remote, hybrid, or in-person. What actually moved the needle was business acumen: professionals strong in it posted 27% lower failure rates, regardless of which framework sat on the wall.

Framework still matters. It was just never the whole story, and treating “which methodology” as the central question misses where most programmes actually break.

A PM Solutions case study makes the same point at a larger scale. A U.S. staffing company with more than 8,000 internal and 90,000 contract employees had already tried and failed to stand up a PMO once. On the second attempt, the team built a hybrid methodology suited to the client’s actual environment, blending traditional project management, agile, and the touchpoints where each meets software delivery, then added a governance structure, portfolio visibility and resource planning on top of it. Within six months, every project flagged red under the new reporting system, more than $13 million worth of work, was recovered. One severely troubled multi-year project, over budget and behind schedule, was turned around in four weeks once it had a dedicated programme manager working inside that structure. Not a framework doctrine. Governance and visibility.

The Real Adoption Curve

That pattern shows up in the adoption numbers too. Hybrid delivery has grown 57% since 2020, while purely predictive approaches have fallen 24% over the past three years. The pattern behind that shift is simple: pure Waterfall and pure Agile were both answering questions the actual work wasn’t asking, and organisations are admitting it with their adoption numbers rather than in a strategy memo.

Rigid, one-size-fits-all implementation is what actually ages badly, more than the framework choice underneath it. Portfolios that mix delivery models by what the work actually demands, a predictable cadence for mature products, flow-based delivery for continuous work, fast validation cycles for early bets, consistently outperform portfolios that force every initiative through the same certified process regardless of fit.

What This Means for the Programme You’re Running Now

The practical shift isn’t abandoning structure for chaos. It’s building governance that travels with whichever delivery model fits the work, instead of assuming the delivery model is the governance.

Start by naming decision rights before the kickoff, not after the first dispute breaks something. Someone owns scope changes. Someone owns the call when a dependency slips. Everyone on the programme should be able to name both without asking. Build the escalation path into the plan itself rather than inventing one under pressure in week eight, and match the delivery model to the type of work in front of you rather than to what worked on the last programme. A regulated, multi-vendor transformation and a ten-person product team shipping a new feature are not the same problem, and forcing them through the same framework produces the same failure pattern twice.

Track what the framework was supposed to deliver, not whether the ceremonies happened. A team that ran every stand-up and still shipped nothing useful followed the process and failed anyway.

The Question Every Kickoff Should Answer First

Before the next programme gets a charter and a framework stamped on the cover page, ask a harder question first: who owns the decision when priorities collide, and does that answer exist in writing before the first sprint starts?

If it doesn’t, the framework on the cover page was never going to save the programme underneath it.

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.