At a conference I attended recently, I listened to teams discuss the challenges they faced in deploying software in their organizations. The consensus was that the software is easy; the people are hard. That is to say, getting up to speed with a new software solution itself is relatively easy compared to getting people to change their behavior and successfully adopt new software. 

ROI Requires that Teams Actually Use the Solution  

One of the speakers said something that really stuck with me. This person said, “There is no return on investment without adoption, and there is no adoption without user acceptance.” And while that may seem obvious, many times the end user of the software is forgotten. Other priorities — like budget, schedule, and various agendas — put a lot of pressure on the deployment plan. The human aspect, as important as it is, gets lost. 

Gaining Acceptance Later in the Implementation Will Cost You 

When implementing a new solution, it’s imperative that you get your team on board from the get-go – and not just for the purpose of keeping them happy. Just as it’s more costly to identify inaccurate requirements late in the product delivery lifecycle, the same principle holds true for user acceptance. Resistance from users identified late is always going to be more costly than adoption issues identified and addressed early.  

While implementing a new solution may be a top–down decision, it’s important to remember that the users are the ones who will need to adapt to the change. The primary impacted stakeholders (i.e. the end–users) will be more receptive to a major change if they are participating in the process, rather than being told that they must adopt a new tool.  

Change is difficult, and without a full understanding of the benefits of a new solution, teams may feel frustrated or resistant. One way to preemptively combat resistance is by identifying long- and short-term goals for each team member and encouraging users to be involved in the implementation process. 

The Key to User Adoption is People  

Having worked in professional services for over a decade, I have come to see just how valuable it is to understand the people side of deployments. 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 new solutions, particularly those that also come with process changes, and how to make those changes stick. 

My interest in this topic goes even deeper. A few years ago, I completed a master’s program in psychology where I studied human behavior and why people do or do not change. I’ve found that what I learned during my study of psychology has translated quite well to the consulting world. 

In this post I won’t be able to outline the perfect adoption plan for your organization; this would be futile as no two companies have the same needs or challenges. But I will discuss the approach we recommend when planning for a solution rollout that maximizes adoption. 

If You’re Taking a Trip, Bring the Whole Team Along 

 I’m going to start with an analogy:  

Let’s say you’ve pretty much determined that everyone on your team could benefit from a vacation. You’ve even heard people say so. You’ve had some good conversations about what people want and need, and with that knowledge you pick out a destination that’s going to recharge everyone. 

Next, you have to figure out what kind of transportation you’re going to use to get everyone to the identified location. You’ve gone online and talked to some others about what kind of vehicle works best for teams like yours.  

So, with the information you have, you go ahead and buy the perfect car for this trip. It has all the things you need.  

In case you haven’t figured out how the pieces of my analogy fit into the rollout of a new solution, here it is:  

• The people are those who would benefit from a new process and solution to meet their business objectives 
• The “destination” is that ultimate goal, where the benefits are realized 
• The “car” is the new software solution that gets you to that ultimate goal

But here’s something you have to consider before you embark on this journey: You have to figure out where everyone lives, what kind of baggage they’re bringing with them, and how you’re going to organize picking them all up so you can all be in the car at the same time, happily enjoying the journey to your destination. More on that in a bit.  

Key Factors in Planning a Successful Software Deployment 

If you’ve ever actually planned an out-of-town experience with coworkers (or family, for that matter), you know it’s impossible to make everyone happy all the time. Introducing a new way of working to your teams can be even more difficult. Why? 

Before I answer that, remember that these are the main things to keep top-of-mind when planning a successful deployment: 

• Bringing new teams into a new solution, with new processes, 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.

New data for 2019 reveals the growing gap between product complexity and requirements management. Find out more by downloading our report. 

Design Your Approach Based on the Specific Needs of Your Team  

Change is hard – especially when people are involved. You can put up your pie chart or line graph with anticipated benefits and have everyone nodding their heads in agreement, and you can find the perfect “car” to get you there. But you cannot assume that pointing at that amazing vacation spot on a map or showing off your awesome new vehicle will translate to motivation and acceptance for the people who must be on board in the end.  

Of course, some will be on board immediately, so make sure you identify those people and train them to evangelize for the effort. These advocates are a great asset as you complete your rollout to the rest of the organization. Successful organizations often pair these early adopters with new users to help them get up to speed with the new process.   

Others may need more attention, and you must pay careful attention to their fears and objections and speak to them early and often. 

Consider the Delta Between Where Your Team is Today and Where You Want to Be 

You must consider the maturity of your organization and teams. Of course, it doesn’t have anything to do with the emotional maturity of the individuals (though that could come into play), but the maturity of their processes and toolset and how they’re accustomed to getting their work done today. In my experience as a consultant, I find that team maturity ranges widely, especially when it comes to requirements management processes and supporting tools.  

Knowing where teams are — or their level of maturity — is important for a number of reasons, not least of which is anticipating resistance. Think about the person who is currently using a Word doc that they keep somewhere on their laptop to manage the requirements for a really complex product. This might be considered a pretty basic level of maturity. 

Now, 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 computer? What resistance can you anticipate and what will be your approach? Again, communication early and often is going to be key to getting this person on board with a new solution.  

Learn more about best practices for change impact analysis by reading our blog post. 

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, causing teams to dig their heels in and get stuck.   

When you are bringing on a new team into your deployment effort, don’t just set up training on how to use the tool. You’ll want to engage with your people at a personal level so you can uncover their anxieties and address them. You’ll need to anticipate their questions and welcome their concerns. When you know their concerns, you can address them; it’s the concerns you don’t know about that can manifest very late and cause problems for the whole deployment.  

For example: Consider a 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 to simply ask them. 

Remember that unanswered questions today turn into resistance tomorrow. Provide opportunities for people to voice their questions early so you can address them. Consider establishing clear channels for communication with users.  

Explore product development strategies for systems engineers by downloading our whitepaper. 

Adopt a Change Management Model to Give Your Project Structure 

There are many change management models out there, and I recommend researching these until you find one that make sense for the size of your company, its culture, and your strategic goals. I personally like the ADKAR model from Prosci. 

The five parts of this specific change management 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. 

 We’ve also seen great success from teams who have read this book: “Change Management: The People Side of Change,” by Jeffrey M. Hiatt and Timothy J. Creasey.  

A good change management model, like ADKAR, will help you consider the approach you want to take as you get started on your deployment plan. You’ll want to think about:   

• How you will build awareness, not just of new processes and solutions, but also why you’re taking on this initiative and what you hope it will do for your organization. 
• How you will communicate the benefits of using the solution, particularly the “what’s in it for me” for each individual or each team. 
• How you will build knowledge about how the solution works, relative to the current tool, and how to get the most of it. 
• How will you ensure people gain the ability to use the solution with the proper training for their position, in a style that will help them feel empowered and not burdened through the learning curve. 
• What kind of reinforcements you can 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 but the key is to engage with this line of thinking early and be open to adjusting as you learn more.

To learn more, watch our webinar to learn about other best practices for implementing new technologies.