GitaCloud

Change & Adoption

Adoption Is Not Training. Adoption Is Operating Model.

By A GitaCloud Principal·February 22, 2026

The two-week training course at the end of an implementation is the most expensive mistake in enterprise software. We retired it. Here is what we do instead.

The two-week training course at the end of an implementation is the most expensive mistake in enterprise software. It is the most expensive because it is the cheapest line item — somewhere on page seven of the program plan, signed off without examination — but it determines whether everything that came before delivers any value at all.

Here is what actually happens when adoption is treated as training. The implementation ships on time. The training happens. The planners attend the training. The planners go back to their desks. Within four weeks, three things appear: the parallel spreadsheets are back, the platform’s recommendations are being ignored, and a quiet narrative spreads through the planning organization that the new system “doesn’t really understand our business.”

None of that is true. But once it spreads, it becomes structurally true, because no one is using the system, so no one is feeding it the corrections that would make it sharper, so its recommendations stay slightly off, so no one wants to use it. The platform’s value erodes silently. The program is declared a success because it shipped on time and on budget. The CFO never sees the lift.

We retired the two-week training course five engagements ago. Here is what replaces it.

01Day-in-the-life designs before configuration.

We do not begin configuring the platform until we have designed how every decision-making role spends its day on the new system. Down to which screen they open first on Monday morning. Down to which exception queue they triage before lunch. These designs are co-built with the planners who will use them — not delivered to them at training.

02UX prototypes by week six.

We do not show planners a working system at week twenty-two. We show them a prototype at week six. They click around. They complain. We change things. We do this five more times before the platform is even built. By the time the real system shows up, they have already shaped it.

03Co-testing throughout sprints.

Planners are in the sprint reviews. Not at the end. Every two weeks. They see what was built, they break it, they ask for changes. User Acceptance Testing becomes a formality because UAT is a checkpoint, not a discovery.

04Enablement materials built alongside the build.

The playbooks, the SOPs, the day-in-the-life guides — these are produced during the build, by the people doing the build, not by a documentation team translating after the fact.


The cost difference between this approach and the two-week training course is real but small. The value difference is the entire program. We have never had a major adoption issue at go-live. Not once. That is not luck. That is what happens when adoption is treated as operating model design, not as training.


More from Insights

Talk to a principal about this.

Start the conversation

← All insights