OBSERVATIONWe have all experienced this: a round of discussions generating wonderful ideas, with a promise to reconvene and determine next action items. The problem is those action items rarely become a reality, because there was never a sufficient amount of follow-through to act on those ideas. We know that user adoption (UA) of IT systems does not occur without deliberate action items. Since the goal is to conduct specific activities that encourage end-users to engage your IT system as designed, we need to move from mere discussions and ideas to committed actions that promote user adoption. In order to maintain both focus and follow-through of user adoption plans, it is recommended to reconstruct your project team meetings in a way that generates ideas and creates specific follow-up actions.
CONSIDER THISFor each strategy phase of the user adoption (UA) plan (e.g. analysis, engagement, learning, support, etc.) create two separate meeting times and agendas:
- “Brainstorming Session”
- “Implementation Planning”
- Ascertain and list the relevant topics for that phase of the UA plan (rely not only on the project plan and initial team discussions but also on your UA consultant/expert).
- Organize each agenda topic in a logical sequence to create a seamless and singular focus throughout the session.
- Place specific time limits for each discussion topic, and be realistic as to what can be accomplished, as brainstorming/discussions can take longer than expected. Therefore do not attempt to overload the meeting agenda with too many topics. If needed, consider more than one brainstorming session vs. one long session.
- During the brainstorming session, ALWAYS include the predicted impacts to user adoption of each idea.
- Assign specific assignments to session participants with the due date set for the following meeting: “Implementation Planning”. Typically, these assignments are data gathering/research in nature, which shall help the team determine the implementation plan.
- Revisit each discussion topic in the same sequence from the brainstorming session.
- Address the findings from the various assignments in order to decide how to best proceed. Again, validate each decision based on predicted impact to user adoption.
- Agree to a specific series of implementation activities to enact your team’s decisions. This must include primary ownership and enactors of activities, time-frames, resources required, leadership endorsement and support.
THINGS TO THINK ABOUTAs you plan for your next UA meetings, remember what the overarching goal is: to enact specific actions that will create user adoption of your IT system. Using the above steps can help you and your team follow-through on your user adoption ideas to create long lasting results.
RELATED RESOURCESCheck out these other resources for more information related to this topic:
- Check out MyUserAdoptionPlan.com - an all-in-one User Adoption Portal
- Take the Tri Tuns User Adoption Challenge - a free online assessment tool
- Read: “Does Your User Adoption Methodology Remove Barriers To Adoption?”
- Read: “Design the right metrics to improve user adoption”
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?