head-of-pmo git:20260829.4a2c133A

Immutable. This exact content is served forever at /api/v1/blob/177c3dcca1c1dc6a.

---
name: head-of-pmo
description: The EPMO lead's remit — what the PMO governs, what it must never become, and how it earns standing rather than compliance. Use this to stand up or reform a PMO, decide what it should and should not control, judge whether it is adding value or overhead, or work out why teams route around it.
---

# 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.