We are wired to improve. We do not like doing the same things in the same way repeatedly. We intuitively find new ways of doing things, hopefully for the better. Even if it is not for the better, the next time we do the same thing, we remember what we had done and why we were not happy with it and try to implement a new way that we consider an improvement. Then we immediately compare the result of the “new” way to our expectations and decide if we should adopt this new way or try a different way. Sometimes we adopt the new way but still continue to make small adjustments because we “feel” like we can do better.
This is more prominent in sports. Let’s take a look at basketball. The very first time we learn how to shoot a basketball, we do not really think about it, just shoot and look at the result. The second time, however, we now have some feedback from the previous shot, and we adjust accordingly and see what the result is. We follow the same process in the consecutive shots and try to get even better.
If we dissect this process of getting better, we see that we first plan how we are going to shoot. Then we execute the shot. After we observe the result of our shot, we study the execution results by comparing the result to our expectations or predictions, which in this case is to make the shot. After all that we finally decide if we should stick with this way of shooting or if we should improve something about it for the next time. We do this repeatedly until we are satisfied with the results. If we were to become professional basketball players, then we would probably never be satisfied, and this cycle would continue indefinitely as we would need to improve under different conditions and raise our shot’s percentage.
This is a vicious cycle we implement naturally in everything we do. It’s not just in sports but in our daily lives, with our relations, with our children, with the way we drive, etc. We run multiple “improvement cycles” at any time. Some of these cycles will be quicker and we go into a second, third, fourth cycle very fast. Some of them have a slower feedback loop and implementation timeline. These take longer to get feedback and implement subsequent cycles.
We all have this ‘continual improvement culture’ naturally, intuitively, instinctively. If this is true, why do we have a hard time doing the same in organizations? Why is something so natural to us, unnatural in an organization?
There are many reasons for this, but what we can decide in sometimes a split second, takes longer and more discipline for the organization to achieve due to more people being involved in the process as well as other external factors playing a role. More people mean more mental models, more ideas, more agendas, and cultural and psychological backgrounds. When it is just one, the decision process is quick. However, in an organization with people from different backgrounds and mental models, it takes a process, a method and discipline to achieve a continual improvement culture.
We all improve in different ways, but the steps we go through are the same.
We learn by experimenting. When we experiment, we tend to do it on a small scale so we do not disturb the whole system or the process as it may be costly. We also do our experiments in a test environment. For example, athletes never try something new in a race or competition as it is too risky to try the unknown when the stakes are very high. In a race or competition, they execute what they practiced in training repeatedly. New techniques and improvements are all for training sessions.
Organizations are no different when it comes to improvements. The stages they go through are the same however we need to make sure there is uniformity and standardization in our approach so that everybody is on the same page. This alignment is necessary so different people specialized in different disciplines can communicate clearly.
Let’s look at how we can implement this way of thinking in our organizations and teams and have a continual improvement culture.
=> Continual or Continuous Improvement? There is a difference between them. With continual, you pause after execution and study the effects of the improvement before making more adjustments. Continuous is constantly improving without studying the results of the improvements made. Without studying you are not learning and seeing the effects of the improvement.
It makes it easier to communicate when we name things. Let’s call the stage where we plan how to make an improvement as “Plan”, when we execute it as “Do”, when we compare and study the results as “Study” and finally when we decide if we should continue or abandon the experiment as “Act”. You guessed it: it is a PDSA Cycle.
=> For the history of the PDSA Cycle see: http://www.apiweb.org/circling-back.pdf
The PDSA is represented as a cycle and for good reason: It is continuous. It is usually depicted in the following manner:
A lot of organizations or teams stop doing PDSA Cycles after only 1 iteration (1 cycle of P-D-S and A). However, as depicted in the figure above, the PDSA is a cycle and it usually takes a few iterations of the cycle to make sure the improvement is tested under different conditions.
PDSA’s power is that it builds upon the knowledge gained in the previous improvement cycle. We can imagine the PDSA cycle and its subsequent cycles as a spiral:
The knowledge is never lost, and it keeps building on top of the knowledge gained previously in the inner circles. Let’s take this spiral, turn it sideways and make it 2D to get the following perspective:
The continuous nature of the PDSA Cycles and why we must do multiple cycles is more evident in the image above. Often, the first iteration is used to get a better perspective of what is going on. For example, shooting a basketball for the first time.
We can have multiple variations of PDSAs for different purposes. For example, if we do not know what data to collect, we can run a PDSA for data collection purposes. After we decide if the changes need to be implemented (Act), we can run a PDSA for implementing the changes. Although the stages on each of these PDSAs are the same, the questions asked, and the tasks performed in these stages, depending on the type of PDSA you are running would be different.
We start with a charter. First, we write down the aim of the PDSA Cycle to determine what we are trying to accomplish. We then come up with a list of items to collect data on. This list will form the basis of our improvement measures and will help us to determine if the changes we test result in an improvement or not.
Writing the boundaries of the PDSA Cycle is a good idea. We do not want the test to involve more than what is necessary. Examples of boundaries could be the reception area of a doctor’s office, “Product A” Development or Packaging. Finally, we define our team to document who is involved with this project and to what capacity.
The next step is to answer the following question: What change will result in improvement? This is where running a PDSA Cycle comes into play.
The Plan stage usually takes a good amount of time especially on the first iteration of a new PDSA Cycle. During the consecutive runs, this stage is generally much shorter compared to the initial iteration.
It is usually perceived that we need to plan the test straight away. However, we need to know what we are planning for first.
In the Plan stage, we first look at the improvement measures we listed in our charter. We take these measures that are relevant to the PDSA Cycle we are running and make predictions as to what results we expect to get after running the test. Predictions form the basis for us to determine if we made any improvements or not. It is extremely important to write these predictions down. If we don’t record the predictions, once the test is over and the results are in, people will generally agree with the results and say this was what they expected all along anyway. Writing down and documenting the predictions gives us a chance to have an honest discussion.
We determine what information and data to collect based on these measures and come up with a data collection plan, if necessary. The data collection plan refers to how you are going to measure and collect information when executing the Do stage.
We now know what information to collect, how to collect it, and measure it. We can now devise a test plan on how to execute our experiment and move along the cycle to the Do stage.
This is the stage where we execute what we have planned in the “Plan” stage. We are running our experiment, collecting necessary data, etc. We also observe how this stage progresses in order to analyze our PDSA process later.
Study is where the learning and knowledge building happens. This is where we pause, study the results, analyze the data and see if there were any surprises that were not part of the plan (this is why we observe our PDSA process during the Do stage).
It is helpful to understand variation to filter out noise from real data. It may be useful to make use of machine learning software at this stage, especially if large data is involved.
After the Study stage is done, one of the following can occur:
- Implement a change based on what we learned from testing on a wider scale.
- Abandon the PDSA - go back the way we were doing things
- Run another iteration (a different test or same test under different conditions, with modifications or tweaks)
It is possible to adopt the current changes, while at the same time, continuing with iterations to see if further improvements are possible. The word “Act” means we need to act in the context of the PDSA based on the information in the previous 3 stages (as well as the collective knowledge gained in the previous iterations).
Depending on the situation, it is also a good idea to run the test a few more iterations and see if our results hold under different conditions.
This stage is a great example of double loop learning from Chris Argyris. As we observe what we have been doing in the “Do” stage, we may decide that there is a need to improve on the previous plan.
There are a couple of misconceptions about PDSAs that I am aware of. It seems like a good idea to mention them.
One misconception about PDSA Cycles is they are only used for improvement purposes. While they are generally used for improvements, they can also be used for product development or testing new ideas. We use PDSAs when developing our product.
Another misconception is that PDSA cycles are often seen as a slow-paced process where the absolute correct answer or improvement must be discovered before any action is taken. There is nothing in the PDSA that would require it to execute it this way. Once one understands PDSAs, it will become more evident that PDSA Cycles can be very fast depending on the context. As we have seen, the Plan stage is not about knowing-it-all or a huge specification approach, but more about planning what to do in the PDSA Cycle. For example, we use PDSAs in software product development as well as process improvements. Some PDSA Cycles can take anywhere from a few weeks to a few months to run, depending on the context (process or product development). In some cases, we go through a few PDSA Cycles within a week.
The PDSA cycle is a very simple and effective concept. This simplicity and its applicability to many different situations can be viewed as one of its main strengths. However, at the same time, this simplicity hides some of the complexity and some of the greatest challenges to use it successfully. Users need to understand how to adapt the use of PDSA to address different problems and different stages in the life cycle of each improvement project. This requires several skills and knowledge to be used in conjunction with the PDSA Model.
One problem that I have seen time and time again is the lack of uniformity in the methods and approaches used in PDSAs. Different teams or departments can have different mental models for each of the PDSA stages and this can be troublesome for the organization. The information and data vary in different PDSAs, but uniformity on the method is a vital step in building corporate knowledge and to get everyone on the same page.
Another issue I have seen is that organizations store their PDSA or improvement project efforts and related documentation in various places. To make matters worse, as departments or teams operate as siloes, they all have their own preferred storage systems. This results in no organizational knowledge being built because literally, nobody knows what the other teams or departments are doing. Add that to the rapid change and movement of mid-management usually seen in organizations and you have a serious problem in your hands.
A continual cycle is what humans do naturally in order to learn. This is “programmed” into us biologically and psychologically. Once organizations recognize they are made of humans and the capacity for this trial & error way of dealing with experiences is already extant, then they can focus on improving by enabling people to do what is in their nature. This feeds into the innate need for learning and improvement of people and the organization ultimately benefits.
=> shameless plug
Acquate offers consultancy and training on how to run PDSA Cycles effectively. We have a software as a service application that helps you manage your organization as a system, run various analysis tools with your data and manage your continuous improvement projects. We use PDSA Cycles and use The Model for Improvement as the base framework as described in the book, The Improvement Guide
. We developed the PDSA section of our application in collaboration with The Improvement Guide authors. If you are serious about your improvement projects and continual improvement, I highly recommend this book, and of course, our software for running your improvement projects.