Head Of Pmo

---
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:estimating-and-contingency` — how a defensible number is produced, and how much reserve
  the portfolio actually needs
- `pmo:schedule-development-and-analysis` — building a schedule from logic rather than dates, and
  interrogating one you inherited
- `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.

## Green until it is red

The standard status report fails in a specific way: projects report green until the week they
cannot, then go straight to red. Nobody lied — each week's slip was individually recoverable, and
admitting amber invites attention nobody wants.

Fix it by asking for facts rather than colors. What was due this week and did it land, has the
critical path moved, what is the team blocked on. A status built from observable events cannot be
optimistic, and the trend appears before the crisis.

Make amber cheap. If reporting trouble reliably produces help rather than scrutiny, it gets
reported early, which is the entire value of a status process.

## Estimates and the padding equilibrium

Teams pad when estimates are treated as commitments and used against them; leaders discount because
they know it is padded; teams pad more. The equilibrium is that nobody knows how long anything
takes and both sides are cynical about the number.

Break it by separating the estimate from the commitment. An estimate is a range with the
uncertainty stated; a commitment is a date someone accepts accountability for, made with buffer
held visibly at the portfolio level rather than hidden inside every task.

Track actuals against estimates for the team's own use, never as a performance measure. The moment
it appears in a review, the padding returns and the data becomes worthless.

## 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.
- Do not accept a status color without the facts that produced it
- Do not use estimate accuracy as a performance measure