Software adoption has more to do with enlisting teams, not training them
At a conference I attended, I listened to teams of people discuss the challenges they faced in deploying new software into their organizations. The consensus was that the software itself was typically easy part, it was the people part that was hard. Why? Because getting people to change their behavior is difficult work.
ROI requires that people use the solution. It seems obvious but…
One of the speakers said something that has really stuck with me. This person said, “There is no return on investment without adoption, and there is no adoption without user acceptance.” It seems obvious, but I can’t tell you how many times the user of the software is forgotten, and I will tell you in my many years consulting even I’ve lost sight of this at times. Other things, like the budget, schedule and various agendas, put a lot of pressure on the deployment plan and so he "people" aspect, as important as it is, often gets lost.
It is more costly to deploy and then attempt to build acceptance than it is to build acceptance early.
As folks working with requirements you will likely recognize the need for making sure you choose the right solution for your team and get them on board from the get-go. Just like it is more costly to identify inaccurate requirements late in the product delivery lifecycle, the same principle holds true for user acceptance. Resistance that is identified late is always going to be more costly. This is why communication is so important, as is having the right people involved.
The key to user adoption is to think of users as…people.
As someone who has been a software consultant for over a decade I have come to see just how valuable it is to understand the people side of the deployment equation. In my years as a business analyst I’ve seen from the inside just how difficult it can be to get people on board with solutions and to make those changes stick.
My interest in this topic goes even deeper. A few years ago I completed a Psychology Master’s program in which I became really interested in topics around behavior and studying why people do or do not change. I’ve found what I learned in the counseling world has translated quite well to the consulting world. As someone who is attempting to introduce change into your organization, you will likely find this to be true as well.
Among other things, counseling is about listening, meeting people where they are, and (especially applicable here) anticipating resistance to change and the many ways it manifests, and having a plan and tools in place to move people.
In this post I won’t outline the perfect adoption plan for your organization; this would be futile as no two companies have the same needs or same challenges. But what I will discuss is the approach we recommend when planning for a solution rollout that maximizes adoption.
Thinking differently about software deployment
If you’ve ever actually planned an outting with co-workers you know it is not an easy endeavor and it’s hard to make everyone happy all the time. Deploying a new way of working to teams is even more difficult.
These are the main things to keep front-of-mind when planning a successful deployment:
- Bringing new teams into a new solution, with new processes and software, is not simply a functional or technical issue, it is a people-centric change.
- Benefits that require that people adopt the solution inherently require that those people change behavior.
- The longer adoption problems go unaddressed the more difficult and expensive they are to address.
A people approach
Here’s the warning: Change is hard – especially when people are involved. You can put up a list or pie chart with anticipated benefits and have everyone nodding their heads in agreement, and you can find the perfect software to get you there, but you cannot assume that pointing at that amazing list of benefits or charts will translate into motivation and acceptance in the people that must be on board in the end. Consider using the recommendations below to broaden a tool-centric approach to include a focus on the people.
Know the delta between where your team is today and where you want to be in the end
Think about the maturity of the team’s processes and toolset and how they are used to getting their work done today. In my experience I find that team maturity ranges greatly, especially when it comes to requirements management processes and tools.
Knowing where people are today is important for a number of reasons, not least of which is anticipating resistance.
Think about the person who is currently using a Word document that they keep somewhere on their laptop to manage the requirements for a really complex product. In terms of where we like to see people with their modern requirements management, this is a pretty basic level of maturity. Before bringing this person into a new solution it is important to think about the degree of change being asked of this person. What does a single-source collaborative system feel like to a person coming from Word files on their hard drive? What resistance can you anticipate and what will be your approach?
Engage with people to counteract resistance
When change is introduced, the initial reaction from most is to resist. This isn’t necessarily a bad thing as not all change is good, but if you don’t address resistance it can lead to rigidity. People can dig their heels in and get stuck. When you are bringing on a new team into your deployment project don’t just set up training on how to work the tool. Engage with them at a personal level so you can surface their anxieties. Anticipate their questions and welcome their concerns. When you know their concerns you can address them; it is the concerns you don’t know that can manifest very late and cause problems for the whole project. For example, think about that person who has yet to log into the software even a month after deployment. What did we not know about this person that let them slip through the cracks? A quick way to find out is really just to ask them.
Remember that unanswered questions today can turn into resistance tomorrow. Provide opportunities for people to voice their questions early so you can address them. Establish clear channels for communication and then start executing your deployment plan.
Adopt a change management model to give your project structure
There are quite a few change management models out there, and I recommend researching these until you find one that make sense for the size of your company, your culture and your strategic goals. I can say that I really like the ADKAR model from Prosci.
The five parts of this model fit well with how we’ve been discussing bringing on teams to improve adoption:
- Awareness of the need for change
- Desire to participate and support the change
- Knowledge on how to change
- Ability to implement required skills and behaviors
- Reinforcement to sustain the change
But you can choose whatever works for you. We also like this book: “Change Management: The people side of change,” by Jeffrey M. Hiatt and Timothy J. Creasey
A good model, like ADKAR, will help you consider the approach you should to take:
- How will you build awareness, not just of new a process and solution but why you’re taking on this initiative and what you hope it will do for your organization?
- How will you communicate the benefits of using the solution, particularly the “what’s in it for me” for each individual or each team?
- How will you build the skills and knowledge needed; what training options and materials will work best?
- How will you ensure people gain the ability to practice and use the solution?
- What kind of reinforcements can you use to ensure that the process change sticks and the initiative’s objectives are met
These are just a few examples of how to use the ADKAR model. I’m sure you can think of more considerations from the model, but the key is to engage with this line of people-centric thinking early.
As I mentioned, these topics of adoption, behavior change and resistance are all really interesting to me. I hope you’ve found them interesting and important as well. And there is so much more to talk about. I’m very interested to hear what you have to say. What challenges have you faced? What have you found helpful? If you’re already a Jama user, are there particular areas of Jama that you have found useful for building adoption? Or challenging?
If you want to hear a recorded version of a presentation based on this material, you can link to it here: Adoption Best Practices for Bringing New Tools & Teams Together