Project Management Office (PMO): What It Does and How to Make It Useful
A PMO can be the function that makes an organization's projects predictable and its investment choices sound, or the function that collects status reports nobody reads. The difference is mostly in what it is asked to do.
By Capstera Business Architecture Staff · Updated
12 min read
A project management office (PMO) is a function that standardizes how an organization's projects are governed and delivered and supports the people who run them. Depending on its mandate, it may provide methods, templates, training and reporting; enforce standards and gate reviews; manage projects directly; or support portfolio decisions about which projects to fund.
Ask a project manager what the PMO does and the answer often depends on last week. If the PMO helped rescue a failing schedule, it is invaluable. If it asked for the same status report in a new template, it is overhead. Both experiences are real, because PMOs are set up for very different purposes and are often judged against a purpose nobody wrote down. The most useful PMOs know exactly which problems they exist to solve, and measure themselves against those problems rather than against the volume of reports they produce.
Key Takeaways
- A PMO standardizes and supports project delivery. What else it does depends on its mandate, which should be written down.
- PMI describes three types by degree of control: supportive, controlling and directive.
- Scope also varies: a project or program office, a departmental PMO, or an enterprise PMO that supports portfolio decisions.
- A PMO should be judged by delivery outcomes, such as predictability and decision speed, not by the volume of reporting.
- PMOs and architecture practices overlap at portfolio level. A shared capability map lets them prioritize and check projects with one view.
- Start small: fix the two or three problems that matter most, then grow the mandate.
What Is a Project Management Office?
The PMO exists to make projects across an organization more consistent, more visible and more likely to succeed.
Without a PMO, each project manager tends to invent their own way of planning, reporting and controlling change. That works for a few projects. With dozens, leaders cannot compare status reports, cannot see dependencies between projects, and cannot tell which projects are in trouble until the trouble is obvious. A PMO solves that by setting common methods and providing a view across projects.
The name covers a wide range of functions. Some PMOs are a handful of people maintaining templates and training. Others run every major project in the organization directly. Some sit in IT; others report to the chief operating officer or the strategy function and support the executive committee's investment decisions. Before setting one up or judging one, it helps to be precise about which kind is meant.
| Function | What it involves | Problem it solves |
|---|---|---|
| Methods and standards | Delivery method, templates, definitions of stages and gates | Every project reinvents planning and reporting |
| Training and coaching | Building project management skills; supporting less experienced project managers | Uneven delivery capability |
| Reporting and visibility | Consistent status, risk and financial reporting across projects | Leaders cannot compare projects or see trouble early |
| Governance and assurance | Stage-gate reviews, health checks, audits of struggling projects | Projects continue long after they should have been fixed or stopped |
| Resource management | Matching skilled people to projects across the organization | The same few people are committed to every project |
| Dependency management | Tracking dependencies between projects and programs | Projects block each other without anyone noticing |
| Portfolio support | Analysis for deciding which projects to start, stop or reprioritize | Investment choices made project by project, without a view of the whole |
| Benefits tracking | Checking whether completed projects delivered the benefits their business cases promised | Nobody learns whether projects worked |
Types of PMO
Two dimensions describe most PMOs: how much control it has, and how much of the organization it covers.
The Project Management Institute describes three types by degree of control. A supportive PMO acts as a consultant and library: it provides templates, training, lessons learned and advice, and has little authority over projects. A controlling PMO requires compliance: projects must use its methods, templates and governance, and it reviews them at defined gates. A directive PMO manages projects directly: project managers report to it, and it is accountable for delivery.
Scope is the second dimension. A project or program office supports one large undertaking and closes when it does. A departmental PMO serves one function, such as IT or engineering. An enterprise PMO (EPMO) spans the organization and usually supports portfolio management, helping the executive team choose and balance investments. Some organizations rename that last role a portfolio or strategy execution office, to emphasize that its job is choosing the right work as well as delivering it.
| Supportive | Controlling | Directive | |
|---|---|---|---|
| Authority over projects | Low: advises | Medium: sets and enforces standards | High: runs projects |
| Project managers report to | Their own departments | Their own departments, with PMO oversight | The PMO |
| Typical services | Templates, training, advice, lessons learned | Methods, gate reviews, reporting standards, audits | Project delivery, resourcing, escalation |
| Suits | Organizations with experienced project managers and low risk | Organizations that need consistency and visibility across many projects | Organizations where delivery capability must be concentrated |
| Common risk | Ignored | Seen as bureaucracy | Bottleneck, and distant from the business |
How to Set Up a PMO
Most PMOs that fail tried to do everything at once. Successful ones start from a small number of problems.
- Name the problems the PMO is meant to solve, in the sponsor's words: late projects, no view across the portfolio, too many projects for the people available.
- Choose the type and scope that fit those problems. A visibility problem may need a controlling enterprise PMO; a skills problem may need a supportive one.
- Write the mandate: services, authority, what is out of scope, and who the PMO reports to.
- Define a minimum method: stages, gates, a few templates and a status report that fits on one page. Add only what a real problem requires.
- Start with a handful of projects or one portfolio, and make their delivery visibly better before extending.
- Agree the measures the PMO will be judged by, such as schedule predictability, time to decision at gates, and benefits tracked after closing.
- Connect it to the investment process and the architecture practice, so the PMO's view of projects meets the organization's view of strategy and capabilities.
- Review the mandate yearly. A PMO's purpose should change as the organization's delivery maturity grows.
Measuring Whether a PMO Is Working
A PMO that measures its own activity, such as templates issued or reports collected, will drift toward producing more of both. Measure what it was set up to improve.
| Problem the PMO addresses | Example measure |
|---|---|
| Projects finish late or over budget | Share of projects finishing within an agreed tolerance of their baseline |
| Trouble is found too late | Average time between a project's forecast slipping and the steering group being told |
| Decisions wait too long | Time from a gate review request to a decision |
| Too much work for the people available | Share of key people committed beyond their capacity |
| Nobody knows whether projects worked | Share of closed projects with a benefits review against their business case |
| Wrong projects funded | Share of the portfolio's spending linked to a named strategic objective and capability |
The PMO and Business Architecture
The PMO sees projects. The architecture practice sees capabilities. Portfolio decisions need both views at once.
A PMO can tell an executive committee that forty projects are running, which are late and what they cost. It usually cannot tell them whether those forty projects are the right ones, whether three of them are building the same thing, or whether an important capability has no project aimed at it at all. Those are architecture questions.
The practical bridge is a shared capability map. When every project charter names the business capability it changes and its target maturity, the PMO's portfolio view can be laid over the capability map. Overlaps appear as several projects aimed at one capability; gaps appear as important, weak capabilities with no project. Prioritization can then weigh projects by the strategic importance of the capability they improve, not only by their own business cases, which are always written to win.
The two functions also share gates. An architecture review at the start of a project, checking that it fits the target architecture and does not duplicate existing capability, is more useful than one at the end, when changing course is expensive. Many organizations run that review as part of the PMO's initiation gate, with the architecture practice providing the content.
Go further
- Capability-based project prioritization — Ranking projects by the capabilities they improve.
- Project charter — Where each project names the capability it changes.
- Business case — The benefits a PMO should check after a project closes.
- Project management — Projects, programs and portfolios, and how they differ.
Common PMO Pitfalls
PMOs tend to fail in a few recognizable ways.
- Reporting for its own sake. Status reports that nobody acts on cost project managers time and teach them that the PMO is overhead.
- One method for every project. A small internal change and a multi-year transformation need different amounts of governance.
- Authority without accountability, or the reverse. A PMO that can block projects but answers for none of them, or that answers for delivery without the authority to influence it, frustrates everyone.
- Disconnected from strategy. A PMO that sees only delivery cannot help choose the right projects, and the organization delivers the wrong ones efficiently.
- No benefits follow-up. Projects close, the PMO moves on, and nobody checks whether the promised benefits arrived.
- Built all at once. Large launches with every service from day one tend to produce templates before they produce value.
Frequently Asked Questions
What is a project management office (PMO)?
A function that standardizes how an organization's projects are governed and delivered and supports the people who run them. Depending on its mandate it provides methods, training and reporting, enforces standards and reviews, manages projects directly, or supports portfolio decisions.
What are the three types of PMO?
The Project Management Institute describes supportive PMOs, which advise and provide templates and training; controlling PMOs, which require compliance with methods and reviews; and directive PMOs, which manage projects directly.
What does a PMO do?
Common functions include setting methods and standards, training and coaching, consistent reporting across projects, governance and gate reviews, resource and dependency management, portfolio support and tracking benefits after projects close.
What is an enterprise PMO?
A PMO that spans the whole organization rather than one department or program. It usually supports the executive team's portfolio decisions about which projects and programs to fund, start, stop or reprioritize.
What is the difference between a PMO and a project manager?
A project manager is accountable for delivering one project. A PMO supports and governs many projects, setting common methods and providing a view across them; in a directive PMO, project managers report to it.
How do you measure a PMO's success?
By the outcomes it was set up to improve, such as the share of projects finishing within tolerance of their baseline, how quickly trouble is escalated, time to decision at gates, and whether closed projects are reviewed against their business cases.
How does a PMO work with enterprise architecture?
The PMO provides the view of projects and delivery; the architecture practice provides the view of capabilities and target architecture. With a shared capability map, they can see overlapping projects and unaddressed capabilities, and run architecture review at the start of each project rather than the end.
Does every organization need a PMO?
Not necessarily. Organizations with a few projects and experienced project managers may need only light, shared standards. A PMO earns its place when the number of projects, their interdependence or their risk makes a common view and common methods worth the cost.
Pro Tips
- Write the PMO's mandate on one page, including what it does not do.
- Cut the status report to one page, and remove any field nobody has acted on in a quarter.
- Add one line to every charter template: the capability this project changes, and its target maturity.
- Run the architecture review at the initiation gate, not the go-live gate.
- Schedule a benefits review for every closed project, and report the results to the portfolio decision-makers.