Ask what does a PMO do and you will get a familiar list: standards, governance, reporting, resource coordination, assurance, training. The list is accurate. It is also a list of things done to projects one at a time, and that turns out to matter more than anything on it.
A good PMO earns its keep. It turns delivery from personal habits into a repeatable process, gives leadership one version of the truth instead of 30, and catches the drifting project before the sponsor does.
The honest answer to what does a PMO do, though, has a gap in it. Every job on the standard list works at the level of the single project. The decision that sets how fast the whole portfolio delivers sits one level up: which projects get the constraint first. The constraint is the one team, skill or asset whose capacity limits how much the organization can finish, the group every project ends up waiting on. In most organizations nobody owns the decision about its time. The PMO is the function best placed to take it, and this article is about why it usually does not.
What does a PMO do?
A PMO, or project management office, is the function that makes project delivery consistent across an organization. It sets the methods and templates projects use, runs governance and stage gates, consolidates status reporting for leadership, coordinates requests for people, and checks that projects follow the agreed process. Its unit of work is the individual project.
In practice that breaks down into six jobs:
1. Set the methods. Templates, lifecycle stages, estimating guides and the tools projects plan in, so every project is run and described the same way.
2. Run governance. Stage gates, approval boards and change control, so money is committed and released in deliberate steps.
3. Consolidate reporting. Collect status from every project and turn it into one portfolio view, usually a RAG-rated dashboard, for executives.
4. Coordinate resources. Field requests for people, broker conflicts between project managers, and keep an allocation plan of who is working on what.
5. Provide assurance. Health checks, audits and lessons learned, so a struggling project is spotted early and the next one avoids the same mistakes.
6. Build capability. Train project managers, coach sponsors and run the community of practice.
Each is worth doing, and each works on one project at a time. Even resource coordination is mostly a series of one-off negotiations between two project managers who both need the same person.
Where does a PMO's time actually go?
A worked example makes the gap visible. The figures are illustrative.
Calder has a PMO of 5 people looking after 32 active projects. Count a typical week, 200 hours in all, and it splits something like this: about 70 hours collecting and consolidating status, 40 on stage gates and change requests, 35 on resource requests, 30 on methods and tool administration, and 25 on assurance and training.
Now look at the constraint. Calder's 4 solution architects are needed by 18 of the 32 projects, and every request for their time arrives as a resource request, served in the order it lands or by whichever sponsor pushes hardest. Assume the architects spread themselves roughly evenly across the 18, and that 3 of those projects are each worth about $50,000 a month once live. Assume too that if those 3 had been given the architects first, rather than a share alongside 15 others, each would have gone live about 2 months sooner. That is 3 × 2 × $50,000 = $300,000 of benefit pushed back. We call that drag cost: the value an organization loses while a project waits.
None of the 200 hours was spent on that decision. Resource coordination came closest, but it answered "can project A have an architect next week?" one request at a time, never "which projects should the architects finish first?" The $300,000 does not appear on the dashboard either, because each of the 18 projects reports honest, slow progress, and slow progress rates amber at worst.
Replace the assumptions with your own and the figure changes. The shape holds: the more of the portfolio that queues at one group, the more the order of work decides the result.
Why can every project be well run and the portfolio still be late?
Because portfolio performance is not the sum of project performance. We call the belief that it is the Project Illusion: the assumption that if each project is well planned, well governed and well delivered, the organization will perform well. In reality the result emerges from how projects interact as they compete for the same scarce people. A PMO built around the six jobs is very good at the first half of that sentence and structurally blind to the second.
This is not a failing of PMO staff. It is a property of what they measure. A RAG status judges one project against its own plan, and no project's plan includes the 17 others queuing for its architect. The watermelon report, green on the outside and red inside, is what that blindness looks like by the time it reaches a steering group.
What should a PMO do about the constraint?
None of the six jobs needs to stop. The change is to add a seventh and let it take priority over the others.
1. Name the constraint. Find the team or skill most projects are waiting on. Queue length is a better clue than utilization, because in a busy portfolio most groups report themselves as fully used. The method is set out in How to Find the One Resource That Sets Your Delivery Speed.
2. Make its queue visible. Add one line to the portfolio report: how many projects are waiting on the constraint right now, and for how long.
3. Sequence instead of sharing. Decide the order in which projects get the constraint's time, and finish them in that order rather than spreading it evenly. Rank them by return per hour of the constraint, the logic behind value per constrained resource hour, not by size or by who escalated last.
4. Gate starts on the constraint. Use the governance the PMO already runs. A project does not pass its start gate until there is room for it at the constraint, which is the argument of Start Less to Finish More.
5. Report delay in money. When a project waits at the constraint, report what the wait costs per month beside its RAG status. At Calder, that would have put the $300,000 in front of someone with the authority to change the order.
Isn't prioritization already the PMO's job?
The objection you are already forming: our PMO does prioritization already. We score every project at intake.
Most PMOs do, and the scoring is useful for deciding what enters the portfolio. But a ranked intake list says which projects are worth doing. It does not say which of the projects already running should get the constraint's next hour, and once 18 of them are live, that second question is settled every week by whoever asks the architects first. A priority list the constraint's queue does not follow is a statement of intent, not a sequence.
Nor does the PMO need the authority to tell a sponsor their project waits. It needs to price each ordering and take the choice to the people who can make it.
So what does a PMO do? The six jobs, done well. The PMOs that change how fast their organizations deliver add the decision that sits above all six: who gets the constraint first. That is also the point at which a PMO starts to work as a Value Management Office, the same function with a mandate to decide which work creates the most value, rather than a new department stacked on top of it.
Leave a Reply