The PMO that survived the budget review: ninety days, three changes

A composite case from the PMOs I've watched live through the CFO's thirty minutes, and the only defense a budget review respects.

The calendar invite says "PMO review, 30 minutes." It comes from the CFO's office. No agenda attached, because nobody needs one. Everyone in the PMO already knows the question that's coming. Somewhere in that half hour, the CFO will lean back and ask: "Walk me through what the PMO actually does."

I've watched several PMOs take that meeting over the years. Some of them don't exist anymore. What follows is a composite of the ones that do, stitched together honestly, because the survivors all did some version of the same three things. And they did them in the ninety days before the invite arrived, not the night before the meeting.

First, though, you have to hear the question properly. It sounds like curiosity. It isn't.

The question under the question

"What does the PMO actually do here" is not a request for your charter. The charter says governance, standards, methodology, delivery enablement. The CFO can read. If the charter answered the question, the meeting wouldn't exist.

Translated, the question is: what would break if we deleted you?

That's the entire review, compressed. A CFO staring at a cost line isn't buying governance. They're buying two things, and only two: decisions that happen faster than they otherwise would, and surprises that get smaller than they otherwise would. Every PMO deliverable is a means to one of those ends, or it's decoration.

The instinct under that pressure is to answer with volume. More slides, more dashboards, a longer list of everything the PMO touches. That instinct is fatal. In a deletion conversation, a list of activities isn't a defense. It's an itemized menu of things to cut.

This is the gap between the charter version of a PMO and the funded version. The charter says "we run stage gates." The funded version says "doomed projects die at month two instead of month eight." Same activity, different sentence. Only one of them survives a budget review.

So here's the composite case. Ninety days, three changes, in the order the survivors made them.

Change one: report decisions, not activity

The first casualty was the monthly steering pack. Forty slides. RAG statuses, milestone walls, risk heat maps, a glossary nobody had ever opened. It took the better part of a week to assemble, and directors skimmed it on their phones while waiting for the meeting to end.

The pack didn't die because it was long. It died because nobody could name a single decision it had caused.

In its place went a one-page decision memo. Four lines per item. What needs deciding. Who decides it. By when. What it costs to wait.

That last line did the heavy lifting. Cost of waiting turns silence into a price. A stalled integration choice stops being a yellow square on slide nineteen and becomes two teams idle while we don't pick a path. Executives can ignore a status forever. A price tag on their own indecision is harder to sit with.

The memo had house rules, too. If nothing needed deciding that week, it said so in one line and the meeting shrank. Once a decision got an owner and a date, it left the page. Nothing was allowed to live there as decoration.

Within two cycles, attendance flipped. Steering went from a meeting people apologized their way out of to a meeting people asked to join, because it had quietly become the room where things get decided. That's the tell. Activity reporting is what a PMO does when it doesn't know what it changed. Decision reporting is what it does when it does.

Change two: own two numbers you can defend

The second change hurt more, because it meant giving up flattering numbers.

Like a lot of PMOs, this one had been reporting outcomes it merely observed. Projects delivered, benefits realized, adoption climbing. Except everyone in the room knew the PMO didn't build the product or write the code. Claiming delivery outcomes in front of the people who delivered them doesn't read as value. It reads as narration. Nobody funds a narrator.

So the PMO repriced itself around two numbers it could truthfully own:

• Forecast reliability. Of the things we said would land this quarter, how many landed? Not velocity, not utilization. Did our word hold?

• Dependency clearance time. When one team blocks another, how long does the blocker live before it dies?

Look at what those two numbers actually are. They're the operational version of decisions faster, surprises smaller. Forecast reliability is the surprise number: when the PMO's word holds, the CFO stops getting ambushed in month eleven. Dependency clearance is the speed number: cross-team blockers are exactly the problem no single team owns, which makes them exactly the problem a PMO can own.

Neither number flatters quickly. The first quarter of honest forecast reporting usually looks worse than the fiction it replaced. The survivors published it anyway. Credibility compounds, and fiction gets audited eventually.

And notice the count. Two numbers isn't a dashboard. That's deliberate. A function that owns twelve metrics owns none of them. Two numbers you can defend under hostile questioning beat twelve you'd have to explain.

Change three: put your own line item on the table

The third change is the one most PMOs never make. This one made its own cost legible before anyone demanded it.

Most functions hide their cost and gesture vaguely at their value. This PMO did the reverse. It put its own fully loaded cost on one line. Next to it, a named list of what it had killed that year: a duplicate tooling contract two departments had been paying for separately, two zombie projects that had outlived their sponsors but not their burn rate, and a weekly reporting ritual that ate hours across a dozen teams and that, when quietly paused, nobody missed or even mentioned.

No creative math. No productivity uplift multiplied by an assumed hourly rate. Just: here's what we cost, here's what we stopped, the second list is bigger, and you're welcome to check.

Zombie projects deserve their own sentence, because every portfolio carries them. A zombie project has no remaining believer, just a budget line and momentum. Nobody inside it kills it, because killing your own project feels like failure. It takes a function whose loyalty is to the portfolio, not the project, to hold the pillow. That's real, attributable money. A PMO that can't point to anything it stopped is admitting the portfolio has no immune system.

Cost that's visible next to value that's vague is how functions die. This PMO made both sides visible and let the CFO do the subtraction.

The meeting, when it finally came

The review still happened. It just went differently.

"Walk me through what the PMO actually does" got an answer that took under five minutes. We make decisions happen on a date, and here's the one-page memo that does it. We're accountable for whether our forecasts hold and for how fast cross-team blockers die, and here are both numbers, with the trend. We cost this. We killed that. Subtract.

Then the CFO asked a follow-up about one of the open decisions in that week's memo, which is its own kind of verdict. You don't ask operational questions of a function you're about to delete.

Here's the through-line, and it's the only defense a budget review respects: a PMO survives when deleting it would visibly make decisions slower and surprises bigger. Not when it's busy. Not when it's liked. Busy is invisible, and liked is cheap. Slower decisions and bigger surprises are the two outcomes a CFO personally suffers, which is why they're the only two a CFO will reliably pay to avoid.

The interview question hiding inside this story

If you work in or near a PMO, this isn't just survival advice. It's interview prep.

"How would you prove your function's value?" is a real question in senior interviews. PMO lead, delivery manager, head of delivery, transformation roles. Most candidates answer with the charter: governance, visibility, alignment. What the interviewer hears is someone who has never been on the wrong end of a budget review.

The answer that lands is this case, compressed into a shape you can carry:

• Start with the deletion test. Value means that removing my function would make decisions slower and surprises bigger. Then say how you'd make that true within a quarter.

• Name the two numbers you'd own truthfully. One for the reliability of your word, one for the speed of unblocking. Refuse, out loud, to claim outcomes you'd only be observing.

• Make the cost side legible. What your function costs, next to what it killed. Named savings, not multiplied assumptions.

The same shape flexes to a Scrum Master interview, an agile coaching role, any job whose value sits one step away from shipped product. The weak answer lists activities. The strong answer names what would break.

Ninety days is enough. Not to transform anything. Just enough to stop reporting activity, own two honest numbers, and put your own line item on the table before someone else puts it there for you. The PMOs I've watched survive didn't win the meeting in the meeting. They won it in the ninety days before the invite showed up.