Batenhorst on Revamping SOPs for Continuous Improvement: Lessons from a Collision Shop

At Pacific Collision Center, our SOPs are designed with an expected quality outcome. This means that the process steps outlined for that particular task will yield an expected level of quality as long as all those steps are followed. This was designed intentionally, with a goal of reducing inspections of work and allowing a consistent work product to be produced. For every step of the repair process in our facility, a process board exists, which is hung up in that work area. In between each process, there’s a quality control (QC) checkpoint that exists during the hand-off to ensure that the work output was self-checked by the individual who produced the work and also checked by the receiving team. Lastly, a posted “standard” of work is available for the team to measure the work they produced (and for the employees who are receiving the work) against a sample of what the work needs to look like. On paper, and in the shop, it sounds like a lean junkie’s nirvana. I have been fortunate to work with this system for the past 20 years. In every location I’ve worked in or implemented this system in, it has been massaged and customized for the team.  

But that is not reality. Reality is, we are human beings, not robots on an assembly line. Feelings, judgements, opinions, frustrations, problems at home, and many other scenarios exist every day in my shop. And yet our process boards and systems hang up all over the shop, telling the tale of a very streamlined and systematic approach to work. It’s all great until it isn’t. In my case, for the past 3 months, I’ve noticed a sharp increase in delays pertaining to quality control being skipped, and the quality of work declining. Don’t worry; we still catch it and fix it before the car leaves the shop. The first thought for why this is happening might be, “they must be busy, and people are rushing”. Like many other body shops across the country, we have seen a 25-30% reduction in volume over the past 2 ½ - 3 months. A delay in my facility is any process deviation that results in additional rework that consumes more than 10 minutes of time to resolve. I track this on a spreadsheet and review the data monthly to look for trends. For the majority of my team, this delay metric is also measured on their performance reviews. 

It’s easy for me to sit in my office and attempt to quarterback this problem alone. In fact, that’s the default problem-solving approach most managers take. It’s also the main reason why problems continue to persist. A manager is not on the front line doing the actual work; the team is. Without the team’s involvement in solving the problem, the buy-in to your solution is likely to result in forced compliance, which may yield a temporary improvement and damage the culture of the team. That’s where PDCA comes in as a much better alternative. Plan, Do, Check, Act is a simple tool that requires no fancy software. It's just a dry-erase board, your team, and a facilitator.  

Plan: To address my QC/Quality problem, I needed to gather data beyond my delay tracker. I needed the raw, unfiltered truth from my team. I created a 10-question anonymous survey, which was simple and high-level, to obtain their feedback regarding the effectiveness of our quality control system. It included a response range of 1 = strongly disagree, and 5 = strongly agree. After receiving their responses, it revealed to me that overall, they have the knowledge and training to do what I am asking them to do, and the majority of the shop did not feel the QC/Quality system was broken, but that it did need to be improved. At this point, I created a “Quality Committee” within the shop. I asked for three volunteers to work with me on this project: one from our non-production team, one from our paint team, and one from our body team. I provided them with another document that had seven discussion points to get more specific responses on the results from the survey. Each representative of the committee went back to their teams, took notes on their responses, and reported back to me.  

Do: During the next meeting, we learned that the shop felt that some of the key elements of our QC process were creating stress and pressure that caused employees to push work through the shop even though the quality didn’t meet the standard. The No. 1 reason for that was not enough time during the QC process. The feedback from the team was to remove the time constraint we had created as well as the physical location of where the QC needed to take place (We had a specific stall for QC). The quality committee made some suggestions to me, which I agreed would be good to test to see the effect on our delays. The time constraint was removed; QC will now take place in the stall where the work was performed. We also decided that the QC handoff will be done together with the work producer and the work receiver, not independently. With a plan in place and congruence achieved within the committee, I drafted a short document that summarized these changes. I met with the entire shop the following day, and we reviewed the changes. We are now in a live beta test of these changes. I set a goal to reduce the quality control/quality-related delays by 50% compared to our current levels.  

Check: With the beta test system deployed, we will monitor the results for the next two months and see how it is performing. Along with me, the quality committee will check in for feedback from the team and review any unforeseen outcomes.  

Act: Once the beta test is completed, the entire shop will meet again to decide if this test was successful. If it worked to achieve our initial goal, we will then make this the new permanent system for quality control. If it fails to achieve the goal, we go back and do another round of PDCA — armed with the new data we obtained from the test. It’s okay if it fails as long as the team makes a genuine effort to test the change. Armed with their buy-in to creating a solution, employees will feel included and heard.  

I didn’t always use PDCA. In fact, the first time I did it on my own without my mentors guiding me, it was intimidating. I feared my team wouldn’t get it, and we would just make the problems worse. I was surprised to see the opposite outcome; it improved trust between my employees and me as well as each other. Accountability was easier for them to deploy among themselves, and they gained a tremendous sense of accomplishment. This cemented PDCA as one of the most important tools I have for resolving problems.  

My last point for my readers to consider is how long your current SOPs have been in place. Who designed them? Do they accurately reflect what you are doing today? How are those SOPs being used? Or are the boards just wall art that people walk by every day? I intentionally use cheap foam board to make our SOPs boards, as we strive to review our processes every 6-12 months to try to poke holes in them. In my case, my QC process had evolved in minor ways here and there, but my team has dramatically changed since the original system was designed three years ago. Some of those employees who influenced that design process are no longer employed by us. There are a lot of great resources on the web for PDCA, and I hope to run into some of you at a future event and hear how it worked for you.