Every few years, your operating model gets redesigned. A consulting firm is engaged, a new target operating model is designed, workstreams are stood up, and a transformation program runs. This time, everyone believes, it is the right one. Eighteen months later, the program closes, the consultants leave, and the organization moves forward with a new structure and a new set of processes.
But the same problems continue to surface. Someone decides the operating model was not right and it needs to be revisited. A new consulting firm is engaged. The cycle repeats.
Leaders who have lived this more than once eventually ask the right question, rarely out loud: who confirmed the last model was correct, and who monitored it to make sure it remained correct?
The Pattern Has a Structure
The TOM cycle is not random. A business problem becomes visible: growth stalls, costs climb, a competitor moves faster, or an acquisition lands and the integration strains the existing model. Leadership engages a firm to diagnose it. The firm provides that diagnosis, and leaders, without independent operating data to assess it against, accept it. A redesign is commissioned.
The redesign is usually competent. The new model is logically sound. Roles are clarified. Process owners are named. A rollout plan is executed.
And then the program closes.
What happens next is not dramatic or new. People keep working. Managers keep managing. But the cadences that were supposed to catch drift, if they were ever fully established, fade. Any governance structure that existed on paper was never truly operationalized, so there is nothing enforcing it and nothing to signal when it stops holding. The model starts to drift: slowly, quietly, without a single moment anyone could point to as the turning point.
By the time the drift is visible, the assumption is that it is a structural problem. The model itself must be wrong. The case for another redesign builds, not because the last one was poorly designed, but because the real question was never asked: was the model still capable? That question requires data. And the data was never collected.
The redesign is not the problem. The absence of any function responsible for monitoring whether the model was still working is what produces the cycle.
What the PMO Was Never Designed to Do
When a transformation program runs, the PMO manages it. That is the right use of the function. The PMO governs projects: defined scope, defined timeline, defined deliverables. When the program closes, the PMO moves on. That is also how it is designed to work.
Transformation Management Offices have the same constraint from the other direction. TMOs are program vehicles, effective at driving a defined transformation. But they are designed to wind down when the program ends. The moment the TMO closes is typically the moment the operating model most needs governance: newly deployed, not yet embedded, and most vulnerable to drift.
The operating model has no end date and no defined deliverable. It is a system that is supposed to produce consistent performance over time, and performance over time requires governance over time. Neither the PMO nor the TMO was built for that. When both wind down, accountability simply ceases. There is no handoff because there is no function to hand off to.
What Project and Program Managers Already Know
CEOs see this pattern at the portfolio level. Project and program managers see it from the inside.
The same conditions surface in new projects that were addressed in previous ones. Issues that were scoped, worked, and closed reappear with different names. Not because the project work was poor, but because no function was monitoring whether the conditions that enabled the solution were still in place after the project team was gone.
Project and program managers who have worked across multiple initiatives in the same organization recognize this quickly. The work gets delivered into an environment that was not designed to sustain it. Without a function responsible for watching the model between engagements, the gap between what was built and what is actually operating widens over time, invisibly, until it is large enough to justify the next initiative.
The question is not whether the project delivered. It is whether anything was governing the conditions required for it to hold.
The Missing Layer
The gap between what the PMO governs and what the operating model requires is structural. It is a function that does not exist in most organizations but should.
That function operates like a standing process audit: periodic, evidence-based assessment of whether the model is still performing and still appropriate, not just whether it was implemented correctly. It needs to do three things continuously:
Monitor the model for signals of shift and drift.
Not every change in performance means the model needs replacing. Some variation is operational. Some is structural. A governance function that distinguishes between the two prevents the misdiagnosis that triggers unnecessary redesigns, and catches real drift before it becomes a crisis that justifies the next consulting engagement.
Ensure the tools and structures serve the managers who own the model.
Governance that creates friction for the people operating the model will be quietly worked around. The question is not whether the governance structure was well designed at launch. It is whether the managers responsible for daily execution find it useful, legible, and worth maintaining. If they do not, drift is not a discipline problem. It is a design problem.
Govern whether the model remains fit as the business environment changes.
A model that was correct at launch can become incapable without anyone making a bad decision. Markets shift. The organization scales. Acquisitions land. The standing governance function assesses not just whether the model is being followed but whether it is still the right model, and routes that question to the right level of the organization before the next external diagnosis does it for them.
The Operating Model Office
What that function looks like in practice is an Operating Model Office: a permanent governance layer, sitting above the PMO, whose job is not to run projects but to govern whether the operating model is working and make changes as the business environment changes.
The OMO is not a transformation program. It does not replace the PMO or the functions that own execution. It provides the decision architecture that the PMO was never designed to provide: continuous monitoring for model drift, structured feedback loops that keep governance useful to the managers who depend on it, and the standing capability to assess whether the model is still capable, not just whether it was correctly implemented.
In organizations that have process owners, documented processes, and reporting cadences in place, an OMO with clear intake criteria moves faster than the informal prioritization most organizations run today, because decisions are made on evidence rather than escalation, tenure, or whoever is loudest in the room.
The TOM cycle repeats not because the redesigns are wrong. It repeats because the infrastructure to govern the model after the redesign does not exist. The Operating Model Office is that infrastructure.
Is the operating model still capable, and is anyone accountable for the answer?
Most organizations ask whether their transformation program was successful. That is the wrong question, asked at the wrong time, answered too soon. If no function owns the answer twelve months after the program closed, the first question does not matter.
Is your operating model governed or just documented?
A 30-minute strategy conversation is enough to assess where the governance gap lives in your organization and what it would take to close it.
Schedule a Strategy ConversationPart of an ongoing series on operational design, process transformation, and what it takes to make change endure.