Change Management for Accessibility: ADKAR Model

Note: This blog post is part four of a series on change management for accessibility. Read part 1, part 2, and part 3 to get caught up before reading the post below!

There is a lot to cover with Jeffrey Hiatt’s ADKAR change management model. If you recall, we have talked about Lewin’s and the plan-do-check-act model in our prior posts. These are great baseline strategies to consider, but with larger organizations, changes just get more complex, and the ADKAR Model may be more appropriate to consider as the strategy to best follow. You will continue to see some of these stages reflected in what we’ve already covered.

ADKAR aims to limit resistance toward change, and it is used to ease change by setting clear milestones to be reached throughout the process. ADKAR is sequential and stresses that every person in the change must reach the goal, though it’s important to remember that they may reach it at different times and that is ok! ADKAR is a bottom-up method that puts the focus on the people behind the change.

A – Awareness Stage

Our first stage, which makes up the “A” in ADKAR is the awareness stage. This stage is all about communicating and growing awareness of why the change is needed. For example, “Our designs are not accessible. Why does that matter?” Because with high-velocity accessibility, design and conceptualization is the first area accessibility best practices can be applied. If you are designing accessibly, then there is a lower risk that accessibility issues will get to production, resulting in significant cost savings. We all know the further in the software development lifecycle (SDLC) you let a bug get, the more expensive it is to fix it.

You will not just announce to a team that they will need to apply accessibility best practices in their designs, but you will focus on growing the awareness of why it is important. Consider these influencing factors:

• A person’s view of the current state. The adage of it is not broken, do not fix it. How will you address that?
• How a person perceives the problems. There are different cognitive styles to help people internalize added information.
• It is also important to consider the credibility of the sender of the information. Employees may receive the message better if it is coming from someone who is well respected and has a reputation for being direct and honest versus someone that the team members do not know or who has a history of vague communication. You cannot always tell everyone everything, but you must be ready for misinformation or rumors that may spring up.
• What about the contestability of the reason for the change? A change might make sense to the team, but then a respected member of the team opposes it. What do you do?

D – Desire Stage

The next stage in this model is the “desire” stage, which is the D in ADKAR. Is it a normal progression from awareness? It can be, but it is not always a place that people arrive at on their own simply by knowing that a change exists. Growing awareness can plant the seed that grows into a desire to make the change.

Back to our example, “As a designer, I want to make accessible designs. It is the right thing to do, and it makes the rest of the project go easier. I want to be clear and concise in my communications to developers so they can code accessibly too.”

If there’s resistance to change, you must address it head-on and at once. The organizational context for the change and how much change is already going on can affect the team’s willingness or desire to go through more change. The resistance can also depend on an individual’s personal situation. Think about what might go on in other areas of the teams’ lives and then think about what motivates them.

K – Knowledge Stage

The K in ADKAR is the knowledge stage. How do we make the change? How do we learn what we need? What skills are we going to gain? Where do we find those materials?

In our example, “I am excited to include accessibility in my designs, but there is one problem, I do not know anything about accessibility. How do I learn what I need to know? What are the processes I need to follow internally? Will they expect me to teach others?”

This is when the panic starts. Too much change at once can be jarring and disorienting, leading to resistance to change, so implement appropriately. The chance of success can boil down to the current knowledge base of an individual. Some of your team members might know nothing about accessibility, while others might have some knowledge or a lot of knowledge. You need to meet each of them where they are.

The ability to gain additional knowledge and the resources that are available for education and training are critical for success. Keep in mind it is equally important to provide knowledge that allows your team to see the change through to the end, not just at the beginning. In fact, training programs for new systems have proven to be critical both during and after the change has been implemented. Sixty-nine percent of the most effective change programs offer training before and after going live.

A – Ability Stage

The second A in ADKAR is the ability stage. Think of ability as not just knowing how to do something but having confidence in your own capabilities and achieving the desired performance level.

In our example, “We know about accessibility standards and how to apply some of them to our designs. To be successful, we set goals within the team and start by addressing color contrast and consistency in our buttons within our component library in the first two sprints. After the first two sprints, we will measure the success of those being rolled out, adjust, and then expand to other accessibility requirements in the third sprint.”

Bridging the gap between knowing how and feeling good about change by putting change leaders in charge of coaching individuals or teams is a great idea. Provide hands-on training to test out skills before we roll changes out, so they can build confidence. This allows you to watch the performance as well and adjust your plan. Consider implementing these changes in phases or stages.

Key factors to consider are:

• Psychological blocks. “I have always done it this way. I cannot change.”
• Physical abilities, intellectual capabilities, the time available to develop the skills, balancing your workload
• The availability of resources to support development are all potential barriers to change

R – Reinforcement Stage

The final stage in the ADKAR change model is the reinforcement stage. This is where you are celebrating the success and making sure it sticks. By implementing accessibility standards in the design process, the team could reduce the number of accessibility issues by 60%!

Publicly, give praise and privately address poor behavior or mistakes. Continue to monitor pain points, gather feedback, and see where extra support might be needed. Consider these factors:

• The degree to which the reinforcement is meaningful to the person affected by the change
• The absence of negative consequences
• An example of what not to do: “Everyone on the team should increase productivity by 50% or else.”

Accountability systems to reinforce the change can be as simple as a manager or a change agent checking in with the individual or group routinely to talk about the goals set and the progress towards them.

Final Thoughts on the ADKAR Change Model

Overall, ADKAR is about putting the focus on the employees. It limits resistance and speeds up implementation. It values employee input and support. Instead of mandating that you must consider accessibility in your designs now, start a conversation with employees to make them aware of the need for the change and convince them of the benefits.

For example, “What do you think about having, or being more successful in our designs, so that fewer bugs get to production, and we do not have to redesign our components which are already in use and production?” This approach ensures a higher success rate for sustained change compared to methods that do not actively involve the people that are affected by the changes.

Up next is a very different change management strategy to consider in your organization: Strategic Execution Framework (SEF).