How does your PMO work? As a Project Management Office leader, or someone setting up a PMO, you need to know where the PMO sits in the company, how it’s organized, and what services it offers. This is your operating model.
An operating model is different from your staffing model (you could have full-time, part-time or a fractional PMO team). And it’s different from maturity level, which is more about how good your capabilities are. A centralized PMO can be immature; a federated PMO can be highly capable.
So what we’re talking about here is how you are setting up your PMO. Your operating model answers this question: “How is the PMO structured and what does it do?” And by the end of this article, you’ll know what your main options are and how to decide which is for you.
Centralized PMO
Definition: A single PMO function serving the whole organization or portfolio.
Strengths and weaknesses
The good thing about having a centralized PMO is that you can get consistency, and a single source of truth for the whole portfolio. As the people who lead on all this stuff, you can mandate what you want, standardize what you want and support the whole organization.
It’s also a lot easier to build deep capability, because you control it all and can support project managers to reach your standards with coaching, templates, training and mentoring.
However, being central often means being attached to the Strategy or IT Director, and you can feel remote from delivery teams. If everything is running through the PMO, there is a risk of becoming a bottleneck.
Best fit: Organizations with a genuinely unified portfolio and the scale to justify a central team.
Decentralized PMO
Definition: PMO capability embedded within business units or programs rather than sitting centrally.
When organizations start out building a PMO, this is where they often start.
Strengths and weaknesses
Decentralized can be good because the people offering governance and assurance are closer to the delivery teams. Your PMO can be more responsive to local context, and tailor your approaches to the kinds of projects you run. A decentralized PMO supporting a construction or property team is going to need different kinds of templates and processes to one supporting the IT portfolio.
Having said that, this model obviously means that there are multiple PMOs in the business. So where do cross-functional projects sit? Do they get reported in more than one PMO? Across the whole organization you could end up with inconsistent standards, duplicated effort. Does each team create their own PMO toolkit? And it’s much harder to get an organization-wide view.
Best fit: Large, diverse organizations where business units really do operate differently.
Federated PMO
Definition: A hybrid of the two models above: central PMO sets standards and provides shared services, local PMOs handle delivery-level support.
If you realized that the decentralized PMO would need a central person or function pulling together all the individual reports because the C-suite want to see a consolidated view, this is the model that addresses that limitation!
Strengths and weaknesses
This model balances consistency with local responsiveness. It’s often the most realistic model for organizations that have tried and struggled with pure centralized or decentralized models. And as it’s a hybrid PMO model, you can pretty much adapt it to work however you want!
However, you need very clear agreement on who owns what, or you won’t address any of the weaknesses of the other models.
Supportive, controlling or directive: how much authority does your PMO have?
There’s a second axis to think about alongside where your PMO sits in the org chart, and it might matter more than the structural model you choose. This is about how much authority and sphere of influence your PMO actually has over individual projects.
The PMBOK angle
Supportive, controlling and directive PMOs have long been part of PMI’s body of knowledge, but the latest edition of the PMBOK® Guide actually doesn’t mention the controlling model at all. A lot of articles will talk about the “three types of PMO” because they rely on outdated information.
There is a lot more detail in the Project Management Offices: A Practice Guide (PMI, 2025) publication that is available free to PMI members. This covers loads more types of PMO, highlighting that really there isn’t a standard operating model. Some of the types that get called out there that I haven’t covered in this article include:
- Agile PMO: Fosters agile practices and values, supports with agile ways of working
- Project Support Office: Provides admin support and coordination, tracking and reporting
- Transformation Management Office: Provides support and can include change management for the larger, transformation initiatives or digital transformation projects
- Innovation PMO: Works with R&D functions, drives experimentation and new product development projects
Anyway, don’t get sucked into the idea that there are only 3 types of PMO – even PMI doesn’t subscribe to that any longer. But since you still want to know about them, here they are! The classifications are still useful for internal conversations with stakeholders as you describe how your PMO is going to work.
Supportive PMO
Definition: The PMO provides templates, best practice, training and access to lessons learned from other projects, but has no real authority to enforce any of it. Project managers can take what they need but they aren’t mandated to follow things to the letter. A consultative PMO is a supportive PMO that takes a more proactive advisory role.
Strengths and weaknesses
This is the lowest-friction option, and it’s usually where new PMOs start, because you haven’t earned the right to mandate anything yet. It’s also the easiest model to introduce into an organization that’s nervous about central control.
The downside is obvious: if nobody’s obliged to use what you’ve built, adoption depends entirely on how useful it is! And ‘useful’ means different things to different people. If your team is resistant to leaning on the PMO, you’ll have a lot of work to do to prove that you’re delivering anything of value.
Best fit: Early-stage PMOs, or organizations with a strong culture of project manager autonomy where you need to earn trust before you can ask for compliance.
Controlling PMO
Definition: The PMO requires some degree of compliance – adopting specific processes, frameworks, templates, tools or governance checkpoints – but project managers still run their own projects day to day.
Strengths and weaknesses
This is where most established PMOs end up because it’s the model that fits best into existing organizational structures. You get consistency without taking over delivery, and you’ve got some teeth: projects that don’t comply can be escalated or blocked from progressing through a gate review.
The risk is that ‘controlling’ starts to feel like exactly what it sounds like if you don’t explain why the compliance requirements exist. Is it bureaucracy or is it useful? Governance fatigue is real!
Best fit: Mature organizations that need consistency across a large portfolio, where PMO credibility is already established. Organizations with project managers at different competency levels, where you want to make sure everyone is operating to the same standard.
Directive PMO
Definition: The PMO actually manages the projects, with authority over project resources and decision rights over the projects.
Strengths and weaknesses
This is the highest-control model, and it’s relatively rare outside a few specific contexts. High-risk, heavily regulated environments (think government major programmes or regulated industries), or organizations that have been burned badly enough by inconsistent delivery that leadership wants direct control. It gives you the fastest ability to intervene when something’s going wrong, but it’s also the model most likely to trigger the loss-of-autonomy resistance I write about elsewhere – project managers reporting to the PMO rather than the business can feel like their professional judgement doesn’t count for much.
Best fit: High-risk or heavily regulated environments, or as a temporary measure to stabilize a portfolio that’s badly off track. Also works where there is already good project management maturity and the requirement for centralized control.
How authority combines with your structural model
You could run a decentralized, supportive PMO – light-touch, embedded, offering help rather than demanding compliance. Or you could run a centralized, directive PMO – one function, with the power to hold people to account, actually managing delivery.
In practice, you’ll probably land somewhere in the middle. Pick the type of operating model you want and then the authority and sphere of influence is largely dictated by how the organization sees you and how much scope you’ve been given to make changes and mandate a governance cadence and processes.
So when you’re choosing your operating model, you’re really answering two questions, not one: where does the PMO sit, and how much authority does it have?
Enterprise PMO vs programme PMO
Yes, there are even more PMO options you might want to consider. Let’s look at a couple of other models that are common enough to warrant a special mention!
EPMO
An Enterprise PMO (sometimes EPMO) is a portfolio-level, strategic function. It spans the whole organization, and often reports to the C-suite. How is this different to a centralized PMO you ask? It’s not really structurally any different, although it’s more focused on strategic planning and execution. For example, it might look broadly at the enterprise risk profile presented by programmes, or strategic fit for initiatives, and making strategic investment decisions. It would make sure execs have portfolio visibility for escalations. A centralized PMO might focus on delivery support (as well as dabbling in the other stuff). You wouldn’t set up an EPMO from Day 1 – it’s something your organization will evolve into over time as it finds it needs a more strategic, birds-eye view of all the in-flight work.
Examples of an EPMO
NASA’s PMO evolved from a single engineering advisor role in 1976 into an enterprise-wide function covering policy, standards, workforce development and mission architecture. The PMO’s knowledge-management and learning functions were built directly in response to the Challenger and Columbia disasters, including appointing a Chief Knowledge Officer after Columbia.
The U.S. Energy Information Administration is a federal statistical agency that stood up an enterprise PMO in 2016, built its own three-level maturity model (Initiating, Developing, Optimizing) rather than buying one off the shelf, and documented real before/after shifts: from what they called an “age of heroes” ad hoc culture to standardized governance, with measurable improvement across successive maturity assessments.
IBM’s Project Management Center of Excellence, set up in 1997, is a corporate example. It was created specifically to drive consistency in project management practice worldwide and formalize the project manager role across the business.
Programme PMO
A Programme PMO is set up and scoped to support a single large program. Initiatives like the London 2012 Olympic Games had PMO support like this. It’s temporary by nature, so it disbands or is repurposed when the program ends.
You could also set up a Project PMO for smaller initiatives, but in my experience that dedicated support is normally provided by a PMO analyst working alongside the project manager, not as a specific project office.
Example of a program PMO
Crossrail is a well-documented program — its Learning Legacy site explains that the IT PMO was a three-person team at its peak, supporting around 2,000 users across 40+ London sites, running governance, funding, procurement and RAG reporting through a formal change advisory board. When did they get time for a coffee? It’s function was to maintain a comprehensive view of all projects and program and enable informed decision-making.
How to choose the right model for your organization
Ultimately, there is no right or wrong model. The PMI Practice Guide for PMOs lists 23 different flavours of PMO, so I think that shows that this is rarely one-size-fits-all.
Pick one and try it, it’s easy enough to morph it into something else later if the business needs you to move in a different direction.
Here are some questions to help you think through what your operating model should be right now:
- How many business units or portfolios need PMO support? (Or rather, how many units are open to the idea of working alongside a PMO and won’t make it hard for you? Just because they need support doesn’t mean they will accept it!)
- How consistent are current standards across the organization?
- Is there appetite (and budget) for a central team, or does capability need to be embedded locally?
And again, don’t worry too much about what you are implementing right now ending up the only option for the long term. It’s surprisingly easy to shift into providing different support, and a lot easier to do that when people come to you asking for help rather than trying to force it on them.
