1. Win Supervisor Support
We have all heard about the importance of top management support for a successful change project. Top management support is great, but even more important on a process change projects is the support of the supervisors over the process. They are the individuals who will help you to understand the major pain points and they are the individuals who will sustain any improvements that are implemented.
Often these individuals are not supportive of changes to the process. They have a very parochial interest in the process – it is their job to ensure it is performing well. They may view a project to change it as an attack on their ability or authority. These individuals are often suspicious of the change and will actively work to undermine it. So as you approach the change, don’t attack the old process; which will be seen as an attack on the supervisor of the process. Rather acknowledge the benefit it has brought the business in the past and focus on how the changes will improve the performance for the new conditions that the process must operate under.
2. Fix the Customer’s Pain
Often this type of project is subject to scope creep. There are many things that could be done to improve the process; but the project team is constrained by money and resources to only implement a few of the potential improvements. Prioritize the potential changes in two ways. First prioritize by the pain the process is causing to the customer of the process. Fix the major pain points first. When there are multiple ways to fix a pain point, then select the approach based upon the most important project constraint, either time or money.
When you start to work on a process, the individuals in the process often have great ideas for improvement. Many times these ideas may be an improvement from the perspective of those working in the process, but they may have no impact on the individuals or organizations that experience the result of the process. Ensure you have addressed the customer’s pain, and then accommodate all of the other changes that you can.
3. Use Current Proven Technology
Many of the process changes today will involve some level of technology or system implementation. A difficulty with technology for processes is that the technology changes rapidly. About the time that you get all the bugs worked out of a new system, it is obsolete and must be replaced. So to minimize that companies will sometimes leap to the new leading edge technology hoping that the time until obsolescence is further off. But with this leading edge technology, there are still many elements that are not well characterized or that are discovered while doing the improvement project. So what is the answer? Try to use current technology that has been proven through multiple applications.
Now that is not to say you can’t use brand new technology. However, when that is the case, the project is a higher risk project. Project estimates should be adjusted and budget and schedule reserves should be allocated to the project because there will be unexpected technical problems that must be resolved.
4. The Changed Process Must Be Simple
When creating changes to a process, you should always be looking to simplify any manual steps or personal interactions with the process. Simple processes will run faster and with higher quality. The principle is known as Poka Yoke, or mistake-proofing. It is not the same as “dumbing – down” the process. I am not suggesting that you curtail any of the performance standards or options, but rather, that you examine each step and determine if there is another way to accomplish that activity that does not require manual interactions, or that makes it easier to accomplish that step correctly.
An approach I have often used is to determine what a “standard normal” run of the process would look like. I then do two things. First create a screen early in the process to determine if this is a “standard normal” run, and then simplify and automate the main process for that “standard normal” condition. The non-standard runs go through a more manual process, requiring more interactions and decisions. This approach will accelerate and improve the quality for the “standard normal” runs. And allow the process operators to focus on the unusual and difficult items without slowing the others.
5. Test and Test Again
One of the biggest problems I have found with process improvement projects is the verification test run that goes flawlessly, followed by the implementation and operational runs that are a disaster. A process improvement is not demonstrated just because you were able to do it once in a row. A pilot run is needed. In addition, the pilot run is susceptible to the Hawthorne Effect which means that the improvement is because everyone is watching while our best people do the work. When the attention is gone and the average, below average, or new worker is involved in the process; the performance improvement is not to be found.
I suggest a pilot run of the process with sufficient quantity to establish “normal flow.” If it is a customer interaction process, you should develop customer use cases that span the range of normal customer interaction. If it uses technology, should test it with all potential operating systems or applications. Finding the problem now while the project team is in place and can fix it is far better than finding the problems after the project is over and success has been celebrated..
Following these five tips will bias your process improvement project for success.