Your PMO Has the Wrong Boss
There is a structural mistake most enterprises make. It is invisible until it is expensive.
The Project Management Office reports to the CIO. Sometimes to a Head of Technology. Occasionally to a Head of Digital. It looks tidy on an org chart. It is wrong.
Project management was not born inside the IT function. It was forged in operations.
The discipline we now call programme delivery emerged in 1957 inside the United States Navy Special Projects Office. Rear Admiral William Raborn's team developed PERT, the Program Evaluation and Review Technique, to manage the Polaris submarine programme. Polaris involved more than 700 contractors building submarines, missiles, and warheads in parallel, against a Cold War clock. There was no IT department. There was operational urgency, and a method invented to deliver under it.
When the Project Management Institute was founded in 1969, the people in the room came from Brown and Root, the engineering and construction firm. From SmithKline and French Laboratories, in pharmaceuticals. The wider founding network reached into AT&T, Booz Allen Hamilton, and Georgia Tech. The discipline these people were trying to formalise was not IT project management. It was the management of complex change in real organisations.
That history matters because organisations forget it. They see modern projects involve software and conclude that project management is therefore a technology problem. It is not. Software is the artefact. The project is the change. Change is operational by definition.
When you place the PMO under the CIO, three things happen. None of them help.
You create a conflict of interest. The PMO exists to be an arbiter. Its job is to weigh competing priorities, surface bad news early, and tell the truth about delivery health across the portfolio. You cannot do that job when your boss is one of the people you are arbitrating between. Internal audit understood this fifty years ago, which is why it sits outside the functions it audits. The PMO needs the same structural independence.
You narrow the portfolio. PMOs under IT see what IT funds. They lose visibility into the M&A integration, the workplace safety overhaul, the new clinical model, the regulatory remediation, the operating model rebuild. These are real programmes with budgets, risks, and dependencies. When they fall outside the PMO's line of sight, the enterprise loses the only function whose job is to see across all of them.
You signal that delivery is a technical concern. Boards read org charts. When the PMO reports to a CIO, the message is that delivery is plumbing. It is not plumbing. It is how strategy turns into outcomes. Putting that capability under technology is the same category mistake as putting strategy under finance because strategy involves spreadsheets.
The pragmatic objection is familiar. The CIO has the budget, the project managers, and the discipline. Fair enough. That is an argument about where the work is currently sitting, not where the function should sit. Toyota did not put the Toyota Production System under finance because the accountants tracked numbers. They put it where it belonged, in operations, and let it shape every other function from there.
There is a better arrangement. The enterprise PMO reports to the COO, or to a Chief of Staff, or directly to the CEO. The CIO keeps a delivery capability for technology work, an IT PMO if you like, but it does not own enterprise portfolio governance. The enterprise PMO sees everything. It speaks for delivery without asking permission from a function it might need to hold to account.
I have run programmes that crossed CRM, ERP, finance systems, and operating model change inside the same organisation. The difference between an enterprise PMO with the right reporting line and a technology PMO doing its honest best is not subtle. The first one calls a programme red when it is red. The second one negotiates the colour.
If you are designing a transformation function in 2026, do the unglamorous structural work first. Decide who the PMO reports to before you decide what tools it uses. The tools will change every three years. The reporting line will shape behaviour for a decade.
The PMO is not an IT capability. It never was. Treating it as one is a choice. Like most structural choices, it produces the outcomes the structure was always going to produce.