Choosing a PMO structure usually feels like an organizational design question. Should the PMO advise or direct? Should it sit at the center, or should each division run its own? These are sensible questions, and most organizations answer them by looking at their reporting lines.
Here is the problem. The cost of a PMO structure does not show up in the reporting lines. It shows up in the queue in front of your scarcest team. That team takes work from every part of the organization, and it can only work in one order.
What is a PMO structure?
A PMO structure is the way an organization arranges its project management office: how much authority the PMO holds over projects, where it sits in the organization, and how many PMOs there are. It decides who sets methods, who approves projects, who allocates people, and who reports portfolio status to leadership.
Most guides describe it along two lines, both useful: how much control the PMO has (the first three below) and where it sits (the last two).
1. Supportive. The PMO offers templates, training and advice. Project managers can take it or leave it.
2. Controlling. The PMO sets standards and checks compliance through governance and stage gates.
3. Directive. The PMO manages the projects directly, and project managers report to it.
4. Centralized. One enterprise PMO covers the whole portfolio.
5. Federated. Each division or business unit runs its own PMO, sometimes with a small central office that consolidates reporting.
Large organizations tend to land on a federated, controlling model because it respects divisional ownership and still gives leadership a consolidated view. That is a reasonable answer to the question it was built to answer. The question it misses is who ranks the work that competes for the constraint: the one team, skill or asset whose capacity limits how much the whole organization can finish. Every PMO structure on that list is drawn around the org chart. The constraint is not. It serves every division at once, so the right order for its work has to be set in a single currency across all of them. That currency is value per constrained resource hour: the value a project returns for each hour it needs from the constraint. If your PMO structure produces three rankings instead of one, nobody can rank by value per constrained resource hour, because nobody sees the whole queue.
Where does a federated PMO structure break down?
Take Harbour, a company with three divisions, each with its own PMO. All 3 send work to one shared group, a 3-person integration team that has about 400 productive hours a month. That team is the constraint. The figures below are illustrative.
Each divisional PMO does its job well and sends its top-priority project to the integration team:
- Retail sends a project that needs 800 constraint hours and returns $90,000 a month once it is live.
- Commercial sends a project that needs 200 constraint hours and returns $40,000 a month.
- Operations sends a project that needs 1,200 constraint hours and returns $60,000 a month.
Each is the right first choice within its own division. But the integration team now holds three priority-one requests from three PMOs, and no one has ranked them against each other. So it does what fair-minded teams do. It splits its time evenly.
On an even split, the Commercial project goes live after 1.5 months, Retail after 4.5 months and Operations after 5.5 months. Over the first 12 months, the 3 projects return about $1,485,000 between them.
Now rank them by value per constrained resource hour. Commercial returns $200 a month for each constraint hour it needs, Retail $112.50 and Operations $50. Run them in that order, one at a time, and Commercial goes live after half a month, Retail after 2.5 months and Operations after 5.5 months, exactly when it would have landed anyway. Over the same 12 months, the 3 return about $1,705,000.
That is $220,000 of extra value in the first year. Same team, same hours, same three projects. The only change is that one ranking replaced three.
Why does a single-project view hide this?
Every divisional PMO in that example would report its project as healthy. Each was approved, staffed and moving. None of them was late against a plan that assumed an even share of the integration team.
This is the Project Illusion: the belief that if each project is managed well, the portfolio will perform well. Project-level reporting cannot see the cost of the order in which shared capacity is spent, because that cost belongs to no single project. It sits in the gaps between them. A federated PMO structure makes the gaps wider, because it adds a boundary between every division whose work meets at the constraint.
The divisional PMOs did nothing wrong. The structure gave each of them a part of the queue and no view of the rest.
How should you design a PMO structure around the constraint?
You do not need to tear up a federated model. Divisional PMOs are good at what they do: they know their sponsors, their projects and their delivery risks. The fix is to add one decision at the right level.
1. Find the constraint first. Before you debate supportive against directive, identify the team that every division ends up waiting on. How to find the one resource that sets your delivery speed walks through the method.
2. Give one body the ranking for that team's queue. That can be a small central function, a portfolio board or an enterprise PMO. What matters is that one group sees every request for constraint hours and sets a single order.
3. Rank in value per constrained resource hour. Ask each division for two numbers per project: the value it returns once live and the hours it needs from the constraint. Divide one by the other. That ranking is portable across divisions in a way that "priority one" never is.
4. Let divisional PMOs keep everything else. Methods, governance, sponsor management and reporting can stay where they are. Only the order of the constraint's work moves up.
5. Feed the constraint one project at a time where you can. An even split feels fair, and it is the most expensive way to spend scarce hours. Why your best people should do one thing at a time explains the mechanism.
Will one central ranking not just add bureaucracy?
That is the objection most divisional leaders raise, and it is fair. Central PMOs have a reputation for slowing things down, and a new approval layer is the last thing a busy portfolio needs.
But the ranking described here is not an approval layer. It does not review project plans, set templates or ask for status reports. It answers one question, in one currency, for one team's queue. In most organizations that question is already being answered every week, just informally: by whoever escalates loudest, or by an even split nobody chose on purpose. Making it explicit usually takes less management time, not more.
The best PMO structure is not the one with the tidiest org chart. It is the one where every hour of your scarcest team has a single owner deciding what it is spent on. If you want to see how that ranking works in practice, Stop Ranking Projects by How Big They Are is the natural next read.
Leave a Reply