Application of the PDCA Cycle

Introduction

The Plan-Do-Check-Act cycle is an iterative problem-solving technique that can be used to improve the quality of an organization’s products or services and to increase customer satisfaction. This paper begins with a description of this problem-solving technique. Next, it is applied to a typical problem encountered at a fictitious software company. Finally, the paper concludes with a discussion of some modifications to the Plan-Do-Check-Act cycle that increases the speed that solutions can be found using this process.

Description of the PDCA Cycle

The Plan-Do-Check-Act (PDCA) cycle is a problem-solving method that can be applied to either existent or latent problems (Goetsch & Davis, p. 272-278). The PDCA cycle begins with the “Plan” step, which presupposes an observation of an undesired behavior, undesired quality, or an opportunity for improvement, and to create a plan to address this. The “Do” step involves implementing the plan from step 1, on a limited basis. The “Check” step determines the success or failure of the implementation. Finally, the “Act” step – also called the “Adjust” step – involves acting based on the results of the “Check” step. If the plan did not work, a brief diagnosis is performed, and the cycle repeats with a new plan based on what was learned from the diagnosis. If the plan was successful, then the plan can be executed on a wider basis, or additional changes can be made, in the next cycle.

PDCA Application

The PDCA cycle will be demonstrated on the following fictitious problem. The software company called Gaggle dot Com makes an online email service called GaggleMail, which is in no way a copy of Google’s Gmail. The PDCA problem solving method will be used to address customer comments that the user interface (UI) is not very friendly to color blind users. The names, phone numbers, and email addresses of people experiencing this problem are recorded by customer service representatives and passed on to the team that will be fixing the problem.

Step 1: Plan

To make the UI accessible to color blind users, the software developers and graphic designers quickly decide to add a toggle for changing the color of the UI. When the toggle is activated, the screen color changes to make the text readable to color blind users. A simple web search indicates that there are different types of color-blindness (WebAIM, 2021), and it is sufficient to increase the contrast between text color and background color, as well as avoiding certain color combinations.

Step 2: Do

The developers implement the toggle in GaggleMail’s UI. In the process of doing so, the software developers test that the toggle does change text and background colors, and the results can be verified using a tool that simulates the way a color-blind person would see the page (Bureau of Internet Accessibility, Inc., 2022). According to PDCA dogma, this action belongs in the “Check” step, but it makes sense to do it here – it is an easy verification, performed by the individual who is in the position to correct any problems, and it takes almost no time. This check verifies the functionality of the toggle, that it changes text and background colors. But are they the right colors? This is where the next step becomes relevant.

Step 3: Check

As described above, the changes in color are first verified by using a color-blindness simulation tool. Assuming that the new colors work with the simulator, it is time to have the customers who reported the problem check that activating the toggle does indeed make the GaggleMail’s UI readable to them. This is called “beta testing,” and the customers are called “beta testers.” The changes to the UI will be rolled-out on a limited basis, just to the beta testers.

Step 4: Act or Adjust

The responses from the beta testers will fall into three categories: “the page is extremely readable,” “the page readability can be improved,” or “the page is still unreadable.”

If the page is extremely readable to color-blind users when using the toggle, the changes will then be made available to all users.

If the page readability can be improved, better colors are chosen, and the PDCA cycle is repeated. If the page is still unreadable to the color-blind, the toggle will be checked to verify that it is indeed working, and if so, a different set of colors are used. Again, the PDCA cycle repeats.

Conclusion

In a highly competitive industry, in which the fictitious Gaggle dot Com company is a part, it is absolutely necessary to run the PDCA cycle as rapidly as possible. This can be done by minimizing the number of employees involved and limiting the team to only the most relevant people. In this example, the relevant employees are the graphic designers, the software developers, and customer service representatives. Only one of each type of these employees will be required, for a total of three people. A formal QA process is not required.

Another way to speed the PDCA cycle is to partially move the “Check” step into the “Do” step. In this example, the software developer personally tests (checks) the toggle while he implements it during the “Do” step.

By executing the PDCA cycle as described here, the GaggleMail UI is improved to make it extremely usable to color-blind customers in just a few minutes. If a bureaucratic process is used – especially processes that involve litigious web accessibility advocates – the changes may be tied-up in committee meetings for weeks.

 

References

Bureau of Internet Accessibility, Inc. (2022, 4 November). What is color blindness accessibility? https://www.boia.org/blog/what-is-color-blindness-accessibility

Goetsch, D. L. & Davis, S. B. (2021). Quality management for organizational excellence: Introduction to total quality (9^{th ed.). Pearson.}

WebAIM. (2021, 12 August). Visual disabilities: Color-blindness. https://webaim.org/articles/visual/colorblind