Ask ten people what a PMO does and you will get ten answers, most of them about templates and status reports. That is the small version. The bigger idea behind project, program and portfolio management is a single uncomfortable question: of all the things your organisation could spend its scarce people and money on, are you working on the right ones, and are you brave enough to stop the ones that no longer matter?

The quick version

  • Project management delivers one temporary effort, a defined product, service or result with a start and an end. The question is "are we doing this right?"
  • Program management coordinates a group of related projects so they deliver a benefit none could deliver alone. The question is "are these projects pulling together?"
  • Portfolio management chooses and balances all the work against strategy and limited resources. The question is "are we doing the right projects at all?"
  • A PMO (project / program / portfolio management office) is the team that supports this, but its value is judged on the decisions it improves, not the reports it produces. Many are shut down because they never proved that link.

The idea in depth: three nested questions, not three job titles

The cleanest way to hold the distinction is the line the Project Management Institute (PMI) has long used: program and project management are about doing the work right; portfolio management is about doing the right work. The PMI's published definitions are deliberately plain. A project is "a temporary endeavor undertaken to create a unique product, service, or result." A program is "a group of related projects managed in a coordinated manner to obtain benefits not available from managing them individually." And portfolio management, in PMI's framing, is the practice that "bridges the gap between strategy and implementation", weighing every initiative against business goals and return (definitions via PMI, restated in Planview's PPM guide).

The useful habit is to stop treating "PMO" as one undifferentiated thing and instead ask which of the three questions a given problem belongs to. A late release is usually a project problem, scope, plan, resourcing. Three teams building overlapping things that don't add up to a launch is a program problem, coordination and shared benefit. Twelve initiatives competing for the same six engineers is a portfolio problem, choice. Treating a portfolio problem as a project problem is how organisations end up with twelve beautifully run projects and no strategy.

flowchart TD
  S(["Strategy
where we're going"]) --> P(["Portfolio
choose & balance the right work"])
  P --> Pr1(["Program
coordinate related projects"])
  P --> Pr2(["Program
for a separate benefit"])
  Pr1 --> J1(["Project: deliver one result"])
  Pr1 --> J2(["Project: deliver one result"])
  Pr2 --> J3(["Project: deliver one result"])
The nesting: strategy sets direction, the portfolio chooses the work, programs coordinate it, projects deliver it. Leaders Loop

An honest limitation. This tidy hierarchy is a model, not a law of nature. Plenty of healthy organisations run portfolios with no formal programs in between, and some "programs" are really just large projects wearing a grander title. The labels matter far less than the questions behind them. Use the three levels to locate where a decision actually lives, not to build three layers of governance an organisation your size does not need.

What a PMO is actually for, and why so many fail

A PMO is the standing function that supports this work: it sets methods and templates, reports on progress, allocates scarce resources, and, at its most valuable, informs which projects start, continue or stop. PMOs span a spectrum from a lightweight supportive office (templates and coaching) through a controlling one (compliance and standards) to a directive one that runs the projects itself.

Here is the part the brochures skip. PMOs have a poor survival record. Widely cited industry figures put the share of PMOs shut down or judged to have failed within roughly three years at well over half, a Gartner figure of around 50% closing within three years is quoted repeatedly, and consultancies cite higher numbers still (see PM-Partners' summary of PMO failure). Treat the exact percentage with caution, these are practitioner and vendor figures, not peer-reviewed studies. But the direction is consistent and the cause is well understood: PMOs are dismantled when leaders cannot see the value they add. PMI's own research lands in the same place, the office that becomes a reporting bureaucracy, disconnected from the decisions executives actually make, gets cut in the first downturn (PMI, "Why PMOs do not deliver to their potential").

What follows from that is simple enough: design the PMO around decisions, not documents. Before standing one up, or defending the one you have, answer one question: which executive decision is worse without us, and how would we prove we made it better? If the honest answer is "we produce a deck no one acts on," you have found the reason the role gets eliminated. A PMO earns its place by killing the wrong projects faster and starting the right ones with clearer eyes, not by perfecting the format of the status report.

A PMO is judged on the decisions it improves, not the reports it produces.

The evidence: doing projects right isn't enough

The strongest case for taking the portfolio level seriously comes from the data on how projects actually turn out, and it is bleak even before you get to whether they were the right projects. Oxford's Bent Flyvbjerg has assembled the largest database of its kind, more than 16,000 projects across sectors and countries. His finding, set out in How Big Things Get Done (Flyvbjerg & Gardner, 2023): only about 8.5% of projects come in on budget and on time, and barely 0.5% hit budget, time and the benefits they promised. He calls the pattern the "iron law of megaprojects", over budget, over time, under benefits, over and over (figures via Thought Economics' interview with Flyvbjerg).

The long-running Standish Group CHAOS research tells a similar story for IT projects, in its 2020 data, roughly 31% counted as successful, around half were "challenged" (late, over budget or short on features), and about 19% failed outright. Be careful with these numbers: Standish's methodology has been criticised by academics for years, and its definitions of "success" are narrow. They are a directional signal, not gospel. But two independent bodies of work pointing the same way is enough to make the point: execution discipline alone does not save you. A project delivered perfectly on time and budget is still a loss if it was the wrong project, and Flyvbjerg's own remedy is heavily about the front end (planning slowly, drawing on reference data from similar past projects) rather than driving harder during delivery.

Which is why the portfolio level pays off most when you spend judgement before you commit, not after. Ask of every proposed initiative: what did comparable past projects actually cost and deliver (not what the optimistic business case claims)? Which of our live projects are quietly "challenged" and should be stopped now rather than nursed to a sunk-cost finish? Portfolio management's highest-value act is rarely starting something, it is stopping something.

A worked example

Take a mid-sized insurer, call it Meridian. (Illustrative figures throughout; a teaching example, not a real company.) Its change budget funds 14 active projects across three departments. Each has a project manager, each reports green or amber, and the quarterly steering meeting mostly reviews status. On paper, delivery is healthy. Strategically, no one can say whether the 14 are the right 14.

A new portfolio lead reframes the meeting. Instead of "is each project on track?", she asks "does each still earn its slice of our six most senior engineers?" Three turn out to be pet initiatives with no clear benefit owner. Two more overlap, both building a customer-notification capability, and belong together as a single program with one shared outcome. One amber project, checked against what similar integrations have historically cost, is revealed as wildly under-budgeted and likely to fail; it is paused before another illustrative £400k is poured in.

flowchart LR
  A(["14 active projects
all reporting green/amber"]) --> B{"Does each still earn
its scarce engineers?"}
  B -->|"No benefit owner"| C(["Stop: 3 pet projects"])
  B -->|"Two build the same thing"| D(["Merge into 1 program
shared outcome"])
  B -->|"Under-budgeted vs. history"| E(["Pause before sunk cost"])
  B -->|"Clear benefit, on track"| F(["Fund & protect"])
Portfolio management at work: the value is in what gets stopped, merged and protected, not in the status colour. Leaders Loop

Nothing here required a new methodology or a bigger PMO. It required asking the portfolio question, are these the right things?, instead of only the project question. Meridian's delivery teams didn't get better at running projects that quarter. The organisation got better at choosing them, which mattered more.

Frequently asked questions

What's the simplest way to remember project vs program vs portfolio?

One project delivers one result. A program coordinates several related projects toward a benefit none could reach alone. A portfolio is all the work, chosen and balanced against strategy and limited resources. Projects and programs are about doing the work right; the portfolio is about doing the right work.

Do we need a PMO?

Not automatically. A PMO earns its keep only if it improves real decisions, which projects start, stop, or get the scarce people. If yours mainly produces reports no one acts on, that is the warning sign behind the high rate at which PMOs get disbanded. Start with the decision you want to improve, then build the lightest structure that improves it.

Isn't this just project management with extra layers?

No, and conflating them is the common error. You can run every project flawlessly and still fail strategically because you chose the wrong projects. The portfolio level exists precisely to catch what project discipline cannot: that the work itself, however well delivered, was not worth doing.

Why do so many big projects overrun if we already know how to manage them?

Because the hardest errors are made at the front end, before delivery starts, optimistic estimates, missing reference data from comparable past projects, and political pressure to approve. Flyvbjerg's research finds the projects that succeed plan slowly and act fast, rather than the reverse. More project-management rigour during delivery rarely rescues a flawed commitment made at the start.

What metrics should a portfolio actually track?

Less "percentage of projects green" and more strategic signals: benefit realised versus benefit promised, the share of capacity tied up in initiatives with no clear owner, and how quickly the organisation stops work that is no longer worth doing. The aim is to surface choices, not to colour-code activity.

Related in the Toolkit

How you run the projects inside the portfolio is its own discipline, the delivery methodology you pick shapes how work actually gets done, and the portfolio's choices only mean something if they connect to strategy execution further up the chain.

Where to go next