February 2, 2020  by

How to handle change resistant users

 

In this article I will explore how an organisation can address Change resistant users.

Understanding why users are resistant to change is a complicated matter. In the end only you and people in your organisation will be able to fully understand the nature of the resistance. In this article I will touch on why I think users are resistant to changes in technology and a few ways to remedy the situation.

 

Why are some users resistant to changes in technology? 

In my experience as an IT Consultant, there are numerous reasons why people are resistant to changes in technology. The simplest and most broad sweeping reason I can give, is that change induces anxiety, the fear of the unknown, and most people aim to avoid that. Another reason I’ve come across is that existing users are good at what they do. Big change means their current skills and knowledge will become redundant. Existing users will need to learn new skills and will therefore become less skilled in comparison to their peers. Some of these users may not care to learn new skills. This is especially true if the driver for change does not directly benefit the user. The benefit might be an increase in profit for the owner or a competitive advantage over competition. This is why as a project team it is important to know the driver and objective of the project. Goals that don’t address user problems, will generally mean less buy-in from users.

 

Change induces anxiety, and everyone is trying to avoid this.

 

A project team shouldn’t see change resistant users a major blocker or get annoyed with them. The approach needs to be one of patience and understanding. End-users are stakeholders after all, their opinion can be very useful in affecting big change. Integrating IT into the business realm and vice-versa is important, so as not to create an adversarial relationship. In an organisation where IT is not a key player, IT is often viewed as a necessary evil. The development or IT team often have to say ‘no’ to business requests. And the business teams don’t understand why. This kind of relationship are the seeds to resistance. 



Strategies for approaching change resistant users.

Each of the following strategies are for different purposes, there is no one-size-fits-all. 

Early engagement

When a project is going to take several years, with 100’s of iterations and releases, it is important to have end users involved early and frequently. This can be done during the initial discovery phase. And in particular during major sprint product demonstrations. They could be consulted in creating or running User Stories. See my article on User Story Driven Application Development for more information on this process. Having users engaged early will give an emotional investment and connection with the change. Often, only the development team and project sponsor feel this connection, because they can see themselves in the output and the project outcome can have big impacts on them personally. 

Organic change

Another approach to minimising the change impact on users is to make change organic. What I mean by this is that users shouldn’t even realise that change is happening or it will be so greatly welcomed, it won’t feel like a burden. This kind of approach should be taken if change is constantly rolled out. Either as a large scale transformation project or change is just a constant part of your internal IT service delivery. Here are some tips on delivering organic change:

1. Have regular training courses and introduce the new changes. 

2. Deliver changes in small iterations and ensure they are released on time with zero defects. Also clearly explain the benefits.

3. This kind of change is often seen in regular version upgrades or patches. For example, a mobile app or video game. Users will be forced to update their software, always in a streamlined way. They may not even realise what changes have been made. It becomes a normal and expected occurrence, with details of the changes outlined clearly in the developer/release notes.

 

In this example, the development team can release changes in a streamlined fashion. Users understand that a change has occurred and can clearly see what changes have been made. They can chose to update or not, however it is always wise to update. Especially if you are using an open source product. As updates can be related to security. Changes in this instance can be incremental and are more organic.

Big bang

The last approach is probably for rare circumstances. A big bang approach would see a large amount of change coming through to users quickly and without much notice. This would mean users will either adapt to the change or not. It can be quite unpredictable. This kind of change would be for medium size user cohorts. Ones that are capable of handling change and have a willingness to learn. Not including users and releasing change all in one go, would probably be due to time constraints. For example, a change needs to be made due to changes to law and there is no time or need to consult users. The change must be made regardless of what users want or need. 

 

Overall recommendations

There are some overall things you can do as a management team or project team, to make changes in technology more easily digestible for your organisation and users. 

  1. Foster a culture of resilience and change early on. Hire people who are tolerant and can embrace change. 
  2. Be transparent with why the change is happening and all stages of change. 
  3. Introduce the concept of Change Champions, who will promote the change at pilot sites.
  4. Include users, especially Subject Matter Experts (SMEs) at the right stages of the project. Users are needed at all stages of development or every meeting. The key stages you will need them is; in the discovery phase, product demonstrations and User Acceptance Testing (UAT).
 
in Change Management 2 comments