Check to Solve Problems

A simple, pragmatic problem solving methodology is the Plan, Do, Check, Act (PDCA) approach. It begins with a Planning phase in which the problem is clearly identified and understood. Potential solutions are then generated and tested on a small scale in the "Do" phase, and the outcome of this testing is evaluated during the Check phase. "Do" and "Check" phases can be iterated as many times as is necessary before the full, polished solution is implemented in the "Act" phase.

The PDCA cycle model is built as a continuous loop and this loop ensures that processes are frequently revisited. This is very beneficial to organizations because if something changes or isn't working to satisfaction it can be changed. It also reduces the chance of something that isn't quite working to be inadvertently overlooked.

The four phases in the Plan-Do-Check-Act Cycle involve:
Plan: Identifying and analyzing the problem.
Do: Developing and testing a potential solution.
Check: Measuring how effective the test solution was, and analyzing whether it could be improved in any way.
Act: Implementing the improved solution fully.

It is the Check stage of the process which often lacks attention. The Plan stage is never a problem because it’s an obviously interesting stage for which there will be no shortage of strategist and project manager to pick up the baton. Do and Act are both production stages to which clear activities can be assigned. The Check stage, however, is often the most subjective of the stages and will typically receive the least focus. If it’s true that information is king, then it follows that the Check stage of the PDCA process is the most important as it fuels the other stages by introducing recommendations which will keep the cycle alive.

A recent car repair experience has been a great reminder of the importance of following the PDCA cycle with particular emphasis on check. While having a tail light replaced we asked to have the oil changed. Upon the oil change and subsequent inspection the garage found the serpentine belt was worn and needed replacement. They changed the belt and this is where the trouble begins. When you first start the car and turn the wheel the belt squeals. This happened for a few days before we had to make another repair appointment.

The garage looked at the car and said the water pump was leaking onto the belt and it needed replaced. The chain of events didn’t seem to make sense so we asked if the belt still squeals to which the repairman said no. We picked up the vehicle and immediately found the belt was still squealing. Now my wife who is not too happy lets into the repairman with the 5 whys to which resulted in an I don’t know. So now we have to bring the car back so they fix the problem we brought the car in for, the squealing serpentine belt.

It was apparent that the repair garage did not check to see if their hypothesis that the water pump leaking was the root cause to the squealing serpentine belt. If they had they would have found what we did which that it still squeals. Hopefully then they would have continued to troubleshoot the problem until they reached the root cause. After which they could confirm their solution solved our problem.

Hopefully, this example will serve as a lesson about the importance of checking that your solutions do in fact address the root cause. When you solve problems in your business remember you are not done until the testing is conclusive. The beauty of the PDCA beyond its simplicity is the iterative problem solving cycle which if followed gets to the root of the problem.