There is a predictable moment in enterprise technology programs where someone looks at the project plan and asks where the change management budget is. The answer is usually some version of: "We have communications. And we're doing training before go-live."
Communications and training are necessary. They are not change management.
Change management is the work of changing how people do their jobs. That is not a communications problem. It is not a training problem. It is an organizational problem, and it requires organizational effort, sustained, resourced, and started before the technical work is finished.
What change management is not
The conflation of change management with communications and training is understandable. Both are visible, budgetable, and produce deliverables. An email campaign generates sends. A training program generates completions. Both can be checked off a list.
What they can't do is address the deeper resistance that slows or stops technology adoption.
Resistance to new systems isn't irrational. People who have spent years developing expertise in a current process face a technology change that will, initially, make them slower and less competent. They will be measured by metrics they don't yet know how to hit. Their institutional knowledge, the workarounds, the judgment calls, the informal networks they've built, is of uncertain value in the new environment.
Telling those people the benefits of the new system doesn't change their experience of the transition. Training them on where to click doesn't address the anxiety about how their performance will be assessed while they're still learning.
What actually drives adoption
The organizations that achieve high adoption of new technology tend to have done three things that don't show up in standard project plans.
They engaged the skeptics early. Not to persuade them, but to learn from them. The people most resistant to a technology change are often the ones who understand the current process most deeply. Their skepticism is frequently specific: "this doesn't work for the exception cases" or "this assumes the data is clean, and it isn't." Those concerns are worth knowing about before go-live, when they can be addressed in the design, rather than after, when they become support tickets and workarounds.
They built internal advocates before they built the system. Every successful large-scale technology deployment we've been involved in had a group of end users, often called super users or change champions, who learned the system ahead of everyone else, helped shape its configuration, and then became the first point of contact for their colleagues after go-live. This isn't a training program. It's a network of credible voices within the organization who can say "I've used this, here's how it actually works, here's what I found hard and how I got past it."
They managed performance metrics during the transition. The fastest way to drive technology abandonment is to measure people against their pre-transition performance targets while they're learning a new system. The first weeks on any new enterprise platform are slower. That's not a sign of failure, it's an expected characteristic of behavior change. Organizations that don't account for it in their performance management create pressure to route around the new system, and the workarounds built in the first month are the ones that persist for years.
The timeline problem
Change management work needs to start earlier than technology programs typically allow it. Here is why.
The organizational changes required for a technology program to succeed, changes to roles, to processes, to how performance is measured, to how decisions are made, take time to design and implement. They can't be done in the last two months before go-live, when the program is focused on testing and cutover. They need to be planned in parallel with the technical design, because the technical design has implications for organizational structure that aren't apparent until you're looking at both at the same time.
A Salesforce implementation that reorganizes the sales operations function requires the reorganization to be planned, socialized, and agreed before the system is built around it, not after. An ERP deployment that changes how purchase approvals work requires the approval authority matrix to be updated before the system enforces it.
These are not technically difficult things. They are organizationally difficult things, and they require the sustained attention of people with the authority to make them happen. That attention costs time. And it cannot begin the week before go-live.
The honest conversation
The change management budget conversation is uncomfortable because it surfaces a tension that most technology programs avoid making explicit: the technology program is not actually delivering a system. It's delivering a change in how the organization operates, for which a system is the enabling tool.
That framing matters because it places accountability differently. A technology program that delivers a working system is not automatically a success. A program that changes how the organization operates, and can demonstrate that change, is.
The question worth asking at the beginning of any significant technology initiative is not "when does the system go live?" It's "when will the organization be operating differently, and what does that look like?" If the answer to the second question is unclear, the program isn't scoped correctly yet.
