PMO — Charter

The PMO earns its existence by answering questions nobody else can: what are we actually working on, what is blocking it, and what happens to everything else if this slips.

In an AI-operated company that job gets easier in one respect — status collection, reporting and dependency tracking automate well — and harder in another, because more work runs in parallel and the dependencies multiply.

What this role owns#

The portfolio. Every active piece of work, its owner, its state, and what it depends on. If this is not in one place and current, the PMO is not functioning regardless of what else it does.

Delivery governance. How work is initiated, approved, changed and closed. Light enough to be followed, firm enough to mean something.

Dependencies across teams. The single largest source of delay in multi-team delivery, and the one nobody owns by default.

Change control. Not preventing change — making its cost visible at the moment it is requested.

The decision and risk registers. Kept current, reviewed, with owners.

KPIs#

Blocked days is the one to watch. Most delivery improvement in most organisations is available there, not in working faster.

AI agents in this function#

Status agent — assembles project status from the systems of record rather than from people writing updates. Removes the weekly reporting tax and produces something more accurate than self-reported RAG statuses.

Dependency monitor — watches commitments between teams and flags a slip on one side before it lands on the other.

Risk scanner — reads project artefacts for unstated risks: unconfirmed dependencies, missing acceptance criteria, single points of knowledge.

Meeting-to-record agent — turns a discussion into decisions, actions and owners. A human confirms before it enters the register.

What stays human: prioritisation, the decision to stop a project, negotiating a date, and telling a sponsor something they do not want to hear.

SOPs#

• Intake — how a request becomes a project: sponsor, measurable objective, out-of-scope list.
• Weekly portfolio review — exceptions only. Green projects take no meeting time.
• Change control — every request states what it displaces: scope, date, or budget.
• Escalation — routes and response times, with a named deputy for each decision-maker.
• Closure and lessons learned — including projects that were stopped. Those teach the most.

Templates#

Project Plan · BRD · Test Plan · Release Checklist · risk register · decision log · change request.

Depth on the underlying disciplines is in the PMO Knowledge Center.

Workflows#

In: new requests · status from systems · escalations · change requests · risks raised.

Out: the portfolio view · exception reports to the CEO · decisions needed, with options · confirmed dependency commitments.

Handoffs: Engineering and QA for delivery · Finance for budget · CEO for stop/go on anything material.

The loop that matters: a blocker surfaces → an owner is named → a decision date is set. A blocker without both of those is just a status update.

FAQ#

Does an AI-operated company still need a PMO?#

More than a traditional one, if anything. More work runs in parallel, so dependencies and prioritisation get harder. What changes is that the PMO stops being a reporting function and becomes a decision-support one — the reporting is automated.

Isn't this just bureaucracy?#

It is when the artefacts exist to satisfy a process rather than to answer a question. The test for every artefact: which decision does this inform? If none, stop producing it.

Agile or predictive?#

Match it to the situation, and say which you are running. Most real portfolios are a fixed outer boundary of budget and date with adaptive delivery inside — a coherent position, but only if it is stated rather than pretended.

What is the fastest improvement available to most PMOs?#

Measure blocked days and publish them by cause. It converts "we are late" into "we lost eleven days waiting for a decision on X", which is actionable and hard to argue with.

What else is coming for PMO