Transformation Doesn't End at Go-Live

I once walked into a transformation project a week before go-live.

The project had been running for eighteen months. The team was about to deliver on time and on budget, and they were already planning the celebration. They had every right to feel proud. By the metrics that matter to most project managers, this was a win.

A week after go-live, more than a hundred issues had been logged. Basic user role permissions, the kind of thing that determines whether anyone can actually do their job in the new system, were not fully built out. The hyper-care period got extended, then extended again. Twelve months later, the technology roadmap was almost entirely about making the new platform operational. There was no budget for evolution. Some of the senior executives genuinely believed that once the project was live, no further work was needed. This was inside a heavily regulated environment where the rules change very frequently.

I was brought in to clean it up. I have been brought in to clean up versions of this story enough times to recognize it on sight.

Here is what I have come to believe.

The most common failure mode in transformation work is not technical. It is not even change management. It is the moment when a new leadership team walks into a long-suffering organization, sees everything that is broken, and decides to fix it all at once.

The pattern is almost ritualistic. New management. Long list of accumulated problems. Bold transformation announcement. Aggressive timeline. Lots of beautiful slides about the wonderful “future state.” And, of course, an optimistic budget.

What gets shipped, at the end, is a platform that delivers on a fraction of the promise, because the scope was always too ambitious, the budget was always too timid, and the calendar was always too tight. The team celebrates anyway, because by the only metrics anyone is tracking, they succeeded. Mostly on time. Mostly on budget. But, live!

Then the work actually starts. The work nobody planned for. The work that has no budget.

The mistake is to treat transformation as an event.

A platform implementation is an event. A go-live is an event. A signed contract is an event. None of these things is transformation. Transformation is what happens after, the slow accumulation of process changes, adoption work, operating-model adjustments, second-order discoveries, and ongoing recalibration that turns a new system into a new way of working.

The world that the transformation is responding to keeps changing, and everything else should be changing with it. Not six months from now. Not two years from now. Not five years from now. Now. One day at a time.

There are specific things you do differently when you take this view seriously.

The first is to refuse to commit to an implementation until the scope is concrete, the must-have requirements are well understood, and the Level of Effort, both time and cost, is assessed with at least 70% confidence. Not a hunch. Not a directional estimate. 70% confidence, signed off by the stakeholders who will own the outcome.

The second is to build a governance mechanism that lets the project flex without losing discipline. Things will change. They always do. The discipline is not in preventing change; it is in making sure every change goes back through the same stakeholders for explicit approval or rejection. No silent scope creep. No quiet assumptions. No surprises at go-live.

The third is to stop declaring victory at go-live. Build the post-implementation period into the project plan from the start. Name the adoption metrics you will track. Assign owners for the operating-model changes that the new system requires. Budget for the work that everyone in the industry has known is necessary for thirty years and that almost no one actually funds.

This is where being on the seam between business and technology earns its keep. The flaws that produce post-go-live chaos are almost always visible months before they cause damage. Someone has to be willing to flag them and slow the project down to address them. That someone usually has to speak both languages, hold both sets of pressures, and have the political weight to make the conversation happen.

The balancing act.

There is a fair pushback to everything I just said. Sometimes the world does not give you the luxury of incremental change. Sometimes the right move is radical change at speed, and the operator who keeps tightening bolts while the ground shifts is the operator who ends up perfectly optimized for a market that no longer exists.

The discipline is knowing when to apply which mode. Move radically when the strategic ground has moved, when a new capability has reset what is possible, when a regulatory change forces a step-function response. Move incrementally for the work that comes after, the sustained integration, adoption, and refinement that turns a radical bet into an operating reality.

The mistake is treating these as opposing philosophies. They are not. They are sequential modes of the same discipline. The companies that win are the ones that can recognize a step-function moment, move on it decisively, and then settle back into the steady tempo of making the change actually work. Both modes, applied at the right time, under the same governance.

This used to be a problem of large transformations. It is now a problem of every AI implementation in the field.

AI moves faster than any technology any of us have worked with. Models change. Capabilities expand. Tools that were experimental six months ago are production-ready now, and tools that look production-ready today will be obsolete in a year. The temptation to ship something, anything, and declare victory is overwhelming. So is the opposite temptation, to keep planning, keep evaluating, keep waiting for the dust to settle. Both are losing positions.

The companies that will get real return from AI are not the ones with the most ambitious launch plans. They are not the ones running the most pilots either. They are the ones whose operating models can absorb a moving capability frontier without breaking, who can recognize a step-function moment when it arrives, and who can return quickly to the steady work of making it operate.

A note on what all this produces.

The discipline I am describing is not about smoother implementations. Smoother is a side effect. The thing this discipline produces is implementations whose business cases actually materialize. The cost reductions that doesn’t kill value. The revenue streams that depend on the system actually being used. The risk reductions that hold up under regulatory scrutiny because the controls are real, not theoretical.

The system that is used is the system that delivers. The system that is not used is a sunk cost wearing the costume of a capability. Most transformation projects produce more of the second than the first. That is the real cost of declaring victory at go-live, and it is paid in the currency that matters most to the executives who funded the project.

It is not sexy.

This is the part where I should give you something inspirational. I do not have it.

What I have is a discipline. Small, daily, often invisible adjustments. The willingness to flag problems before they become disasters. The patience to stay with the work after the celebration has ended. The instinct to recognize when steady tempo is wrong and when radical movement is the only honest response.

It does not produce celebrations. It produces compounding returns. Most leaders prefer the celebration. That is part of why so few of them produce returns.

The work that lasts almost never looks like the work that gets praised. It is also, almost always, the work that wins.