Scaling a PMO from zero: five lessons from $3M to $40M

When I stepped into the infrastructure operations role at JET Charge in 2021, there was no PMO. There was a whiteboard, a shared inbox, and a handful of people who were very good at getting chargers in the ground through sheer effort. That worked at $3M a year. It was never going to work at $40M.

Two years later the division was doing $40M in annual project revenue. Thirteen times the volume. The team went from 5 to more than 40. We had delivered over 100 EV infrastructure projects across Australia and New Zealand, including the first 40-plus charger installation in the country.

The PMO is the thing that made that survivable. Not the reason we grew, but the reason growth did not break us.

Here is what I learned building it from zero.

1. Controls before headcount

The instinct when work piles up is to hire. More projects, more people. It feels like progress and it is the most expensive mistake you can make early.

If you add people to a system with no controls, you do not get more throughput. You get more people improvising in more directions, and now you have a coordination problem on top of a delivery problem. Every new hire has to be told how things work, and if "how things work" lives in three senior people's heads, those three people become the bottleneck for onboarding everyone else.

I got this half right and half wrong. Early on I hired to relieve pressure, then spent the next quarter watching variance get worse because there was no shared way of working for those people to plug into.

The order that worked: define the process, prove it with the team you have, then hire into a system that already exists. A new project manager should be able to look at how a project moves from won to closed and follow it, not reinvent it.

Controls are not bureaucracy. Controls are the thing that lets a new person be useful in week two instead of month three.

2. Standardise the boring 80 per cent

Every project felt unique to the people running it. Different site, different client, different council, different power constraints. And some of that genuinely was unique.

But most of it was not. Roughly 80 per cent of any infrastructure project is the same sequence of the same steps: scope confirmed, site assessed, design signed off, materials ordered, install scheduled, commissioning done, handover complete. The 20 per cent that is genuinely bespoke is where your good people should be spending their judgement.

So we standardised the 80 per cent ruthlessly. Same project stages. Same definition of done at each stage. Same templates for the documents that got produced at each gate. The same checklist for a site assessment whether it was a two-charger depot or a forty-charger public program.

The payoff is not just efficiency. It is that variance drops when everyone does the repeatable part the same way. We cut delivery variance by 25 per cent, and most of that came from standardising the parts nobody found interesting. Boring is a feature. Boring is repeatable. Repeatable is what you can scale.

3. Reporting is a product, and it has users

For the first while, reporting was something I did to make executives comfortable. A weekly deck, assembled by hand, mostly backward-looking. It took hours and I resented every one of them.

The reframe that changed it: reporting is a product. It has users. Those users have jobs to do, and the report either helps them do those jobs or it is waste.

The executive team's job was to make capital and hiring decisions. So the report needed to answer: are we going to hit the number, where is the risk, and what decision do you need from me. The delivery leads' job was to unblock projects. So their view needed to surface what was stuck and who owned the next action.

Once you treat it as a product, obvious things follow. You stop reporting metrics nobody acts on. You build it once and automate the assembly instead of rebuilding it every Friday. You ask the users what decision the report is supposed to support, and if it does not support a decision, you kill it.

A report that nobody makes a decision from is not information. It is theatre, and it is expensive theatre because your best people are the ones producing it.

4. Governance should speed delivery up, not slow it down

Governance has a bad name for a reason. Most of it is designed to protect the people running the process, not the people trying to deliver. Stage gates become approval queues. Sign-offs become a way to spread blame. Every one of them adds latency.

I wanted the opposite. Governance that a delivery lead would actually thank you for.

The test I used: does this gate catch a problem early enough to be cheap to fix? A design review that happens before materials are ordered saves you from a five-figure reorder. That gate earns its place. A status meeting that exists so a manager feels informed, held every week regardless of whether anything changed, does not.

We built gates at the points where mistakes get expensive if they slip through: scope confirmation, design sign-off, pre-commissioning. Each one had a clear owner and a clear yes-or-no decision. No standing committees. No "let's circle back."

Good governance feels like guardrails on a road, not a checkpoint on a border. It keeps you moving fast because you trust you will not drive off a cliff. When people started routing themselves through the gates voluntarily because the gates saved them pain, I knew we had it roughly right.

5. Hire for judgement, not process-following

This one I feel most strongly about, because it is the opposite of what you would expect after everything above.

I spent all this effort standardising and building controls. So surely the hire is someone who follows a process well? No. The more standardised your process, the more you need people who know when to break it.

The 80 per cent that is standardised runs itself. The 20 per cent that decides whether a project succeeds is judgement: the council that is being difficult, the power upgrade that just blew the timeline, the client whose real priority is different from their stated one. No template covers that. You need someone who can hold the standard in one hand and the exception in the other and know which situation they are in.

I learned to interview for it differently. Less "walk me through your project management methodology" and more "tell me about a time the plan was wrong and what you did." I wanted to hear people reason under uncertainty, not recite a framework.

The process-followers are fine when everything goes to plan. Nothing at $40M and 13x growth goes to plan. You are hiring for the days it does not.

What I would tell someone starting from zero

Build the controls before you feel you need them, because by the time you feel you need them you are already behind. Standardise the boring parts without apology. Treat every report as a product with a user and a decision attached. Make your governance something delivery people are grateful for. And hire people whose judgement you would trust on the worst day, not the best one.

The PMO did not make us grow. The market and the product did that. But it is the reason we grew from $3M to $40M without the whole thing coming apart at the seams, and that is worth more than it sounds until you have watched an operation come apart at the seams.