Does your organization use a PMO as a way to manage the various P functions: project, program, and portfolio management? Plenty of organizations do use PMOs. However, I rarely see them as effective in furthering the organization's operational excellence or the strategy. Instead, I too often see them as yet another function that creates delays in the organization.
(Note: I'm a consultant. No one ever hires a consultant when things are going well. So your PMO might be a thing of beauty and a joy forever. In that case, please comment so I can learn how you do this.)
Those PMO-created delays are all about the decisions managers must make. (See Why Minimize Management Decision Time for more details.)
When times are predictable, we do not need frequent decisions. However, when everything is in flux, we need more frequent and faster decisions. As I write this, in 2025, almost everything is unpredictable. Many managers now realize they need to make more frequent strategic decisions.
As to decision cycle time, we know this: the more we create functional silos to make decisions, the slower the overall decision time. The PMO is a functional silo.
How a Functional PMO Often Works
Here are the responsibilities I often see with a functional PMO. The PMO selects:
- Which projects and programs to fund in the project portfolio. Those are two strategic decisions: Which products allow us to attract more customers (product strategy), and which products do we want to fund for now to enable our corporate strategy (the portfolio)?
- How the project and program managers work. These are tactical decisions about operational excellence.
- Which measures to track. While these are supposed to define operational excellence, too often these measures don't help decisions. However, these measures often decide the culture of the organization.
Very few people (or workgroups) can manage to work at both the strategic and tactical levels. (See How Strategic or Tactical is This Position? for one example of how it works for a person. See Purpose vs. Product: Differentiate Your Strategy from Tactics (Portfolio & Roadmaps) for how it works for the organization.)
When it's too difficult to manage both the strategic and tactical people tend to choose one or the other. Or, they want to “simplify” the various decisions. That's when they decide to only review the portfolio on a quarterly or yearly basis, regardless of the needs. Or, they decide that “all projects and programs” will use the One Framework to Rule Them All, instead of helping teams tailor their approach based on that team's project, program, or organizational risks.
Worse, too many PMOs do not measure anything related to outcomes. Instead, they measure outputs, such as velocity, schedule, or cost variance instead of how frequently the team can deliver to the customers, the team's cycle time. The team's cycle time is directly related to the number of experiments the organization can run. Those experiments help organizations decide where to invest in the product strategy or the project portfolio to create more value.
The tactical decisions (measures and how projects work) matter. However, they matter much less than the strategic decisions.
When the Tactical Decisions Create Friction for Faster Strategic Decisions
Sam, a CEO, realized their market was in the midst of substantial change. To capitalize on those changes and acquire more customers, he wanted a monthly decision cadence for the project portfolio. But the teams had a cycle time of at least one week for any feature. Too often, their cycle time was closer to seven or eight days. Why? The PMO had created a framework based on stages and controlling decisions instead of flow. (This is a tactical decision about how projects should work and what to measure.)
Even though the people in the PMO had worked on software projects, they had never worked on an agile software project. They did not understand how collaboration and flow efficiency changes how people work. Their expertise was old. However, they created their agile framework. (No, they had not yet read my Project Lifecycles book.) Unfortunately, that framework relied on velocity instead of cycle time. Worse, because the PMO had zero influence on the managers and because of the culture's insistence on individual measures, teams did not collaborate enough. Instead, people worked as individuals. That create much longer cycle times than the company needed.
Because the PMO was a separate function, the PMO had incentives about “efficient” work (output), not collaborative work to create an outcome. The managers each had their own incentives (another strategic problem). However, the managers decided who got which raises. Some managers rewarded more collaboration because it increased capacity. Others did not.
There was more about measures, but the big thing the PMO tracked was capitalization and velocity, not the flow metrics.
The result? An organization that created a dividing culture, not a collaborative culture. Sam needed was a collaborative culture.
The PMO could not adapt easily, because it was a silo that reinforced the old culture. Sam needed the actions and culture to change. Worse, the PMO did not fix either of the product strategy or corporate strategy problems.
Adding More Functions Does Not Solve the Strategy Problems
If an organization wants a more agile approach to managing the project portfolio, they need a more agile approach to product strategy. The image above is from Multiple Short Feedback Loops Support Innovation.
The inner loop of the “onion” is the team's cycle time. If you want to use a PMO, help them focus on operational excellence by releasing useful value as fast as possible. That's how to manage the team's cycle time. That might include training about how to collaborate as a team, how to make smaller stories, and how to track and manage WIP.
The next loop is the product strategy loop .(In the image above, it's the red feedback loops on the left.) The product leaders can review what a team (or teams, in the case of a program), can do next—but only as fast as the team can finish something of value.
Finally, the outer-most loop (the green arrows on the right) is the corporate strategy loop where the people who can change the strategy need to wait for the team to deliver some increment of value. Often, the corporate-strategy people need to wait until the product strategy people say, “We did enough for now. What do you think?”
By definition, the PMO does not make any product strategy decisions.
The point of a project is to enable a team to release some value that solves problems for a customer. And the point of management is to acquire a new customer. While a PMO might support operational excellence in the form of project and program management, the PMO has no influence on the next set of value or the next set of customers. The managers do.
Use Managers to Make Decisions
Managers make strategic decisions. That's why I'm fond of using managers to decide on the project portfolio. (With input across the organization, of course.)
I recommend a cohort of senior managers to decide on corporate strategy and manage the project portfolio. Assuming these managers assign teams to projects, they don't need too much time to decide. And they can choose again when life changes. (If portfolio teams try to assign individuals, it takes them forever to decide and they never know who's really working on what.
What about operational excellence? If managers understood about cycle time and feedback loops, they would want to make the decisions that decrease cycle time. Managers could then create a culture that rewards collaboration, not individual work. Managers could encourage people to optimize up for an overarching goal.
Would organizations still need project and program managers? Probably. That would encourage project and program managers to continually learn new techniques and new ideas to be more effective in their roles.
We don't need another function in the organization. That's why I don't find PMOs to be all that useful. Instead, the managers who need to decide should decide those strategic decisions. That's the fastest way to make a decision.
If you do find PMOs useful, please comment and explain the value they offer you, in your organization.