Designing a project management office that earns its place

When an organisation starts running more projects than it can comfortably coordinate, someone eventually proposes a project management office, or PMO. The reasons are familiar: projects report in different formats, nobody can see the whole picture, the same mistakes keep recurring, resources are double-booked and executives cannot tell which projects are healthy. A central function that standardises methods, collects information and supports project managers looks like the obvious answer.

Sometimes it is. A well-designed PMO can improve the quality of decisions, reduce waste and help an organisation deliver more of what matters. But PMOs also have a reputation for becoming bureaucratic: producing templates nobody wants, demanding reports nobody reads and enforcing processes that slow projects without improving them. Many are restructured or closed within a few years of being created, often because nobody could explain what value they added.

The difference usually lies in design. A PMO that earns its place is built around specific problems the organisation needs to solve, given an appropriate mandate, staffed with the right capability and measured by outcomes rather than activity. This article explains, in general terms, the main types of PMO, the services they can offer, how to set the mandate and measures, the common failure patterns and what a lightweight version looks like in a small business.

Start with the problem, not the structure

Before deciding what a PMO should look like, write down the problems it is meant to solve. Different problems need different responses:

If the organisation cannot name the problems, it is not ready for a PMO. If it names many, it should prioritise. Trying to do everything at once is a common cause of failure.

The main types of PMO

PMOs are often described by how much control they exercise. A widely used classification distinguishes three broad types:

• Supportive. The PMO provides templates, guidance, training and access to lessons learned. Projects use them voluntarily. Control is low and the PMO acts as a service.
• Controlling. The PMO requires compliance with certain methods, templates, reporting and reviews. Control is moderate, and the PMO checks conformance.
• Directive. The PMO directly manages projects, often by employing the project managers and assigning them. Control is high.

PMOs are also described by scope. A project office supports a single large project. A program office supports a group of related projects. A portfolio office or enterprise PMO supports decisions across all the organisation’s projects and programs. Some organisations also run a centre of excellence that develops methods, tools and capability without managing projects directly.

These categories are useful for thinking, but real PMOs mix them. A PMO might be directive for capital projects, controlling for IT projects and supportive for small improvement initiatives. The right mix depends on the organisation’s risks, maturity and culture.

Services worth considering

Most of a PMO’s value comes from a small number of services done well. The common ones include:

• Portfolio visibility. A single, reliable view of what projects exist, their status, cost, risks and expected benefits.
• Prioritisation support. Information and analysis that help executives decide which projects to start, continue, pause or stop. The saying no to good projects article explains why selection is about the whole set, not individual approvals.
• Capacity and resource management. Matching project demand with the people and skills available, and showing where bottlenecks are.
• Front-end support. Helping sponsors define projects, prepare business cases and plan before commitment.
• Gate reviews and assurance. Independent checks at key decision points, focusing on whether the project should proceed.
• Methods and templates. A small, practical set of tools scaled to project size and risk.
• Capability development. Training, coaching and mentoring for project managers and sponsors.
• Lessons learned. Capturing what worked and what did not, and feeding it into methods and future plans.
• Benefits tracking. Following whether completed projects deliver the outcomes promised.

Choose the few services that address the organisation’s most important problems. Add others only when the first ones are working.

Setting the mandate

A PMO’s mandate defines what it is responsible for, what authority it has and whom it serves. An unclear mandate is one of the most common causes of PMO failure: the PMO believes it has authority it does not have, project managers see it as interference, and executives wonder what they are paying for.

A good mandate answers:

• Who sponsors the PMO? It needs an executive sponsor with enough authority across the organisation to support it.
• Whom does it serve? Executives, sponsors, project managers or all three, and in what priority?
• Which projects are in scope? All projects above a threshold, a particular portfolio, or only some categories?
• What authority does it have? Can it require compliance, stop a project at a gate, reallocate resources, or only recommend?
• What decisions remain with others? Sponsors and executives typically keep investment and priority decisions; the PMO informs them.
• How will its value be judged? Measures agreed at the start.

Authority should match the problems the PMO is meant to solve. A PMO asked to fix poor prioritisation, but given no access to the executive forum where priorities are set, cannot succeed.

Where the PMO should sit

Where a PMO reports affects what it can achieve. A PMO located inside one department, such as engineering or IT, tends to serve that department’s projects and struggles to influence decisions elsewhere. A PMO reporting to the chief executive or general manager can support enterprise-wide prioritisation, but it risks being seen as an extension of head office control.

A useful test is to ask where the decisions the PMO is meant to improve are actually made. If the main problem is portfolio prioritisation, the PMO needs a direct line to the executive forum that sets priorities. If the main problem is delivery quality within a technical function, it may sit sensibly within that function. As the organisation’s needs change, the reporting line may need to change too. Mandates that outgrow their place on the organisation chart are a common reason PMOs lose effectiveness.

The relationship with project managers

A PMO succeeds or fails largely on its relationship with project managers. If they experience it as a source of help, such as better templates, quicker answers, coaching and early support when a project is in trouble, they will use it and provide honest information. If they experience it as an auditor that adds work and reports their problems upward without helping solve them, they will provide the minimum and shape their reports to avoid attention.

Two habits help. First, make every request for information earn its place: if the PMO asks for something, it should be able to say which decision it informs. Second, treat bad news as useful. A PMO that responds to an honest red status with support rather than blame will receive earlier and more accurate warnings.

Measure outcomes, not activity

Many PMOs measure what they do: templates issued, reports produced, reviews held, people trained. Those measures show activity but not value. Executives ultimately care whether projects deliver more reliably and whether the organisation invests in the right work.

Better measures, chosen to match the PMO’s purpose, include:

• the proportion of projects delivering within agreed tolerances for time and cost;
• the accuracy of forecasts, for example how much forecast costs change late in projects;
• how early significant problems are identified and escalated;
• the proportion of projects that pass gates with a sound justification, and the number stopped or reshaped at gates;
• the time taken to make portfolio decisions;
• benefits realised against those approved; and
• feedback from sponsors and project managers on the usefulness of PMO services.

Some of these are hard to measure perfectly. Even approximate measures focused on outcomes are more useful than precise measures of activity.

Why PMOs fail

Several patterns recur:

• Process without purpose. The PMO introduces a method because it is good practice, not because it solves a problem the organisation recognises.
• Reporting burden. Project managers spend more time producing reports for the PMO than the information is worth, and the reports are not used to make decisions.
• Policing instead of helping. The PMO focuses on compliance and becomes an obstacle rather than a resource.
• Wrong people. A PMO staffed by administrators cannot credibly challenge experienced project managers or advise executives.
• No executive engagement. If executives bypass the PMO’s information and processes, projects quickly learn they do not matter.
• Too much too soon. Launching a full suite of services before any one of them works erodes credibility.
• Ignoring culture. A highly controlling PMO in an organisation that values autonomy will face resistance, however good its intentions.

Building a PMO in stages

A practical approach is to build in stages, earning credibility before expanding:

1. Define the problems and the mandate. Agree them with the executive sponsor.
2. Start with visibility. A simple, honest list of current projects with status, owner, cost and key risks often delivers immediate value.
3. Add one decision service. For example, a capacity view or a light gate review for projects above a threshold.
4. Introduce minimum standards. A small set of templates scaled to project size, replacing rather than adding to existing documents.
5. Measure and review. After six to twelve months, assess whether the problems are improving and adjust.
6. Expand only where value is proven. Add services such as benefits tracking or capability development when the foundation works.

A worked example

This is an illustrative example. The organisation, figures and events are hypothetical.

A mid-sized manufacturer with 180 staff has 27 active projects: product launches, equipment upgrades, an ERP change and several improvement initiatives. Executives complain that every project is “green” until it suddenly fails, and engineering staff are assigned to too many projects at once. The general manager proposes a PMO with three staff, a full methodology and monthly reporting on all projects.

Before approving it, the leadership team names the problems: unreliable status, overloaded engineers and projects starting without clear justification. It designs a smaller PMO: one experienced project manager reporting to the general manager, with a twelve-month mandate to deliver three services. First, a single-page monthly portfolio view of all projects over $50,000 or using more than one person-month of engineering time. Second, a monthly capacity view of engineering demand against availability. Third, a short gate review before any new project over $100,000 is approved.

Within six months, the portfolio view shows that 11 of the 27 projects have not progressed in two months. The capacity view shows engineering demand at about 140% of available hours. The leadership team pauses eight projects and stops three. Engineering demand falls to about 95% of capacity, and the average time to complete the remaining projects shortens noticeably. Only then does the business consider adding standard templates and lessons-learned reviews.

How this applies to a small Australian business

A small business rarely needs a separate PMO, but it often needs PMO services. A lightweight version might be:

• one person, perhaps part-time, who maintains a list of all significant projects and their status;
• a monthly meeting where the owner or management team reviews that list and makes priority decisions;
• a simple capacity view of the people who are most often overloaded;
• a short checklist that projects above a set size must complete before starting; and
• a brief review at the end of each significant project to capture lessons.

The program, portfolio, PMO and procurement roles article describes how these responsibilities fit together and how they can be combined in smaller organisations.

Common mistakes

• Creating a PMO without naming the problems it must solve.
• Copying a methodology wholesale rather than scaling tools to project size and risk.
• Measuring activity instead of improvements in delivery and decisions.
• Giving responsibility without authority or executive support.
• Overloading project managers with reporting that is not used.
• Staffing with administrators when the role needs experienced practitioners.
• Expanding before proving value in the first few services.

Frequently asked questions

Should the PMO employ the project managers? Only if the organisation wants a directive PMO and has enough projects to justify a pool of professional project managers. Otherwise project managers usually sit in the business functions and the PMO supports them.

How many staff does a PMO need? As few as can deliver the chosen services well. Many effective PMOs start with one or two experienced people and grow only when demand is proven.

Is a PMO the same as a methodology? No. A method is a set of practices; a PMO is a function that may maintain and support a method, among other services. Buying or writing a methodology does not create the capability to use it.

Questions to ask

• What specific problems would a PMO solve for us, and which matter most?
• Who will sponsor it, and what authority will it have?
• Which projects are in scope, and how will thresholds be set?
• What will the PMO stop us doing, as well as start?
• How will we know in twelve months whether it is adding value?
• Do we have someone with the experience and credibility to lead it?
• Could the services we need be delivered without creating a separate function?

Bringing it together

A project management office is a means, not an end. It earns its place by solving specific problems: unreliable visibility, overloaded people, weak justification, recurring mistakes or disconnected strategy. Design it around those problems, choose the right level of control, give it a clear mandate and executive support, staff it with credible people, measure outcomes rather than activity and build it in stages. In a small business, the same services can be delivered without a separate office, through a short list of projects, a regular decision forum and a little discipline about what starts and what stops.

---

Source: KEVOS editorial notes. Examples and figures in this article are illustrations.