I have spent much of my career building and leading PMOs. I have also seen how easily a useful one can become a place where reports go to be assembled and decisions go to wait. A PMO should exist for a reason. That reason might be a merger, a major technology change, or a kind of work the organization needs to learn how to do consistently. It should not be that the PMO was in last year’s organization chart.
My test is fairly simple: What problem can this PMO solve that the organization cannot solve well on its own? If the answer is clear, give the team the authority, relationships, and freedom to do the work. If nobody can answer, a new dashboard will not fix the problem.
Good reason 1 · Lead the unusual
Some work does not fit neatly inside any one department. A merger cuts across technology, operations, customer support, finance, and the people who have to explain the change to customers. A network transition can depend on build schedules, device readiness, field operations, and customer migration all moving together. Each group may be doing its own job well while the overall effort is still in trouble.
That is where a PMO can earn its keep. It can bring the right people into the same conversation, make dependencies visible, clarify who will decide what, and keep the organization focused on the outcome. The point is not to collect everyone’s status. It is to notice that two perfectly reasonable local plans cannot both be true, then help the people involved resolve the conflict before it becomes a crisis.
During the Sprint and T-Mobile network integration, the hard part was not merely keeping a list of tasks. Technology teams wanted to advance the network, while local and operations teams needed stability. Neither concern could be dismissed. The useful PMO work was to make those tradeoffs explicit, set shared decision criteria, and keep the teams moving together as conditions changed.
This work requires more than templates. It requires judgment, credibility across functions, and a willingness to get into the details. Sometimes the PMO has to convene a decision. Sometimes it has to pick up a problem that has no natural owner and help solve it. That is leading the unusual.
Good reason 2 · Standardize the repeatable
The second good reason follows the first. If an organization has to solve the same kind of problem again, it should not start from a blank sheet each time. A PMO can capture what worked, simplify what did not, and turn hard-earned experience into a process that people can actually use.
The progression is usually gradual: unusual work becomes rare work, then repeatable work, then a standard way of operating. At each stage, the PMO should ask what can be made simpler and who should own it next. Good standardization removes uncertainty and repeated effort. Bad standardization adds forms, gates, and meetings long after the decisions they were designed to support have disappeared.
I saw this in wireless network transitions. The experience gained retiring WiMAX as LTE grew gave teams relationships, governance, and a working approach to draw on when later technologies needed to be harvested. The second effort was not identical, but it did not have to be invented from scratch.
There is an important distinction here. The PMO should not cling to work once it has become ordinary. It should help the organization make that work routine, then take on the next difficult problem. That does not mean working itself out of a job. It means continuing to justify its place by solving problems that still need special coordination.
Bad reason 1 · Because we have always had one
Organizations inherit structures. A PMO that was essential during a major transformation can remain in place after the work changes. The team keeps its cadence, templates, and reporting because those were once useful. Eventually the question “Why do we have a PMO?” gets the answer “We have always had one.”
I do not take that as a criticism of the people in the PMO. In fact, capable people can keep a low-value process running remarkably well. The issue is whether the work still warrants a dedicated organization. Does the PMO lead important cross-functional efforts? Has it made repeatable work easier for everyone else? Does shared capacity solve a real staffing problem? If not, a busy calendar is weak evidence of value.
The answer may be to change the PMO’s mission, size, or operating model. It may be to move mature processes to the teams that use them. The honest review starts with the purpose, not with a defense of the current organization chart.
Bad reason 2 · To enable bad behavior
This is the uncomfortable one. A PMO can become a workaround for leaders who will not make decisions, teams that will not speak to each other, or managers who want an extra layer to enforce accountability for them. Adding a coordinator can make the symptoms less visible without fixing the underlying behavior.
Suppose two leaders have incompatible priorities. A PMO can identify the conflict, show the cost of delay, and get the decision in front of the right people. It cannot sustainably make both leaders’ commitments true, and it should not absorb blame when they decline to choose. Likewise, a weekly status meeting is no substitute for a functional owner doing the work they agreed to do.
A strong PMO will make these problems visible without turning every disagreement into a public fight. It should give leaders clear options and consequences, then hold the decision where it belongs. If the organization expects the PMO to compensate indefinitely for poor ownership, it is asking the team to manage around the problem instead of solving it.
Five questions worth asking
Before creating a PMO, or renewing the mandate of one you already have, I would start with five questions. They are more useful than asking whether the team is busy.
What work is genuinely unusual? Look for efforts that cross organizational boundaries and have important dependencies that no one function can manage alone. If the answer is simply “all projects,” the scope needs more thought.
What have we learned enough to standardize? Identify practices that make the next effort easier, then test whether people actually use them. A process that exists only in a PMO handbook has not improved how the organization works.
Which decisions are getting stuck, and who owns them? The PMO should put clear choices and consequences in front of the people authorized to decide. If the same decision comes back every week, another meeting is unlikely to be the cure.
Where does shared capacity help? A neutral pool of project managers can serve uneven demand across teams. Estimate what work that capacity will deliver, how people will be assigned, and whether the arrangement is better than placing them directly in the business.
What should leave the PMO next? Name the work that is becoming routine, agree who can take it over, and decide what higher-value problem deserves attention. This is the question that keeps a PMO from confusing continuity with contribution.
The question to keep asking
A PMO’s work should change as the organization changes. When the unusual becomes familiar, preserve what was learned. When a process becomes routine, simplify it and put ownership where it belongs. Then look for the next important piece of work that crosses boundaries and needs someone to bring it together.
The test is not how many projects the PMO tracks, how polished its reports look, or whether it can prove everyone used the template. The test is whether it helps the organization make better decisions and get difficult work done.
Lead the unusual.