Problems are inevitable in any engineering build process. As a result, problem solving is an engineering fundamental. Often, this process is straightforward. A screw is found to be loose; a part was not made to specification; a cable was inadvertently disconnected.
However, problems can sometimes be more confounding. Perhaps the problem has resurfaced unexpectedly despite a “solution” being implemented. Maybe the problem seems complex enough that we need to involve a team in devising a solution. It is possible that the client has discovered the problem and issued us a “Corrective Action Request (CAR)” and we need to formalize our root cause investigation.
Whatever the motivation, there is a clear need for a robust approach to Root Cause Analysis (RCA) for these more confounding problems. This blog will discuss Simplexity’s RCA approach along with related templates and tools to help us along the way.
Root Cause Analysis Process:
Simplexity’s Root Cause Analysis (RCA) process is largely based on the core structure of the 8D Problem Solving Process.
Figure 01 – List of the Eight Disciplines (8D) – ASQ.org
Foundational in the 8D process are D0 and D1, Planning and Creating a Team. Though critical steps, these are often overlooked. Root Causing can be a complex process and requires a thorough plan executed by a diverse team of experts. Root causing, ultimately, is a team sport. Assembling a team early and engaging them throughout the process will be critical to success.
In its native state, the 8D process has some limitations of practicality. For Simplexity’s highly technical applications, the 8D process has been augmented to incorporate elements of the scientific process. Specifically, step D4, D5, and D6 are given increased detail and usefulness by integrating scientific studies called “PDSA experimentation.”
“PDSA” refers to “Plan Do Study Act.” PDSA experiments are run in a cyclic nature, feeding into one another until arriving at a result. The graphic below depicts each step of this process. Ultimately the goal is to clearly outline the objective of the study, the expected results, the test parameters, the actual results, and the next steps.
Figure 02 – PDSA Infographic – Smartsheet.com
Before executing PDSA cycles, the RCA team must first thoroughly define the problem. Insufficient problem definition can lead to unnecessary investigations, incomplete information, or even missing leads that may steer investigations towards the true root cause.
To aid with thorough problem definition, Simplexity implements an “Is / Is-Not” process. During this process, the RCA team gathers to ask questions like “Where is the problem occurring?” or “Who is not experiencing/seeing the problem?” Some samples are represented below.
Figure 03 – QualityTrainingPortal.com
After asking these probing questions about the problem, a more detailed problem statement can be written. This updated problem statement is then studied for possible causes. To do this, Simplexity implements an adapted Fishbone diagram (also known as a Cause and Effect or Ishikawa diagram).
Figure 04 – Fishbone Diagram Sample – ASQ.org
Possible causes are then carried through the process and studied using the PDSA process in search of a true Root Cause. If the PDSA investigations yield a promising solution, implementation is done in a series of careful steps to ensure the solution is robust and does not create any negative externalities.
First, the solution is “Light-Switched.” When light-switching the solution, you essentially are asking the question “Can you recreate the failure by switching off your solution and then eliminate it by switching it back on?” Going through this process is about building confidence that you have control of the solution.
Once this confidence is gained, the solution is implemented in a small batch. This allows the solution to be studied in situ without impacting the full batch, in case something goes wrong.
If all goes well with small-batch implementation, it is time to update documentation to reflect the identified root cause and solutions. Documentation is imperative. Especially, in a consulting environment, it is highly likely that a design gets handed off multiple times. Thoroughly documenting root cause analyses helps all future design owners efficiently diagnose similar problems, and to avoid making changes that re-introduce the original problem, by granting them access to pertinent information.
An additional means of “future-proofing” an RCA effort is to do a deeper dive into possible systemic causes. Basically, the goal here is to study why this even happened in the first place. What can we do as an organization, or in our Quality processes, to prevent this type of problem from recurring? Are there changes that can be made to the Design Review process? What about mentoring programs for new engineers?
The tool used for studying this is a “5-Why’s” diagram. This diagram prompts a series of deeper and deeper questions about why the problem occurred. See below for a sample.
Figure 05 – 5-Why’s Sample – velaction.com
Once systemic root causes have been studied, it is time for full scale Implementation and Monitoring, some of the final steps of the RCA process. When monitoring the final implementation of the solution, it is recommended to cast a wide net. Do not only monitor the areas thought to be related to the RCA effort. Doing so may cause you to miss adverse effects in other subsystems.
Ultimately, the last step of Root Cause Analysis is to congratulate the RCA team. Root Causing is difficult work, and a successful close to an RCA effort is worthy of celebration.
Root Cause Analysis Implementation:
Simplexity uses Atlassian tools for many of our internal processes. Atlassian tools like Confluence and Jira help us to work across multiple sites, collaborate with clients, and coordinate things like design materials, timekeeping, resourcing, and more.
The defect management process used by Simplexity exists in Jira. Key process steps such as assessment, investigation, implementation, etc. are tracked and gated. The RCA process is an expansion of the “investigation” step of Simplexity’s defect management process, particularly suited for confounding problems.
To better integrate Root Cause Analysis into Simplexity’s existing processes, we have generated a template and set of tools on Confluence that can be quickly copied to the project with a Root Cause need. The RCA team can then fill this page out rather than generate something from scratch. This helps to ensure completeness and uniformity.
The Confluence page outlines Simplexity’s refined 8D process, incorporating Confluence-formatted tools along with helpful instructions and prompts. Let’s take the Is / Is-Not Diagram for example.
Filling out this Is / Is-Not table helps to refine the problem into something more actionable, excluding extraneous paths and making sure valuable information does not get missed. Most importantly, capturing this on Confluence means that if the team’s understanding of the problem changes, it is easy to return to this table, update it, and generate an updated problem statement.
For example, let’s say that in this process the RCA team clearly outlined in the “Where?” section that “The problem Is Not showing up on units 1, 2, and 4” and “The problem Is showing up on unit 3.” The problem statement then clearly dictates that this defect is present only on unit 3. Weeks later, the defect appears in unit 1. The RCA team can look back and see clearly that the problem was not showing up in unit 1 at the time of the Is / Is-Not diagram and can adjust that assumption to redefine the problem.
Another sample Confluence-formatted RCA tool is the 5-Why’s diagram. As described previously, the 5-Why’s helps to dive deeply into possible systemic causes. The adapted format shown below organizes the 5-Why’s in a tabular format, enables traceability by adding ID numbers to possible causes, allows linking of relevant Jira’s, Confluence pages, tagging users, etc.
Like the Is / Is-Not diagram (along with other tools throughout this template), the 5-Why’s is companied by a set of instructions and recommendations for use.
The value-add of capturing an RCA in such detail is hard to overstate. In short, strong RCA documentation removes ambiguity and improves traceability. Simplexity’s Confluence-based Root Cause Analysis approach provides a platform for this strong documentation and communication both internally and with our clients.
Root Cause Analysis Conclusion:
Root Cause Analysis is a fundamental and essential tool for problem solving. The 8D process for problem solving is a widely used format for coming to robust conclusions and implementing solutions.
Ultimately, time spent up front on an effective root cause analysis pays dividends in the future by avoiding recurrences, unexpected side-effects, high frequency problems in production, etc.
Mixing in key elements of the scientific method and porting the process into Confluence yielded a template for success that can be used by Simplexity engineers to help clients dive deeply into confounding problems and efficiently come to a stable and effective solution.
Software: Design Complete
Hardware: Pre-production units for design verification
MFG. Readiness: CM schedule and budget, Unit build tracking