For me, the phrase “digital adoption” evokes an image of finding old, orphaned technology and giving it a new home. That abandoned laptop deserves to have a good home, right?
Okay, maybe not quite what they mean, but adoption is important no matter the context! Digital adoption in the enterprise is all about deploying new technology to employees in a successful, low-impact manner, and employing methods to allow employees to learn, understand, and begin using new technology. But change is hard, both for IT and for the employees, and there are complications and hurdles that both groups struggle with on any change:
- When you don’t see the prerequisites aren’t met and the deployment fails.
- When you don’t have an accurate accounting of users and devices for the deployment.
- When your new tech fails and results in a lack of usage, or even triggers a revolt for the old stuff.
- When your slow speed and legacy software holds the company back from modernizing.
- When new software doesn’t account for what the business actually needs, or how it functions.
- When employees don’t like the changes you’re trying to implement and educating them seems impossible.
- When ROI projections aren’t achieved because your new rollout fails or its adoption lags.
And Digital Adoption is also tightly linked to Digital Transformation. Without transformation, there’s nothing to adopt. And while you can’t go out and solve the world’s problems in these two processes, there are some logical places to start. For me, starting always means identifying the outcomes I want to achieve, and the hurdles to getting there.
Here’s my Spinal Tap list of 11 ideas to handle any digital adoption project:
1) Fix your foundation!
Anything you deploy to an enterprise that is already broken will not stand, and will eventually crumble as well. Leveraging DEX, look for weak spots that could cause your project to fail and fix them. And use that information as your comparable baseline.
2) Employees need to be engaged early and often when a new technology is being considered.
No one likes surprises, especially when they require us to do something different in our daily memorized routine. People like to know WHY something is changing, and what’s in it for me. Knowing WHEN the change will come is also important to my understanding and accepting the change.
3) Don’t implement change just for the sake of change.
Anything new needs to solve a problem or improve a bad experience.
It should fill a void, save costs, capture more market share, or make some process or existing technology better. If in any way the UX or DEX is worse than the previous, forget it.
4) Make training undeniably employee friendly.
Provide unique and individualized education paths to accommodate different methods of learning. Ensure access to escalation and support. Leverage train-the-trainer and SME assignments. Make documentation and continuous learning easy to find and consume.
5) Don’t forget about mobile devices, even if it’s only for support or feedback.
For better or worse, we're attached to our phones, so you might as well give employees that option.
6) Provide incentives and even gamification. People learn from repetition and by doing.
Providing lessons in a game scenario also aids in understanding operations as well as outcomes. And incentives shouldn’t be underestimated. Change is hard and people often need some help to adjust.
7) Gather routine feedback from the moment the rollout starts and adjust course based on real feedback.
And then get feedback on the adjustments you made, and compare your results to your original baseline. The ability to adjust based on real and timely feedback is a critical and often missing component of large scale rollouts.
8) Monitor adoption rates for your new tool(s) and migration rates from your legacy platform(s).
This is an area that IT has traditionally been blind to. They see a successful deployment, but are unsure if the employees have started using it yet. Can we shut off the old system? Let’s look at logon records, or send a survey. When adoption is integrated into DEX, you not only see usage statistics of both platforms, you can also ask them in context about the change.
9) Don’t skip integration with other systems if there’s a benefit.
I’ve seen employees rely heavily on Notepad, where they can copy and paste critical information from one system to another. The resulting workaround workflows that employees create are a function of poor, or nonexistent integrations and can end up costing your business a lot of productivity time and money.
10) If ROI was a factor in the migration, measure the benefits achieved as they are accomplished, and not too far down the road.
Make sure to understand the currency needed. In other words, it may very well be monetary, but value can also come in terms of time, product output, employee sentiment, customer retention, or NPS.
11) Make sure the program plan scales to the size of your organization.
For example, gaining feedback via email is fine for a pilot group of 10, but not a production group of 10,000.
So practically speaking, step-by-step, where do you start?
FIX THE CURRENT ENVIRONMENT
- New tech will always fail on top of old tech
- Use See/Diagnose/Fix approach to create stability.
SOLICIT BUSINESS INPUT
- Partner with business leaders to develop a needs-based plan.
- This plan will serve as the foundation for your communications
BUDGET FOR CHANGE
- While tech should improve costs or increase revenues, making change will have an up front cost
TEST TEST TEST
- Any change should include a robust test and validation process, along with production pilots.
- Baseline and track technical and feedback metrics before, during, and after the change to validate test results.
LET DEX SHOW YOU THE WAY
- DEX platforms can serve to validate testing, helping with comms, baseline and tracking, measuring usage, and gaining ongoing feedback.
