Most PMOs were built to report on delivery problems. Not fix them. The mandate stops at the line between tracking what’s wrong and actually doing something about it. And that line is where most programmes quietly fall apart.
Nobody set out to build a reporting function.
When organisations invest in a PMO, they’re not usually trying to create more meetings. The ambition is always delivery improvement – better outcomes, more consistent execution, fewer projects that run over time and budget. That ambition is entirely reasonable. The results, more often than not, are not what anyone planned.
PMO satisfaction scores in surveys are consistently low. Leaders describe their PMOs as overhead-heavy and impact-light. Teams on the ground see them as the people who want the RAG update by Thursday, not the people who come and help when the programme is in trouble. Something has gone wrong – not with the people, but with the model.
The function built for governance, judged for delivery
Here’s the structural problem most organisations won’t name directly: PMOs are usually built for assurance and measured on delivery. They’re designed to provide oversight – to track status, consolidate reporting, maintain standards, and flag risk. All of that is valuable. None of it is the same as making delivery happen.
When a programme starts slipping, the PMO can tell you precisely how it’s slipping. It can produce a timeline showing exactly when the first warning signs appeared. It can document the decisions that were made and the risks that were accepted. What it often cannot do is fix it – because it was never resourced to fix it. The mandate stops at the line between reporting and doing.
Diagnosis without the authority or resource to intervene isn’t governance. It’s expensive documentation.
The assurance trap
There’s a reason PMOs drift toward assurance work, and it’s not because PMO professionals lack ambition. It’s because assurance is measurable, repeatable, and defensible in ways that delivery improvement is not. You can show a dashboard. You can point to a methodology framework. You can evidence that the standards are being applied.
Delivery improvement is messier. It requires intervention in live programmes, difficult conversations with senior stakeholders, and the kind of hands-on involvement that doesn’t fit neatly into a PMO operating model built around reporting cycles. So the PMO reports. The programme misses its date. The PMO reports on why.
Over time, the function becomes associated with the process of recording failure rather than the practice of preventing it. That’s not a perception problem. It’s a design problem.
What mandate actually means
The PMOs that do improve delivery share a few things that are worth examining. First, they have genuine mandate – not just the authority to ask for updates, but the authority to challenge decisions, escalate resource issues, and in some cases halt work that isn’t viable. Without that, the PMO is advisory at best and ignored at worst.
Second, they have access to deployable capability. When a project is in trouble, they can do something about it – whether that’s providing experienced project management support directly, reshaping a plan, or making a resourcing recommendation that leadership will act on. The difference between a PMO that influences delivery and one that observes it is almost always about whether they can put the right people into the problem.
Third – and this is the one most commonly missing — they’re treated as a delivery partner by the organisation’s leadership, not as a compliance function. The moment a PMO is primarily associated with gates and sign-offs, it loses the trust of the delivery teams it’s meant to support. That trust, once lost, is extremely hard to rebuild.
The PMOs that work have mandate, capability, and trust. Most are funded for the first, given a fraction of the second, and have to earn the third against the odds.
The capability gap no one wants to fund
There’s an awkward reality sitting in the middle of all of this: if a PMO is going to improve delivery, it needs to be able to put experienced delivery resource into programmes that need it. That means either having those people permanently on staff – a significant headcount investment – or having access to them flexibly when they’re needed.
Permanent staffing is rarely sized for peak demand. The result is that the PMO has enough resource to run the reporting function but not enough to deploy meaningful support when a programme is struggling. The gap is visible, the solution is known, and the budget conversation never quite happens.
A more honest conversation about what the PMO is for
If you want your PMO to improve delivery rather than report on it, the conversation has to start with what it’s actually resourced and mandated to do. Not what the operating model says on paper, but what happens when a senior programme is in difficulty at 11pm on a Wednesday and someone needs to make a call.
For some organisations, the answer to the capability gap is a flexible resourcing model – access to experienced programme and project management resource that the PMO can deploy without a permanent headcount decision. It doesn’t replace the internal function. It gives it teeth.
The honest truth is that most PMOs already know what they need. The question is whether the organisation is willing to fund the version that actually works.
Stoneseed provides PMaaS – experienced project and programme management resource deployed at pace, without permanent headcount. If your PMO is resource-constrained, it’s worth a conversation.