Project Execution, Uncategorized
One of the most common conversations we have with clients centers on the PMO. And those conversations are less about whether they need one, but whether the one they have is actually helping. I’ve seen organizations where the PMO is a genuine force multiplier – improving decisions, accelerating delivery, and giving leaders real visibility into what’s working and what isn’t. And I’ve seen others where it’s become the thing teams work around. The difference usually comes down to one question: Is the PMO designed to control the work, or to enable it?
The Wrong Starting Question
The argument over the PMO usually starts in the wrong place. People ask whether the PMO should enforce governance or support delivery, as if those are opposing jobs. A PMO exists to improve execution across a portfolio. The real question is how it does that. Does it create the conditions for better decisions, faster delivery, and clearer accountability, or does it become a checkpoint machine that slows work down in the name of control?
That distinction matters. A gatekeeper PMO measures compliance first. It focuses on stage approvals, document quality, status reporting, and process adherence. In theory, that sounds reasonable because organizations do need controls, and funding should not be released without scrutiny. And risks should not be hidden, nor should delivery teams improvise their own methods for every project. But in practice, gatekeeping often expands well beyond sensible oversight because review forums tend to multiply. Templates grow longer, decisions move upward, and teams start managing the PMO instead of managing the work.
Once that happens, the PMO stops reducing risk and starts redistributing it. As a result, delivery slows and escalations increase. Project managers spend more time formatting updates than resolving issues. This means senior stakeholders get polished dashboards but weaker signals. Governance remains visible, but control becomes superficial. The organization feels managed, yet outcomes continue to slip.
The Enabling Alternative
An enabling PMO works from a different premise. It assumes that governance should help delivery, not compete with it. Its role is to make good practice easier to apply at scale. That means providing usable standards, not just mandatory ones. It means giving teams decision support, portfolio visibility, integrated planning, and realistic prioritization. It means helping leaders understand trade-offs early, before projects become recovery exercises.
This does not make the enabling PMO “light touch” or soft. In many cases, it is more technically rigorous than a gatekeeper model because it defines decision rights and sets data standards. It creates consistent controls for schedule, cost, dependency, and risk management. It establishes portfolio-level views that expose capacity limits and strategic conflicts. The difference is in the design. A gatekeeper PMO inserts itself into the path of work. An enabling PMO improves the path itself.
That design choice shows up in everyday behavior. When a project requests approval, a gatekeeper PMO asks whether the form is complete. An enabling PMO asks whether the business case is coherent and whether the assumptions still hold. When delivery slips, a gatekeeper PMO asks for a revised status and a recovery date. An enabling PMO asks what dependency failed, what capacity was overcommitted, and what decision the sponsor now needs to make. One approach protects the process. The other protects the outcome.
Governance by Exception
The problem, of course, is that most PMOs are pulled toward gatekeeping by default. Executive pressure, audit requirements, and past project failures drives it. When an organization has been burned, the instinct is to add control points with more review, evidence, and sign-off. That reaction is understandable, but it often confuses activity with assurance. A project can pass every gate and still be poorly conceived, under-resourced, or strategically unnecessary.
A stronger PMO model accepts that governance has to be selective. Not every project needs the same level of intervention. Not every risk deserves escalation. Not every steering committee decision requires PMO mediation. The PMO should apply tighter controls where uncertainty, spend, complexity, or regulatory exposure justify them. Otherwise, it should standardize the basics and get out of the way. Governance by exception is usually more effective than governance by saturation.
This also changes the PMO’s relationship with project managers and delivery leads. In a gatekeeper model, the PMO often sits above them, checking compliance. In an enabling model, it sits alongside them, raising the quality of planning and reporting while keeping portfolio discipline intact. That does not remove accountability from delivery teams. It sharpens it. Delivery teams own execution. Sponsors own decisions. The PMO owns the framework, the data model, the portfolio view, and the escalation logic. That clarity of ownership is what makes outcomes more likely.
The Shift That Matters
For leadership, the practical takeaway is simple. If the PMO is mainly known for approvals, templates, and challenge meetings, it is probably acting as a gatekeeper. If it is known for better prioritization, earlier risk visibility, cleaner decisions, and more reliable execution, it is acting as an enabler. One creates friction and calls it control. The other creates clarity and calls it governance.
The best PMOs do not choose between control and support. They combine both, but with discipline. They are firm on standards, precise on accountability, and economical with process. They do not try to own delivery. They make delivery more likely to succeed, and that is the shift. The PMO should not be a locked gate in front of progress. It should be the operating layer that helps the organization move through complexity without losing control.