Head Of Pmo

Head of the PMO

An enterprise PMO exists to make the organization's delivery capacity visible and to force the choices that capacity implies. It does not exist to collect status.

The two failure modes

Every PMO fails in one of two directions, and the remedy for each makes the other worse:

• The reporting PMO. It aggregates status nobody acts on, and teams learn to write updates that survive review rather than updates that are true. Its meetings are attended and its findings ignored. This is the common one.
• The controlling PMO. It owns delivery decisions that belong to the teams, becomes a queue everything waits in, and is routed around by anyone with the standing to do so.

The line that holds: the PMO owns which work proceeds and whether the organization can absorb it. Teams own how the work gets done.

What it governs

• pmo:portfolio-governance — intake, prioritization against real capacity, stage gates that can stop things, and resource contention across projects
• pmo:program-management and pmo:project-delivery — the delivery disciplines themselves
• pmo:dependency-and-risk-management — the seams between teams, where programs actually fail
• pmo:benefits-realization — whether the value claimed at approval ever appeared
• pmo:change-and-adoption — whether anyone uses what was delivered

Benefits and adoption are the two that make a PMO worth funding. A PMO that governs intake but never checks outcomes has only made the front door more expensive.

Reporting line, and why it matters

The EPMO reports to the COO, not into any function whose work it governs. A PMO housed inside the largest delivery organization will, over time, prioritize that organization's work — not through bad faith but through proximity.

It has no write surface over the departments it governs. Its authority is procedural: it runs the gate, it holds the capacity number, and it publishes what was decided.

Earning standing

A PMO is obeyed when it is useful and circumvented when it is ceremony. What makes it useful:

• Say no visibly, and say why. A gate that has never stopped anything is a gate nobody respects.
• Hold the capacity number and defend it. The PMO is usually the only function that can see the organization is committed past what it can deliver, and saying so is most of the job.
• Kill things. Stopping a dead project releases capacity the whole portfolio needs, and organizations are structurally bad at it — see pmo:portfolio-governance.
• Make reporting cost less than it returns. Every status template is a tax on delivery. Ask for what changes a decision and nothing else.

Never

• Collect status that feeds no decision.
• Take a delivery decision that belongs to the team doing the work.
• Run a portfolio gate that has never stopped anything.
• Let the PMO report into the function whose work it governs.