PMOs have a reputation problem, and a reasonable amount of it is earned. Ask engineers in a large organization what the PMO does and you will get answers ranging from polite to unprintable.
And yet every delivery organization that reliably lands complex work has something that looks like one. Somebody owns the critical path across teams. Somebody tracks the dependencies that fall between them. Somebody has the uncomfortable conversation about a date.
The difference between the version that helps and the version everyone routes around comes down to one thing: what it is allowed to decide.
The reporting trap
The failure mode is easy to recognize. A PMO is created to give leadership visibility. It builds a template, chases teams for updates every week, and assembles a pack. The pack is comprehensive, arrives on schedule, and is mostly read to page two.
Nobody in the function has authority to change anything the pack describes. When a program goes red, the PMO reports that it is red. When a dependency slips, the PMO records the slip. Its entire output is description.
Delivery teams work out quickly that the pack is a tax rather than a mechanism, and they start managing the pack instead of the work. Status stays amber because amber generates fewer questions than red. Which is how a program remains cautiously optimistic for eleven months and then discovers a six-month delay in month twelve — not because nobody knew, but because the mechanism for saying so was purely descriptive and the incentive ran the other way.
Decision rights, written down
Before the first steering committee, write down which decisions this function makes, which it recommends, and which it escalates. Not as a philosophy — as a list.
Reprioritizing within an agreed scope boundary: decides. Reallocating people between workstreams inside the same budget: decides. Moving a milestone date: recommends, with options. Changing scope, budget, or the go-live commitment: escalates.
Then hold to it, particularly the first time it is inconvenient.
And escalations should never arrive naked. "Workstream three will miss the March gate" is a status update. "Workstream three will miss March. Here are three options with cost, risk, and knock-on effects. We recommend the second, and we need a decision by Thursday to hold the rest of the plan" is management. The first makes the problem leadership's. The second makes the decision leadership's, which is the only part that should be.
Report by exception
A report that opens with what is off track and what is being done about it gets read. A comprehensive one that requires the reader to locate the problem does not.
The shape that works is roughly one page. Items off track, the impact, the action, the owner, the date it resolves. Then a short summary of everything on track. Then, for the people who genuinely want it, an appendix with the full detail — which exists partly so that the people who want completeness stop pushing it onto page one.
The other half of this is reporting against a baseline that does not quietly move. If a date changes, the baseline stays and the variance is visible. Rebaselining is a legitimate decision, but it should be an explicit one, made in a meeting, with a recorded reason. Programs where the baseline silently tracks reality are always on plan, right up until they are not.
Governance sized to the risk
There is an opposite failure worth naming, because organizations that have been burned tend to overcorrect into it: ceremony that outlives the risk it was built for.
A weekly steering committee is appropriate when a program is in trouble or in a critical phase. Keeping it for eighteen months after the program stabilized consumes the attention of exactly the senior people you will need for the next problem, and trains everyone to treat governance as a formality.
Review the governance itself on a cadence, and be genuinely willing to dismantle parts of it. A quarterly review that replaced a weekly one is a sign of a program that is going well, not of a function losing control.
The test
Two questions will tell you which kind of function you have.
When was the last time this function changed a decision rather than recorded one? And on the last program where a date slipped, how long was it between the delivery team knowing and leadership knowing?
If the answers are "I cannot think of one" and "a couple of months," the function is not managing delivery. It is a reporting line with a project management qualification, and the programs are being run — or not — somewhere else entirely.