An article by Alun Davies-Baker, Management 3.0 Facilitator explaining the PDCA model, that becomes relevant when looking at uncertainty and change management.
According to Voltaire, “doubt is an uncomfortable condition, but certainty is a ridiculous one”. Unfortunately, or perhaps, fortunately, I didn’t have this retort in mind when I was being shouted at by my CEO for not delivering what I had apparently ‘promised’.
When I tell the story of that project, many people have a similar story to tell – stakeholders and management are often uncomfortable with uncertainty. When they hear numbers about time and budget they only remember the ones they like, usually the smaller ones.
Those of us from the Management 3.0, Agile and Lean communities, understand that predictive, upfront planning is often a recipe for failure. What Voltaire stated is true for a complex adaptive system, certainty is an illusion because the exact future is still unknown.
There is no such thing as complete certainty. For example, I used to commute by car to work. Same car, same route, every workday. Guess what? It didn’t take the exact same time every commute.
Google Maps was good at forecasting my journey time based upon the latest travel information. It would update the initial prediction based on new information, such as weather, the weight of traffic, accidents, road work, etc… Sometimes, the actual route to my destination would dramatically change.
Google learns from system feedback to refine the forecast. The world is made up of interrelated and interconnected systems that are infinitely complex. Anyone who says they are 100% certain is telling you they can predict the future.
Whether innovating a new product, running a project or executing standard operational processes, the exact outcomes are unknown. Until we start doing something, everything is a guess or an assumption about what we think will happen. We need to find out how wrong we are as soon as possible!
The good news is that teams and organizations can usually do a lot to manage uncertainty by learning from feedback and experience. The best learning comes by getting an early version of a product, plan, or whatever out there in the real world.
The PDCA Cycle, also known as the Deming Cycle, the Deming Wheel, or the Shewhart Cycle, PDCA is an iterative and incremental practice for controlling and continuously improving processes and products. It is a way of finding out how wrong we are and learning from that knowledge.
The four steps of the PDCA Cycle
- Plan – what we will do, how we might do it and, importantly, why we’re doing it. This may relate to an operational or a project process for example
- Do – it (execute the plan, process, procedure)
- Check – the results and outcomes in terms of the solution and our approach to delivery
- Act (sometimes Adapt) – use, or act upon, what we have learned to inform our next Plan step.
PDCA is a commonly used approach, as it is simple, natural and applicable to many situations, such as:
- The creation and the continuous improvement of operational processes and procedures
- Innovating or maintaining product or services in our marketplace
- Dealing with uncertainty when running projects or programs. (NB: This is the main focus of this post)
The explanation of the PDCA model is also part of the Management 3.0 Change Management module, that will be discussed in our Foundation Workshop.
Deming, Lean & the Quality Movement
The approach is attributed to W. Edward Deming but has roots in earlier theories and practices. When Deming introduced PDCA to Japan in the 1950’s he referred to it as the Shewhart Cycle after his mentor at Bell Labs, Walter A. Shewhart. It was widely adopted by Japanese businesses and so became known as the Deming Cycle.
The adoption of PDCA in Japan led to the creation of the Toyota Production System (TPS) by Taiichi Ohno and others. TPS has given birth to the Quality Management and Lean movements across the world, first in manufacturing and increasingly in all aspects of business organizations. In turn, Lean has greatly influenced the Agile movement.
In more complex situations, such as a change project or product delivery the exact path we should follow is unclear. This reflects many modern roles in the workplace where there is a need for creativity and innovation. In such a scenario, a team would do well to adopt an adaptive and experimental Lean or Agile approach, and in fact many do.
In Lean and Agile, each PDCA cycle focuses on a small chunk of the overall work:
- Teams plan to focus on small batches i.e. a subset of the overall requirement
- Earlier reviews and testing means quality problems are caught sooner than later
- Small batches mean quicker releases and therefore quicker customer feedback
- Frequent market feedback enables teams to validate value assumptions – ‘did they really want that feature?’
- Team effectiveness is frequently reviewed to find improvements
Another application might be improving the efficiency of operational processes using a Six Sigma approach, based upon PDCA. The goal is to remove redundancy and minimize process deviations. This enables improved efficiency, monitoring and control leading to reduced costs over time.
Origins of the Deming Cycle
The origins of PDCA go back even further than Deming and Shewhart to theories around experimentation and learning.
The scientific method, as developed from the work of Francis Bacon (Novum Organum, 1620) has a similar cycle:
- Hypothesis (Plan) – our big idea, what we think will happen
- Experiment (Do) – what we do to see if our ideas are right or wrong
- Evaluation (Check / Act) – how did we do? What have we learned? What will we do differently? Etc, etc
- Rinse, repeat…
Another similar idea is that defined for learning by John Dewey:
- Discover (Plan) – thinking up new ways of doing things (hypothesis)
- Produce (Do) – performing the new ways of doing things (experiment)
- Observe (Check / Act) – see the outcomes of our actions leading to a new Discover step (evaluate)
- Rinse, repeat…
Learning is never just an intellectual exercise. Nor is it a matter of changing behavior. It is an interactive process linking the two in a spiral of continually expanding our capabilities.
Peter Senge, Building Learning Organisation, Journal for Quality and Participation, March 1992
We think about how to do something and then do it. The act of doing helps us learn if we were right or if we need to make a change. So, PDCA is a learning cycle that helps teams identify problems and opportunities to be addressed. Such approaches help maximize the use of learning to improve our knowledge to inform the next set of activities.
PDCA Steps in more Detail
Plan
During the Plan step, like the Dewey learning cycle Discover step, the team comes up with an overall goal and ideas on how to get there.
- Why are we doing it?
- What is the change we wish to make?
- How will we do it?
- How will we know we have done it?
First of all, to get people moving, they need a goal. They need something to change for.
Jurgen Appelo, How to Change the World: Change Management 3.0 (p. 13)
An overarching goal enables effective decision making by giving a firm sense of purpose and destination. A good goal will connect with people’s intrinsic motivations better than catchy slogans and clever straplines. If people can connect to the goal, they are more likely to willingly come on the journey.
We can be smart about the way we start and look for teams and activities that reflect where we want to get to as an organization. It makes complete sense to build on current successes and momentum.
Once you know the destination, the best way to get started is to find an example of things going well somewhere and then to copy the good behaviors. Try to find a situation that can act as a shining example of how you want things to be, or in other words, find a bright spot of good behavior.
Jurgen Appelo, How to Change the World: Change Management 3.0 (p. 14).
Teams can start by analyzing the existing data, discussing current knowledge and successful experiences to develop possible options. It is also a good idea to set intermediate goals to move the team forward to the overall goal.
It is important to think about metrics and how we will measure the impact of our actions. Planning to do some benchmarking during the Do step is a good idea.
NB: Beware of too much analysis and planning – plans do not need to be perfect before we start. The value we get from doing (Do) is that there will be unforeseen learning and realizations that cannot be planned upfront (learning is not purely an intellectual activity). We want to find out how wrong we are as soon as possible. Failing early is still valuable to learn what not to do.
Do
In this step, we Do what we planned as the first steps towards our overall goal. How you proceed is context-specific but early feedback is desirable to learn what works and what does not.
In software development, this might be after a few weeks of work (or sooner). For a business change program, the feedback loop is likely to be longer to assess the impact of organizational changes.
A grand vision is necessary. But the crucial steps to go in that direction should be simple enough for everyone to understand.
Jurgen Appelo, How to Change the World: Change Management 3.0 (p. 15)
Either way, the aim is to test out our ideas in a way that minimizes risk and see usefully significant outcomes before we have expended too much money and time.
Check
Here we close the feedback loop to analyze the results based on our benchmarking activities. At the very least there is a discussion to see if our actions have had the intended impact.
You have to validate what works and get rid of what doesn’t. In other words, you need feedback.
Jurgen Appelo, How to Change the World: Change Management 3.0 (p. 17)
There are different views to consider when we check how we did. Does the solution work correctly and does it meet the actual business needs. The other aspect is whether the process we are following to deliver the solution works – is it effective or should we refine it too?
Act
In the final step, we look at how to make improvements to our process. Observations, from the previous steps, help us identify issues with our ways of working and the solution. More often than not, these issues were not foreseen and are only identified after they have occurred.
At the end of this step, we should have come up with better ways of working or even a refined overall goal. This learning and refinement feed into the next Plan step as the PDCA cycle repeats.
Short feedback cycles are better than long ones. Knowing whether or not something works, prevents you from investing for too long in a bad approach. Fast feedback reduces the risk of getting it wrong, and gives you more leeway to experiment. And when things are still fresh in people’s minds there are more details that they can reflect upon when they give you feedback.
Jurgen Appelo, How to Change the World: Change Management 3.0 (p. 19)
Problems and errors identified should not be repeated in the next cycle of PDCA. We have the opportunity to make informed and timely course changes. Whatever the context, the PDCA cycle repeats based on improved knowledge with the next experiment.
PDCA in Action
As mentioned above, PDCA is a natural way of working. It is how most people learn without even realizing it. Below are a few examples where we see PDCA in use.
Within most Agile frameworks ‘timeboxes’ are used to control and manage work. A timebox is a fixed period of time with an overall goal. In Scrum, a timebox is called a Sprint and in SAFe (Scaled Agile Framework) and other frameworks it is known as an iteration
Agile timeboxes (Sprints / Iterations) are split into smaller timeboxes that we can map to PDCA
- Plan – a team starts with Timebox (Sprint / Iteration) Planning. What is the timebox goal, what can we deliver, and how will we do it?
- Do – execute the plan to build and test the product to meet the goal
- Check – hold a Timebox (Sprint / Iteration) Review to see how we did
- Act (sometimes Adjust) – finally, there is a Timebox (Sprint/Iteration) Retrospective to see where we can improve our ways of working
A more traditional waterfall project can also be thought of as a long PDCA cycle.
- Plan – a project team run analysis and design phase to create a Project Plan
- Do – the plan is executed e.g. through a development phase
- Check – the project team then check the deliverables during a test phase
- Act (sometimes Adjust) – finally, there is some kind of project review phase to assess success and lessons learned
Often the issue with such a predictive planning approach is that the feedback loop is too long. We do not get feedback early enough to make changes based upon learning. Solutions are then built based on assumptions and a general misunderstanding of business needs.
Looking for great tools to enhance your retrospective? Find them here
Conclusion
PDCA is a simple practice that can be applied to many different contexts and at different levels of scale. It has its roots in ideas and practices that go back centuries and have endured because they are pragmatic and common sense.
Like all adaptive systems there needs to be buy-in and support from senior leaders. Modern leaders need to understand and be comfortable with uncertainty. In many modern organizations the development of products depends heavily on teams innovating and standing out from the competition.
Leaders need to foster a ‘safe to fail’ culture that supports creativity and experimentation. Teams need room to learn, even if that means failing part of the time.
There is no certainty; there is only adventure
Roberto Assagioli
Header image by Elizaveta Dushechkina (via Unsplash)
