OBSERVATIONMany 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 THISBlaming 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?