IS implementations routinely underinvest in change management. The technology budget gets line items. The people budget gets a rounding error.
A few years ago I read through a post-mortem report for an ERP implementation that had gone badly. The project had a detailed budget: software licenses, hardware, integration work, consultants, training sessions. Each line item was documented with real numbers and a justification. When I finally found the change management budget, it was a single line: "communication and adoption activities, $15,000." The implementation itself had cost millions.
This is not unusual. In my experience reading about IS implementations and the research around them, the pattern repeats: technology spending gets detailed attention, and the work of actually helping people change how they work gets what is left over, which is usually not much.
The gap matters because the technology is rarely what fails. The ERP system in that report worked fine technically. It processed transactions correctly. The integration with the old system was messy but functional. What went wrong was adoption. Months after go-live, a significant portion of users had reverted to workarounds, shadow processes, and in some cases the old system running in parallel because "it is just easier." Nobody planned for that outcome. Everyone was surprised by it anyway.
Kotter's (1996) 8-step change model is one of the most widely cited frameworks in organizational change management practice. His argument, at its core, is that successful change requires more than a good technical plan. It requires creating urgency, building a guiding coalition, developing a clear vision, communicating that vision consistently, removing obstacles, generating short-term wins, consolidating gains, and anchoring the change in culture. These steps are sequential and interdependent. You cannot skip to step six without doing four and five. The model is commonly referenced in management consulting and change management literature, and while I have not found it in the IS academic literature with the depth that, say, Rogers or TAM appears, the logic maps directly onto the IS implementation problem.
Kurt Lewin's older and simpler model describes change in three phases: unfreezing (disrupting the status quo), moving (making the actual change), and refreezing (stabilizing the new state). What strikes me about this model is how much it emphasizes the phases that are not the change itself. Unfreezing and refreezing together represent the organizational work that surrounds the technical change. IS implementations tend to focus almost entirely on the "moving" phase: installing the system, migrating the data, configuring the workflows. The unfreezing work, helping people understand why the old way is no longer adequate, and the refreezing work, making the new way normal, are consistently underinvested.
The Prosci ADKAR model, widely used in IS change management practice, makes a similar point more granularly. ADKAR stands for Awareness, Desire, Knowledge, Ability, and Reinforcement. The model describes five things a person needs to go through before they will actually change their behavior. Awareness means understanding why change is happening. Desire means wanting to participate. Knowledge means knowing what to do in the new system. Ability means being able to do it. Reinforcement means having support that makes the new behavior stick. The typical IS implementation invests heavily in Knowledge and Ability through training, but often skips Awareness, never earns Desire, and provides almost no Reinforcement once training ends.
I think the underinvestment in change management comes from a measurement problem as much as anything else. "Go-live" has a specific date. The system is either installed or it is not. That date is concrete, reportable, and easy to plan around. "Adoption" is a continuous variable with no clean endpoint. It is harder to measure, harder to report upward, and harder to justify spending money on before the system is live. By the time the adoption problem is visible, the project is technically "complete" and the budget has been released.
According to Gartner research on enterprise technology adoption, the gap between technology deployment and realized business value is a consistent finding across digital initiatives, and organizations routinely underestimate the change management investment required to close that gap. Gartner has noted this pattern across enterprise software implementations for years (see https://www.gartner.com/en/newsroom for their current releases on this topic). I want to be careful not to overstate specific figures here, but the direction of the finding is not controversial.
What I find interesting is how resistant organizations are to this lesson even when they have experienced it directly. Organizations that had a painful ERP implementation with poor adoption often go into the next implementation with essentially the same change management budget as before. The lesson from the post-mortem is that the training was insufficient. The response is to add more training hours. But ADKAR would suggest the problem was not training. It was Desire and Awareness. More training hours does not fix "I don't understand why we're doing this" or "I think this system is making my job worse."
Resistance to change is real and documented in the IS literature as a predictable factor in implementation outcomes. What is less often discussed is that resistance is usually rational. People resist because the new system genuinely is harder to use in the short term, because they do not understand the benefit to them specifically, or because previous technology changes in their organization did not deliver what was promised. That history is context, and change management that ignores the history usually fails.
The most effective change management approaches I have seen described in the literature and in practitioner accounts have a few things in common. Leadership is visibly committed and explains the why, not just the what. Employees have real participation in the implementation process, at minimum in how the system gets configured for their specific workflows. And there is genuine investment in the period after go-live, when adoption behavior is being formed.
The hard part is that all of this costs money and time, and the ROI is not as clean as "we installed the system." But implementations that skip it keep producing the same post-mortems. Eventually, somebody has to write the $15,000 line item a lot larger.