“Innate resistance to change, lack of involvement in the implementation process, lack of management support, poor technical quality which makes the system appear ‘unfriendly’, and the lack of interaction between the designers and users…all of which will contribute to the demise of a software project”
It’s a fact: some people like change and others don’t. And we also know this about change: it is inevitable. Everything around us is changing right this moment. The change might be gradual but it is happening.
A change not so gradual is a software implementation. Compared to how slow changes take in our lives, implementing new software is a rapid change. Maybe this is why so many people don’t like new software implementations within the company — the change is too much at once.
But that’s just one of the many reasons people resist a new software application.
It’s also just one of the many ways your project can get derailed. In this blog post, we’ll examine why users resist adopting to new software and what you can do to help get them on board.
Types of Resistance
Resistance to the new system will fall into the following categories: active resistance and passive resistance.
Active resistance is openly questioning the reasons for bringing in new software. Also communicating to others a lack of the underlying need for making a software change in the organization.
How to spot people actively resisting the system: you’ll see them chatting with co-workers and voicing their opinion against the new system. They will try to get others to rally and join the cause. In more extreme circumstances, he or she may leave the organization in protest to the new system (the same way in which Jerry Maguire made his legendary exit).
Passive resistance is a little more difficult to detect and may take time to uncover those who are passively resisting the system. Why? People may actually express support for change, but when change is getting closer to being implemented, resistance starts to come through.
How to spot people passively resisting the system: users who are “faking” their way through the project. These individuals may seem happy to see you and willing to use the system but once you turn your back on them, they quietly undermine the project’s success. Make strong connections with your superusers/subject matter experts and rely on them to provide you with intel on the passive resisters.
Strategies to Overcome Resistance to the New System
In a moment I’ll list some of the common things to look for during an implementation which contribute to user resistance.
But before doing so, we need to cover two types of strategies to help you conquer user resistance.
James Jianga, Waleed A. Muhannab and Gary Kleinc conducted research on user resistance and how to promote acceptance of the system. To overcome resistance, researchers have proposed a variety of strategies, which can be classified into two categories: participative and directive.
Participative strategies include:
- Training in the use of the new system
- Establishing user support services
- Allowing time to experiment with the new system
- Praising new system use
- Encouraging open communication between management and employees
- Incorporating user participation into the design process
- Documenting standards for the new system
If you’re a consultant or project manager working on a software implementation project right now and you haven’t included any of these strategies, you had better sit down and figure out how you’re going to apply as many of the strategies as soon as possible. User participation is priority 1.
Directive strategies include on the other hand, are those imposed by management:
- Provision of financial incentives for new system use
- Job reassignment
- User rights directives
- Role modifications
- Job elimination for those who do not learn to use the new system
- Power redistribution
- Top management support
- Job title modification
- Job counseling
If you’re a manager at a company implementing new software, time to do some assessments on your organization. Be sure to meet with your project leads and/or consultants to get a feel for how people are reacting to news of the new application. Also be sure to have the project leaders identify any users who are either passively or actively resisting the system.
Top Reasons for Resisting the New System
Let’s have a look at some of the top reasons people resist switching to the new software system and see which types of strategies we can apply to help us overcome user resistance.
Love for the legacy system
Are users still lovin’ on the legacy system? You know, the old one you’re trying to replace?
It’s very common to have people latch on to something familiar while rejecting something unfamiliar to them (the new software system). Especially if you have had this old system in place for a long time.
But to steal a line from the popular Semisonic song Closing Time, “Every new beginning grows out of some other beginning’s end.”
When it comes to transitioning to the new system, it’s best to severe ties with the old system ASAP. As in the day you go live with the new system, the old one gets shut down.
You might be asking how you fix data in the old system if it is turned off? I mentioned cutover in this blog post as something needing to be well planned in Phase 4 of the training and implementation plan.
You’ve got to have a solid cutover plan to be able to leave your legacy system behind.
Send your last invoice from the old system. Ship the last customer order from the old system. Close the books one more time in the old system.
LET IT GO
If there’s an invoice or customer order needing to be fixed after you have transitioned to the new system, you’ll have to make the fix in the new system.
Personal Story: when I was rolling out Oracle Projects, there were some invoices sent in the old system but the customer came back to us and told us there was an error on the invoice to be corrected.
To do this, we had to first cancel (void) the invoice in the old system. Only a handful of people in accounting still had access to this legacy system and we had to work with them to get it voided.
Afterward, we created the correct invoice in the new ERP system and sent the revised invoice to the client.
You have got to have this type of plan in place when you cutover to the new system.
But what about people? How do you get them to let go of the old system?
Specifically, start creating proficiency tasks to encourage system use and familiarity. Then praise those who have successfully completed the tasks. Also begin conducting monthly web meetings and status calls to encourage open communication between management and employees.
Without being privy to the situation, these directive strategies will be at the discretion of the management team and the employee’s direct manager. Everyone involved will want to work closely Human Resources to ensure everything is being handled appropriately for some of the more stringent strategies being applied.
A General Loathing for the New System
A user’s resistance to change from a system they have used for years can quickly turn into a roadblock during your implementation. This usually happens because the processes involved in the new system are very different from the legacy system.
Especially when implementing ERP behemoths like Oracle and SAP.
The new system may require accessing additional screens, more mouse clicks, etc. When it comes to an ERP system, it uses a centralized and integrated database with more controls on processes, thus needing more checks, interlocks and database postings, when compared to the old system.
This gives the impression (or it just might be true) the ERP system is slow and users, who may already be resistant to the change, often start complaining.
So how do we handle this situation?
First let’s look at why the user is being resistant to adopting the new system. Here are some common reasons along with an explanation:
| Reasons for Resistance | Explanation for Resistance |
| Parochial self-interest | Resisting change to prevent losing something of value |
| Misunderstanding and lack of trust | Misconceptions about the implications and insufficient information of the benefits and gains |
| Different assessment | Employees see more costs than benefits and those initiating the change see the reverse as true |
| Low tolerance for change | Fear of not sufficiently developing the skills and behavior required |
| Increased efforts | Additional efforts or abilities needed for the job |
Where does your particular user(s) reside in the table? Once you have identified the reason and the explanation work on getting him/her back on track.
Again, start creating proficiency tasks to encourage system use and familiarity. Then praise those who have successfully completed the tasks. Also begin conducting monthly web meetings and status calls to encourage open communication between management and employees.
Anytime you feel the need to “lay down the law” with these directive strategies, be sure to include appropriate management and human resources when applicable.
Often you’ll see users who have been in the legacy system for some time being the ones giving you grief.
Depending on the person you could expect red herring excuses when these users are confronted with their lack of user adoption. These are your passive resisters.
Be prepared to put in extra effort with these resisters in order to get them to support the new system. With some persuasion and extra coaching, most of them can be brought around.
Recognize you are probably going to have a few hold outs who will only respond to the stick side of a carrot and stick approach. You need to be supportive of people going through the change, but not at the expense of jeopardizing the project.
An ERP study by Sayeed Salih, Ab Hussin and Halina Dahlan from Universiti Teknologi Malaysia revealed 55.8% of users indicated a lack of user training and education as the reason for resisting the change the new system.
Their study also showed the relation between the knowledge transferred by the ERP consultants during and after implementation to the end users and a 10 step process could solve issues for user resistance.
Keep in mind user training should not be limited to the system features. It should serve as a need to educate users about the system and how they contribute to it.
Always operate with this in mind: how will this affect my users? Will this feature enhance the user experience or allow them to be more efficient in their job?
When it comes to software it is ALWAYS about the user.
Not involving users in the design phase
Often organizations do not involve key users during the implementation process or seek their active support before embarking on a software implementation. If you’re not involving the users early on in the design (or build-out) phase, you’re just asking for trouble.
When conducting software implementations there are “Prerequisites” to be completed. One of them is meeting and learning from the experts in the organization — the business process experts. When you meet with them, the goal is to sit down and document all the business processes this expert is responsible for.
Then build a test instance of the software you are launching to validate the configuration meets the needs of the users. This gives them time to experiment with the new system.
And you are getting key users and stakeholders involved early and often. If a new system is implemented like a routine software upgrade, then it will only result in a half-hearted acceptance of the system.
Big ERP implementations require lot of pre-implementation activities like: process modeling, process mapping, etc. These activities require extensive interaction with key users.
It not glamorous, nor fun, but it’s GOT to happen. These are very critical steps to the success of your software launch.
If you’re working on a project and have not involved any users in the design process, stop what you are doing and go meet with the appropriate individuals.
And when documenting the processes, keep it simple. Like this:
In this case, there are no directive strategies to apply from a management standpoint. This issues is to be resolved by the project team.
Lack of top management participation
In all of my findings on software implementation failures, this reason always sits at #1.
There’s just no way around it: a lack of top management support will prove to be fatal for your software implementation project.
It’s pretty simple. If management is not going to support the new system why would the users? People will either see, or get word, management is not 100% on board and no one will bother to participate in the project.
Why doesn’t management support a software project? Often a software implementation project is seen as an IT project rather than a business project and as a result, top brass of the organization refrain from actively participating in the implementation process.
This is why an IT driven implementation is sure to fail.
In smaller firms it’s not as prevalent simply because the CEO is closer to ground operations and thus has an interest in seeing the project succeed.
With larger firms, it’s important to monitor how meetings and corporate communications are being handled (email, TV, blog, posters, etc). This usually provides insight to how well the project is being supported. If it’s like crickets in the organization, then there’s a problem. What strategies can applied here?
The list may seem like something you’ll do for the users but you’re actually going to apply them to the management team. How? By showing them exactly how you plan to do each one of the listed strategies during the project. With management knowing they have a solid plan in place, they will be more likely to support the initiative. Do this early on. As in yesterday.
However, you could potentially do the same thing as the participative strategy if you are asked “what will you do if users resist?”
In reality, top management needs to be properly engaged early on so they can “sell” the project to the rest of the organization.
If they aren’t selling for you, then you have a tough road ahead. But all is not lost.
There are two things you could do immediately if you’re in the midst of a project and management still hasn’t bought in:
- Revisit your project plan and make realistic changes to it. If there are resources unavailable or interruptions in the timeline, make changes and notes
- Have a forum/venue to share this updated plan (like a steering committee or governance board meeting)
This is the forum you should use to raise issues around resource availability and to highlight any negative effects on the project.
Why? The steering meeting is typically attended by the project sponsor (who should be one of the senior management team). The role of the sponsor is to support the work of the project manager and to assist in the resolution of contentious issues.
This is where honesty and integrity come in. Be absolutely clear with them as to what is going on with the project so a solution can be found.
Side note: If you’re part of top management or can influence top management, here’s a reference table of “what not to say” during an implementation.
| Do Talk About | Don’t Talk About |
| Larger deals/contracts | Higher productivity |
| Happier customers | Tighter management |
| Less wasted effort | Automation |
| Improving business processes | Job elimination |
| Achieving goals easier | Leverage |
| Giving employees tools they need to succeed | All-inclusive system |
If employees get the feeling you’re bringing in new software to unify the company and make it more coherent and coordinated, they will follow your example.
But if they sense you’re going to use the system to lay blame or fuel political battles, they will subtly sabotage the system as they would any enemy. Instead, celebrate the small wins you are accomplishing while rolling out the system.
Don’t try to do everything at once. This will overwhelm the organization and more importantly: the end-users. Without the support and engagement from the end-users the implementation will fail before it ever began.
Over Promising on Software Features
And under-delivering on them? Yikes.
At least 50% of all ERP system implementations do not meet expectations, and one third are utter failures.
Any user will resist software delivered with the promise of goodness and benefits yet when they use it for the first time, they discover it has neither.
No one likes broken promises.
Like top management buy in and involving users in the design phase, this should be handled early on in the project. This is when those business processes get mapped or reengineered and then the software is closely matched.
During your time with the users, be aware of scope creep.What is scope creep? It’s when we can’t say “no” to features the end users want. Rather than focusing on the critical features and getting them out the door, we say yes and continue to build and test and build and test and then delay the rollout and/or fail altogether.
If you’re keenly aware of scope creep, you can avoid over-promising on features.
Employ these strategies from the get-go and you’ll find the implementation of your software will go a lot smoother.
This is a project team responsibility. Always be clear to the users about what to expect with the new system. If you are ever asked if the software will be able to do “this” or “that” simply say “Great idea! Let us look into adding this feature and we’ll get back to you”
If the software can’t do it, it can’t do it. Perhaps a different application should have been selected. Otherwise pay a ton of money to have someone create a custom enterprise application to meet your “unique” business needs.
Poor planning and time management
This is never good for any project. Any poorly planned software implementation will surely encounter user resistance. If it’s poorly planned, either the go-live date will be accelerated or pushed back. What I have discovered is companies often tend to be intimidated by the time and money required for an implementation and then look to accelerate the go-live date to offset these misunderstood costs.
Without the right strategy and tools, implementation acceleration has the risk of inadequate end user training, an ineffective change management strategy, reduced reengineering of business processes, and other problems lead to higher overall cost of ownership and the erosion of benefits from the new system. It’s negating the purpose of implementing the software in the first place.
On the other hand, extending the implementation period has its own share of drawbacks.
Excerpt from a client: “We have taken a very long cutoff period for implementation, i.e., we have decided to go live in August 2012 instead of doing so in April 2012. To do this we had to backdate the server, and adjust some stock transactions, accordingly. However, this is now proving to be a major challenge while reconciling accounts.”
Often when a go-live date gets pushed out, it’s not a good sign. And if it’s because project personnel need more time, then it’s a personnel/resource issue and not a software issue. You might have to look at your resources.
Strategies to apply in this situation? None of the above. Both participative and directive strategies infer there is a functioning instance of the software. If the implementation has been poorly planned, is there a functioning instance to which these strategies can be applied?
Instead, conduct a thorough risk analysis on the project and especially scrutinize the critical business processes. Start with those and ensure they work. Maybe the organization can live without other parts of the business not operating for a certain period of time.
Or see if there are temporary work-arounds you can implement to keep parts of the business running while things get fixed. It may even have to be something manually tracked in Excel and then later put into the system either manually or through a data load.
To avoid this in the future, be sure your implementation is done incrementally and in a phased manner.
Your Story
What about you? What kind of user resistance have you encountered and how were you able to overcome it?
Leave a comment below and let me know!