User Adoption: Easier Said Than Done

— January 17, 2018

User Adoption: Easier Said Than Done

Your company has invested thousands of dollars in deploying new software. It’s taken months, if not years to plan and install. It’s been hyped up at all of the company meetings. It’s part of the corporate strategy. Finally, it gets deployed and everyone is trained.

Yet, no one uses it, and it becomes an IT Team embarrassment. The IT team blames the users and the users blame the IT team. Sound familiar?

Why do user adoption efforts fail time and time again? What’s the secret to ensuring companies get a return on investment when they purchase software? As a business analyst who has partnered with companies to improve user adoption rates for much of my career, I have some theories:

  • Employee Buy-In – Make a concerted effort to ask your employees what would help them do their jobs better. They certainly know and will tell you if your company is committed to hearing about how they can make company-wide improvements. Catalog this feedback and turn it in to an actionable and strategic plan. Make your employees part of the software evaluation process. Not only will it boost morale, it will also improve your return on investment.
  • Alignment to Processes – A critical link to increased user adoption is whether that system supports corporate processes. Sometimes, the processes are not efficient and need to be changed. That should happen well before new technology is introduced, if possible. Technology is there to complement the process, not replace it. Document your corporate processes, validate that they work, and then start to look for software that will best support those processes. When you don’t, you end up with even more manual processes that are, in reality, band-aids for true improvement. It can become a spider’s web of spreadsheets and emails, and that’s a slippery slope.
  • Requirements Analysis – You would never buy a car or make any other major investment without thinking about what you need versus what you want. Yet, when it comes to software, many companies simply buy it without truly assessing their needs. Companies should elicit business requirements for off-the-shelf software just as they would custom software. If they find themselves overly-customizing off-the-shelf software, then it was most likely the wrong choice in the first place. Compare your requirements against all of the features of the software packages you are looking at: don’t just take the sales person’s word for it. Ask to see how the software could meet your company’s requirements during the software demo. Weight the requirements and then score the packages against the different options. The highest score wins—plain and simple.
  • Training – Always tie the software training to the underlying workflow and processes. Don’t just train on the software. Teach teams how the software will enable employees to do their jobs better. I have sat through many training classes on how to use a system or tool that were not rooted in purpose: instead, the instructor trained users on how the software worked. Eyes started to glaze over and the instructor may as well have never taught the class. The target users will more often revert to old ways because no one has connected the dots for them.
  • Speed to Market – The days of having a year-long deployment plan for a software roll-out are over: technology changes too quickly. One year becomes 18 months… then two years. The software may never get deployed and if it does, by then the end user’s needs have changed. When companies start off with how technology can best complement their corporate model and processes first, they are beginning their evaluation with a methodical approach that can be executed quickly. Try to deploy software in small doses, but keep the deployment timeframe within a three-month period. That way users don’t feel overwhelmed, but you are using a “just-in time” model.

User adoption is the end game: it’s not just a bonus. When companies approach a software deployment with that perspective, the questions that IT teams ask at the beginning of the project start to change. How can you be sure that users will actually use the software you are about to invest thousands of dollars on? The simple answer is to ask and involve the users before you even begin the software evaluation. Every successful project has user buy-in.

Business & Finance Articles on Business 2 Community

Author: Dana McInnis

View full profile ›