User Adoption Insights From Tri Tuns

THE MYTH OF USER RESISTANCE


by Jason Whitehead

OBSERVATION

Many people blame “user resistance” as the reason why their systems are not adopted.  The prevailing attitude seems to be that if we provide adequate training and communication (often the extent of the “Change Management” effort), then it must be the users fault if the system is not used.  I like to call this the “Train, then blame” approach to User Adoption. There is an implicit assumption that user choice is the sole factor affecting user adoption.  However, when we look closer, we see that this is often not the case. 

There may be many other reasons why your people might not be using your system, and in many cases it is not their users fault at all.  For example:
  • Many times there are organizational barriers outside the users control that prevent them from adopting the system
  • Design disconnects between the technology, process and users prevent users from adopting the system
  • Conflicting priorities, misaligned reward systems, and the directives of immediate supervisors result in a situation of, “hoping for A, while rewarding B”
  • The Change Management and IT implementation methodology were inappropriate for driving user adoption
  • No action was taken after go-live to create and sustain full user adoption

CONSIDER THIS

Blaming poor user adoption on “User Resistance” may be convenient and it may shift the onus for taking action from you to the users, but it may not be accurate.  There may be other factors causing your adoption problems and the responsibility for taking action may fall on YOU, not the users!

THINGS TO THINK ABOUT

  • What factors outside of the users’ control would prevent them from adopting the system?
  • Have you adjusted reward & recognition criteria to reward people for adopting the system and penalize them for avoiding the system?
  • What are the reasons (other than the technology itself) that people did not adopt earlier systems?  What did you do to address these issues?
  • Did you take appropriate action before, during, and after go-live to address user behavior and drive user adoption?  How can you move beyond traditional “Change Management” efforts to drive desired user behavior over the long term?
Quick Subcribe:  User Adoption Quick Tips & Insights Newsletter

Get even more User Adoption tips & insights sent to your email.

        

 Insights Newsletter                                         User Adoption Quick Tips 


Anonymous 13-Jan-2010 06:57 AM

Thanks for writing such an honest approach to a technology implementation. You've posed some excellent questions under " Things to Think About". Let's discuss some of your points. Best, Sandy

Anonymous 01-Feb-2010 12:16 AM

Great post, I am going to bookmark this and share. Thanks!

Anonymous 01-Feb-2010 03:04 AM

Thanks, Amy! I am glad that you like and I appreciate you sharing it with your friends & colleagues. Please feel free to contact me if you have any questions or thoughts that you want to share. I am always looking to learn from the experience of others!
Thanks again, Jason Whitehead

Anonymous 01-Feb-2010 04:16 AM

Jason, I read the post. I've led change management around multiple federal ERPs and I agree that blaming the "user" is not always correct, and blame in general resolves nothing. I agree with much of your "Things to think about". I've found that all to
often user adoption is slow due to poor communication, weak change management, and often lack of proper management of client expectations. In several ERP implementations I've worked on, user resistance was high because the users themselves were simply ignored,
or their needs and wants were not assessed from the onset, so the technology being implemented could not be properly designed to fit the role the user must perform daily. Government agencies often hire large firms to implement their technology, and only sometimes
to manage change and communications in parallel. This approach is not always successful. I've worked for the large firms, I've worked for the small firms, and now I work for myself as I became frustrated with exactly what you mention here. The "users" have
a responsibility to adopt the new system, but they can only do so if their opinions and needs have been heard, the changes and reasons for them have been communicated, information is given to them about their new roles, and training is provided - throughout
the implementation.

Anonymous 01-Feb-2010 04:26 AM

Hi Scott, Thanks for sharing your thoughts and experience. It seems like we have had similar experiences with both IT projects and OD. I am very interested to learn more about your work. Perhaps we can connect for coffee or a phone chat sometime. Jason

Captcha Image


Copyright © Tri Tuns, LLC 2011. All Rights Reserved.