What should a PMO own, and what should it leave alone?

The fastest way to break a PMO is to be vague about what it owns. Give it too little and it becomes a passive collector of other people's updates, with no authority to change anything. Give it the wrong things and it starts making delivery decisions that belong to the people actually doing the work, and it quietly undermines the very teams it exists to support.

What a PMO should own is the connective tissue of the portfolio. The standards for how delivery is reported, so that information is comparable across programmes. The cross-cutting view of dependencies and resources, because no single programme can see the whole board. The cadence and the data that let leadership make portfolio-level choices. These are things that only make sense above the level of any one programme, which is exactly why they belong to the PMO.

What a PMO should leave alone is how an individual programme chooses to deliver. The sequencing of its work, the calls its delivery lead makes day to day, the trade-offs inside its own scope. A PMO that reaches into those decisions confuses oversight with control, and the result is a delivery team that feels supervised rather than supported, and that starts managing the PMO instead of managing the work.

The line I hold is between the system and the work. The PMO owns the system that delivery runs inside. The language, the standards, the visibility, the rhythm. The teams own the work itself. When that line is clear, the PMO becomes something delivery leads want, because it removes friction and makes their real problems visible to people who can help. When it is blurred, the PMO becomes something to be managed around.

There is a governance dimension to this as well. A PMO often holds the assurance role, checking that what is reported reflects reality. That is a legitimate and valuable thing to own, but it is different from owning the delivery itself. Confusing assurance with delivery is how a PMO ends up both marking the work and being blamed for it.

For a leader setting up or fixing a PMO, the most useful exercise is to write down explicitly what it owns and, just as importantly, what it does not. The second list is the one that gets skipped, and it is the one that decides whether the teams trust the function or merely tolerate it.