Types of PMO: which one you have, and which one the work is asking for

Three types of PMO, and the only thing separating them is how much authority the office holds. A supportive PMO advises. A controlling PMO requires. A directive PMO runs the projects itself, using its own managers. The level it sits at and the methods it owns both follow from that single choice.

Three types, separated only by how much authority they hold

The taxonomy survives because it rests on one variable that changes everything else.

A supportive PMO is consultative. It holds the templates, the training, the lessons from previous work and the person who knows how the finance system handles capitalised spend. Projects come to it because it is useful, and its control is low by design.

A controlling PMO does all of that and attaches a condition. Use the defined method, the defined forms and the defined governance, and be able to show that you did. The support has not changed; some of it is simply no longer optional, so control is moderate.

A directive PMO removes the question by supplying the project managers. They sit in the office, they are line managed by it, and they are assigned to work. Control is high because the office is not asking a project to do anything, it is the thing doing it.

Type	Position on method	If a project ignores it
Supportive	Publishes templates and advice, and leaves the choice with the project	Nothing, and that is legitimate
Controlling	Defines the method and checks conformance	The work is not approved to proceed
Directive	Applies the method itself, through its own managers	The question cannot arise

That third column is the whole diagnostic, worth running against your own office before reading further. Whatever the charter says, the type is settled by what happens the day a project quietly does not comply. If the honest answer is that somebody sends a reminder, the office is supportive, whatever it has been called.

Level is a second axis, and it answers a different question

Ask what type of PMO somebody has and the answer often names a level instead. Two questions are sharing a word, and separating them is most of the work.

Level is the scope of work an office serves. The APM defines a PMO as an organisational structure that provides support to projects, and notes that it may be a project, programme or portfolio management office depending on what is being supported. A project office serves one piece of work and dissolves with it. A programme office serves related projects sharing an outcome. A departmental office serves a business unit. An enterprise office sits above all of them and often decides what gets funded at all.

The two axes are independent and every combination genuinely exists. An enterprise office can be entirely advisory: a small strategy-facing team with excellent reporting and no power to stop anything. A single-project office can be fully directive, staffed with the managers running one large programme. Treating the axes as one is how an organisation ends up with an enterprise PMO asked to guarantee outcomes it has no authority to influence.

A third meaning of “PMO level” is worth setting aside: the level an office scores on a maturity model. That describes how well it does whatever it does and implies nothing about type. A supportive office can be extremely mature.

Method is where a PMO’s type becomes policy

Every PMO has a position on delivery method whether or not it has published one, and the position follows from its type. A supportive office publishes. A controlling office requires. A directive office simply applies, because its own people are doing the work.

This is the largest single thing PMOs do. In PMI’s survey of PMO frameworks, standards, methodologies and processes appears as a primary workstream across every framework identified, and the centre of excellence variant is defined outright as an office that equips the organisation with methodology, standards and tools so project managers deliver better. An office whose entire purpose is method is a recognised shape, and it is usually supportive: a centre of excellence that starts failing people for non-conformance stops being somewhere anyone visits voluntarily.

The distinction causing the most trouble is between a guideline and a standard, because organisations reach for the softer word while operating the harder thing. A guideline carrying a compliance check is a standard, and the soft label only makes the rule harder to argue with. Publish two lists: what is mandatory, and what is recommended. A team can work with either, but not with one document where the difference is a matter of tone.

Then there is tailoring, which is where mandated methods fail. A method that fits a twelve-month systems replacement does not fit a six-week regulatory change, and forcing both through the same gates produces theatre in one direction and real risk in the other. Reporting cadence is the first casualty: a fortnightly report on six weeks of work is four reports and no information.

Change requests are where the type stops being theoretical

To find out which type of PMO an organisation really has, watch a change request move through it. Nothing exposes the authority setting faster, because a change request is a decision that has to land somewhere.

Change request	What triggers it	What it changes
Corrective action	Performance has already drifted from the plan	Realigns future work with the plan
Preventive action	A risk that has not happened yet	Reduces the chance of future drift
Defect repair	Something delivered does not meet its specification	Fixes or replaces the delivered thing

All three sit inside the existing plan. Corrective action answers something that has gone wrong, and is usually raised off an entry in the issue log. Preventive action answers something that has not gone wrong yet, and is raised off the risk register. Defect repair answers a delivered thing that fails its specification, which is a quality finding rather than a delivery one.

A fourth category is commonly counted alongside them and is a different kind of decision: a change to the baseline itself. The first three change what the work does while leaving the plan intact. A baseline change alters what the plan says, so every performance figure reported afterwards is measured against a different document. It deserves a higher bar and usually a different approver.

Which is where the type shows up. A supportive office logs the request, helps write it properly and has no vote. A controlling office is or convenes the change control board, and its approval is what lets the work proceed. A directive office is frequently the body raising the request, since its own managers are running the projects.

Which type the work is actually asking for

Choose from the delivery problem rather than from ambition, because every step up the authority axis is paid for by somebody losing autonomy, and that cost is real whether or not the business case shows it.

Three questions get you most of the way. First, is the problem knowledge or compliance? If projects go wrong because people do not know how to do the thing, a supportive office fixes it and a controlling one only adds paperwork to the same mistakes. If they go wrong because people know exactly what to do and choose not to, advice will not touch it. Second, who carries the delivery risk? An office answering for outcomes needs the authority to affect them, and the mismatch is the commonest structural fault in PMO design. Third, can the office hold project managers as staff? A directive PMO that cannot recruit and retain them is directive on paper and an understaffed supportive office in practice.

For most organisations the honest answer is a supportive office with a small number of genuinely mandatory controls, which is a controlling office with a short list. It sounds indecisive and it works, because it concentrates authority where it is worth spending: the funding decision, the baseline change, the point where an unrecoverable commitment is made. Mandating everything and mandating nothing fail for opposite reasons at roughly the same rate.

The reason PMOs get closed

A PMO is overhead. That is a description rather than a criticism: the office does not deliver the thing the organisation is paying for, it makes delivering it more consistent. So it lives or dies on whether that consistency is worth more than it costs, and it is judged on that in every budget round.

The offices that get closed share one property, and it is not being expensive. It is holding responsibility without authority. A controlling PMO asked to guarantee outcomes while every real decision, funding, prioritisation and resourcing, sits with the business units will produce reports nobody acts on and escalate risks nobody owns, until it reads as a reporting cost rather than a delivery function. It is not failing at its job. It has been given a job that cannot be done from where it sits.

Directive offices fail more slowly. They work until they become the constraint: every project needs a manager, the managers all come from one place, and the office turns into a queue. The symptom is business units starting projects without telling anybody, and that shadow work stays invisible until something in it goes wrong.

Both are versions of type drift. An office is set up as one type, asked over a few years to behave like another, and nobody restates the authority to match. The remedy takes one sentence: write down what the office can stop, review it annually, and change the type deliberately when the answer changes. An office that cannot say what it can stop has already answered the question.