Change is difficult in most organizations. It is easiest to just keep doing what has been done. Once something has reached a point where the need for change has been acknowledged how the organization proceeds is important.
The first part of the process isn’t in the scope for this post; but most often the process should start by using the PDSA cycle to understand the current situation, decide what to try, test improvements and iterate over those improvements until an improvement has been deemed worthy of being deployed widely.
The PDSA cycle process automatically includes studying the results of a possible change as part of the process. And it includes collecting evidence on the results of deploying an improvement widely and studying those results. That evidence will most importantly show if the expected results are achieved (it is far more common for changes to fail when put into action than most people acknowledge). If the expected results are not achieved learn why not, what happened?
Even though the plan is to create an improvement that can be deployed more broadly it is very possible for that to fail for some reason. A common reason for failing is failing to understand the necessary conditions for success. Yes, the PDSA test worked, but maybe you didn’t realize that result was really dependent on the special knowledge and skill of a critical person involved in the PDSA process, or the location where the test was run was different enough from alternative sites that the improvement wasn’t robust enough to be deployed more broadly.
There are many reasons the change may need to be iterated over to adapt it to different conditions. The important factor, that is far too often overlooked, is to collect evidence on the result of the change as it is deployed and to study that evidence to determine if the improvement is able to be deployed more broadly without modification. It may be that you learn more PDSA is needed as part of the process to deploy it more broadly.
Part of the Act phase of the PDSA cycle should be to make a prediction about the level of support needed to deploy the improvement more broadly. In some cases the process of deploying the improvement more broadly will need its own PDSA (a PDSA on how to deploy the improvement). This could be the case for a complex change that where it would be valuable to learn what factors should be considered in different conditions (suggestions for what factors to consider in doing PDSAs at different sites at the time of deployment for example). Or the deployment PDSA could be to study what conditions are required to adopt the improvement or to create alternative suggested improvements depending on various conditions.
For simple PDSA improvements, or to deploy the improvement in similar situations these complications do not come into play. However, it is always critical to include process checks to evaluate if the improvement works as intended. It is amazing how often changes are adopted without any process to evaluate the effectiveness of the change. This leads to many problems and creates conditions where the rate of improvement is very slow.
The rate of improvement is increased by improving how the organization improves. Monitoring the impact of changes is needed for this reason (to learn what is working well systemically and what weaknesses exist in how the organization is improving) as well as to make sure each change does actually improve results as expected. And if the results do not improve, to make sure those involved in the process are doing what should be done, and if results are even better learn why and share that with others that have be included as part of the wide deployment on the change.