How do you balance speed and accuracy when performing root cause analysis and corrective action?

RCA’s use robust methodologies to find the root cause and contributing factors for parent events. Depending on the scope and severity of the parent event different tools allow for the best analysis. Some examples include a 5-why analysis (asking a series of why questions in escalating detail), a PEMMES or 6M analysis (Method Machine Material Measurement Mother Nature and Manpower), a fishbone diagram (capturing factors and inputs that feed into a root cause), or the simplest a brainstorming analysis. Corrective actions fall into three categories (corrections, corrective actions, and preventative actions). Corrections address the subject example, CAs work to correct more systemic issues, and PAs work to prevent the issue in the future.

The RCA and CA speed (time to resolution) will depend on the complexity of the problem, structure of the organization and other factors. It is best to set a reasonable deadline and work towards it, though if not resolved then management approval sought for an extension so the risk is accepted by them. What is important is that the corrections are completed quickly and the risks controlled in the interim until a more permanent solution is identified.

Always be willing to weigh the impact of the causing event with the effort of the RCA and CA’s and consider commensurate investigation tools and scope of CA’s. Using standard templates and a focused effort on high risk or recurring events can go a long way toward reducing cycle times with limited resources. Lastly, learn to recognize and classify events of similar types the same. This helps overall trending and can reduce the need for repetitive action.

The more learning and process improvement you do, the faster you will get at it. Some scholars have characterized the organization's learning rate as the time it takes to make a 50% reduction in defect levels. If you use the Pareto principle, the project with the most potential for improvement will yield about that, so your organizational learning rate is how long it takes to start and finish an improvement project that has significant impact. As you develop a standard RCA and CA process, and your team moves from forming to storming to norming to performing, you'll see that time to improvement decrease.

It may depend on uncertainty. If the problem is simple or complicated (system has many pieces that act in a linear manner), then a "waterfall" process may be appropriate, where one spends a lot of time on RCA to find the single CA that makes a difference. If the problem is complex (system is not visible, or behaves in nonlinear manner), then a "prototype" process may be better, where we hypothesize a root cause and correct for it, see if that worked, and if not, continue the cycle.