menu
Last updated on
Plutora Blog - Agile Release Management, DevOps, Digital Transformation, Software Development, Value Stream Management

Plan-Do-Check-Act: Understanding and Applying PDCA

Reading time 8 minutes

The world of business transforms at the speed of light. Businesses try to define new processes and improve existing ones. However, what works and what doesn’t work? It’s a matter of experimentation to find processes that work well for your organization. 

Nowadays, businesses can pick from a whole range of methodologies that support process improvement. To name just a few methodologies, there’s Kanban, the Scaled Agile Framework (SAFe), and Plan-Do-Check-Act (PDCA). 

Although most of the above methodologies might seem new,  they share a history of hundreds of years. The PDCA methodology is one of the most robust principles and has powered hundreds of large corporations. Companies such as Nestle, Lockheed Martin, and Toyota have openly adopted and endorsed the PDCA methodology from their very beginnings. 

Business intelligence: do more with less effort with Plutora

Cut through the noise of software delivery and break silos with powerful dashboards and reports.

Learn More

This blog post covers everything about the PDCA methodology. 

  • What’s the history of PDCA?
  • What is PDCA?
  • What four elements define the PDCA methodology?
  • How is the agile framework related to PDCA?
  • How is Kanban related to PDCA?

Let’s start by exploring PDCA’s history. 

What’s the History of PDCA?

In the 17th century, Francis Bacon redefined the scientific method. Without knowing, he invented the basis for how agile-minded developers currently work. The scientific method defined how to pose a question, gather insights, and formulate a hypothesis. 

Later, in the 1930s, Walter Shewhart transformed the basic processes model of Francis Bacon and added the Act component to it, inventing the new PDCA methodology. The Act part tells you to decide whether a solution was successful or not. If the solution was successful, you implement it. If the solution was not successful, you go back to the planning phase to develop a new hypothesis you want to test. You repeat this process until you find a successful solution. 

Shewhart said that it’s imperative to act on the feedback and experience you collect after implementing a process. If you don’t act on the system feedback, you can’t reach a state of continuous improvement. 

In the 1950s, W. Edwards Deming defined the Plan-Do-Study-Act model. He emphasized the need to observe and learn from the test results, but the Plan-Do-Check-Act also focuses on analyzing the results to measure the effectiveness of a solution. Deming’s’ model formed the basis of quality control and quality management. 

PDCA later formed the basis of other methodologies such as 

  • the Agile Manifesto, which focuses on producing software iteratively and incrementally, compared to the traditional waterfall model; and
  • the Kanban model, which tries to build a culture of continuous improvement.

So, what exactly is the PDCA methodology about? 

What Is Plan-Do-Check-Act?

If I had to explain PDCA in the most basic sense, I would describe it as a four-step iterative process used to analyze and improve business processes or business strategies. 

For example, a software engineering company wants to reduce the time it needs to complete its continuous delivery pipeline. After analysis, they find a major bottleneck: for every new production deployment, a software developer was manually adding new environment variables to the production environment. This left room for potential mistakes and slowed down the deployment process. Here, PDCA could be used to detect inefficiencies, implement solutions, and measure the outcomes of those solutions. 

The PDCA methodology promotes quality improvement by changing business processes. It enables businesses to analyze the root cause of issues and make changes again and again to achieve better results. 

What’s the Major Benefit of Using PDCA?

A business can find a successful business strategy that works for their organization using the PDCA methodology. You can apply the PDCA methodology to any business strategy or process that you want to improve. 

Now that we understand what PDCA is, let’s take a closer look at each phase of the PDCA methodology. 

Defining the Four Elements of PDCA

Let’s examine each part of the PDCA process. To make things easier, we provide an example related to software engineering. 

Plan-Do-Check-Act diagram

Phase 1: Plan

The whole PDCA process starts with understanding the problem you’re trying to solve. Once you understand the problem you want to solve, it’s time to think about potential hypotheses that you want to test to solve the problem. 

During the Plan phase, your goal is to pick one possible solution and develop an implementation plan. Don’t forget to define your expectations quantitatively so that you can later verify the accuracy of your expectation during the Check phase. 

Let’s look at an example. Say that you want to improve the build time for your continuous integration (CI) pipeline. Developers often have to wait for code feedback from the CI pipeline. This slows down developers. Sometimes they switch their attention to another coding problem while waiting for code feedback. This is surely a suboptimal method of working. 

Therefore, you want to identify different improvement possibilities, such as caching Node.js dependencies for your development environment. As a hypothesis, you could state that caching dependencies will improve build time for your CI pipeline by 25%. 

Next, the plan you decide to implement is caching all dependencies for your development environment. You only want to update the cached dependencies whenever a dependency version has updated or developers have added a new dependency to the project. 

You might wonder how you should pick a possible solution among the different improvement possibilities. Start with the solution that returns the highest potential improvement but also take into account the estimated amount of work to compare all improvement possibilities. 

Next, during the Do phase, you want to implement your caching solution. 

Phase 2: Do

After you have identified a solution, it’s time to implement it. Preferably, you want to test the solution within a small-scale project. Therefore, you create a new CI pipeline and a build environment to measure the effects of implementing dependency caching. 

Make sure you define a metric, such as measuring the build time for your CI pipeline. You’ll use this metric to verify if you’ve solved the problem. 

Phase 3: Check

During the Check phase, you want to use the data to determine if the implemented solution works as expected. Here, we’ve measured the time it took to create a new build with dependency caching enabled and compared it with build times that lacked dependency caching. This allows us to calculate a percentage-based measure of improvement for the build time. 

Use this number to validate your hypothesis. Do the results meet your quantitative expectations? 

Now, if the proof of concept solution meets your expectations, move on to the Act phase. If the proof of concept solution didn’t return the expected results, go back to the first phase, Plan, and develop a new hypothesis to test. 

Assuming your proof of concept solution works well, let’s move to the last phase, where we implement the winning solution! 

Phase 4: Act

During the Act phase, you want to implement the winning solution. However, remember that the PDCA methodology doesn’t stop here. PDCA is a continuous process that aims for continuous improvement. 

Therefore, it’s still worth exploring other ideas to further improve the efficiency of your CI pipeline. For example, you can add more pipelines to distribute the work, thereby providing developers with faster coding feedback. 

Lastly, the Act phase also serves as a reflection phase. Discuss the inefficiencies you’ve experienced when improving your business process. This often leads to new PDCA initiatives and sparks new ideas to further improve a particular process. 

How Does the Agile Methodology Relate To PDCA?

To understand the relationship between the agile methodology and PDCA, we must first know about the Agile Manifesto of 2001

Seventeen developers met in Snowbird, UT, in 2001, to discuss and develop an iterative method of programming to replace the traditional waterfall methodology

Iterations can exponentially increase the efficiency of software development; each stage is evaluated before going to the next one, thus preventing a chain of problems at the end. 

The agile methodology is actually an alignment of PDCA in which short term cycles of two weeks, called sprints, are performed to improve a software project. 

What are the benefits of the agile methodology? 

  • More frequent checks result in improved processes
  • Progress is evaluated more closely
  • Bugs get caught early on in the software development lifecycle
  • Rapid development cycles allow quick responses to changing market conditions.

Recommended reading: Agile vs Waterfall by Plutora. 

Conclusion

This post explained how you can implement the PDCA methodology to enable continuous improvement and how PDCA forms the basis of other methodologies such as agile and Kanban. All of these methodologies help organizations improve business processes. 

However, sometimes it’s useful to take a look at a simple model, like PDCA, that is the basis of those other methodologies. PDCA is based on continuous improvements and iterations which are used in almost every industry and will have continued relevance in the future. 

Want to get started with process improvement? Try out Plutora! Plutora offers a value management platform that measures and tracks different key performance indicators (KPIs) that you define. Furthermore, it helps you measure the outcome of each effort to bolster continuous improvement. In other words, you can use Plutora as a PDCA tool to support you during the different PDCA phases.

Michiel Mulders Michiel Mulders

Michiel is a passionate blockchain developer who loves writing technical content. Besides that, he loves learning about marketing, UX psychology, and entrepreneurship. When he's not writing, he's probably enjoying a Belgian beer!