Both the PMO and the EPMO exist to manage project work systematically. The confusion comes from the fact that many organizations have one without the other, or have one that is trying to do the other's job.
The simplest way to separate them: a PMO governs how individual projects are run. An EPMO governs which projects should exist and how they connect to organizational strategy. One focuses on delivery quality. The other focuses on portfolio composition.
What a PMO does
A Project Management Office establishes the standards, methodologies, and tools that govern how projects are executed across a function or department. Day to day, a PMO:
- Sets project management frameworks and templates
- Monitors delivery of individual projects and reports on schedule, budget, and scope health
- Supports project managers with training, tools, and process guidance
- Maintains the project registry for its area of ownership
- Escalates risks and issues that cross project boundaries
The PMO's primary question is: are our projects being run well? It measures delivery quality, not strategic alignment.
What an EPMO does
An Enterprise Project Management Office sits above individual PMOs and governs the portfolio at the organizational level. The EPMO:
- Translates organizational strategy into a prioritized portfolio of initiatives
- Manages demand across the entire enterprise, not just a single department
- Makes resource allocation decisions across functions when demand exceeds capacity
- Governs portfolio composition: what gets approved, funded, and started
- Provides executive leadership with a consolidated view of all strategic investments
The EPMO's primary question is: are we working on the right things? It measures strategic alignment and resource efficiency, not delivery methodology.
The organizational layer difference
A PMO typically sits within IT or within a single business function. Its scope is the work within that function, and it reports to the function's leadership, usually an IT director or a VP of operations.
An EPMO sits above that. Its scope is the whole organization, and it typically reports to a C-suite executive, the CIO, COO, or CEO. This positioning is not incidental. An EPMO needs the organizational authority to make cross-functional resource decisions. A PMO that reports to an IT director cannot tell the marketing team to pause a project because IT capacity is fully committed. An EPMO reporting to the COO can.
Side-by-side comparison
| PMO | EPMO | |
|---|---|---|
| Reports to | IT Director / VP | COO / CEO / CIO |
| Scope | Single function or department | Enterprise-wide |
| Primary focus | Project delivery quality | Portfolio strategy and resource alignment |
| Approval authority | Process governance | Portfolio investment decisions |
| Manages intake for | IT or departmental projects | All strategic initiatives across functions |
When organizations typically create an EPMO
Three situations consistently trigger the move to an EPMO:
Multiple siloed PMOs that are not coordinating. When IT has its own PMO, marketing has one, and the digital transformation office has one, each is making resource decisions in isolation. Projects from different functions compete for shared resources, and nobody has a view of total enterprise demand. The EPMO is created to provide that view and to mediate cross-functional conflicts.
Executive leadership can't answer basic portfolio questions. When the CIO is asked "what is the total IT investment in strategic initiatives this year" or "how much of our development capacity is committed," and can't answer clearly, the organization is missing an EPMO function. The inability to answer those questions is the symptom. Lack of consolidated portfolio governance is the cause.
Project approvals happen without visibility into enterprise capacity. When business units can commit IT resources to projects without a centralized approval process, the portfolio expands without constraint. Projects get approved that the IT team doesn't have the capacity to deliver. An EPMO adds the capacity gate that prevents this.
The common confusion points
Many organizations rename their PMO to an EPMO without changing what it actually does. The name change accomplishes nothing. An EPMO has portfolio governance authority and enterprise-level resource visibility. If the office lacks either, it's still a PMO regardless of what's on the org chart.
The reverse also happens: organizations build an EPMO before the PMO function is mature. An EPMO built on top of inconsistent project delivery is ineffective because portfolio-level visibility requires reliable project-level data. If projects in the portfolio aren't reporting status accurately, the EPMO's consolidated view is noise, not signal. The PMO function needs to work before the EPMO layer adds value.
Do you need both?
For organizations under roughly 500 people with a single IT function and a manageable portfolio, one PMO is usually sufficient. The PMO can handle both delivery governance and portfolio management at that scale.
As scale increases and multiple functions are running parallel portfolios, the EPMO layer adds visibility that no individual PMO can provide. A large healthcare organization running clinical systems projects, infrastructure projects, and regulatory compliance initiatives simultaneously across multiple departments needs a layer above the individual PMOs to arbitrate resource conflicts and ensure the portfolio reflects what the organization has decided to prioritize.
The trigger for building an EPMO is usually a specific, painful moment: two departments competing for the same data engineers, an executive who can't explain to the board what IT is actually working on, or a failed initiative that nobody had the capacity to deliver and nobody escalated in time.
The EPMO's relationship to resource capacity planning
One of the EPMO's most practical functions is maintaining a current picture of enterprise resource capacity and comparing it against portfolio demand. This is the input the portfolio governance body needs to make approval decisions that the organization can actually fulfill.
For more on how that capacity picture gets built, see our guide on capacity vs demand gap analysis in IT portfolio management. For the intake process the EPMO governs, the IT work intake process article covers how requests move from submission to approval decision.
Frequently Asked Questions
What is the difference between an EPMO and a PMO?
A PMO governs how individual projects are executed: standards, methodologies, tools, and delivery quality. An EPMO governs what the portfolio contains: which initiatives get approved, how resources are allocated across the enterprise, and whether the portfolio reflects strategic priorities. The PMO focuses on delivery; the EPMO focuses on selection and alignment.
When should an organization create an EPMO?
Three situations consistently trigger the move to an EPMO: the organization has multiple PMOs in different departments that are not coordinating, executive leadership cannot answer basic questions about total IT spend or resource availability, or project approvals are happening across functions without visibility into total enterprise capacity.
Can an EPMO replace a PMO?
No. An EPMO built on top of inconsistent project delivery is ineffective because portfolio-level visibility requires reliable project-level data. The PMO function must exist and work reasonably well before an EPMO layer adds value. They serve different purposes at different organizational levels.
Who does an EPMO typically report to?
EPMOs typically report to a C-suite executive such as the CIO, COO, or CEO. This positioning gives the EPMO the authority to make cross-functional resource and portfolio decisions. A PMO reporting to an IT director cannot perform EPMO functions effectively because it lacks the organizational authority to govern work across multiple departments.