Why Transformations Die Before Go-Live

There is a precise moment when a transformation program begins to die, and it is almost never the moment leadership notices.

It is not the failed integration test. It is not the slipped milestone. It is the day the people who will actually live the change hear about it for the first time, and they hear about it too late to do anything but comply. The platform is already chosen. The process is already redesigned. The timeline is already committed to the board. Their job, as they understand it, is to accept what has been decided for them.

Everything that goes wrong later traces back to that moment.

The comforting lie about technology

When a program fails, the postmortem usually blames the technology. The ERP was too rigid. The integration was harder than the vendor promised. The data migration was a mess. All of that can be true and none of it is the real cause.

Modern enterprise platforms work. They are proven at thousands of companies. If the software were the problem, no one would ever succeed with it. The uncomfortable truth is that the thing that most often breaks is the human system around the software: the people who have to change how they work, and whether anyone gave them a reason and a runway to do it.

Blaming technology is comforting because it is nobody's fault in particular. Blaming the change approach means looking at how leadership sequenced the work. That is a harder conversation.

Change management as a go-live task

Walk into most programs and you will find change management scheduled the way you would schedule training. It sits near the end of the plan. It has a small budget relative to the build. It gets a name like "organizational readiness" and a start date a few weeks before launch.

The phrase you hear is some version of "we'll handle the people side closer to go-live."

That framing guarantees the outcome. By the time the change effort starts, every decision that affects how people work has already been made without them. Communications become announcements. Training becomes a scramble to teach a process nobody helped shape. Adoption becomes a hope rather than a design.

A go-live event is a date on a calendar. Adoption is a behavior that has to be built over months. You cannot compress the second one into the week before the first.

The foundation, not the finish

Change management belongs at the front of a transformation because it shapes the decisions everyone else is going to build on.

Who actually does this work today, and what happens to their day when the new system arrives? Which leaders in the middle of the organization will either carry the change or quietly kill it? What does the business stand to lose in productivity during the transition, and how do we protect it? These are questions that change how you configure the platform, not just how you announce it.

When you answer them early, the technology decisions get better. Scope gets more honest. The timeline reflects reality instead of ambition. And the people expected to live the change help design it, which is the only reliable way to get them to own it.

What early actually looks like

Early does not mean a kickoff email. It means:

• Naming the specific groups whose daily work changes, before the design is locked.
• Putting a senior operator close to the executive sponsor so the people risk gets the same attention as the budget and the schedule.
• Identifying the managers who influence adoption and bringing them in while they can still shape decisions.
• Measuring readiness as a real signal, not a slide, and being willing to move the date when the signal is bad.

None of this is exotic. It is just sequenced correctly, which almost nobody does.

The test you can run today

If your program is well into delivery, ask one question. Do the people who will use this system every day feel like it is happening to them, or with them?

If it is happening to them, you do not have a communications gap you can close with a roadshow. You have a design problem, and the design problem is that adoption was never treated as part of the build.

The good news is that it is recoverable. Not by adding more training at the end, but by pulling the people work forward into whatever time remains and giving it the authority it should have had from day one. The cost of doing that mid-program is real. The cost of not doing it is a system that goes live on paper while the business keeps running the old way in the dark.

Technology gets the credit when a transformation works. People decide whether it works at all. Fund that accordingly, and start before you think you need to.