Project Management Office (PMO): What It Does and When You Need One

No capital works program decides to run every project differently. It happens anyway. One project manager builds a cost report the finance team likes. Another builds one the board likes. A third inherited a spreadsheet from a consultant who has since left.

Individually, all three are fine. Put them in front of a board that wants total exposure across the construction program, and nobody can answer without a week of manual work. A project management office is what an organization builds when it decides that week is too expensive to keep paying.

What Is a PMO (Project Management Office)?

A project management office (PMO) is the centralized department or function that defines how an organization runs its projects. It owns the standards, the reporting formats and the escalation rules every project follows. It does not manage projects directly. Its job is to make separate projects comparable, so decisions above project level rest on evidence.

Most definitions stop at "centralizes and standardizes," which describes the activity without saying what it is for. The point of the activity is decisions. Three things get confused with a project management office often enough to be worth separating out.

• It is not a delivery team. Staff it with project managers who also run projects and you get neither.
• It is not an owner's representative, which is a delivery role on a single project acting for the owner under the contract. A PMO sets the standard that role reports against.
• It is not a reporting tool, although a badly designed one shrinks until reporting is all it does.

The Project Management Institute frames it as a management structure that standardizes project governance and lets projects share resources, methods and tools. That definition runs through successive editions of the PMBOK Guide, and PMI now publishes a separate practice guide devoted to project management offices alongside it. That is a reasonable signal that one sentence was never going to cover the range.

Brian Hobbs and Monique Aubry's PMI research into PMO structures found 75 distinct functions in the literature. They narrowed those to 27 for a survey of roughly 500 PMOs, then found a much smaller structure underneath. There is no single model. The four functions below matter more than any org chart does.

What Does a PMO Do? Core Functions and Responsibilities

Whatever shape it takes, a PMO ends up owning the same short list. The standards projects run on. The reporting that makes them comparable. The assurance that checks the reporting is true, and the capability that keeps people doing all of it. Each has a recognizable way of going wrong.

Above those sits strategic alignment, the work of checking the portfolio still matches organizational goals. Projects delivering no business value get stopped, not managed. Resource management and resource allocation across competing projects sit underneath, alongside knowledge management and the project management methodologies the organization has settled on.

One test sorts any function you are considering adding. Does it help a decision get made faster or better? A PMO that collects information nobody acts on is administrative overhead with a governance job title.

The 3 Main Types of PMO: Supportive, Controlling, and Directive

Supportive PMOs advise and provide templates on request. Controlling PMOs mandate a method and verify compliance. Directive PMOs own the project managers and run the projects through them.

The taxonomy comes from the Project Management Institute and was set out through the sixth edition of the PMBOK Guide. The seventh edition moved away from the three-type model. It remains the framework nearly every organization actually uses.

Each type suits a different situation and fails in a different way.

Where construction and infrastructure owners run a central function under any name, it usually behaves like a controlling PMO. The reason is contractual. Money sits under contracts administered by named individuals with independent duties. Pulling that authority into a central office creates problems it does not solve.

How to choose which type you need

Three questions settle it, and they are about the organization, not the ambition you have for it.

• Can you name who signs off each class of decision today? If not, a supportive PMO will change nothing, because there is no decision structure for the advice to reach.
• Do your projects already run to a recognizable method? If they do, controlling formalizes what exists. If every project invents its own, directive may be the only thing that lands, and it will cost you goodwill.
• Does the central function carry any accountability for delivery outcomes? If it does not, do not give it directive authority. Authority without accountability is the failure mode described further down.

A supportive function that gets ignored tends to harden into a controlling one. Planning for that from the start is cheaper than arriving at it by attrition.

Project, Program, or Portfolio Office: Which One Do You Have?

A project office supports individual projects. A program management office coordinates related projects working toward one outcome. A portfolio office decides which projects get funded at all.

The quickest way to tell which one you have is to look at the decision it owns.

Getting this wrong produces a predictable failure. An organization stands up what it calls a PMO, staffs it to do program management, then asks it to make portfolio decisions about which projects proceed. Those are separate skill sets on separate reporting lines. Project portfolio management needs access to capital planning that a delivery-focused office rarely has.

The enterprise version of the portfolio tier is usually called an EPMO. The distinction is real. An EPMO reports to the executive on strategy. A project management office reports to delivery on progress.

If your projects share a funding envelope, you probably have a program office.

PMO vs Project Manager: What's the Difference?

A project manager owns the delivery of one project. A PMO owns the system that project is delivered within.

Neither outranks the other outside a directive model. Seniority is the wrong question to be asking; the split is about decision rights.

Treating that split as a hierarchy is what produces the resentment PMOs are known for.

Lorne McClurg is a director at Moto Projects with more than 20 years in project management, most of it client-side. He puts the test for whether anyone in the structure can function at all.

"Have they got the responsibility, authority and accountability to be able to make decisions and provide direction?"
_{- Lorne McClurg, Director, Moto Projects}

All three, held together, or the role does not work. A project manager with accountability and no authority is the most common broken version. A PMO that takes the authority without the accountability is the second.

Who Works in a PMO? Roles, Structure, and Skills

Two roles exist from day one. A PMO director owns the function and its relationship with the executive, and an analyst produces the portfolio view. On capital projects, you also need somebody who can challenge what projects report about cost and schedule.

Headcount varies more than any other aspect. Some roles are needed from day one and some arrive later.

A one-person PMO is real and workable, provided it is scoped honestly. One person can hold the reporting standard, run escalation and maintain templates. One person cannot run assurance across a dozen projects, because assurance means independently checking what the reports claim.

Say which of those the role does not cover, in writing, before anyone assumes otherwise.

The skill that decides whether the function works is not project management. It is asking a project team a question and knowing from the answer whether they are on top of the work. That is judgment, which is why administrators alone cannot staff the function.

How a PMO Works on Capital Projects

On construction and capital projects, a PMO governs money that sits under contracts held by other people. That single fact changes almost every instrument it uses. It is also why generic construction project management advice, transplanted from corporate portfolios, rarely survives contact with a building site.

An owner running traditional lump sum has no contractor margin inside its budget. There is a cost baseline and the commitments made against it. Under a guaranteed maximum price, progressive design-build or an alliance, the owner is also managing a fee and a shared contingency. That is a different governance job again.

Change works differently too. A change order, called a variation in Australia and the UK, is a contractual mechanism rather than a backlog item. Once instructed, it adjusts the contract sum. It may also support an extension of time, but only if it affects the critical path and is notified inside the contract's deadlines.

Those differences run through every artifact the function produces.

Owners underestimate the last row. The Construction Industry Institute built an entire instrument around it, the Project Definition Rating Index, which scores how completely a project is defined before execution begins. Its research consistently ties stronger front-end definition to better cost, schedule and change performance. Whatever the score, it is settled before anyone breaks ground.

A capital project management office that only reports on work already under construction has arrived after the money was committed.

One boundary matters more than the rest, and getting it wrong creates legal exposure, not inefficiency. A PMO does not certify payments. Certification sits with the named certifier under the contract, whether that is the superintendent under AS 4000, the architect under AIA A201, or the engineer under FIDIC. Those duties are independent by design.

What the PMO governs is the process around certification. Payment applications get assessed inside the contractual window, certified amounts reconcile to the cost report, and nobody certifies outside their delegation. Those windows are statutory in Australia and the UK, and set by federal and state prompt payment law on US public work.

PMO vs Project Controls vs Owner's Rep: Who Does What?

Three functions do overlapping work here and the names get used interchangeably. That is where most of the confusion starts. Project controls owns the data. An owner's representative runs one project for the owner. A PMO sets the standard both work to.

Capital owners often do not use the word PMO at all, and the public accountability record shows it. Australia's Victorian Auditor-General reviewed 251 capital projects worth A$35.7 billion in its 2016 audit of capital project performance and cost.

The New South Wales Audit Office's Capital projects 2025 report was tabled in March 2026. It found all nine projects it examined had slipped by between one and six years, with A$907 million written off across the top 40 state agencies in three years.

Both reports document capital delivery failure in detail. Neither uses the term "project management office." They describe the function in other language.

These are the words owners use instead. They are not interchangeable.

In US transit, PMO means something else entirely. Project Management Oversight is a formal Federal Transit Administration program under 49 U.S.C. §5327 where contractors monitor grantees' capital projects on the funder's behalf. It is close to the opposite of an internal project management office, and the acronym is identical.

So a lot of owners already perform most of these functions, spread across a project controls team and an owner's rep. Nobody has drawn the org chart.

What Are the Benefits of a PMO?

Most benefit lists written for this function cannot be verified by anyone reading them. Two things can be. How long a decision takes, and how long it takes to state total exposure across the program.

Each PMO benefit below is paired with the mechanism that delivers it and the evidence that it worked.

The benefits worth putting in a business case are the ones with a number attached. Decision latency and total-exposure reporting time are the two most owners can measure inside a quarter, which makes them the right pair to commit to.

Both depend on every project reporting against the same cost breakdown structure, and that is the real constraint, not the reporting itself. A disciplined spreadsheet convention will hold until the portfolio outgrows it. Past that point, capital program management software exists to enforce the structure so the roll-up stops being a monthly reconciliation exercise.

Where a PMO sits in the organization decides how many of these it can deliver. A function reporting to the executive responsible for the capital program can enforce a standard. One reporting into a single delivery team can only recommend.

When Does an Organization Need a PMO?

An organization needs a PMO when reporting has stopped being comparable between projects and decisions are waiting on people, not information.

No published threshold is worth trusting for this. Jurisdictional thresholds do exist, like the Federal Transit Administration's Major Capital Project criteria or the UK's Government Major Projects Portfolio. Those govern assurance of a single project, not whether you build a central function. Anyone quoting a project count for the second thing has extrapolated from the first.

Score yourself against six signals instead. Two or more means the answer is probably yes, and four or more means it is overdue.

Strong signals. Any one of these on its own is usually enough.

• Reporting is not comparable. Producing a portfolio view means manual reconciliation every month.
• Decisions wait on people, not data. The information exists and nobody knows who signs.
• The same mistake has happened twice. Two projects hit the same problem and nothing was retained between them.

Moderate signals. These count, but rarely on their own.

• The coordinator has another job. Portfolio oversight is somebody's second priority by design.
• Nobody can name total exposure. Committed cost plus forecast across the program takes more than a day to produce.
• Assurance is done by the delivery team. The people reporting progress are the only people checking it.

The coordinator with another job is the signal owners recognize fastest.

"Good business managers know that they're not project managers and they engage the services of independent project managers."
_{- Lorne McClurg}

His argument is capacity, not competence. The day job funds the capital works, and blending the two means one of them gives way.

Cost is the question everyone asks next. Benchmarks do exist, and PM Solutions has run its State of the PMO research biennially since 2008. The caveat is that almost all of it comes from corporate and IT portfolios, and none of it breaks out owner-side capital delivery. Treat the numbers as a starting point. They are not a comparable.

The shape is knowable even where the benchmark is not. A controlling project management office is a manager and an analyst, before you add scheduling and cost capability. Set that against what a decision costs when it is made slowly or made twice.

How Does a PMO Govern? Decision Rights, Escalation, and Reporting

Governance fails at one question, and the question is who signs. A decision matrix records who decides what. An escalation rule records what has to come up. A named sponsor sits where the ladder terminates.

The sponsor is the piece most often missing. Somebody has to own the business case and the benefits, and be senior enough that escalation terminates below board level. Without one, everything either stalls in the PMO or goes straight to the board.

The other two instruments usually exist already, in some form, and are usually vague about exactly who signs.

"A lot of problems we see in governance occur when it's not clear who has the responsibility and who is accountable for making a decision."
_{- Lorne McClurg}

"Trust is eroded because decisions aren't done in the best interest of the project, they're done in the best interest of a participant. We have breakdown trust issues, which then leads to breakdown in communication, which then leads to poor decision making or unwieldy, untimely decision making."
_{- Lorne McClurg}

The early warning is behavioral. People stop raising things and retreat into their corners when they are not being listened to and not being given decisions. By the time it reaches a status report it has usually been true for months. Broader project governance sets the frame all of this operates inside.

Writing the decision matrix

A decision matrix is one page. It names each decision, the threshold at which it moves up, and who holds it. Most organizations find it harder to write than they expect, and the difficulty is the problem surfacing.

A capital owner's version generally looks something like this.

Thresholds are illustrative. Set yours against portfolio size and existing delegations. Do not copy these.

Setting the escalation rule

Delegated authority is not the PMO's to set. It comes from the board, the chief executive or the enabling legislation, it attaches to a named delegate, and it usually cannot be sub-delegated. What the PMO does is make it legible.

Set the threshold too low and every minor purchase becomes an approval queue, consuming the capacity the function was created to protect. Set it too high and the first anyone hears of a problem is when it is unrecoverable.

Some categories escalate whatever the value attached to them.

• Anything that breaches the approved scope, budget or completion date in the business case goes up immediately.
• Any notifiable safety incident or regulator attendance goes up the same day.
• Any fraud, probity or conflict-of-interest matter bypasses the normal ladder entirely.
• Any notice of dispute, claim or extension of time goes up on receipt, because notice periods run from the date served.
• Anything with statutory, planning or environmental consequence goes up before a position is taken.
• Anything with political, ministerial, trustee or media exposure goes up before it is answered.

Designing the reporting

Iain Davidson, State Chief Executive for Colliers in the ACT, built a capital project management business inside Colliers from scratch. Davidson is a Mastt customer, disclosed here before quoting him. He starts somewhere most organizations skip.

"You need to set up your framework. Needs to match in line with your overarching either government governance or business governance, project governance. So set it up. What's the tempo like? What's the stakeholder level like? What are your core areas that needs to be reported on?"
_{- Iain Davidson, State Chief Executive, Colliers ACT}

Framework before platform. He then describes the platform his team rolled out, and the tension it had to resolve. He wanted something "rigid enough so you don't have those mistakes, but flexible enough to tailor make it to the projects you need."

Each governance layer needs a different document. A working group needs detail and exceptions. A steering committee needs the decisions requiring its authority. A board needs position, trend, and what could change materially before it next meets. Producing one pack and sending it to all three is a common and expensive failure, and our guide to construction reporting works through the formats.

Dr Greg Usher's doctoral research at the University of Southern Queensland was on client-side project management. He frames the purpose in a way that changes what goes in the pack.

"Fundamentally what our job is is to remove the uncertainty and the fear from what is going on in that project."
_{- Dr Greg Usher, Adjunct Research Fellow, University of Southern Queensland}

A report built to remove uncertainty leads with position and exposure, states what changed, and names what needs deciding. A report built to demonstrate activity contains none of those things.

How to Set Up a PMO: A Step-by-Step Process

Setting up a PMO starts with the problem the organization actually has and ends with standardized reporting. Running that sequence backwards is the most common way the function fails in its first year.

Step 1: Find the problem before designing the solution

Interview the executives who asked for a PMO and establish what they want fixed. That becomes the definition of success, and it is usually narrower than the job title implies. Talk to the project managers as well, before anything is designed. They will work inside whatever you build. They also know where the current process breaks.

Step 2: Baseline the portfolio

List every project with its approved budget, approved completion date, current forecast, current stage and named delegate. Most owners cannot produce that list on day one. Producing it is usually the first genuine win, and it tells you immediately which projects have no owner and which numbers nobody can substantiate.

Step 3: Map how work actually flows

Trace how ideas become projects, how they get approved, tracked and changed. Map what happens, not what the process document says happens. The gap between the two is usually where the available improvement sits.

Step 4: Pick the type, and publish what the PMO will not do

Choose supportive, controlling or directive against the organization's maturity, not its ambition. Then write down what the function will not cover. That list prevents the scope creep described in the next section. It is also the cheapest way to keep the function trusted.

Step 5: Write the decision matrix and the escalation thresholds

Do this before any templates. It is the part that makes the PMO useful, and it is routinely done last. If the matrix cannot be agreed, you have found the real problem and should say so. Reporting will not paper over it.

Step 6: Fix the data spine

Establish one project list with unique identifiers, one cost breakdown structure and one set of stage definitions. Without it every portfolio view is manual forever. The project management office becomes a reconciliation service instead of a governance function.

Step 7: Standardize reporting last

Build the reports once you know which decisions they have to serve. Then pick three changes, embed them, and pick three more. Phased rollouts tend to survive where big-bang rollouts get reversed.

Starting at step seven is tempting, because templates are visible and feel like progress. Teams read it accurately as bureaucracy arriving ahead of any benefit, and adoption never recovers.

Why Do PMOs Fail, and How Do You Avoid It?

PMOs fail when the paperwork stops changing decisions. The complaints from the people governed by them are specific enough to fix.

The last row is the most damaging and the least discussed. A team that reads oversight as a spy for senior management controls every source the PMO needs, and the PMO controls none of them. That failure is mechanical. Culture has nothing to do with it.

The second row has a distribution problem underneath it, and McClurg describes what it looks like when the tooling makes circulation free:

‍"Most of the software packages people carpet bomb, you know, use the old blunderbuss and throw out correspondence and documents to anyone and everyone. They become a really good tool of filling inboxes full of crap that most people don't need to read."
_{- Lorne McClurg}

Distribution lists are the cheapest thing in any reporting system to expand and the hardest to contract. Naming a recipient for each report, and a reason, is the fix that costs nothing.

Not everyone accepts the premise, including practitioners with decades on capital work. McClurg is currently registered on at least four platforms across the projects he is running.

‍"I think there's a lot of people who hide behind software and hide behind what it supposedly does or doesn't do to avoid having conversations."
_{- Lorne McClurg}

He draws his line at scale. Asked where software genuinely earns its place, he points to really big, complex programs of projects and doubts it for standalone ones. The same dividing line arguably applies to the central function itself, though that is an inference from his position rather than a claim he makes.

One test survives both sides of that argument. For each governance step, ask whether it protects the organization or only proves compliance. Steps that only prove compliance can go, and the people doing them already know which ones those are.

One claim to avoid, because it circulates constantly, is that most PMOs get shut down within a few years. The figure traces back to one study by consultant Michael Stanleigh, which surveyed 750 organizations and found more than 75% closed their PMO inside three years. It is a consultancy's own research and the data has never been open to independent scrutiny. A PMO stood up for a defined purpose and closed when that purpose was served has not failed.

How to Measure PMO Performance

Compliance reads green while a portfolio deteriorates. That is why most PMO scorecards are useless. Measure decision latency, forecast volatility, contingency burn rate, change order rate, gate approval cycle time and movement in the forecast completion date instead.

These are the six worth tracking. Most need a register or a completed project before they produce anything.

• Decision latency. How long an escalated item waits before somebody resolves it. Almost nobody tracks it, and it measures the thing a PMO is actually for. Without an escalation register carrying date raised and date resolved, use the proxies already in your reporting, such as request for information aging and change order assessment aging.
• Forecast volatility. How far the forecast final cost moves month to month, and whether it only ever moves one way. This is measurable on a live project, unlike accuracy at outturn.
• Contingency burn rate against percentage complete. Exposes optimism earlier than cost variance does.
• Forecast completion date movement. Tracked cumulatively and this month. A date that only travels one direction is the same signal as contingency that only goes down.
• Gate approval cycle time. Submission to decision, measured in working days.
• Change order rate, split by cause. Separate owner-initiated scope change, design development, differing site conditions, statutory requirement and contractor-initiated. Owner-initiated change is the only category the owner directly controls, which makes it the one worth isolating.

Counting change orders matters even when each one looks harmless on its own. Timothy Mather, who co-authored a scheduling protocol and spent years building project controls software, describes the aggregate effect:

‍"You can suffer from death by a thousand cuts where if you have a thousand change orders in a project, even if none of them affect the critical path, you know that you've increased the risk of that project ending late because you can't have that much change and not impact something along the way."
_{- Timothy Mather, COO at Strategic Business Solutions and former CTO of PMA Technologies}

That is the argument for tracking the count and the cause, not just the value. A portfolio view that reports change order dollars and not change order volume misses the risk Mather is describing.

Forecast volatility and forecast completion date movement are the two a new PMO can populate in its first quarter, because both come straight off the monthly report. The other four need a register, cause coding or a completed project before they produce a clean number. Promising a full scorecard and delivering a partial one costs more credibility than it buys.

The same discipline applies to the portfolio dashboard. It should not brief the reader on each project's background. It should point at what is wrong, why, and what happens if nothing changes. That is the structure our PPM report template is built on.

Is a PMO Worth It for Your Capital Program?

A project management office earns its place by shortening the distance between a problem appearing on a project and somebody deciding what to do about it. The templates, the registers and the monthly pack are instrumental to that. If the distance is not shrinking, the function is overhead however complete the reporting looks.

Write the decision matrix before the template library. Who decides what, at what threshold, and what has to be escalated. The PMO dashboard template gives you somewhere to put the answer once you have it.

Interview Sources

Every quote in this article comes from a recorded interview conducted by Mastt. Each one is available in full.

• Lorne McClurg, Director, Moto Projects. Client-Side Project Management: Why Communication Wins Projects, June 2026.
• Iain Davidson, State Chief Executive, Colliers ACT. How to Build a Capital Project Management Business From Scratch, July 2026.
• Dr Greg Usher, Adjunct Research Fellow, University of Southern Queensland. What Is Client-Side Construction Project Management and What Does It Involve?, July 2026.
• Timothy Mather, COO, Strategic Business Solutions. AI in Construction Scheduling and the Future of Project Controls, May 2026.