Two Rollouts, One Lesson: The People You Bring In Early

Picture two companies rolling out the same system. Same vendor. Same implementation partner. Roughly the same timeline and budget. One of them absorbed the change and moved on. The other is still fighting it a year later, with a leadership team that quietly believes it bought the wrong software.

It did not buy the wrong software. It ran the wrong change.

The rollout that looked efficient

The first company treated the project as a delivery problem. There was a plan, and the plan was tidy. Configure the system, train the users, cut over on a weekend. The steering committee met, the vendor hit its milestones, and everyone could point to a green status on the dashboard.

The operators, the people who would live inside this system every day, entered the story about six weeks before go-live. They saw it in a presentation. By that point every decision that shaped their working lives had already been made. Which fields were mandatory. How an exception got handled. What happened to the small manual step that quietly held the whole process together.

Nobody had asked them, so nobody knew that step existed.

When the system went live, it collided with reality. The process assumed clean inputs that never showed up clean. The exception path that the software could not handle happened forty times a day. And the people, who had been handed a decision rather than included in one, did the rational thing. They kept the old spreadsheets alive in the background. They treated every gap as proof the thing was broken. Adoption flatlined.

Management read this as resistance. It was not resistance. It was the predictable response to being told instead of asked.

The rollout that looked slow

The second company started somewhere else. In the first month, before anyone argued about configuration, the work was to understand how the job actually gets done. Not the documented process. The real one, with all the workarounds people had built over the years because the documented process never quite fit.

That meant sitting with the operators and asking plain questions. How do you actually close this out. Where do you lose time. What would break if we changed step four. Which of your workarounds is a bad habit, and which one is holding the business together?

Those conversations changed the design. Not dramatically, but in the places that mattered. The exception path got built because someone who does the work every day said it had to exist. A field that would have been mandatory got made optional because forcing it would have created a new round of workarounds.

By go-live, the people using the system had fingerprints on it. When something went wrong, and things always go wrong, they did not reach for the old spreadsheet. They flagged the issue and helped fix it, because they saw it as their system, not one that had been installed on top of them.

The trade nobody wants to make

Here is the part that makes leaders uncomfortable. The second rollout was slower at the start. It looked less efficient on the plan. Bringing people in early always does, because listening takes time and the answers complicate the tidy design.

That is the trade. You spend a few weeks up front, and in exchange you get a system that survives contact with the actual business. Skip those weeks and you appear to move faster, right up until go-live, when you pay it all back with interest in the form of stalled adoption, shadow processes, and a leadership team looking for someone to blame.

Why this keeps happening

The pattern repeats because early engagement is easy to cut. It does not show up as a deliverable. It has no license cost. When a plan is under pressure, the discovery conversations are the first thing to get compressed, and the people work is the first thing to get pushed to "training" at the end.

But training at the end is not engagement. It is notification. Telling someone how to use a decision they had no part in is not the same as bringing them into it.

What to actually do

A few things hold up across every transformation I have worked inside:

• Find the operators before you finalize the design, not after. The people closest to the work know where it will break.
• Treat workarounds as information, not as failures to correct. Every workaround is a record of where the official process fell short.
• Give people real decisions to own, not just tasks to complete. Ownership is what turns compliance into adoption.
• Protect the early engagement time when the plan gets squeezed. It is the cheapest insurance you will ever buy on a program.

The technology in both stories was identical. The governance, the vendor, the budget, all comparable. The only meaningful variable was who got a say, and when they got it.

That is not a soft lesson. It is the whole game. Change moves at the speed of the people who have to live with it, and you decide early whether they are carrying the change or bracing against it.