Which PMO Model Fits Your Organisation?
The question arrives in a familiar shape. Somebody has read that PMOs come in three kinds, the organisation is deciding which one it wants, and the conversation turns into a choice between labels. Six months after the label is chosen, the PMO is doing something different from what the label implied, because the label was never the thing that determined how it would work.
What determines it is authority: what this office is permitted to decide, and what it can only advise on. Everything else in a PMO design, the size, the staffing, the reporting line, the services it offers, follows from that and adjusts to it. Choosing a model well means settling the authority question honestly first, against the organisation you actually have.
The question underneath the question
Appendix X2.4 of the PMBOK® Guide covers PMO type, model and structure without landing on a recommended one. That reticence is well judged, because the structure follows from what the organisation needs decided and who it will let decide it, and those two answers differ enormously between a regulated infrastructure business and a software company of the same size.
The productive starting question is not which kind of PMO to build. It is which decisions are currently being taken badly, late, or by nobody. A portfolio where three programmes are competing for the same scarce specialists has a resource allocation problem that needs somebody with authority to arbitrate. An organisation where every project reports in a different format has an information problem that needs a standard and somebody to enforce it. A business that keeps approving work it cannot staff has a pipeline problem that sits with the sponsor group. Those three diagnoses produce three different offices, and only one of them looks like the PMO most people picture.
Authority is the dimension that decides the rest
An advisory office holds no decision rights of its own. It offers help that teams can take or leave: planning support, facilitation, an estimating history, a second pair of eyes on a business case. Its influence is earned, its standing depends on being useful, and it works well in cultures with strong delivery capability and low tolerance for imposed process. Asked to provide assurance, it will struggle, because it can request information and cannot compel it.
A standard-setting office owns how things are done without owning what gets done. It defines the method, the templates, the stage gates and the reporting, and compliance is expected. It suits organisations that need comparability across a portfolio, or that carry regulatory exposure where evidence must be consistent. Its characteristic failure is producing more standard than the organisation can absorb, at which point teams comply visibly and work around it quietly.
A deciding office holds real authority over the work: it prioritises, allocates people, starts and stops projects, and controls the funding route. This is the least common design and the most demanding, because it only functions where senior management genuinely delegates those decisions. Where the authority is nominal, the office is left carrying accountability it cannot exercise, which is the worst position in the catalogue.
The practical test is not which of these you would like to be. It is which one your organisation will actually back when a programme director disagrees with the PMO in front of the executive. Ask that question before the design is written, because the answer is rarely the one on the slide.
Scope and position
Scope sets how much of the organisation the office covers, and the honest options are a single programme, a business function, or the enterprise. Each buys something different. A programme office knows its work intimately and cannot compare across the portfolio. An enterprise office sees the whole picture and is always one step removed from the detail. Large organisations usually end up federated, with a small central office holding standards and portfolio information and local offices doing delivery support, which works provided the boundary between them is written down and not left to be discovered.
Reporting line matters more than most designs allow for, because it determines what the office can survive. A PMO reporting to a delivery director will find it difficult to report honestly on that director's programmes. A PMO reporting to finance will be pulled towards cost control and away from delivery support. A PMO reporting to the executive has the standing to be uncomfortable and the exposure that comes with it. None of these is wrong; each one shapes what the office can be trusted to say.
An aerospace manufacturer had two assembly programmes and one PMO that had grown up supporting the older of them. When a second, differently structured programme started, the office extended its existing method across both. The newer programme was building a lower-volume variant with heavy engineering change traffic, and the fortnightly reporting cycle designed for a stable line produced information that was out of date before it was read. The fix was not a bigger PMO. The central office kept portfolio reporting, resource arbitration between the two programmes and the change control standard, and the newer programme got its own small delivery office running a weekly rhythm inside the central standard. Two models, one organisation, because the two programmes needed different decisions made at different speeds.
Choosing, and changing your mind later
A PMO design is a bet on what the organisation needs now, and the need moves. An office set up to impose consistency on chaotic delivery has a different job once delivery has settled, and the common failure is carrying on enforcing a standard whose problem has been solved. Reviewing the design annually against the decisions it was built to improve is cheap, and the review should be willing to shrink the office.
Knowing when a governance structure has outlived the problem it was built for, and having the standing to say so about your own function, is a judgement a structured PMP exam preparation course approaches through proportionality, which is where most governance questions actually live.
For a PMP® candidate, the frame worth holding is that a PMO is an organisational mechanism whose form should follow the outcomes it is meant to support, and that more governance is not automatically better governance. In any situation describing a PMO being set up or reformed, the useful thing to ask is what decision is being improved and whether the office has been given the authority to improve it.
List the decisions the office will own, in writing, and take that list to the person who will have to back it. If they hesitate over any item, that item is not yours, whatever the model is called. A small office with three decisions it genuinely holds will outperform a large one with a broad mandate and no teeth, and it will be considerably easier to defend at the next budget round.
Interested in going further?
Designing a PMO means committing to how much authority a function will hold before anyone has tested whether the organisation will stand behind it. Omega's PMP® Exam Preparation covers governance structures as design choices with consequences, across regulated, commercial and delivery-led organisations.
The PMO material in Appendix X2 of the PMBOK® Guide Eighth Edition goes further into type, model and structure.
Ad · Amazon affiliate link.
References
A098: PMO Value: What Should a Project Management Office Actually Deliver?
A101: PMO Maturity Models: Useful Diagnostic or Corporate Theatre?
A099: Customer-Centric PMOs: A Better Test of Relevance
A093: Choosing a Project Governance Model
A067: How Your Organisation Limits or Enables Agile Delivery
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
