What is the process for identifying the root cause of a problem in a Lean Six Sigma project?

𝗔 𝗣𝗿𝗼𝗯𝗹𝗲𝗺 𝘄𝗲𝗹𝗹 𝗱𝗲𝗳𝗶𝗻𝗲𝗱 𝗶𝘀 𝗮 𝗣𝗿𝗼𝗯𝗹𝗲𝗺 𝗛𝗮𝗹𝗳 𝗦𝗼𝗹𝘃𝗲𝗱. 𝗧𝗼 𝗱𝗲𝗳𝗶𝗻𝗲 𝗮 𝗽𝗿𝗼𝗯𝗹𝗲𝗺 𝗰𝗹𝗲𝗮𝗿𝗹𝘆 𝘄𝗲 𝗰𝗮𝗻 𝘂𝘀𝗲 𝗣𝗿𝗼𝗯𝗹𝗲𝗺 𝗕𝗿𝗲𝗮𝗸 𝗗𝗼𝘄𝗻 𝗮𝗽𝗽𝗿𝗼𝗮𝗰𝗵. Breaking down a problem into its components is a robust/useful data collection process following a structured 5W-1H approach. In this approach, teams need to answer the questions with W’s & H’s 1W – What exactly is the problem "The Perceived Problem"? 2W – Where does the problem occur? Point of Occurrence – Location 3W - When did the Problem Occurred? Point of Occurrence – Time 4W – Who identified the Problem? 5W – Why is this a Problem? 1H - How Big is this Problem (Severity – How many parts Failed / Rejected?)

Very often defining the problem is challenging because at the beginning we mostly deal with “symptoms”. The symptoms are very rarely the problem.

I will not repeat the process steps and the tools used already mentioned by other colleagues. But I will say that, in my experience, the critical part is understanding what a problem is. A problem is always a gap, a difference, between what we currently see/measure/define by our measuring units/describe as process steps (qualitative and quantitative attributes) and the desired state of things defined in our standards/expectations/want to be results. Once this is clear, stick to the process and thou shall not fail: apply tools and follow the problem solving process steps.

My advice to problem-solvers is to avoid going straight to solution-mode without first identifying & understanding the pain-points of the process or service they're studying. The DMAIC model works great for this purpose... if you follow the recipe. Finding the root cause is part of the middle "A" step. But understanding what a root cause is should not be taken lightly; 1) It's a factor causing a non-conformance. 2) As Roula El Haddad mentions, it's not to be confused with the symptom. 3) It's often not visible or obvious otherwise it would be a "just go fix it" activity. Basically, finding the root cause is a core building block of a continuous improvement effort that allows for the discovery of underlying or systemic reasons for the error.

After supervising processes for over 30 years, I can assure that one of the most important information to gather is the employee experience, and their ideas on what the root cause of the problem could be. Defining the problem and its potential cause is half the path to finding the right solution.

Root cause analysis is a collection of tools and processes we can use to determine the most important causes for an issue we are trying to resolve. This is an important function as one of the top 5 reasons for project failures is poor root causation / no root cause identified

Using the SME (Subject Matter Experts) to tell you what they are having an issue with is the best way to start in my opinion. Then you can do a 5 Why, PDCA or any other process for problem solving you have in your toolbox. Then I follow the DMAIC process or do a Kaizen depending on what the issue/problem is. Gathering data for the problem is a most important process step. I have a saying, "without data it is just your/my opinion." Data allows you to measure the issue and put together a plan.

During my experience with Lean Six Sigma projects, I've found that having a well-defined project charter with clearly delineated boundaries is instrumental in preventing scope creep and ensuring timely delivery of project goals. For instance, in a project to improve downstream yield, having a precise problem statement helped us focus our efforts on the most critical area, the packaging production line. This resulted in a 2% loss decrease annually. Additionally, involving key stakeholders like customers, process owners, and subject matter experts in defining the problem statement ensured that our efforts were directed towards addressing the true root cause of the issue.

Best Tool I have personally used to identify root cause of the problem is 5 why's. Asking questions to the right person is key to finding the root cause

It’s also important to do a MSA ( Measurement System Analysis) to reduce variation or inconsistency in the measurement process including errors from tools or of manual measurements.

Well if Polychain GT Carbon can't fix the problem, then I suggest a bigger hammer. Thanks for asking. So I always wanted to be the guy that came up with the next sigma program, or iso9002, or 5S, so I could ride around getting paid to present seminars that often go against common sense, then people who are not the best thinkers apply practices that are not universal and screw up the company. Oops sorry, I'm off to the next presentation or better yet the next bad idea to infect manufacturing....next please

Simple words, if you do not know the starting point, from where you are going to compare the results obtained, you do not know if you arrived or not, therein lies the importance of measuring current performance or condition.

Containment Anyone? There are some great points presented in this article and the comments. It seems a critical step is missing from the 6 steps presented, that being an interim containment step. One that ensures no further defects or quality issues (known as “escapes”) persist or reoccur. In fact, a team should never proceed to formal root cause analysis (RCA) phases unless an interim containment has been established. The risks of not doing so can be disastrous to a product or a company’s reputation. Those interested might consider the Eight Discipline (8D) Problem Solving approach, which is also known as the Problem Solving Process (PSP) in the aerospace industry. It provides a time-tested approach that also includes a containment step.

the management guru Peter Drucker famously said, “If you can't measure it, you can't manage it.” it says everything and that's always true like if you can’t know whether or not you are successful unless success is defined and tracked.

Clearly articulate and describe the problem that needs to be addressed. This step involves gathering information, collecting data, and understanding the impact of the problem on the process or organization.

Again, what do you measure, the documented process or the real applied process and how are your measures established, do you use the right metrics. What you measure is what you'll get even if it isn't the results you want.

To measure the current performance, it is necessary to collect all the data obtained and document the process performance. The data and information collected in this phase establish references for the intended improvements and, at the end of the project, it is possible to compare the current scenario with the result obtained. To obtain a measure of problem success, you need a detailed process map, a data collection plan with an operational definition of the Project, a measurement system analysis, a process performance analysis, a risk management plan.

Los conceptos de precisión y exactitud son vitales para evaluar el sistema de medición. No olvidemos la evaluación de la capacidad de proceso para evaluar el nivel sigma de un proceso.

Key point that I believe is trying to be stated is that of ”value stream mapping” Why? As mentioned in couple of the contributions is gathering “relevant” data which is basically understanding cause and effect for those “value added items” This allows you to focus on data that matters by knowing which items impact the outcome (ideal situation) you’re looking for

After clearly defining the problem, stakeholders could apply tools like fishbone diagrams(useful for writing down all possible causes of the problem), 5 Whys(for drilling down to the root of the problem by analyzing why the problem occurred), and regression analysis. It’s important that stakeholders can use these tools to organize the investigation process, this goes a long way to document the root cause process.

Be aware that there may be multiple root causes. In fact, most times that is the case. Identifying as many root causes as posible also means you open yourself to having more options to eliminate the problem.

Temos algumas ferramentas que são mais utilizadas para análise de causa raiz como o Diagrama de Ishikawa, o Pareto e o método dos 5 Porquês. É de extrema importância analisar a causa raiz para que o problema seja resolvido de fato onde nasce, assim sua eficiência será muito maior.

I think that combining different tools is important to isolate the root cause. The Ishikawa (or fish bone) diagram helps gather all potential sources even the least likely ones. the 5whys can help dig deeper and eliminate candidates. Anyway, communication with all stakeholders is crucial

it is also called Cause-and-Effect Analysis it involves using a Fishbone diagram (Ishikawa diagram) to identify potential causes of the problem, it is a visual representation of the problem-solving process, with the problem at the head of the fish and the potential causes as the fishbones.

Firstly we need to do a containment action based on the issue. Secondly we need to analyze the data using some of the tools like 5 WHY analysis, fishbone diagram, box plots and identify the potential root causes (can be multiple or single). Thirdly, based on the potential root causes, the actual root cause must be decided (again single or multiple). Fourth, the corrective action must be decided for the identified root causes.

From my past experience, 5W2H has been a great help. But, again, this root cause found may not be answering the definition or problem stated. It is crucial to define specifically of the issue and collect the corresponding data as accurately as possible.

It may just be shorthand to speak of "the" root cause but it creates a real risk of causing the team to think that causes always arrange themselves neatly into a hierarchy with one (or a critical few) at the root. Some problems do, but "systems thinking" helps us see that some effects are simply part of a self-reinforcing cycle (e.g., trying to suppress all forest fires), some are interactions between two or more equally-fundamental components (fuel, oxygen, heat), and that root causes may be far less actionable than intermediate causes (e.g., inadequate communications being the root of any number of dysfunctional behaviors in organizations).

Don’t use a fishbone If you have a problem it is a deviation from target and there is no reason to guess the root cause or allow groups of people to give an opinion or guess as to the root cause. You need to collect the facts and define the problem using the facts or collect the data which are the facts. This idea seems to alien to many people who do problem solving. Just my opinion 👍

Starting with the 5 why method will give fast results. Later on these results can be integrated in a fishbone diagram, while further investigation on first ideas can be taken. This will give you fast results if time constrains is a factor.

Identifying the root cause can sometimes be very complicated. If it is not possible to identify these straight away, it is sometimes more efficient to determine several potential causes using a cause tree and the 5-Why method. Measures can then be developed to eliminate these potential causes.

Regression analysis is also an important tool that helps estimates the impact, variables or causes have on each other as well as the final problem.

Or implement a MVP and validate the results. I’ve even seen others make a non root cause more apparent to validate impact of the cause.

One of the tools that have been used during the “Verify” phase is to reintroduce the root cause to confirm if it is the source of the problem. If it is the actual cause then the problem should come back into the process providing additional assurance that the correct root cause has been selected.

In some cases, it may be challenging to recreate the failure due to various factors with a significant impact, such as cost, scrap KPI, or time constraints. However, whenever possible, I highly recommend replicating the failure more than once. This not only confirms the root cause but also allows for a step back to reassess and define the problem accurately in case is neccesary.

Solutions to the root causes of the problem must be implemented here. Must to be created a list of potential solutions, a revised process map, a list of confirmed solutions, a risk analysis, and then an implementation plan. Initially you should test solutions to correct and avoid the possible root cause of the problem.

Takes the users on board. Solutions should be developed with those who will ultimately use them. Very good solutions can be developed in the form of workshops.

After implementing solutions, we must give enough time to standardise it and then take up May further improvement Read across, standardisation of the solution is important too.

While both implementing and monitoring are important steps, the monitoring step can help provide information for other areas or processes that were not anticipated. Solutions should not be implemented in a “silo”. When solutions are implemented other areas should be investigated to see if there has been an effect on costs, legal requirements, or potentially new problems. Double checking to make sure no new problems have come up will help promote the success of the solution.

Test, implement and either fail quickly giving time to change course or succeed and work to understand why it had a positive result so you can know when the data will yield a repeatable result.

Now the focus is to maintain the gains verified during in the implement solutions, to achieve this, it is essential that you define control criteria such as, for example, checklists, process capacity analysis, visual standards, poka-yoke, audits, etc.

Las graficas de control y planes de control así como herramientas LEAN son necesarios para yener mayor probabilidad de sostener las mejoras en el tiempo.

One final point would be to consider “Yokoten” or other similar areas that could benefit from the countermeasures you have implemented to solve the various issues

While the listed steps appear to cover the Six-Sigma method, they don't fully align with the DMAIC mnemonic. I find remembering DMAIC helps to remember the process. The 5 steps of 6-Sigma (technically) are: 1. Define (the problem) 2. Measure (collect relevant data) 3. Analyze (determine and verify root cause) 4. Improve (eliminate root cause) 5. Control (Monitor AND control the improved process) I must note that in step 5, the author ends with "monitor". In my experience, far to often we implement "monitoring" and data collection without the necessary focus on action from that monitoring. Never forget, the purpose of monitoring is to drive action to improve. Monitoring/Measuring without action is eventually just waste.

Bill H. Is exactly correct. He maps yet another “recipe” back to Motorola’s Six Sigma DMAIC. The late Dr. Mikel Harry calls this “Recipe madness.” Control was often weak and thus C was added to DMAI. C is to monitor processes AND ACT on the input variation originally found in the analyze and improve phases is the control phase. Compliments also to writers in avoiding words which require defining. This is the opposite of lean by wasting time when the writer has to then translate to the language of the reader.

While the focus of problem solving is on « occurrence », in other terms « why did this happen », the detection (lack of) is often overlooked. In my experience, you learn a lot in understanding why a problem was not detected before it happened and finding solutions to better detect it. Some problems might be expensive or complicated to solve but can be easy to detect before they happen.

Identifying the root cause follows a methodical process. It begins by clearly defining the problem and collecting relevant data to comprehend the current process state. Utilizing tools like Fishbone Diagrams, 5 Whys, or Pareto Analysis systematically explores potential causes. Validation of the root cause through data analysis and team consensus is crucial. Subsequently, corrective actions are developed and implemented. Continuous monitoring ensures sustained improvement, and findings, along with implemented changes, are documented for future reference. Collaboration with cross-functional teams adds diverse perspectives, emphasizing the goal of not only solving immediate issues but establishing lasting process improvements.

Never forget to save the "Lessons learnt" in the story library for the company, this way the next time (or in five years) you will save time by not repeating mistakes. Mistakes are only negative if you don´t learn from them.

Consider the human element. Take more time in the beginning doing research before jumping to conclusions. Meet with customers. Interview employees. Benchmark similar processes.

To identify the right root cause first and foremost step is 1.Establish a clear problem statement- I could see mostly teams don't write clear problem statements. An effective problem statement solves 50% of the problem why because it sets a clear direction. 2. Once the problem statement is clearly defined, then get in to the root cause analysis. As the name specifies (ROOT), go to the root of the problem. Don't stop at superficial level. As you go to the root level only you can establish the clear corrective action which can prevent the recurrence of the problem otherwise even you try to implement corrective actions, the problems will pop up again. There are many tools for RCA but these are best 1.Ishikawa diagram 2.Five Why analysis

Most times there are several reasons or causes for defects. Plan should include, an approach to check other causes and monitor in which conditions they show. That way there can be actions to reduce or eliminate recurrence.

5Why? Fish bone diagram Technique FMEA Analysis