Why PMO as Code: the PowerPoint-and-email PMO fails.
Today's PMO runs on PowerPoint, Excel, SharePoint, and email. Every artifact is stale by the time anyone reads it, and the approval trail lives in inboxes.
Four tools and no source of truth.
A portfolio runs across PowerPoint decks, Excel spreadsheets, SharePoint wikis, and approval email chains. The four never agree, none is authoritative, and each is somebody’s best guess at what was true last Thursday.
Problem 1: stale on arrival.
A deck takes hours to build. By the time it’s distributed, the schedule has slipped, the budget number has changed, and the risk that was escalated yesterday isn’t in it. The act of creating the artifact is the moment it becomes out of date.
The staleness is built into the architecture. A hand-maintained artifact can only reflect what its author knew at save time, and nothing keeps it current because the data it summarizes lives somewhere else entirely.
Problem 2: RAG is self-reported fiction.
Every PM in the portfolio decides whether their project is green, amber, or red. The criteria are informal and the incentive is to stay green, so the dashboard stays green until something fails in public.
Amber means whatever the PM wants it to mean this week, and red requires a difficult conversation. The system is least likely to produce the one signal that matters.
Problem 3: governance you can’t audit.
A stage gate amounts to an email in which someone forwards a deck and someone else replies “approved.” Three months later, no one can find the thread, no one agrees on what was actually approved, and there’s no record of what conditions the approval was contingent on.
When an auditor or a postmortem asks “who approved this, and under what conditions?”, the answer is “we think it was Dave, in an email, sometime in March.” Auditors know the difference between a record and a guess.
Problem 4: the army-of-PMs tax.
In a mature portfolio, much of the PM headcount maintains the reporting layer above the projects. Someone collects status from each lead, and someone else turns it into slides for a meeting about the slides. None of this is project delivery.
PMO as Code removes the collection step. Status is derived from the documents, so the reporting layer has nothing left to assemble, and the PM’s job returns to running the project.
Why I wrote this.
My career began in development. I did some interesting things in the non-profit sector, corporate media, and then federal space. I eventually wound up kicking off a DevOps movement at the White House Communications Agency, before spending the next several years consulting with Fortune 500s around the world on their development practices. That path led me to a position over delivery modernization at Freddie Mac, and on to running my own company teaching others how to get on top of AI readiness.
Now, I lead the PMO at a Fortune 200, and I bring a lot of expectations with me.
In engineering, the truth always lives in the source. Every change is tested multiple times before it is deployed, and real-time monitoring shows the state of the whole as it truly is. Nobody ever has to ask the deployment how it feels about the way things are going. Stuff is either working or it isn't, and when done properly, the stuff not working never makes it out to the customer.
Project and portfolio management, on the other hand, have always been much more subjective. Numbers are usually collected by hand, entered into a Gantt chart or pointed to a backlog, and invariably make their way into some status deck to hand off to leadership. The insights that may be garnered are usually out of date by the time anyone reviews them, and inaccuracy is almost treated as a feature. Why show red when green is such a more calming color, right?
The automated development discipline I spent twenty years helping install around the world always seemed to stop just outside of the PMO's door. PMO as Code is an answer to that problem.
If you view documents as the source for the PMO system, a lot of engineering practices and parallels begin to apply. Document pipelines can test every structural change just like code is unit tested. Modern LLMs can judge whether a requirement actually serves the goal it claims to, just like infrastructure monitoring judges a service against its thresholds. Project status can be derived from core documents the way a binary is built from code. And reconciliation loops keep the delivery boards converged with the documents, the same way GitOps keeps a cluster converged with its manifests. When something drifts, the system notices before I do.
On my own portfolio, when an automation flags a project amber, the public dashboard says amber, and nobody gets to change it for a slide deck.
The world going AI native is what makes this approach an urgent need instead of merely the right way to do things. AI-assisted delivery moves faster than any hand-assembled report can describe, so the choice is a reporting layer that compiles in seconds or outdated insights that were overtaken by events before they even got manually updated.
Whether PMs will trade away their curated plans and polished decks for raw Git and Markdown is a question yet to be answered, but I'm providing the thoughts and tools necessary to get started for free right here, and all feedback is welcome. I'm keeping it all public and open: the tool and the standard are Apache 2.0, free to adopt if you choose.
John Tanner
What comes next.
The principles name the five defaults behind the response, and the artifact crosswalk maps each problem to its as-code equivalent. The case study shows the whole approach against a real document set.