Implement Robust Corrective Actions – 3 Tips and 2 Pitfalls
Hey, Congratulations are in order! You have successfully gone from observing symptoms of undesired process outcomes, worked your observations into a problem statement, analyzed the symptoms and problem using one or more of the many useful methods, and nailed down the root cause of the underlying problem.
You are 80% of the way to the finish line, so don’t stop now! One more step: Corrective Action.
Background
My colleague Taylor C., whom you met earlier, called me recently. Her Product Engineering team had worked through a perplexing issue, a design verification test (DVT) failure on a product enhancement that involved changes to mechanical components, electronic circuitry, and firmware.
She believed that the team had finally identified the root cause and they were preparing to implement corrective and preventive actions. She asked me to be her sounding board before committing serious time and money on implementing a solution.
Here are some things Taylor and I discussed – tips you can use in moving from root cause to corrective and preventive action. The approach you take will be heavily dependent on the complexity of the problem you’re attacking.
We’ll look at low, medium, and high complexity situations, and finish off with two crucial pitfalls that (unfortunately) snare teams too often.
Handling Low Complexity (Low Cx) Problems
Low Complexity (Low Cx) Problems
Many problems in the “Low Cx” classification are nonconformities that occur so frequently in a process that they are not perceived as problems, they’re “just part of the fabric.”
One example:
A contract manufacturer (CM) running automated system final acceptance testing experiences occasional failures of an entire day’s production because firmware updates are downloaded overnight, without notice, from the customer’s overseas engineering site to units under test at the CM.
The CM then must restart and retest all units the next day.
Often the corrective action for Low Cx problems is to change a procedure to the inverse of what caused the problem.
In the system acceptance testing issue above, our solution was to forbid code updates directly to units under test. Instead, we set up a local server to which the customer downloaded their new firmware. Then, once units had completed test, we could install new code in a controlled manner and conduct a regression test addressing the changes before packing and shipping.
About Medium Complexity (Med Cx) Problems
Medium Complexity (Med Cx) Problems
Many Med Cx issues arise because of global processes in which successive operations are performed hundreds of miles apart. Similarly, problems can occur when the factory test and a customer’s incoming test are performed using different equipment, procedures, or pass/fail criteria.
For example:
A firm manufactures optical amplifier modules. A technician performs final test using legacy test equipment in a manual procedure.
Their customer selects a sample out of incoming shipments to validate the product before installing in their facilities. They use a commercial automated test instrument designed for the purpose, which includes comprehensive data collection and analysis.
The customer frequently returns entire shipping lots back to the manufacturer because the sample fails incoming acceptance. Very costly, and obviously detrimental to customer satisfaction.
Problems of this nature generally require a team approach involving all affected functional areas in the business unit. Lean Six Sigma techniques such as Cause-and Effect Diagrams and 5-Why are useful in identifying the root cause from among possible causes, and then initiating corrective action.
People from diverse functions offer different perspectives on the problem. Bringing them together to address the issue helps ensure that a corrective action to solve one problem – a process change, a new procedure, or other action – does not create another unforeseen problem.
Dealing with High Complexity (Hi Cx) Show-Stoppers
Lean Six Sigma provides many techniques that can help when facing the (thankfully) rare Hi Cx problems. However, the tools do not “do the work for you.” Therefore, it is wise to practice their use on some Low and Medium Cx problems, so those tools are not totally foreign when the big problem does occur.
An example:
One of my team’s efforts on a Hi Cx problem is described in the case study, “Product Upgrade Pre-launch Out-of-Box Failure (OOBF).” The device critical function of “Event and Error Logging” failed in multiple units pulled from Finished Goods, delaying the planned launch.
Resolving this problem required experts across multiple disciplines to move from show-stopper symptoms to implementing and validating the solution.
The linked Case Study details the analysis which led to determining root cause (it was not what anyone initially thought, by the way!) and the corrective actions to eliminate the problem.
For Hi Cx problems, be sure to put attention on both corrective action (CA) and preventive action (PA).
What’s the difference? In brief, the CA is a solution intended to resolve the identified problem on the specific product or business process being addressed. The PA is a comprehensive solution designed to address similar problems in other products or business areas that could potentially be affected by the same root cause.
Two Common Pitfalls to Avoid
Recall, I promised to note a couple of pitfalls before leaving the topic of Corrective Action implementation, and here they are. (Drum roll…)
Pitfall No. 1 — The ‘Shotgun’
Teams sometimes develop a Cause-and-Effect diagram with a good problem statement, 5 or 6 main categories, and perhaps 20 possible causes identified. Then, rather than determining which one or two of the 20 possibilities are the root cause(s) of the problem, they try to implement a countermeasure for every one of the suggested possible causes.
What’s the problem with this “shotgun” approach? Fundamentally, it keeps the team from completing the final step of determining Root Cause.
The thinking is it’s easier to fix everything that might be causing the problem than to overlook something. As a result, it costs time and money to take actions that do not have any demonstrable influence on the problem at hand. Furthermore, it dilutes the effectiveness of the solution by incorporating other superfluous actions into the mix, which may in fact lead to new problems.
Pitfall No. 2 — No Control
High complexity problems, especially, can take a long time to work from symptom through corrective action (CA). The feeling of success after weeks of uncertainty sometimes leads the team to neglect the important aspect of monitoring process performance after implementing the CA.
Using the Lean Six Sigma ‘DMAIC’ framework can help ensure the team puts control measures in place to monitor the effectiveness of the changes. Recall, DMAIC is the 5-step framework for process change:
σ Define
σ Measure
σ Analyze
σ Implement
σ Control
Recognize that the job is not finished until the control mechanism is in place for ongoing monitoring. Identify the one or two ‘critical to function’ variables and a simple way to keep them in control. Automate the control if possible, or devise a quick manual run chart using your favorite spreadsheet.
Corrective Actions: Building the Skill
As I told Taylor when we wrapped up our meeting, developing, implementing, and validating Corrective and Preventive Actions once you have determined the root cause of a problem is one of the most valuable transferrable skills you and your project teams can learn. Having those capabilities benefits your company and your own career.
Practice the Corrective Action process on the low and medium complexity problems that arise so that when (not if) you encounter the next high complexity show-stopper, you can confidently deliver a robust solution.
Dann Gustavson helps Program Managers and their teams achieve superior results through high-impact program execution. Prepare, structure, and run successful programs in product engineering, manufacturing operations (including outsourcing), and cross-functional change initiatives.
Contact Dann@Lean6SigmaPM.com.