When an organization decides to build a PMO, the first question is almost always the same:
"What does a world-class PMO look like?"
That is the wrong place to start.
Not because it is a foolish question, but because it points somewhere else. It points at another company, with a different strategy, a different culture, a different level of maturity, and priorities that are not yours. The answer gets imported whole — the structure, the templates, the reporting cadence, the job titles — and planted in ground it was never designed for.
A year or two later, someone concludes the PMO "didn't work."
Why the model does not travel
Copying feels rational. If it worked there, why not here? But what usually gets copied is the visible output, not the conditions that produced it.
It answers a question you never asked
Every effective PMO was built to solve something specific: poor visibility across a portfolio, competing priorities, decisions that took too long. Copy the shape without the problem and you get a treatment for a condition you do not have — while the condition you do have goes untreated.
Maturity cannot be imported
An advanced PMO works in a mature organization because everything around it is ready: trustworthy data, understood governance, teams already used to the discipline. Drop the same model into an organization that has not got there yet and you get form without substance — reports that are filled in but never read, processes followed but not understood.
Culture beats structure
An org chart is drawn in a day. Culture takes years. When an imported PMO demands behavior that does not match how the organization actually works, the culture does not change — the PMO gets routed around. Work continues through the old channels, and the office becomes another layer of paperwork.
The right question
Instead of "what does the ideal PMO look like," start here:
That question inverts the design sequence. You no longer start with a structure and hunt for a purpose to justify it. You start with the need and build the structure that serves it.
The difference shows up in the outcome. A PMO created for governance ends up policing projects. A PMO created to serve strategy ends up enabling decisions.
Four things that shape your PMO
Before drawing any structure, read your organization through four lenses. Their answers dictate the design — not the other way round.
What is the organization trying to achieve over the next three years? Growth needs a PMO that accelerates launches. Efficiency needs one that exposes waste. Transformation needs one that manages the dependencies between initiatives. The goal defines the function.
Where does the organization actually stand today — not where it wants to be? If projects run on scattered spreadsheets and unreliable numbers, the first move is not a strategic PMO. It is a foundation of information you can build on.
How do decisions get made here? On data or on relationships? Centrally or locally? A PMO that ignores this answer collides with it later — and in that collision, culture wins every time.
What hurts most right now? Late delivery, budget overruns, no visibility on workload, initiatives working against each other? Start with the sharpest pain — the first visible win is what buys the PMO its legitimacy.
Notice that no off-the-shelf model answers any of these. Every answer is local.
How to tell whether it is creating value
The measure is not the number of reports, nor how complete the templates are, nor even the percentage of projects on schedule. The measure is the PMO's effect on decisions.
- Leadership checks the PMO's data before deciding
- Troubled projects surface early, not late
- Teams ask for support without being required to
- Weak initiatives get stopped, not continued out of habit
- Reports are submitted but never discussed
- Teams do the work outside the PMO, then document it inside
- The PMO is justified by compliance, not by results
- Nobody can name one decision it changed
If the second column looks familiar, the problem is not the quality of the imported model. The problem is that it was imported.
The bigger idea
A PMO is not an org chart. It is a decision about how the organization wants to think about its projects.
Copy it from outside and you inherit another company's way of thinking. Design it from inside and you get something that knows its context, speaks its language, and serves its goals.
Build one that reflects your strategy, empowers delivery, and creates lasting value.
If this article raised a question about your own organization, we would be glad to talk it through.
Talk to MIRAS →