Why Training in the Last Two Weeks Is Already Too Late

On most programs, training shows up as a line near the end of the plan. Build finishes, testing wraps, and someone books rooms for the two weeks before go-live to walk users through the new screens. It feels responsible. It is actually where adoption quietly dies.

By the time you are running those sessions, every decision that shaped how people work has already been made. The process is set. The configuration is locked. The reporting structure is baked in. You are not preparing people for change. You are informing them of a change that already happened to them.

Training is the last mile, not the whole road

Training answers one question: how do I click through this task. That matters. But it is the smallest part of getting people ready. It does nothing for the questions that actually drive adoption. Why are we doing this. What happens to the part of my job I was good at. Who decided this, and did they understand what I do all day.

When those questions go unanswered until the final sprint, people fill the gap with their own story. Usually it is a bad one. They assume the change was designed by people who do not understand the work, and they hold that assumption right through go-live.

What readiness looks like before build

Readiness starts before a single screen is configured. The work is not glamorous and it is not a workshop with sticky notes.

Map who actually does the work

Org charts lie. The person listed as owning a process is often not the person who keeps it running. Before build, you find the people who actually do the job, the ones with the workarounds and the tribal knowledge, and you talk to them. They will tell you where the new design is going to break in practice.

Name the real gaps

Compare what people do today against what the new process will ask of them. Not the tooling. The behavior. A change that removes a manual reconciliation someone has done for a decade is not a training problem. It is an identity problem, and it needs to be handled as one, early.

Bring operators into design

The cheapest time to hear that a design will not work is during design. Put the people who will live with the system into the review room while decisions are still open. When they shape the outcome, they defend it later. When they are handed it, they resist it.

What readiness looks like during build

Build is where most change teams go quiet and wait for something to demo. That silence is a mistake. The build phase is where you keep people close to the change as it takes shape.

Show work in progress, even when it is rough. Let the operators react to real screens and real flows, not slide decks. Every reaction during build is a problem you can still fix cheaply. Every reaction after go-live is a support ticket and an erosion of trust.

This is also when you build the local voices who will carry the change. Not a communications cascade. Actual respected people on each team who understand what is coming and can answer their colleagues honestly. When the change has a credible face on the floor, adoption stops depending on a memo from the program.

What the final two weeks should actually be

Do this work early and the training before go-live changes character entirely. It stops being an introduction and becomes a confirmation. People walk in already knowing why the change exists, having seen it take shape, having had their objections heard. The session is muscle memory on a system they already understand the purpose of.

Skip it and the pattern is predictable. Go-live produces a support queue. Productivity drops. Within weeks people rebuild their old workarounds on top of the new system, and the organization pays for a platform it never really adopted.

The uncomfortable part

Readiness work is harder to sell than a training plan because it does not produce a clean deliverable. There is no completion certificate for a well-run design review or a hard conversation with a team lead. But it is the difference between a system people use and a system people tolerate.

The technology was never the risk. The people who have to change how they work every day are the risk, and they need far more than two weeks. If the first time they hear about the change is in a training room, the outcome was decided long before anyone logged in.