Two process improvement methodologies are widespread. The first, PDSA (Plan, Do, Study, Adjust), is often used with the Lean business management approach. The second, DMAIC (Define, Measure, Analyze, Improve, Control), is most often associated with Six Sigma’s statistical process control method.
Related: Support and Facilitate Each Step of Your PDSA Process with KaiNexus
Both are extremely useful tools, and we encourage you to learn more about them, but today we want to take a deep dive into the elements of any effective process improvement plan, whether it is within a structured methodology or not.
Spoiler alert: Your process improvement plan will result in a new standard way of performing each task that represents the current best practice. It will be documented and performed consistently no matter who operates the process.
If that is not in place today, for the process you want to improve, it is essential to start by stabilizing the process and ensuring everyone is doing the same things consistently, even if you don’t like the result.
Why? The only way to know if the change you implement is an improvement is to measure baseline results. That’s not possible unless the process is performed consistently. So even if the current practice is bad, enforce consistency for long enough to get some objective measurements on which you can judge future results.
You want to improve your process for a reason. Perhaps there are obvious defects and the need for rework. Or maybe you know there is a better way to cut costs, speed up cycle times, or use your team more efficiently. At any rate, you know your results are not what you want them to be, so now is the time to define the problem.
Next, it is critical to determine what is causing the problem. This is how you move from workarounds and Band-aids to meaningful solutions. When looking for the root cause, remember to focus on processes and workplace conditions rather than blaming people. “Human error” is an easy label, but there is room for improvement if the process isn’t error-proof.
The people who operate the process must be involved in identifying the problem and its cause. Ideally, the improvement projects are initiated by the people closest to the problem, your customers, and your products. When people are involved in designing the improvement plan, they are more invested in its success, more likely to follow the standard operating procedure, and better able to sustain improvement.
A helpful technique for finding the root cause is called the 5 Whys. You start with a problem statement, then ask “why” until the cause is identified. Usually, about five iterations do the trick, but it may take more or less, depending on the problem. Here’s a simple example.
Problem: My car won’t start.
Why?: The battery is dead.
At this point, with just one why, it is tempting to jump to solutions and replace the battery. But we know better, so we ask why again.
Why?: The alternator is failing.
Have we found the root cause? Maybe, but let’s ask why again.
Why?: Too many accessories are straining the charging system.
If I replace the battery and the alternator but don’t do anything about the accessories, I have not addressed the root cause, and my car will eventually fail to start again.
Now that you’ve stabilized your processes, established baseline results, and identified the root cause of the problem, defining what will constitute an improvement makes sense. Of course, your goals will vary based on your business and the type of process, but regardless, they should be as specific and measurable as possible. Examples might include:
When setting goals, keep in mind that what you are looking for is incremental improvement. Process improvement is ongoing work, so you don’t have to get to perfection in one shot. Instead, frequent small changes are the path to success.
As is the case with the car example above, sometimes identifying the root cause of the problem will make the way to achieve your goals clear. In other cases, you’ll need to evaluate multiple possible solutions to the problem and choose the one with the highest chance of success. The change may be something as simple as changing how workers communicate, or you may need to redesign the process entirely.
Now you are ready to document the project plan, implement the proposed solution, and measure the results. How long you will need to wait to know if your solution was effective depends on the nature of the process and the type of change. The process must be consistently performed during the measurement phase according to the new practice. This becomes somewhat of a “candidate standard” while you wait to gather enough data to determine if your change worked.
Once the data is in, a few possible results will guide the next steps.
The change achieved the stated goal. Amazing! You can now move directly to Phase V.
The change represented an improvement but did not meet the stated goal. Incremental progress is still progress, so it may make sense to move to Phase V and start another improvement cycle to try more solutions. It also may be the case that there is a way to amplify the change you implemented to get more of the results you seek. In that case, make some slight adjustments and gather more data.
The change did not achieve improvement. In this case, you have a couple of things to think about. First, if there were other proposed solutions, you might implement one of them and then measure again. Another thing to consider is that perhaps you did not find the root cause of the problem after all.
If you’ve achieved some or all of the desired results, it is time to ensure that the improvement holds up over time. The first thing to do is share and document the new best practice and make sure it is adhered to consistently. It is also good to set a cadence for measurement against your new baseline result to make sure that it doesn’t slip after a month or a quarter.
This approach to improvement gives you a structure that you can apply to any process as often as needed.