The PMO Nobody Trusts
- and What to Do About It.

If you ask delivery teams what they think of the PMO, you will almost always get one of two answers: they ignore it, or they resent it. Neither is a sign that the PMO is doing something wrong in a simple, fixable way. Both are symptoms of the same deeper dysfunction: a function that has drifted away from its actual job.

What the PMO is supposed to do.

The purpose of a PMO, at its core, is to make the portfolio deliver better outcomes than it would without one. That means different things depending on the maturity of the organisation and the complexity of the portfolio, but it always involves some combination of: giving leadership visibility they could not otherwise get, reducing the coordination overhead that kills delivery teams, and making decisions faster by putting the right information in front of the right people at the right time.

What it does not mean is administering project templates, tracking RAG statuses, or enforcing methodology compliance for its own sake. A PMO that focuses on those things is busy, but it is not useful. And after a while, the organisation notices.

Pattern one: the reporting machine.

The most common PMO failure mode is becoming an elaborate status collection and distribution system. The PMO chases project managers for weekly updates, aggregates them into a report, formats it, and sends it upward. That cycle, chase, collect, compile, distribute, consumes most of the team's capacity and produces very little that leadership could not get by reading the project updates directly.

The problem is not the reporting itself. Visibility is genuinely valuable. The problem is that the PMO has stopped interpreting the data and started just moving it. Leadership gets a summary of what project managers said, not an independent view of where the portfolio actually stands. When decisions go wrong as a result, the PMO gets blamed for the report, when the real failure was not doing the synthesis job that only the PMO is positioned to do.

The fix is to make the PMO accountable for the insight, not the compilation. That means comparing what was reported last cycle against what was delivered, identifying projects that are consistently optimistic in their updates, flagging interdependencies that individual PMs cannot see, and framing escalation options rather than just describing problems. This is harder work than collecting statuses, but it is the work that earns trust.

Pattern two: the compliance officer.

The second failure mode is enforcing process without understanding why the process exists. This typically happens when a PMO has been given responsibility for a methodology: a project lifecycle, a set of stage gates, a template library, and starts measuring adherence rather than outcomes.

Delivery teams experience this as bureaucracy. They are not wrong. A project manager running a two-week discovery spike does not need a 14-field business case template signed off by four committees before they can talk to users. When the PMO insists on it anyway, the relationship breaks down, and the PMO loses access to real information because the team learns to route around it.

The underlying issue is that process exists to reduce risk and improve predictability. When the PMO loses sight of that purpose, it starts applying process uniformly rather than proportionately. A simple internal improvement project and a multi-year regulatory program should not go through identical governance hoops. Designing a proportionate governance model: light-touch for low-risk, rigorous for high-stakes, is one of the most valuable things a PMO can do. It almost always requires pushing back on the temptation to standardise everything.

Pattern three: the wrong accountability.

The third pattern is the hardest to name without causing offence, but it is real: a PMO that has been structured to serve the person who owns it rather than the portfolio it exists to support. This usually shows up not as overt dysfunction but as a subtle misalignment of priorities: the PMO produces the reports the CIO wants to show the board rather than the reports that help delivery leads make decisions. The metrics that get tracked are the ones that look good in a leadership review rather than the ones that expose real risk.

Delivery teams pick this up quickly. They see that raising problems through the PMO creates reporting problems for their sponsor, not solutions for them. So they stop raising problems through the PMO. The PMO becomes a clean layer on top of a messy reality, and eventually, people start working around it entirely.

Fixing this requires the PMO lead to have genuine independence, or at least the organisational authority to report what is true rather than what is comfortable. It also requires leadership to actively create the conditions for that: asking the PMO for bad news, not just status, and rewarding the function for surfacing risk early rather than for producing reassuring slides.

What changes things.

In my experience, the PMOs that earn trust share three characteristics. They have a clear answer to the question "what would delivery teams and leadership be worse off without?", and that answer is specific and credible, not generic. They are accountable for outcomes: not "did all projects submit status reports on time?" but "did the portfolio deliver its commitments, and did we flag the risks early enough to act?" And they have a way of listening to the organisation: regular conversations with delivery leads about where the governance process is adding friction versus value, and the willingness to change when the answer is unflattering.

None of this requires a large team or sophisticated tooling. It requires a clear-headed answer to a question that most PMOs have not been explicitly asked to answer: what problem, exactly, are you solving?