Adoption. There, I said it. I got it out of the way. In fact, I'm gonna say it again: adoption. When I work with our customer teams responsible for rolling out and/or maintaining Jive, that word (adoption) evokes a bit of uneasiness. It's as if adoption has become synonymous with monster and it's easier to look the other way than stare it down in its brutal face. And for good reason.
He's not very scary once you get to know him.
Driving adoption calls upon us to be good (I mean, really, really good) at managing change. See, therein lies the catch: change management is more or less dealing with change for other people. It's not just your own reaction to the change that you have to worry about. No, it's the reactions of hundreds or thousands. In order to truly drive adoption, we have to anticipate how the people within our organizations are going to react to the change and have a plan to address those reactions.
It doesn't matter if you are about to launch Jive or launched Jive several years ago, change management is equally relevant to preparing for launch as it is to expanding the use of Jive across your organization over time. And it really doesn't have to be as daunting as it may seem. This blog series will focus on change management as the foundation from which you can successfully drive adoption. The series will focus on three topics:
- The basics of change management
- Do's and don'ts of managing change
- Lessons learned from our customers
The series will focus on internal community challenges though many of the points are certainly relevant to external communities as well.
What is change management?
Change management is an entire field in and of itself. As a field, it was born by combining the engineering field's mechanical focus on change (systems and processes) with the psychology field's human focus on change (people). In large part, this is because the concept of change management began in the manufacturing industry and that industry's focus on achieving efficient, systematic quality. For our purposes, let's simply think of change management as a methodology that is used to transition teams and/or organizations from a current state to a desired future state. It's a mouthful, I know.Let's break it down as it applies to a Jive internal community:
- The current state = the existing intranet, email, and/or other tools that may be used inconsistently across the organization
- The desired, future state = all employees on Jive, using it consistently across the organization
- The transition = everything that you're going to plan and do to make the desired, future state a reality -- to get all of your employees on Jive and using it consistently across the organization
Or, if your organization is already on Jive, it might look more like:
- The current state = Department A using Jive as if they wrote the book on best-practices, but Department C avoiding Jive altogether and using email
- The desired, future state = Department C using Jive even half as fantastically as Department A
- The transition is everything that you're going to plan and do to make Department C use Jive even half as fantastically as Department A
See, the transition is where the change management happens. Articulating the current state is comparatively easy. Articulating your desired, future state is also comparatively easy. The hard part is figuring out what you need to do to make the change happen: the transition.
Change management in action: the transition is life or death for this little guy
If the transition is where the change management happens ... how does it happen?
There are many schools of thought about change management. Most notably, there is John Kotter's seminal eight step process and Jeff Hiatt's ADKAR model. If you have time to study Kotter and Hiatt, I encourage you to do so. If you don't, then I humbly offer a synthesized version of all I've learned and taught about change management as it relates to Jive through the Five W's + H + R (the R is my addition) that many of us learned in grade school: what, why, who, when, where, how, and report. The R is pretty important to change management.
You have to be able to explain what it is you are trying to accomplish. Customers who have worked with me probably get sick of me reminding them to focus on the what first and before anything else. It's very easy to jump straight to the how. After all, that's where the solution is and it's way more fun to think about the answer. But first, tell me: what's the what? Your "what" may be similar to the statement that describes your desired future state. Or, this may be refined to be a bit more tactical. Try to find a way to state it in one sentence or a even better, a few words. Think of defining your what as if it's a tagline you want everyone to remember. Think about it from the perspective of the audience. Think about it in terms of an actionable statement (hint: actionable = using a verb). For example, "Enable online collaboration hub for reseachers" is a much stronger statement than "Researcher collaboration group."
Once you are able to articulate the what, you need to be able to state why it matters. This is essentially a matter of stating the value proposition. Think about it in terms of your audience wanting an answer to the question "what's in it for me?" There are times when the reason why it matters cannot be articulated by thinking through why it matters for the audience. In these cases, think about engaging leadership to communicate the what and why statements. In so doing, your why statement essentially becomes leadership directive, which is often an excellent motivator. If you can get leadership to deliver the what/why messages, even if it's not a leadership directive, it creates a valuable sense of urgency and natural buy-in.
This one is simple but easy to overlook. Who will be impacted by the change? Really, really think this one through. It's easy to overlook all who may be involved, but this is critical to understanding if different populations require different messaging and/or instructions. Often it takes thoroughly diving into individual use cases to identify all of the parties involved. The time is well spent since the second part of this step is understanding the population(s) in order to tailor communications to them and more effectively socialize the change. For example, you might find that your who consists of end users as well as organizational managers.
Timelines help us process and accept the change we may feel inclined to resist. It's the difference of being told you have to have surgery vs. you have to have surgery next week. The latter allows us to more readily accept what's about to happen. The former creates more anxiety because we are not sure how long we will be in the uncomfortable state of certainty. When you think about communicating the timeline, allow yourself a bit of buffer in your all-employee communications. For example, if you are targeting an April 15 deadline, tell your general population the change will happen in the second quarter. As you get closer, refine the communication: it will happen in April; it will happen in mid-April; it will happen on April 15. Of course, you will have to communicate the dialed-in timeline to leadership and the project team, but you can save yourself from having to reset expectations by keeping it vague at first and refining along the way.
Think about this in terms of where the action will happen. If it's an intranet replacement, this may be as easy as turning on your computer, going to your bookmarked URL and voila you're in the new intranet. If this is a more in-depth use case, the "where" is likely a container in your community. For example: A space in which to do X or a group in which to do Y.
Once you have your users where you want them, it needs to be very clear what actions you want them to take (or they can take). This will vary use case to use case, but if you think through the details of what the user will do, then you can design places within your community to facilitate these actions. For example, going to a help space and not having it be immediately clear how to find an answer or ask a question creates a frustrating user experience. Design to facilitate desired actions whenever possible with lightweight how-to instructions available for those who need such tools to reinforce their learning process. Try to keep the detailed how-to instructions to more complicated processes.
Finally, it is crucial to determine how you will know you've been successful. What will you measure? How will measure it? To what will you compare the measurement against (baseline) to demonstrate improvement over time? But here is the more crucial part: once you know, share it. Report out on your organization's progress. Celebrate the wins and be transparent about where there is still room for growth. Even better if you can put a goal around it that leadership supports as a key priority.
These change management steps will help you get to the future state
You may arrive at your five W's + H + R in a different order than what's shown above. That's okay. For any future desired state, you may have numerous W's + H + Rs. That's okay, too. For every what, you may have multiple why's and who's, etc. That's also okay. Just remember to phase what you tackle so that it is manageable. Taking a phased approach not only keeps your workload more sane, it also makes the change easier to manage for your organization. Guide the change you want to see and let the structured methodology of change management help you drive more adoption across your organization. Think about what that is meaningful to you right now. Then think through why it matters. Then think of who it will impact, when they will need to make the change, where it's going to happen, and how they will do what you need them to do. Then, think through how you will measure your success.
Put together your plan and you'll be ready to start driving adoption!
In the next part of this blog series, we'll cover the do's and don'ts of change management.