Change management: why people don't use what you bought, and how to get them to use it

Key Takeaways

• Change management is the work of getting people to stop doing things the old way and start doing them the new way. Installing the system is the easy part. Getting people to use it is the project.
• People adopt a tool when they believe it helps them do their job. In the study behind the technology acceptance model, perceived usefulness mattered more for usage than ease of use (Davis, MIS Quarterly, 1989).
• Incentives can block a technology that works. In Pakistan, a tool that cut material costs was adopted by 5 of the 35 factories that received it for free, because cutters paid by the piece lost money using it (Atkin et al., Quarterly Journal of Economics, 2017).
• What gets adopted can also be dropped. Nine years after a successful intervention in Indian textile plants, about half of the new practices had been abandoned, mostly when the plant manager changed (Bloom et al., AEJ: Applied Economics, 2020).
• The famous claim that 70% of change efforts fail has no empirical support. Mark Hughes traced where it came from and found no valid evidence (Journal of Change Management, 2011).

A company buys a CRM, pays for the licenses, hires someone to configure it and runs a one-day training. Three months later the sales team is still tracking clients in a spreadsheet and on WhatsApp, and the CRM holds the same records it had on launch day. Nobody openly objected. They just don't use it.

The same scene plays out with ERPs, inventory systems, AI tools and new procedures. The problem is rarely the software. This guide explains what change management is, why people don't adopt what the company buys and how to get them to use it, drawing on studies rather than opinions. It is part of our guide to digital transformation for businesses.

What is change management?

Change management is the set of decisions and actions a company takes so its people move from the current way of working to a new one, and stay there. It applies to any change: a system, a process, a reorganization or a policy.

In technology projects it is often confused with training or internal communications. Both are part of it, and neither is enough. A salesperson who fully understands how the CRM works may still not use it if logging every call takes time away from selling and nobody looks at what gets logged.

That is why it helps to think about change in terms of behavior. The useful question is who has to do something different on Monday, what exactly, and what they gain or lose from it.

Why don't people use the technology the company bought?

People don't use a new technology when they see no benefit for their own work, when it costs them more than it gives them, or when the old way is still available and still works. Resistance is rarely irrational, and it almost always has a concrete explanation.

The most studied model on this is Fred Davis's technology acceptance model. In his 1989 article, Perceived Usefulness, Perceived Ease of Use, and User Acceptance of Information Technology, he measured with 152 users how much two factors weighed in the use of a system. Perceived usefulness correlated with usage much more strongly than ease of use. An easy system that solves nothing for the person using it stays idle.

There is another reason that gets less attention: the system may serve the company and not the person who has to feed it. The manager wants to see the sales pipeline. The salesperson has to log every interaction and gets nothing in return. If nobody fixes that imbalance, adoption depends on goodwill.

Software companies measure this too. Pendo, a company that analyzes application usage, reported in its 2019 Feature Adoption Report that 80% of features in the average software product are rarely or never used, based on data from 615 of its customers. It is vendor data and it measures features, not companies, but it shows that buying capability and using it are two different things.

Is it true that 70% of organizational change efforts fail?

There is no solid evidence that 70% of organizational change efforts fail, even though the figure is repeated in books, conferences and consulting proposals. Mark Hughes traced five of the sources that cite it in Do 70 per cent of all organizational change initiatives really fail? and concluded that none of them offers valid and reliable empirical evidence.

The figures on digital transformations published by consulting firms such as BCG or McKinsey are a different thing: they come from their own surveys of executives and measure whether the company believes it met its objectives. They are useful as a signal and should be cited with that scope.

The same goes for the figure most often used to make the case for change management. Prosci, the firm behind the ADKAR model, reports in its Best Practices in Change Management study (12th edition, 2023) that 88% of respondents who rated their change management as excellent met their project objectives, compared with 13% of those who rated it as poor. These are practitioners rating their own work. The relationship is strong, but it does not prove that one causes the other.

What change management models are there?

The three most widely used models are Lewin's, Kotter's eight steps and ADKAR. None of them is a recipe, and each one is useful for looking at a different part of the problem.

John Kotter published his eight steps in 1995 in Harvard Business Review, in Leading Change: Why Transformation Efforts Fail, as a list of the mistakes he saw companies make. Two of them show up often in technology projects: not planning short-term wins, and declaring victory too soon, when the system is installed but is not yet the normal way of working.

ADKAR is useful as a diagnostic. If people know why the change is happening but don't want it, the problem is desire, and more training won't fix it. If they want it and can't do it, what's missing is ability or practice.

How to manage change when implementing a technology, step by step

These seven steps work for a CRM, an ERP, an AI tool or a new process. They start before you buy and end months after launch.

1. Define which behavior has to change

For each group of people, write down what they will do differently: "salespeople log every quote in the CRM the same day", "the warehouse records outgoing stock in the system when it ships". If you can't write that sentence, you don't yet know what you are implementing. The process map is the starting point, because it shows who does what today.

2. Ask who wins and who loses with the change

Look at how each affected person is paid, measured and recognized, and whether the change increases their workload, lowers their income or takes away control. It is the question most often skipped and the one that explains the case in this article. When someone loses, you have to compensate them or redesign the change. Expecting them to accept it out of loyalty to the company rarely works.

3. Involve the people who will use it before you buy

The people who do the work know the exceptions, the shortcuts and what really takes time. If they help define the requirements and test the options, the system fits their work better and they feel it is theirs. Taken to the end, they are the ones who build the solution, as we explain in employee-driven digital innovation.

4. Show the value with each person's real work

Generic training in an auditorium teaches where the buttons are. What drives adoption is seeing, with your own cases, what you save or gain. Train by role, at the workstation and with real data, and leave someone from the same team as the go-to person for questions in the second week.

5. Close the old path once the new one works

As long as the parallel spreadsheet exists and managers keep asking for the report by email, the new system competes with the old one and loses. Set a date to stop accepting the old format, after confirming the new one handles the frequent cases. Closing it before that only pushes work outside the system.

6. Measure usage, not training

"100% of the team was trained" says nothing about adoption. Measure behavior: percentage of quotes logged in the system, weekly active users, reports management pulls from the system and not from another source. Look at those figures by group, because the average hides the area where the change never took hold.

7. Give the change an owner after launch

Launch is halfway there. Assign someone from operations, not from the project, to make sure the new behavior holds, and document the process so it doesn't depend on one person. The evidence from India shows why: when the manager who drove a practice leaves, the practice tends to leave with them.

Resistance to change: obstacle or information?

Resistance to change is often information about a real problem with the change. Reading it only as an obstacle throws that information away. Jeffrey Ford, Laurie Ford and Angelo D'Amelio made this argument in Resistance to change: The rest of the story (Academy of Management Review, 2008): the usual view puts all the blame on those receiving the change, when those driving it also create resistance through broken agreements, poor communication or changes they never explained.

In practice, when someone pushes back it pays to ask what that person knows that the project team doesn't. Sometimes it is fear or habit. Other times it is an exception in the process nobody considered, or a loss nobody saw. The case below is one of the latter.

Real case: the tool nobody wanted to use in Pakistan's soccer ball factories

Sialkot, in Pakistan, is a city known for making hand-stitched soccer balls. A group of economists led by David Atkin designed a new die to cut the synthetic leather pentagons with less waste. By their conservative estimate, it lowered the material cost per pentagon by 6.76% and total costs by about 1%, in an industry with average margins of 8%.

In May 2012 they gave the die for free to 35 factories. Fifteen months later, only 5 of them had used it to produce more than a thousand balls. When asked why, the reason owners cited most was employee resistance. Cutters were paid by the piece, the new die slowed them down at first, and the material savings didn't go to them. Some told the owner the tool didn't work.

So the researchers tried an adjustment. For one group of factories they explained the incentive problem to the owner and offered one cutter and one printer a one-time payment of about a month's earnings (150 and 120 dollars) if they showed the owner they could use the die competently. Of the 13 factories in that group that had not adopted it, 5 did so within six months. In the comparison group, none did. The results are in Organizational Barriers to Technology Adoption (Quarterly Journal of Economics, 2017), with an open-access working paper version at NBER.

The lesson applies to any company implementing technology. The tool worked and the owner wanted to use it. What held it back was that the people who had to operate it lost money with it, and you only see that if someone asks who wins and who loses, which is step 2.

The study by Bloom, Mahajan, McKenzie and Roberts in Indian textile plants shows the other side: change also has to be sustained. Nine years after a consulting intervention that raised productivity, the plants still held a large advantage over the control group, but about half of the adopted practices had been abandoned. A change of plant manager and less time from directors were two of the most cited reasons.

What changes when what you implement is artificial intelligence?

With AI, the adoption problem often shows up in reverse: people already use it on their own, with personal accounts, before the company decides anything. Change management then is less about persuading and more about putting things in order, with clear rules on what information can be used and with which tools. We cover this in the guide to an AI acceptable use policy.

The second challenge is judgment. An AI tool can be installed and used every day without anyone checking what it produces. That is why at Suricata Labs we talk about C³: curiosity, criteria and creativity, the capabilities that make adoption worthwhile. Buying licenses doesn't build them.

The seven steps in this guide apply the same way. To prioritize where to use AI, continue with how to implement AI in a business.

Frequently asked questions about change management

What is change management in a company?

It is the work of getting people to adopt a new way of working and keep it. It includes understanding who is affected, what each group gains or loses, how they are taught, how usage is measured and who is responsible for the change after launch.

What are the most common causes of resistance to change?

The most common are that people see no benefit for their own work, that the change adds workload or cuts income, that the old way is still available and that nobody consulted them. Fear and habit exist, but resistance often points to a real problem in how the change was designed.

What is the ADKAR model?

ADKAR is a Prosci model, created by Jeff Hiatt, that describes five conditions a person needs in order to change: awareness of why, desire to take part, knowledge of how, ability to do it and reinforcement to sustain it. It helps diagnose which of the five is holding a group back.

How long does it take a team to adopt a new system?

It depends on the change and the size of the team, and there is no reliable general figure. What you can do is measure actual usage every week from launch and not close the project until the new behavior is the norm and the old path is closed.

Who should lead change management?

It should be led by someone with authority over the operation that is changing, supported by people from the same team who act as go-to people. An outside consultant or the IT department can design and support it, but the change holds when the person running the daily work requires it and uses it.

Adoption is the part of the project nobody budgets for

Companies budget for licenses, configuration and training, and almost never for the time it takes to redesign incentives, close the old path or measure usage in the months that follow. That is where much of the value of what they bought gets lost.

At Suricata Labs we don't sell or implement software. We work with companies on what comes before and after: understanding the process with the people who do it, deciding which technology makes sense and getting the team to adopt it.

See how we work with companies | Schedule a conversation

Read also: Business process map: what it is and how to build one