For those responsible for management systems you have most likely noticed the elevation of continuous improvement and specifically the use of a Plan-Do-Check-Act (PDCA) cycle in related standards, guidelines, and even regulations.
Here are a few examples (API RP 1173, ISO 9001, ISO 22301):
The use of improvement cycles has been effective in specific contexts and areas. So it’s not a surprise to see PDCA (or similar) cycles also being applied to management programs and systems. However, guidance on what and how PDCA is to work at the systems level has been few and far between.
At a macro level the same acronym (PDCA) is being used however the details of what is to happen within each step is vague, and differs from standard to standard. In some cases PDCA is being used as a process to build the system as if it was a project methodology. In most cases PDCA has been re-defined as the model for the system processes within a given standard.
It looks like PDCA is used as magical pixie dust sprinkled everywhere where things are managed.
If you are confused by all of this, you are not alone. Research has shown that the inconsistent use of PDCA has contributed to the failure of not only what we might call “Management PDCAs” but traditional process improvement as well. It is difficult for organizations to get the benefits from PDCA when it is being re-defined, co-opted, and misapplied.
In this article we take a look at “Management PDCAs’”and how these compare with traditional continuous improvement cycles. We will try to clear out some of the confusion and find out if Management PDCAs are going to be a hero or end up as a zero – not amounting to very much and perhaps making things worse.
History of PDCA
There is much written and available on the topic of continuous improvement. PDCA is not new and has evolved over the years. Here are a few of the familiar ones you probably have heard or know about:
Deming Wheel
Shewhart Cycle
Japanese PDCA
PDSA
PDCA / A3 (Lean)
DMAIC (Six Sigma)
Kaizen / Toyota Kata
Observe-PDCA
OODA
Build-Measure-Learn (Lean Startup)
And others
At a basic level, PDCA is a model for continuous improvement that uses iterations to optimize towards a goal. In practice, focusing on smaller improvements with frequent iterations accelerates learning and establishes behaviours that build towards an improvement culture. When this is done well it results in a virtuous cycle where both action and behaviours reinforce each other delivering more and better improvements over time.
No wonder management standards and regulatory bodies are looking at harnessing the power of PDCA – it has been a real super power.
What all these continuous improvement cycles have in common is that they are all meta processes that stand outside of what you want to improve. You can in theory (practice may be different) apply them to improving tasks, processes, systems, programs, and many other things.
Each encapsulates a methodology where the specifics of what happens inside the cycle depend on what you want to improve. For example, some are focused on problem solving, while others on discovery of better ways to achieve a particular target or goal.
The majority of them are most effective when applied to incremental changes at the process level and less so at involving system-wide improvements.
What is the Problem with Management PDCA?
Let's now take a look at how PDCA is being used by many management systems standards and guidelines. We will consider:
PDCA as a project methodology
PDCA as a systems model
PDCA as a new variant for continuous improvement
PDCA as a replacement for CAPA (corrective actions / preventative actions)
PDCA as a project methodology
Many have adopted the practice of viewing all management processes through the lens of P-D-C-A.
While PDCA may define a natural process for management where we plan the work, work the plan and then check to make sure the plan was done, this is not the same as continuous improvement and what PDCA was intended for.
As an example, ISO defines PDCA in the following way:
PDCA is a tool that can be used to manage processes and systems.
P-Plan: set the objectives of the system and processes to deliver results (“What to do” and “how to do it”)
D-Do: implement and control what was planned
C-Check: monitor and measure processes and results against policies, objectives and requirements and report results
A-Act: take actions to improve the performance of processes
PDCA operates as a cycle of continual improvement, with risk‐based thinking at each stage.
On paper this sounds good, but this is a form of linear thinking. in this case PDCA has been flattened out to form a sequence of steps. There is no improvement cycle and the only activity to improve is specified in the ACT step not the DO step where it happens in traditional PDCA.
PDCA as a system model
Several management system standards have conceptualized their management activities as part of an overarching PDCA cycle. In essence, PDCA has become a system cycle and not an improvement cycle in the traditional sense.
To help us understand this we need to consider the difference between management systems and management programs. At a high level when you want consistency you use a system; when you want to change something you launch a program.
Management systems, which is what ISO and others provide standards for, are meant to maintain state which means consistently achieving a specific level of performance with respect to such things as quality, safety, security, and so on. This is accomplished by monitoring processes and taking action to correct for deviations in whatever way that is defined.
Management programs, on the other hand, are used to change state to achieve new levels of performance. This is a feed-forward control loop that adjusts system capabilities to achieve higher standards of effectiveness. This fits closer to the notion of continuous improvement towards better outcomes rather than deviation from standard.
Both feed-back and feed-forward processes can benefit from PDCA but only partially. The benefit of iterations only occurs as often as "defects" are discovered or "standards" are raised. This limits the scope of improvements to those events and mostly to the reactive side of equation when risk has already become an issue.
PDCA as a new variant
When standards envision their systems as improvement cycles they are creating a new variation of PDCA that works differently than traditional PDCA cycles.
The processes that are linked to Plan-Do-Check-Act steps are intended to operate simultaneously. For example, in the case of AP RP 1173 Pipeline Safety Management System, you never stop doing DO'ing operational controls to CHECK safety assurance.There is no sequencing of steps, or iteration happening here. Instead, PDCA is used to describe a function that the set of processes performs.
This is different than conducting a PDCA followed by another PDCA and then another until you achieve your goal.
PDCA as a replacement for CAPA
Continuous improvement in the form of PDCA has been placed on the reactive side and embedded in the system as mostly a replacement for CAPA.
All too often I have seen PDCA used to define a process for actions. Again, this is linear thinking applied to managed work. There is no iteration, no striving towards a goal, no incremental improvement.
From Zero to Hero
What seems to have happened is that we have a conflation of improvement strategies all under the umbrella of PDCA. It is no wonder why there has been confusion and lack of success.
For PDCA to be more than words on page (or magical pixie dust) it should follow the principals defined by each methodology. Failure to follow the principals has been reported as a large contributor (perhaps the largest) to why PDCA has not been effective.
With respect to Management PDCAs these should:
Not be used as a process to build a system. PDCA is intended to improve the system after it has become operational. PDCA is a cycle that is repeated not a linear step of project steps. There are other methodologies to establish systems such as Lean Startup for example.
Not be used as a replacement for CAPA. PDCA should instead be a proactive process for continuous improvement focused on staying ahead of risk and prevention not only on reacting to incidents.
Be part of the system but not the system itself. Mapping management system processes to PDCA steps misrepresents management system dynamics which will lead to ineffective implementation and operations.
Be repeated as often as possible to develop habits and leverage iterative improvements. The power of PDCA comes from proactive actions reinforced by proactive behaviours to establish a virtuous cycle. What most have instead is a vicious cycle – reactive actions reinforced by reactive behaviours.
Where best to use PDCA?
Continuous improvement needs to occur across all levels but at a minimum incorporate be used to improve processes (loop 1), and improve systems (loop 2):
Loop 1: At the process level ,PDCA should focus on improving efficiencies and consistency. This is where Lean practices are most useful. Process level improvements tend to utilize existing capabilities to reduce waste and improve alignment. These improvements can be accomplished using frequent incremental changes over time.
Loop 2: At the program level PDCA would focus on improving effectiveness of a system. This could be called a Program PDCA. This should follow approaches that utilize experimentation and system level interventions. System level improvements benefit from step-wise improvements that elevate capabilities to effect better outcomes. It is more difficult to incrementally improve through a maturity curve.
What do you think?
Kommentarer