Product Delivery Resources

Why Your Rollout Strategy Must Put People First

Software adoption has more to do with enlisting teams, not training them

Zeb Geary | October 29, 2015

At a conference I attended not too long ago, I listened to teams of people discuss the challenges they faced in deploying software into their organizations. The consensus was that the software itself was the easy part, it was the people that were hard – that is to say, 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. He 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, the schedule and various agendas–put a lot of pressure on the deployment plan and so this 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 than if it was identified and addressed early. This is why communication is so important, as is having the right people involved.

The key to user adoption is to think of them 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, particularly those that also come with process changes, and to make those changes stick.

My interest in this topic goes even deeper, to my education in psychology. A few years ago I completed a 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.

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.

Let’s take a trip and bring everyone 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 there, happy and ready for fun. You’ve gone online, and talked to some other people about what kind of vehicle works best for teams like yours when going on vacation.

So with the information you have you go ahead and buy the perfect car for this trip. It has all the things you need: the right number of seats, air conditioning, individual jacks so everyone can listen to their own music with headphones, and it has great gas mileage. You’ve scored!

Slide1

At the risk of stating the obvious:

  • “Everyone” is the teams that could benefit from a new process and toolset to meet their business objectives in a more efficient way with better quality, or whatever your ultimate goal is, such as continuous product release or better management of complex requirements.
  • The “destination” is that ultimate goal.
  • The “car” is your software solution that gets you to that ultimate goal.

But here’s something you have to consider before you embark on this vacation: 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.

The main factors in planning a successful software deployment

If you’ve ever actually planned an out-of-town experience with co-workers you know it’s not an easy endeavor and it’s hard to make everyone happy all the time. Deploying a new way of working to teams can be even more difficult. Why is that?

Before I answer that remember that 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, 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.

Begin designing your approach based on the specific needs of your team

Ok, so here’s the warning: 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 car will translate to motivation and acceptance in the people that must be on board in the end. Of course, some people will just get it so make sure you identify those people and train them to evangelize for the effort. But others may need more attention and we have to 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 in the end

This is what we call maturity of your team. Of course, it doesn’t have anything to do with the development or emotional maturity of the individuals, but the maturity of the team’s processes and toolset, how they’re used to getting their work done today. In my experience as a consultant I find that team maturity ranges wildly, especially when it comes to requirements management processes and toolsets.

Knowing where people are–there 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. In terms of where we like to see people with their modern requirements management this is 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 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 – and 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’s 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 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 many 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 want to take as you get started on your deployment plan:

  • How you will build awareness, not just of new process and solution but 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 (I’m sure you’ve thought of a few other relevant questions already) but the key is to engage with this line of thinking early. It is difficult for everyone when you have deployed something and then realize that you need to take a step back and build awareness around the solution.

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 even challenging?

If you want to hear a recorded version of a presentation I recently made on this top you can download it here in the Jama Community. Let’s keep this conversation going – we can use the community to share and build on ideas.