Skip to content

09Service

PMO Setup & Program Management

Portfolio governance sized to the work: cadence, gates and benefit tracking that survive scrutiny.

PMO setup, done honestly, starts with a question most providers skip: should this office exist at all? A programme management office earns its cost only when the portfolio is large enough that decisions — sequencing, funding, killing, resourcing — genuinely exceed what a good operating cadence can carry. When it is justified, I build the right-sized version: portfolio governance that produces decisions rather than status, a programme cadence with real gates and escalation thresholds, benefit tracking a CFO will accept, and the minimum reporting that supports all three. When it is not justified, I will tell you so and build the lighter thing instead — an operating rhythm and clear owners, at a fraction of the cost.

The craft comes from running programmes where the governance had to hold, not from a methodology binder. The quality programme that moved 95% to 99% across 2,000+ campaigns, the billing transformation that cut a two-month cycle to fifteen days across 75 entities and 2,000+ employees — these were multi-workstream programmes with sceptical stakeholders, hard baselines and benefits that had to be proven, run inside a global network where slippage was visible immediately. The formal grounding is there too — Google-certified in both project management fundamentals and agile process management, alongside Lean Six Sigma — but certifications describe the toolkit. The evidence is that the programmes landed and the gains held.

The design bias throughout is smallness. The best PMO is the smallest one that governs: a handful of gates that actually gate, a portfolio review that kills weak projects while they are still cheap, benefit baselines set before work starts, and reporting thin enough that delivery teams barely feel it. The office is built to be handed over — an internal owner runs it, the playbooks are theirs, and my exit is part of the design. What I will not build is a template factory: a PMO that measures its own health by compliance with its own paperwork has already failed, expensively and quietly.

01The problem

Transformation portfolios fail politely. A dozen initiatives run in parallel, each with a deck and a RAG status, none with a decision behind it. Steering committees meet monthly to watch slides. Benefits are claimed at approval and never seen again — the P&L somehow unmoved by three years of green dashboards. Meanwhile delivery teams spend more hours reporting progress than making it. The instinct is to add a PMO. But a PMO built as a reporting factory makes all of this worse. Governance is the missing piece — and governance means decisions.

02Signs you need this

When this is the right call.

  • 01

    A dozen initiatives are running and nobody can rank them

  • 02

    Steering meetings review status but never make a decision

  • 03

    Benefits are claimed in business cases and never found in the P&L

  • 04

    Every project has been amber for a year

  • 05

    Delivery teams spend more time reporting progress than making it

  • 06

    Two programmes are quietly fighting over the same people

03The method

How the work goes.

  1. 01

    Decide if a PMO should exist

    A short, honest sizing exercise: the real portfolio, the decision load it generates, and whether an office clears the bar over a good cadence with clear owners. The recommendation is written and argued either way — including when the answer is no, which it sometimes is. Sizing first protects everything after it.

  2. 02

    Design the governance

    Decision rights, stage gates, escalation thresholds and a portfolio view ranked by value and risk — designed before any template exists. Reporting is derived last, sized to the decisions it must support and nothing more. Governance produces decisions; paperwork is only what decisions leave behind, never the other way around.

  3. 03

    Stand up the office and cadence

    The portfolio review, the programme rhythms, the benefit baselines and the tooling — built on whatever systems you already run. I chair the first cycles myself so the standard is set by demonstration: gates that actually gate, escalations that actually move, minutes that read as decisions rather than attendance.

  4. 04

    Prove benefits and hand it over

    Benefit tracking wired to baselines a CFO will accept — claimed at the gate, measured after delivery, reconciled against the P&L or the operating baseline. Then the office transfers: an internal owner trained in the chair, playbooks documented from live operation, and my involvement tapering to a scheduled end.

04In depth

What this work really involves.

Status theatre — how programme governance fails politely

The failure has a recognisable liturgy. Slides are prepared for the steering committee. The steering committee receives the slides. Progress is noted, risks are acknowledged, the RAG stays amber-trending-green — and nothing is decided, because nothing was framed as a decision. Six months later the portfolio holds the same twelve projects plus three new ones, delivery capacity is quietly oversubscribed, and the only measurable output of governance is the reporting burden itself. The root cause is a category error: treating governance as visibility. Visibility is cheap and abundant; decisions are scarce and expensive, and a governance system is only real if projects get killed, resequenced and refunded because of it. The first thing I change is the agenda: every item arrives framed as a decision, or it does not arrive.

The portfolio review that earns its authority

A working portfolio review has a shape, and it is not a slideshow. It opens with the portfolio view — every initiative on one page, ranked by value, risk and resource draw. It spends its time on exceptions: gates due, thresholds breached, resource conflicts, benefits falling short of baseline. Each exception is framed as a choice with options and an owner, decided in the room, logged, and checked at the next cycle. And it kills things. A portfolio that never cancels a project is not being governed — cancellation is the system working, reclaiming money and people from initiatives that have stopped deserving them while the loss is still small. Run this way, the review becomes the most consequential ninety minutes in the month, and attendance stops being a problem.

Right-sizing: the smallest office that governs

PMO sizing fails in both directions. The heavyweight version metastasises: a template for everything, a meeting for every template, analysts whose job is formatting other people’s progress — drag sold as control. The invisible version fails more quietly: one coordinator with no authority, maintaining a spreadsheet nobody reads, while the real decisions happen in corridors. The right size follows from decision load, not headcount fashion: how many initiatives, how much contention for the same people and money, how many gates genuinely need scrutiny independent of the teams being gated. For many mid-sized companies the honest answer is two or three capable people with real authority, a sharp portfolio review and thin reporting. The test is always the same: does the office make the portfolio easier to steer, or just better documented?

When a PMO should not exist

Part of this service is the recommendation not to buy it. Below a certain portfolio weight — roughly, when initiatives number in the single digits and share few dependencies — an office adds process without adding governance. What that situation needs is cheaper: a monthly portfolio slot inside the existing operating review, one named owner per initiative, a one-page status standard and a kill rule. I have no interest in building offices that exist to justify their own reporting; they consume the credibility that real governance later needs. There is also a temporary variant worth naming — a programme office stood up for a defined transformation and dissolved on completion, deliberately, rather than lingering as overhead. If the honest recommendation is no PMO, the sizing exercise ends there — and costs you a conversation.

Benefit tracking that survives a CFO

Most transformation benefits die between the business case and the P&L, killed by baselines that were never set. The discipline is sequencing: baseline before work starts — the current cost, cycle time or defect rate, measured and agreed; benefits claimed at the gate in terms that reconcile to that baseline; then measured after delivery, with the delta attributed honestly — including the share that came from volume changes or would have happened anyway. This is the same evidence standard I apply in process transformation work, where a gain that cannot be shown against a control is a story rather than a result. Portfolios run this way develop a compounding advantage: funding decisions improve because benefit claims carry track records, and teams stop inflating cases they know will be measured.

Programme cadence, gates and escalation

Between portfolio reviews, individual programmes need their own discipline. A cadence proportionate to risk — a weekly working rhythm for delivery, a gate only where a real commitment changes: funding released, scope locked, a go-live authorised. Escalation thresholds set numerically in advance — schedule slip, cost variance, benefit erosion — so that surfacing a problem is mechanical rather than a career judgement; the worst programme failures are the ones everyone privately predicted and nobody formally raised. On method: I hold Google certifications in both classical project management and agile process management, and the honest position is that the argument between the camps is mostly theatre. Gates govern commitments; agile governs how work flows between commitments. Any competent programme uses both, sized to the work rather than to a tribe.

Standing it up, and handing it over

A PMO built around an external consultant is a leased capability with a cliff at the end of it — so the handover is designed first. The office runs on your systems, not mine. An internal owner is identified early and trained in the chair, not beside it: by the middle cycles they are running the portfolio review with me as counsel rather than chair. The playbooks are written as we operate — gate standards, review agendas, escalation rules, benefit method — so documentation is a by-product of running the office, not a leaving gift assembled in the final week. And my exit has a date. The test of the build is the one I apply to every engagement: the office your team runs a year later, without me, at the same standard.

05What it looks like

What an engagement looks like

  • A defined build: sizing, governance design, first cycles run together
  • Honest sizing — including the recommendation not to build one
  • Runs on your existing tools; no platform mandate, no template factory
  • Transferred to an internal owner with playbooks — exit by design

Outcomes

  • A portfolio review that gates, kills and re-sequences — visibly
  • Benefit claims tied to baselines a CFO will accept
  • Reporting load that shrinks while control improves
  • An office your own people run at standard after I leave

Questions

Common questions.

Four stages. A sizing exercise that decides whether an office is justified at all — argued in writing either way. Governance design: decision rights, stage gates, escalation thresholds and the portfolio view, with reporting derived last and kept minimal. Stand-up: the portfolio review and programme cadences running live, benefit baselines set, tooling configured on your existing systems, with me chairing the first cycles so the standard is demonstrated rather than described. And transfer: an internal owner trained in the chair, playbooks documented from live operation, and a scheduled end to my involvement. The typical build runs a few months from sizing to a functioning office; the transfer completes over the cycles that follow.

Possibly not, and I will tell you if so. The honest threshold is decision load: when initiatives are few and largely independent, a good operating cadence with named owners governs them better than an office would — cheaper, faster and with less resentment. A PMO earns its cost when the portfolio generates decisions that exceed what that cadence can carry: contention for the same people and money, dependencies between programmes, gates that need scrutiny independent of the teams being gated. The sizing exercise settles it with evidence rather than instinct, and the honest answer is often "not yet — here is the lighter thing to build instead". That answer costs you a conversation, not a consulting programme.

Scope and lifespan. A PMO is standing infrastructure: it governs the ongoing portfolio of projects and programmes as a permanent management capability. A transformation office is temporary by design: stood up to govern a defined change agenda — an integration, a restructuring, a major operating-model shift — and dissolved when the agenda completes. The governance mechanics are the same: gates, cadence, benefit baselines, escalation. What differs is the exit: a transformation office that lingers after its transformation is overhead wearing a lanyard, and the dissolution date belongs in the design. I build both, and part of the sizing exercise is deciding which one your situation actually describes — companies often ask for the permanent version when they need the temporary one.

Both, unapologetically, because the argument between them is mostly tribal. Gates exist to govern commitments — releasing funding, locking scope, authorising a go-live — and no amount of agility removes the need for those decisions to be made deliberately. Agile governs how work flows between commitments, and it is genuinely better than waterfall micro-planning for most knowledge work. I hold Google certifications in both project management fundamentals and agile process management, which is another way of saying I have no methodological tribe to defend. The design question is always the same: what does this work need? The answer is usually gates at the commitments, agile in the delivery, and far less ceremony than either camp sells.

The sizing exercise takes a couple of weeks and stands alone — you can take its recommendation and build internally if you prefer. A full build typically runs three to four months to a functioning office: governance designed in the first weeks, the portfolio review and programme cadences live by the middle, benefit baselines and playbooks accumulating throughout. The transfer to your internal owner completes over the following cycles, with my involvement tapering to a scheduled end rather than trailing off. What stretches timelines is rarely the mechanics — it is portfolio truth emerging: the first honest ranking of initiatives usually surfaces two or three that should not survive it, and deciding their fate is governance’s first real test.

No new platform is required, and I am deliberately agnostic. Portfolio governance runs adequately on tools most companies already own — a work-management system you actually use, a spreadsheet discipline for baselines, a one-page status standard — and the failure mode I am guarding against is the reverse: buying a portfolio platform and mistaking its dashboards for governance. Tooling questions get answered after the governance design, because the tool should implement the decision system, not substitute for it. Where you already run Jira, Asana, Monday, MS Project or a PPM suite, the office is built on it. The configuration cost of fitting your existing stack is almost always lower than the adoption cost of a new one.

By sequencing it the way an auditor would: baseline first, claim second, measurement third, attribution honest. The baseline — current cost, cycle time, defect rate — is measured and agreed before work starts, because a benefit without a baseline is a press release. Claims at the funding gate must reconcile to that baseline in terms a CFO recognises. After delivery, the delta is measured and attributed, separating what the programme caused from volume effects and background drift. Two disciplines keep it honest over time: benefits stay attached to named owners after project close, and the portfolio review revisits realised-versus-claimed quarterly — which quietly ends benefit inflation, because teams learn their cases will be checked against reality.

Someone senior enough that the portfolio review keeps its teeth. The common failure is delegating the office to a coordinator two levels below the decisions it must govern — the reporting survives, the authority does not, and within two quarters the review is theatre again. The right owner is typically a head of operations, a senior programme leader, or in smaller companies the COO directly; what matters is standing — they can hold gate discipline against a programme sponsor who outranks the paperwork. Part of the build is developing this person deliberately: they chair alongside me, then instead of me. And part of the sizing honesty is saying so early if nobody plausible exists, because an office without a credible owner should not be built yet.

Three filters separate builders from template vendors. First, ask what they have governed, not what they have installed: the best PMO consultant has run programmes with hard baselines and sceptical stakeholders, and can show the numbers that resulted — governance craft comes from being accountable to it. Second, ask when a PMO should not exist: anyone without a crisp answer sells offices for a living, and their sizing advice will always land on "yes". Third, ask what the office looks like a year after they leave: the answer should be an internal owner, playbooks, and a review that still kills weak projects — not a renewal proposal. Method certifications matter less than those three; treat them as table stakes, not differentiation.

Naturally — the disciplines share one spine. A PMO build often follows process transformation work, because a re-engineered operation tends to surface a portfolio of follow-on changes that needs governing. It pairs with operations governance and BI, since the portfolio view draws on the same single-source-of-truth discipline as the leadership scorecard. And inside a fractional COO engagement, portfolio governance is frequently one workstream among several rather than a separate contract. The sequencing advice is honest in both directions: if what you mainly need is the operating cadence and measurement, start there — a PMO layered onto an ungoverned operation just documents the chaos at higher resolution. The sizing exercise will say which order your situation calls for.