Six months after going live, you may find yourself wondering why users aren’t fully using the new system. What is going on?
The day you go live with your major transformation project is a happy day. Months of planning and effort are finally over, and the entire team shrugs off their exhaustion to celebrate this milestone. Six months later, however, and you’re wondering why usage is lower than expected. Why is that?
What gets in the way of user adoption?
So much effort goes into getting the system live: setting strategy, defining requirements, picking a vendor, and implementing the software. It’s tempting to stop there and declare that the mission has been accomplished. Unfortunately, the Go Live Date is the last day of system implementation, but the first day for your users. And that’s when you’ll start seeing things that are getting in the way of user adoption, for example
- Training failed the users – ineffective, too long ago, not enough practice time, people didn’t attend, new hires weren’t here yet, the training room didn’t have wi-fi that day
- Incentives aren’t adjusted – forgot to implement the famous Salesforce.com adoption technique “If the details aren’t in Salesforce.com, there’s no commission on the sale”
- Acceptance testing – users weren’t required to test the system will real-life situations, which failed to uncover configuration and system errors. Then the users will tell you that the system isn’t working.
- Adoption goals and report – not goals with dates were established before going live, so no one is feeling the pressure to start using the system.
- Turning off the old system – keeping the old ways open almost ensures no one will migrate to the new system.
- Post-implementation support – when questions and issues come up, where do users turn for help? Too many struggling projects haven’t offered the support users need when they are trying to get there work done.
- System related items – there may be some configuration or code issues that get in the way, or possibly network, security, and database items.
Many of you reading this may recognize this list as a set of change management disciplines. This list can go on further, of course, but that’s not the point. We know there are many ways a project can slip off the rails and fail to get full user adoption.
How to cope with tepid adoption
While all this can be frustrating, the good news is that there are ways to address adoption issues at any point after implementation. One great way to do this is through a cross-functional discussion to identify and prioritize what needs to be done, and to cooperatively plan on addressing the top priority items. Finding a neutral facilitator may help keep the tension and frustration in the room manageable and allow leaders to focus on fixing the problems.
One tested method we like is a “reboot workshop”. We invite one leader from each affected area to participate in a one day workshop. Some homework is done in advance by us and by the participants so everyone is prepared for the discussion. We then methodically march down a change management agenda. We assess and discuss the gaps between the expectation and reality.
For example, here may be our training goal:
“100% of users trained well enough to do
all their work on the new system from day one”
And in reality, the bank falls far short. People missed the training, due to vacations, illness or client needs. The training wasn’t as good as was hoped. Some learners needed more practice and never got it. People quickly forgot what they were trained to do.
A roadmap for change – and the way back to high user adoption
After a full and lively discussion, the white board is filled with ideas and plans, some items are prioritized, people are assigned, dates are agreed upon. In a way, the rest of the project has been planned out. Done well, with energy and positive intent, a mediocre deployment with mediume or low adoption can be converted into a successful, high use success story.
Would you like to self-assess your implementation? Take this short survey to find out.