PREPARE2LEAD

Restarting a PMO: Why You Shouldn't Throw Out What Came Before

Most PMO leadership jobs aren't about building from scratch. They're about restarting something that was stood up, ran for a while, then stopped when the money did. Here's how to do that without losing the people you need on side.

Every so often a job ad comes in that's more honest than whoever wrote it realised. This week it was a PMO leadership role. Read past the polish and the story was plain. There used to be a PMO here. It ran for a while. The money stopped. Now things are slipping and they need it back.

That's a different job from the one the ad thinks it is. They think they're hiring someone to build a PMO. They're hiring someone to bring one back. Those aren't the same thing.

rebuilding a PMO governance function

Building a PMO from nothing is the easy version

Building from nothing is the easier of the two. A blank page has no history. You walk in, you look at what's needed, you design it, you build it. Nobody's upset. Restarting is harder, because the ground isn't empty.

When a PMO is stood up and then stopped, usually for money, it doesn't just vanish. It leaves things behind, and how you treat them decides whether your restart works or fails in the first month. It leaves governance that was designed, some of it good. It leaves reporting that was built and then dropped, so the templates are still there but nobody fills them in. It leaves standards that were half adopted. And it leaves people who lived through the first version and formed their own view on whether it helped them or got in their way.

That last one is what most people walking into a restart get wrong.

Why people build their own way of working

When there's nothing there, people build their own thing. A spreadsheet, a saved file, whatever suits them. They do it because it's easy, and because it only has to make sense to one person, them. A real process is harder, because it has to make sense to everyone at once. It never quite fits, so people push against it.

But the main thing that goes wrong is that nobody stays. A contractor writes the process, then leaves. The team put together for one job finishes it and goes back to their normal work. The process has no one left to look after it, so it gets forgotten. Projects don't last, so the process running them doesn't last either.

The wrong instinct: throwing it all out

The wrong instinct is to throw it all out. New person arrives, wants to make a mark, calls the old approach broken, and starts again from a clean sheet. It feels decisive. It looks good in the first steering meeting. And it quietly causes the restart to fail, for two reasons.

First, it's usually wrong on the facts. The old PMO didn't fail because it was badly designed. It failed because someone stopped paying for it. If you treat a money problem as a design problem, you throw away work that was fine.

Second, it tells everyone who built or used the old version that their effort was wasted. The programme manager who actually used the old reporting now watches you bin it on day three. You've just taught the most useful person in the building that engaging with the PMO is a waste of time. You won't get that person back.

How to restart a PMO the right way

So here's how I'd actually do it, and there's nothing clever about it, on purpose.

First, look at what's there before you touch it. The opening weeks aren't for building. They're for understanding. What did the last function produce? What got used and what got ignored? And what are the projects using right now, in the gap the old PMO left? People don't stop needing governance just because the central team went.

Second, meet the people before you meet the framework. Ask one question in a dozen ways: what would actually help you here, and what did the last version get wrong? What have you done in the past? What are you doing now? What do you think will work in the future?

Third, set the target and build on what survived. Set the operating model, the reporting lines, the standards, and a clear answer to who's accountable for what. But build it by adapting what already worked, not by replacing it. Keep the reporting the teams actually used. Bin only what genuinely failed. Then walk people through it and embed it, rather than publish it and hope.

What it cost me to learn this

I learned this the hard way at the Police Information Technology Organisation, PITO. It had one of the best PMOs I've ever worked in. When PITO became the National Policing Improvement Agency, much of that good work disappeared. I interviewed to write the new process for NPIA, and I said I'd go back and look at what PITO already did and bring that in. I think that cost me the job. Maybe I pitched it wrong. But people want to feel they've added value, and to them, reusing what was there didn't sound like value.

If there's one line to take from this, it's adapt, don't replace. Replacing is ego. Adapting is judgement. It's harder, because it means giving credit to work you didn't do. But it's the only version that survives contact with the people who were there before you.

To build something that works and lasts, make it easy, simple and clear. That's what people actually need. Not something new for the sake of being new. Something that works, and that they'll follow.

Test what you actually know

The certificate gets you considered. What we teach gets you chosen. Take a free PRINCE2 mock exam under exam timing and see exactly where you would get caught out. There are four to work through, two Foundation and two Practitioner.

Take a free PRINCE2 mock exam