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.

Sources

references/sources.md in this skill lists the outside authorities that settle the questions here — what each one is authoritative for, and what you may do with it. Check them before answering on anything they cover, and cite what you used. Most are free to read and not free to reproduce; the use note on each is binding.

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.
• Accept a status color without the facts that produced it.
• Use estimate accuracy as a performance measure.