User Adoption Is a Journey, Not a Destination

How are IT projects like new restaurants? Most seem to fail. Depending on which stats you look at, a new restaurant has a better chance of lasting a year than certain enterprise systems have of delivering business results.

Analysts tend to agree that one of the biggest reasons IT projects fail is poor user adoption. Especially now, when digital transformation is driving companies to implement new solutions, if employees don’t embrace them, there can be little transformation.

Companies know it, too. In my experience consulting for supply chain firms on systems integration, user adoption has been the number-one concern for the past five years.

And when clients are concerned, solutions providers need to be concerned. Because clients rarely take responsibility for adoption problems. They tend to blame the vendor instead. That’s why the entire project—before, during, and after implementation—needs to have user adoption at its core. Here’s how.

Before: Identify Value-Drivers, Avoid Complexity, Set Expectations

User adoption suffers, not surprisingly, if a solution doesn’t make users’ jobs better. You may be offering a solution that really should deliver a better result. Maybe it’s more automated or provides a simpler way of working, but users don’t trust it. Old habits die hard, and users often try new solutions but then fall back to their familiar spreadsheets and legacy methodologies to effectively “check the work” of the new solution.

So, before a solution provider gets started, it’s critical to work with the client to understand the specific pain points a solution is meant to address. It’s not enough for the client to say it wants a solution that will help maintain healthy, adequate inventory levels. How do internal users experience inventory fluctuations, and what about the new solution will positively affect that experience?

For users to embrace a new solution, you can’t lead with features, no matter how cutting-edge. Everything must be tied to value.

Similarly, once the solution provider and client agree on which problems can be solved, it’s important to avoid complexity. If the solution can do 100 things but only 10 problems need solving, focus on the latter, because getting too creative or ambitious can hurt adoption. Users feel overwhelmed and avoid the solution altogether, and clients don’t experience results.

But it’s equally important to set expectations. If your recommendation is to roll out part of a solution because users will embrace it and deliver immediate value, present a roadmap by which you introduce more features over time and spell out how those features will influence the business. Moreover, be up front about when the client can reasonably expect results. In the supply chain field, if I’m helping implement a solution designed to drive down inventories but inventory levels are already through the roof, I need to set expectations about how long it will take for levels to come down.

This isn’t an easy discussion. If leadership is investing time and money in a new solution, it’s natural to want everything now. But adoption is the key and should be at the heart of your proposal. I find that it’s useful to present various scenarios to a client. One solution might be aggressive and feature-rich but could adversely affect adoption. And another might be conservative, involve targeted functionality, and require a longer timeline during which the solution provider takes the appropriate measures to set up the client for maximum user adoption.

During: Build the Right Team and Rethink Training

With a plan in place, it’s time for solution design and integration. Working with the client, it’s important to build the strongest possible team of customer subject matter experts (SMEs). There’s a temptation on the part of clients to assign employees they think they can spare to the project team. But for several reasons, you want their Michael Jordans, not their bench players, to ensure user adoption.

For starters, training starts now. Not only does Michael Jordan bring to the design team the best expertise and insight, but he has the respect of staff—the users on which success depends. Jordan creates a positive feedback loop though which design suggestions make their way to the team, and information on how the solution will improve their jobs makes its way back to employees, initiating their training at the same time.

As the design/build proceeds, there are a couple important steps before go-live. First is user acceptance testing (UAT), during which you put the solution in front of key users to make sure it works the way it should. Second is running business simulations using actual data—sort of a “day in the life” with the new solution.

Keep in mind, before UAT and simulation training, the solution should be as rock solid as possible. It’s hard to recover from a handful of users experiencing a solution glitch—however minor—just as they’re learning to use the system.

Ultimately, training shouldn’t just be three days in a conference room once the solution goes live. But neither should it include everyone all at once. Opening a new solution to everyone at the same time can be a problem. More likely, you’ll want Michael Jordan and his starting five to be the first users. After all, their training started during design. As the client rolls out the solution to more people, user shadowing—new users observing established users—is a good practice for promoting adoption.

After: Monitor Adoption and Spread the Word

When the solution goes live and the client expands the user base, it’s important to understand their experience. A growing category of digital adoption platforms (DAPs) can help. These DAP solutions run alongside enterprise software and do a couple things. First, they monitor how users interact with the software. (Are users using it the way it was intended?) Second, they can offer real-time, in-app guidance. (“Click here to complete the task.”)

Solution providers and their clients benefit from DAPs in a few ways. The real-time guidance can boost user understanding and satisfaction. The project team can identify better ways of implementing features based on how users are—or aren’t—using the current ones. And depending on the DAP solution, any changes the team makes to processes or features are automatically reflected in all training and documentation materials.

Whether you adopt a DAP or not, the important thing is to establish that feedback loop and respond with new or improved capabilities as adoption grows.

Finally, as you hit upon a user adoption success story, tell it. Work with clients to describe their experiences at conferences or webinars. Because as obviously important as user adoption seems, it remains elusive and a prevailing headwind for IT projects. With planning, it doesn’t have to be that way.

Anderson Campana is the digital supply chain planning practice lead at Tata Consultancy Services, an IT services, consulting, and business solutions organization founded in 1958 with operations in 46 countries and 600,000 employees worldwide. Campana has more than 33 years of experience, working in companies including Accenture, PepsiCo, Cognizant, and Syngenta.