There is a straightforward test for whether a PMO is ready to make use of artificial intelligence, and it has nothing to do with what software it runs. Someone senior asks an unscheduled question in a portfolio review — not a hostile one, just something outside the pack. Can the PMO answer it in that meeting?

In most organisations the answer is no. The question becomes an action, the action becomes a request to fourteen programmes, and the answer arrives a fortnight later attached to a different meeting, by which point the decision has been made without it. A PMO in that state will not be improved by adding a model. It will simply produce the same delay with better graphics.

Where PMO capacity actually goes

When we baseline a PMO, we look at where analyst time goes rather than what the operating model says it should do. The distribution is remarkably consistent across sectors. Roughly:

  • Half the available time goes to collecting, chasing and reconciling status returns.
  • A quarter goes to assembling packs — formatting, versioning, and circulating them.
  • Around a sixth goes to administering the governance calendar itself.
  • What remains, usually under ten per cent, is analysis anyone would call advice.

This is not a competence problem. It is what happens when a function is measured on the reliability of its reporting cycle rather than on the quality of the decisions that cycle informs. The PMO optimises for the thing it is judged on, correctly.

A PMO that spends half its week chasing status is not underperforming. It is doing exactly what it is measured on.

The three shifts

An AI-ready PMO differs in three specific ways, and they have to happen in order.

First, reporting is assembled rather than requested. Data comes out of the tools delivery teams already use, on a schedule, without anyone being asked for a return. This is the change that frees capacity, and until it happens the other two are unaffordable.

Second, assurance is targeted rather than uniform. Instead of every programme receiving the same gate scrutiny regardless of exposure, review effort concentrates where indicators suggest it is warranted. This is uncomfortable at first — it requires the PMO to defend why one programme is being examined more closely than another — but it is the only way scarce senior review capacity gets used well.

Third, the PMO holds a position. It stops being a neutral conduit for whatever programmes report and starts offering a view: this benefit case is optimistic, this dependency is the one that will hurt, this programme should be stopped. That requires the analytical time the first shift released, and the evidence base the second shift produces.

The third shift is where most transformations quietly stop. It is a change in the PMO's relationship with programme directors, and it needs explicit sponsorship from whoever owns the portfolio. Without that sponsorship, analysts will not risk holding a position, and the function reverts to reporting.

What the tooling actually needs to do

Very little, at first. The common failure is buying a comprehensive portfolio platform before the data model exists, then spending eighteen months configuring it to reproduce the existing reporting cycle faster. The tooling requirement for the first phase is modest: reliable extraction from existing systems, a place to hold the consolidated model, and a reporting layer that anyone can query without asking the PMO.

That last capability matters more than it sounds. When a sponsor can answer their own question, the PMO stops being a bottleneck and starts being consulted for judgement rather than for data. It also surfaces disagreements about definitions immediately, which is uncomfortable and enormously useful.

The skills question

Enterprises usually assume this transition requires hiring data scientists into the PMO. In our experience it requires something else: a small number of people who understand delivery deeply and are comfortable interrogating a model's output rather than accepting it. That is a different profile, and it is often already present in the existing team.

The genuine skills gap tends to be in translation — turning a probabilistic output into a recommendation a board will act on, with the uncertainty stated honestly rather than rounded away. That is a communication skill more than a technical one, and it is teachable.

A reasonable first target

Twelve weeks is enough to automate consolidated reporting for a meaningful subset of the portfolio, stand up two or three calibrated indicators, and free perhaps a fifth of analyst capacity. That is not a transformation. It is enough evidence to decide whether to fund one — which is the right thing to be deciding at that point.