One fish jumping away from group into a new bowl with an accessibility icon in it (Change Management illustration for part 3)

Change Management for Accessibility: Plan Do Check Act (PDCA) Model

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

When a company implements a change management strategy, it is making a deliberate decision to improve performance. The goals of change management are to ensure that organizational changes achieve their goals and that people accept and use the changes. The change management process is often difficult and overwhelming, but it may be successful with proper planning and implementation.

To look at the basic steps of change management, there are six steps in the change management process:

  1. Define the change: This step includes developing a clear and concise vision for the change, articulating the business need, and deciding the goals of the change.
  2. Assess readiness: This step involves assessing the organization’s current state and finding the resources that will be needed to support the change.
  3. Plan the change: This step includes creating a detailed plan for how the change will be implemented.
  4. Implement the change: This step involves executing the plan and ensuring that the change is properly implemented.
  5. Monitor and adjust: This step involves monitoring the change and adjusting as needed.
  6. Sustain the change: This step involves ensuring that we sustain the changes over time.

In part two of the change management for accessibility blog series, we discussed Lewin’s Three-Step model, which focuses on the first four parts of these six steps. It does not ignore monitoring or adjusting, it just does not highlight the need.

If monitoring or adjusting is important because of the culture or identity of our organization, we would want to look at a model that includes those steps in the process. This is where we would look at the Plan, Do, Check, Act model for change management.

Plan Do Check Act Model (PDCA)

Plan, Do, Check, Act Model chart
Plan: a change, recognize an opportunity.
Do: the change. Carry out a small-scale study.
Check: the test. Identify what you have learned.
Act: based on what you learned.

William Deming made plan-do-check-act famous. He did so when he was working with Japanese manufacturing after World War II.

Also, Toyota employs this concept as part of its lean manufacturing process. Many agile frameworks are based on the lean manufacturing method, therefore connected to Plan, Do, Check, Act.

Step 1: Plan

The step “plan” is precisely what it says. Recognize the opportunity and specify the requirements. Answer questions like these to help you make an effective plan:

  • What do I need to do this change?
  • How can I make this solution happen?
  • What kind of problem do we have?
  • What does the team have and need to successfully tackle that problem?
  • What does success look like?

Now, one thing I have not included in the “plan” phase is many of the things we discussed with Lewin’s Model: raising awareness, using communication, talking to the team, and recognizing potential bottlenecks.

For example, we do not know how much integrating accessibility into our department will cost the business in terms of time and money. Our aim is to remediate several pages from a recent evaluation that represent our site. We intend to assemble a team that reflects the diversity of accessibility knowledge prevalent throughout the company. We will estimate what the rollout will look like for the rest of the company if we evaluate it on a smaller scale first.

Step 2: Do

Next, we will put the changes into action. Here, you will decide which pages we need to make accessible and work on them during our current sprint. You will then incorporate those modifications into our development cycle using standard methods like as sprint backlog grooming, planning poker, and so on. We will stick to the plan we made before to see how things will turn out in the future.

Step 3: Act

In the “do” phase, you will collect data from the results. You will compare the data to find what is similar and what is different and you would examine the actual “do” procedures to see if they went as expected or needed adjustments to make the process work.

It is critical that you try to create a visual representation of the data while collecting it. Why? Because it will help you in recognizing patterns. Trends in the data could reveal how well the team is performing, or it could elicit feedback from clients on how the achievements were achieved. It can even calculate our team’s velocity.

We will measure the velocity on the pages during the current sprint while we work on the sprint. After that, we compare it to the forecasts made during sprint planning. We will also make sure the team documents any issues that arose because of the code modification. Because we are figuring out how long it will take to remediate these pages, it is critical to focus on the code during code reviews and team retrospectives, as this will all be part of the “act” phase.

Step 4: Check

We will uncover lessons learned throughout the “plan, do, and check” phases, which will lead to continual development. You will complete a retrospective after you have taken the measurements. You can ask questions like, “What were the issues?” during this procedure. How did the procedure go? Is there anything we can do differently? These questions will help us in improving the future cycle.

The important thing to remember about plan-do-check-act is that it is an iterative process. We will keep doing it and increasing it as we have a better understanding of the process and how it works. It is crucial to remember that during the “act” and “check” phases, we ensure that the team and the company believe the lessons learned are for improvement and not failure.

According to a University of Chicago research, success teaches people more than failure. Even when it is easy to learn from mistakes and when doing so is rewarded, this is still true. People forget mistakes and do not take them to heart. We must emphasize to the team that this is a constant learning process to prevent this.

For example, after the sprint is complete, we will review what happened during the sprint on these pages. If we finish on time or early, we will talk about what opportunities helped that happen. If anything took longer, we would talk about what was missing and how we could have done it differently. The team will discuss tools, processes, and training that might improve our time to market in the next sprint, which is also the next loop of plan-do-check-act.

One question I get occasionally is “there are a lot of automated tools on the market that we can use like axe DevTools, how are we going to be even sure that the teams use them as we put them out there?” Accessibility automation has matured a lot in the last three years. These are now workable solutions that are going to help us meet our accessibility goal.

We know what we are going to do with PDCA, so planning is simple. We choose the team, which makes the “do” easier. The “check” phase is fascinating because it allows you to count the number of accessibility concerns. I know the team is using the tools if those issues disappear but is it all the knowledge I need to optimize the process? Measuring tool utilization is also critical in this case.

Conclusion

As a starting point, we used Lewin’s three-stage model to evaluate where we could begin with change. In this post, we used PDCA to investigate if measurement is relevant to the organization and the change’s success.

In the next post, we will look at ADKAR, a model that looks at the requirement for knowledge and change reinforcement. As you can see, as the models’ complexity grows, so do the areas they focus on based on the organization’s needs.

Photo of Michael Harshbarger

About Michael Harshbarger

Michael is an Accessibility Instructor and a Project Manager for Deque’s Training team. He worked for 20+ years in IT for a Fortune 40 company as a Developer, Project Manager, and Program Manager. Michael has experienced Accessibility in the software development life cycle. For Michael Accessibility is both a professional and personal passion. He has seen Accessibility work through the experience of his brother and two of his children.
update selasa

Comments 1 response

  1. re: apparent typo in article title

    maybe I’m missing something but if it’s “Plan Do Check Act” shouldn’t the corresponding acronym be “PDCA” and not “PCDA”

Leave a Reply

Your email address will not be published. Required fields are marked *