Guidelines & Articles

Have you ever wondered what "quality" really means? Is it the durability of an item, the taste of a cake, expensive things, or maybe perfection?

Indeed, it’s none of those.

Quality Is About Meeting Expectations

At its core, quality is simply about meeting expectations, more specifically, the customer’s expectations. Think about the last time you bought something. Maybe it was a cup of coffee, a phone, or even a car. Why did you choose that specific product? Was it because it was the closest one to your needs and ticked all or most of the boxes you had in mind ?

Let’s take a simple example. Imagine a customer looking for a red-coloured product made from low cost materials. If the product fulfils their expectations such as colour, cost, and functionality, it’s considered high quality by them. On the other hand, even the most luxurious and expensive item can feel like a disappointment if it doesn’t meet the customer’s actual needs.

The Promise of Quality

At the end of the day, quality isn’t something you can fake. It’s a promise you make to your customers, a promise to meet their expectations. Every fulfilled promise builds trust. And trust ? that is absolutely the foundation of every successful product, service, and brand.

What does quality mean to you? Write in the comments !

Real Life Cases

Our life consists of problems, which we need to sort out to go forward, while some of them are easy, the others might be quite challenging. Let's take an example from real life first. If you complain that it takes half an hour to take your child to school, is the problem really the distance or the fact that your job offers no flexibility ?

If the problem is the distance, changing schools or moving houses might seem like viable options. But, if the issue is a lack of work flexibility, practical solutions like hiring a shuttle service or adjusting work hours could be more appropriate. When defining the problem, the solutions follow accordingly.

All paths are quite different depending on problem, aren't they ? Just like in life, misdefining problems in a professional context can lead to wasted time, effort, and resources. Let’s look at an example from the industry.

How Misdefining a Quality Problem Affects Your Business

Your customer informs you of a quality issue, claiming that your product cannot be assembled with their parts. So, when you address the problem to the product that you sent to the customer, all efforts, cost and works will be on that. You will maybe measure all them, and check all past data with some data analysis, you'll try to develop some immediate actions to temporary fix the problem although the problem is unclear. Let's imagine, you do all those works and identify an out of tolerance point on the part. But what if the problem still continues after fix this out of tolerance on your product ? It is because, maybe the problem is not about your product, but the customer's process ? Perhaps the issue lies in customer's part variation rather than yours. Wouldn't it be frustrating to realize you’ve wasted a lot of effort, cost, and time on a irrelevant aspect that does not resolved the problem ?

We should justify the problem by identifying correctly. In the case at above, when we address a part without the right verifications, we might spend a significant effort without an useful outcome. But if we could check both our and customer's product at first in order to understand the variation's origin, we could address it to the correct point, which is the customer process for that case.

Effective Problem Definition

Without a clear problem definition, every step you take is just a shot in the dark. Start with clarity, and solutions will naturally follow. In the other word, the right direction can only be done by starting with a correct and sufficient problem definition. In this point, we should get support from proven problem statement techniques for a comprehensive problem definition such as 5W2H.

(The 5W2H technique is a problem definition tool that helps break down a issue by asking seven questions: What, When, Where, Who, Why, How, and How Much.)

Have you ever experienced a situation where mis-defining the problem led to wrong solutions? Feel free to share your thoughts in the comments!

Root cause analysis is a core step in all problem-solving methodologies, including 8D, Six Sigma, A3, and even PDCA. The reason is simple: rather than focusing on the surface-level issue, we go straight to the origin of the problem. If we eliminate this root cause, the issue will be permanently resolved.

We keep asking "why?" repeatedly, ideally five times, to drill down to the root cause.

But what about technical and systemic root causes? Do we need different types of analysis to find them? And once we identify the root cause, how do we decide whether an action is corrective or preventive? Is it as simple as saying, "This prevents the issue, so it's preventive"?

The simple answer is no. Let's take a closer look.

Technical Root Cause & Corrective Action

The technical root cause is the technical origin of the issue, the one we typically identify in all problem-solving studies. Let’s take a simple example. The problem is "Punctured Tire" If we apply 5 Whys method, we can identify the technical root cause following:

We fixed the technical root cause, so you can think that we sorted out the issue..... technically, yes. But we didn’t eliminate the reason behind it. What is the underlying reason behind this last cause? In other words, the root cause can repeat, because we have not prevented the root cause, we just corrected it.

Systemic Root Cause & Preventive Action

The way is simple, we'll just ask one more "Why". This last question will take us where we see the lack of standard. Let’s go one step further and ask one last 'Why?' — this is where we find the systemic root cause

Why wasn't the vehicle owner properly educated on vehicle maintenance ?

The systemic root cause here is that "There is no standardized system in place to educate vehicle owners about routine maintenance, including tire pressure checks." So, based on that, our preventive action would be "to implement mandatory maintenance reminders through automakers and service centers to ensure regular tire pressure checks." This action prevents the re-occurring of technical root cause, because simply we standardized that.

Key Takeaways

We started with a simple punctured tire problem, but it led us to analyze a much broader issue. In this article, the key point is this:

• Fixing the problem itself is a containment action.
• Fixing the technical root cause is a corrective action.
• Fixing the systemic root cause is a preventive action.

If you want to learn more about Root Cause Analysis and CAPA, you can check out my Udemy course

"So" The Art of Reverse Questioning

There are several ways to verify if a root cause is correctly identified. One effective method is to reverse the questioning process. Instead of asking "why" to reach the root cause, we can ask "so?" to trace it back to the potential cause. This reverse approach helps ensure logical consistency and prevents misdirection during root cause analysis. Let's go through an example to illustrate this concept.

Let’s say we have a problem of motor overheating. The team conducts a root cause analysis and identifies that "the cable was placed too close to a high-temperature machine."

• Root Cause: The cable was placed too close to a high temperature machine.
  • So? → It was exposed to excessive heat.
  • So? → The power cable of the fan is damaged.
  • So? → The cooling fan is not working.
• Problem: Motor overheated.

In this example, if you start by asking "why?" from the problem "Motor overheated," you will see that the logic aligns with reverse questioning.

Defect Reproduction

While reverse questioning is a great logical tool to verify, how do we validate that the identified root cause is the real one? The answer is simple: Defect Reproduction.

The best way to validate a root cause is to attempt to reproduce the defect by simulating the root cause. Let’s apply this to our example. We have identified a root cause, but does this really cause the problem? To verify, we can intentionally place the cable too close to a high temperature machine, as stated in the root cause, and observe whether the failure occurs again.

Of course, intentionally causing failures can be costly and impractical. In such cases, we can try to reproduce the defect after implementing corrective actions. Our expectation at this stage is to not see the problem when we simulate it, because corrective actions should provide a permanent resolution.

For example, if we replace the cables with heat-proof ones, even if we place them too close to a high temperature machine, the failure should not occur again. This approach not only indirectly validates the root cause but also confirms the effectiveness of the corrective action.

If you want to learn more about Root Cause Analysis, you can check out my Udemy course

IATF 16949:2016, the Automotive Quality Management System (QMS) standard, consists of 10 main clauses, each with multiple sub-clauses. While the standard provides detailed requirements on what needs to be done, it does not prescribe how to do it, leaving the implementation up to organizations.

So, how should we structure this system within the organizations? What are the key elements that cover the clauses of IATF 16949? Do we have a simple answer?

QMS Processes – The Core of the System

These processes form the foundation that supports all the requirements of the standard. That’s why auditors typically ask for process documentation first, because processes define the structure, execution, and performance of the system at a fundamental level, rather than just listing procedural steps.

These processes can be documented in different formats, such as SIPOC diagrams, Turtle Diagrams, or process flowcharts. The key point is that they must align with QMS requirements and include measurable KPIs. After all, how else can we determine whether a process is performing effectively, right?

Processes vs Departments – A Common Misconception

One important thing to clarify: Processes are not the same as departments. A QMS Process can involve multiple departments, and cross-functional teams can be responsible for the same process.

For example, if you have a New Product Launch Process, it will likely involve both the Engineering and Project Management teams. However, there should always be one primary process owner to ensure accountability.

That being said, I have to admit, I also prefer aligning QMS processes with departments whenever possible. It simply makes governance easier. But does that mean it’s always the best approach? Not necessarily. The key is to strike a balance between functional ownership and cross-functional collaboration.

Key Takeaways – A Structured Framework

So, can we visualize the system like this?

• If IATF 16949 is the roof, then QMS processes are the pillars holding it up.
• Procedures? They are the branches, describing how each process should be executed in a structured way.
• Instructions? These would be the leaves, providing step-by-step guidance for specific works and tasks.

Does this framework make sense to you? Would you agree, or do you have a different approach?

If you ask most people to guess the second word after "Quality," they would probably say "Control."

Quality Control

In simple terms, when we produce a product, we need a control mechanism to ensure all its requirements are met. A control system is essential to maintain consistent quality because we know that processes can fail—not just those performed by people but also those carried out by machines, automation systems, and robots. Regardless of the production method, a control mechanism is always necessary.

Taking it one step further, we even implement a second layer of control to check the controller itself. For example, in some processes, we introduce trap parts to test whether the control mechanism (such as a camera, sensor, or visual inspection) still detects failures. If it fails to detect them, we know something is wrong with the control mechanism, and corrective action is needed.

So, in essence, quality control ensures that a part meets quality standards. But then, what is a quality audit? If we already have control mechanisms in place, why do we need audits? Are they just another layer of control?

Well... the simple answer is no.

Quality Audits

Quality audits are not about measuring the quality of individual parts, nor are they conducted just because companies or governments require them. Audits are performed to ensure that the entire system functions properly. They are essentially an end-to-end sample check of all processes.

Take, for example, Quality Management System (QMS) audits like IATF 16949. These audits assess various aspects of an organization, including documentation, production processes, engineering files, and training records—basically, almost everything related to the company. However, an audit does not guarantee continuous production quality; it’s more like a snapshot of the organization at a specific point in time.

Another example is the VDA 6.3 Process Audit, which evaluates the entire production process through sample checks. But again, it does not guarantee that all products will meet quality standards. It simply captures a moment in time, providing insight into how well the process functions.

What's the Key Difference ?

• Quality control checks specific parameters of a product or process to ensure continuous quality.
• Quality audits assess the health of the entire system, including production and control mechanisms, to verify whether everything is working as intended.

While quality control focuses on production, quality audits evaluate both production and control systems together. In short, audits check whether the entire quality system is functioning properly.

What do you think about these two concepts—Quality Control and Quality Audits? I'd love to hear your thoughts!

The 5W2H method is a widely used framework in problem-solving, quality management, and business analysis. By asking What, Where, When, Why, Who, How, and How Much, we systematically define a problem.

However, there is one particular question in that which often leads to confusion: This question is "Why?"

Understanding the "Why" in 5W2H

At first glance, one might assume that asking “Why?” in 5W2H is the same as performing a root cause analysis. But that’s not the case. The purpose of this question in 5W2H is not to determine why the issue occurred. Instead, it is meant to establish whether the issue is actually a problem in the first place.

Let’s consider a simple manufacturing issue:

Problem: A part is broken. We should ask "Why is this breakage considered a problem?"

Answer: "Because the product requirement states that no breakage is allowed, meaning the part does not meet the specified criteria."

By first confirming whether something is truly a problem, we prevent unnecessary problem solving efforts.

Conclusion

Misusing “Why” in 5W2H can lead to incorrect assumptions and premature root cause analysis. Before investigating the cause of an issue, it is essential to establish whether it is indeed a problem or not.

The 5W2H method is a powerful tool for problem definition, but only when used correctly. Ensuring that the “Why” question is applied properly allows teams to focus on valid problems before investing time and resources in deeper analysis.

If you want to learn more, you can check out my Udemy course.

FMEA (Failure Mode & Effects Analysis) was invented by the U.S. Military in the late 1940s to evaluate potential risks in production. Later, NASA used it to assess risks before long space journeys. Today? It is widely used, especially in manufacturing industries, particularly in the automotive sector.

What is it?

Because of this, we have different types of FMEA, such as: Process FMEA (PFMEA) – Identifies and mitigates risks in production processes. Design FMEA (DFMEA) – Helps to assess the risks in product, tool, or machine design.

Here’s an example of an FMEA template (AIAG FMEA 4th Revision).

How does it work ?

Before conducting an FMEA, we need a structured process, ideally a process flow. Let’s take a simple example. We're a bakery baking bread. If we identify the production process, it looks like this:

1. Mixing – Flour, water, yeast, and salt are combined.
2. Kneading – The dough is kneaded for texture.
3. Proofing – The dough rises.
4. Shaping – Dough is shaped into loaves.
5. Baking – Loaves are baked in the oven.
6. Cooling & Packaging – Bread is cooled and packed.

Next, we identify the requirements for each step. Let’s start with Mixing: What do we expect during the mixing step?

✔ Correct ingredients
✔ Correct amounts
✔ Proper mixing time
✔ Proper mixing speed
✔ Right temperature

These are the requirements of this step, basically, the things we expect during the mixing operation. Now, what about the failure modes?

Once we identify the requirements, it's quite simple, just think in reverse. Correct ingredients can fail if we use incorrect ingredients. Correct amounts can fail if we add too much or too little.

Let's proceed with an FMEA table to understand this better.

• The process step is Mixing.
• The first requirement of this process step is correct ingredients. So we expect to use correct ingredients for this process.
• Next is Potential Failure Mode. Here, we identify "Incorrect Ingredients" which is the opposite of Correct ingredients.
• There could be a lot of different Potential Effects of this failure but let's take a simple one. "Taste issues, customer dissatisfaction". That means, if we have a failure of incorrect ingredients, then this can result with a bad flavour, and customer dissatisfaction.
• Next is Potential Cause. Here, we identify the causes of the problem. So basically the things can cause the failure of Incorrect Ingredients. Let's say "Lack of Training". If we don't give sufficient training to bakery staff, then we can have the failure of incorrect ingredients.
• Next is Controls for Prevention. This is the action which addresses to Cause of failure. So we ask, what should we have in place in order to avoid lack of training ? We don't focus the failure mode here, instead, we focus on causes of the failure. There could be a lot of solution for lack of training, but let's put a simple action, "regular training plan" for the staffs in bakery.
• Controls for Detection ? Here is the place to identify the controls to detect the failure mode directly or the error (cause) where it is possible. So basically in this step, we imagine that the problem happened, we used wrong ingredients. So how would we detect this ? Let's put a taste control with a frequency of each batch.

Now we completed a PFMEA for one requirement of Mixing Step of Whole Bakery Process. We identified some controls to avoid the potential failure mode. So if we do this for the all requirements of Mixing Step, and other process steps as well including Kneading, Proofing, etc.. We would have almost finished this PFMEA study.

What about the numbers ?

You might have noticed that we have also some numbers and class columns in the table. These numbers rate each failure mode based on:

• Severity (S) – How bad is the failure’s impact?
• Occurrence (O) – How often does it happen?
• Detection (D) – How likely are we to detect it?

The Risk Priority Number (RPN) is calculated from the multiplication of these values. Higher RPN = higher risk, so that means we need more actions.

The Class column is used for special characteristics, mainly in industries where technical drawings have strict requirements.

Key Takeaways

Basically first we need a process flow to see the steps, then we list the requirements of those accordingly. After that we identify the failure modes of the requirements, simply way to do is thinking the reverse way. For example: if the requirement of a part is between 10-12mm, then our failure mode can be lower than 10mm, or greater than 12mm. This is what we did in above example with a simple way.

After the identification of the causes, we link the prevention controls with the causes, then link the detection controls with the failure modes and causes. These links are very important to have a robust FMEA. We didn't detail the rating system, as it requires additional information which is not possible to have in this short post (e.g. rating tables, theirs difference, etc..), however we went through the logic by using simple Bakery example.

FMEA is a crucial proactive tool to identify potential failure modes and take actions in advance. This is a fundamental tool to identify the process controls as well. So this is how factories set the controls for their products and production processes (PFMEA). And this is how designers evaluate the risks in their products before they design it (DFMEA)..... Or should we say this is how it should be ? Because sometimes people can consider these tools as a painful workload rather than a tool that was designed to help us, where I completely disagree!

What do you think ?

Can FMEA be applied to most of the things even in our daily life ? Or should it stay strictly within industries? I believe we can do this before a long journey, or even a holiday :) In this way, we can anticipate the risks in advance and take action before it's too late!

If you want to learn more, you can check out my Udemy course

You work in production, in method, or in logistic, maybe in quality ? You don't know the processes well yet. What would you do at first if someone notified a quality problem that needs to be led by you ?

Necessary Recipe

Quality Problem Solving Techniques such as 6 sigma, 8D, or PDCA are structural frameworks. Process knowledge is always better, and welcome as well, however, you can still lead a problem solving study without a well process knowledge as long as you have the following recipe.

• Methodology Knowledge: Asking right questions to team.
• A willing team: Which consist of technical people who know process well.

Asking the right questions is key. Because whether you believe or not, to tackle these questions might be difficult even for the process owners. So as a problem solving study lead, your main strategy is to ask right questions!

A willing team.... this part might not be easy as written there, however, an effective communication can encourage team members to speak up. And those people need to be from the relevant process, because we need process knowledge in someway.

Leading a Problem without a well process knowledge

Let's take an example: "Hey we have a quality problem in the production process, the bushings don't fit the hole of parts, please check and solve immediately!"

You: "Well... I don't know the production process very well, I'm quite new here. And I also don't know what bushings, which parts, how ?"

While all this reaction is quite fair, the questions that you asked are also correct. Because you don't even know what do they tell about! Nothing is normal than asking all those questions. Yes! But let's make it in a structural way.

What is the problem? X14 type bushings don't fit in hole of A20 parts.

Where did it happen? The problem happened in the 3rd Production Line, at bushing operation.

When did it happen? It happened in 23th March 2025, time was 8:00 am. Just as starting in production.

Why is it a problem? Because we expect bushing fits well into the hole of parts as in line with the process flow, however, it doesn't. Therefore, we cannot produce parts.

Who did involve the problem? There is no operator effect, because the operation is done in automatic bench. However, during that time, Mete K. was working there.

How did it happen? The production team prepared the line for the production of A20 parts. The bushings were placed in station. However, when they started to production, automatic bench stuck and stopped after bushing assembly. When they reviewed it, they've seen that the bushing didn't fit.

How Many Parts are affected? Different parts have also been checked, no okay parts, all batches are suspected. (200 bushings, 350 parts)

Don't worry, I will not go to a full problem-solving study here. But for the example above, if we get those answers by asking the right questions, then we will know what happened exactly, which is the key for a problem definition. (5W2H is a technique to identify problems in a structural way)

The above example is just about the problem definition, so you can ask how we will do this for the root cause or corrective actions without knowing the process well. The answer is: as long as you ask the right questions to the right people, you will get there.

For example during the Fishbone analysis (brainstorming tool to identify & categorize potential causes of problem): don't worry to give some stupid examples, just give them some examples to encourage when the ideas don't come from them. Maybe machine pneumatic system doesn't work well ? Bushing diameter has some problem ? Or maybe Part itself has some dimensional problem ? So just try to produce some to encourage them, then let them throw the good ideas.

So, we don't need to know about process ?

Well.. the best way is always having the knowledge of process where you lead a problem solving study. However, this might not always be possible, so in these circumstances, the key is knowing the methodology well and having the right people in the team.

Quality problems are always challenging stuffs in the industries. To be fair, I don't know anyone who becomes happy when they get a quality problem. However, unfolding the uncertainties by asking the right question is the best gun, ultimately it is a superhero to remove the stress on you and make you confident.

In case of a quality problem from the customer or internal, one of the most challenging steps is "finding the dirty batch," which is in the early stages of 8D Problem Solving studies.

For example, we have a few broken parts that were notified by the customer, but what if there are more defective parts somewhere? Even thinking about it can trigger some anxiety. How can we be sure and give an answer to the customer that "Don't worry, all is okay"?

Wish it could be that easy, but not always!

Checking Every Part

We should remove uncertainties through our aim, which is identifying the exact defective batch. However, this depends on various factors, such as failure mode, production process type, production volume, and more.

Should we check every single part in case of a Quality Claim?

This might seem like the most secure option. Because if we check all the parts, then we can ensure that there will be no surprises later. If the production volume is low and there are no different far locations, this can be manageable, even the best method in such cases. Why take risks if it is easy and cost-effective? Absolutely the best method at that point.

But think of it this way: what if the production volume is too high, parts are shipped to many different locations, and there are various intermediate storage warehouses? How can we check every single part? Just imagine that, these kinds of sorting/control activities can even exceed the product's annual net profit. It's literally a nightmare, isn't it?

Risk Assessment

We should absolutely do a risk assessment using all available data.

For example, let's say your customer submitted a quality claim stating that 10 parts were detected as broken, and these parts are also being shipped in high volumes to other locations. Before making a decision about controlling the parts in those locations, a risk assessment helps to identify the dirty batch. Let's make an example of that:

Imagine we received a quality problem notification from the customer, 10 plastic parts broken:

• One of the first things to do is checking the traceability data of those parts.
• So, we've checked the traceability of 10 broken plastic parts and seen that they were produced in 2nd mold. This is strong evidence that something is wrong with that specific mold.
• Even now, we just reduced the quantity to be checked by half!
• Let's go one more step and make a table showing which batches were sent to which location and at what time.
• Now, we also see that the parts produced in 2nd mold were only sent to one location. So, we can just check the parts in that location.

Conclusion

While dirty batch identification can be a bit painful depending on the case, it is worth to avoid wasting money and effort.

Dirty batch analysis is an unwritten obligation that needs to be done, but you need to find out how! Because there are numerous possibilities depending on the process, customer, product complexity, and whether there is a sub-assembly, it gets more complicated. How can you generate a formula for something that varies in difficulty at every organization?

While the formula is not possible, I believe that the experience absolutely helps you do it better and faster the next time.

If you want to learn more, you can check out my Udemy course.

The 5W2H methodology is a structured and effective way to clearly define and analyse a problem by addressing seven key questions: What, Where, When, Who, Why, How, and How Much.

1. What - What is the problem?

Begin by clearly describing the problem. This should include relevant details such as defect type, affected part, and the deviation from the expected condition. The goal is to make the issue instantly understandable.

Example:"A5 windshield has a crack in the corner."

This statement gives us two important pieces of information:

• Product: A5 windshield
• Defect: Crack located in the corner

To improve clarity, we can include more specific data: "A5 windshield has a 4mm long, 1mm deep crack in the corner."

This level of detail helps quickly grasp the detail of the issue.

2. Where - Where did the problem occur, and where was it detected?

Specify both the occurrence location and the detection location. These may be different and should both be recorded to trace the problem accurately.

Example:

• Occurrence: Warwick Plant, 2nd production line, Operation 20
• Detection: London Plant, car assembly line

We should try to give as much as detail about the origin point. If we know the exact point like which operation, which operation's step, we should include it.

3. When - When did the problem occur, and when was it first identified?

Identify the exact time for both the occurrence and detection. If the problem is recurring, provide a timeline or trend graph to show frequency and patterns. If it’s a singular case, state the exact date and time.

Example:

• Occurrence: January 3rd, 2025 – Night Shift, 3 PM
• Detection: January 5th, 2025 – 10 AM

This step is not always straightforward if the failure is not singular. In this case, we should find the dirty batch operation by operation, plant by plant, and part by part.

See the article about finding dirty batch: LINK

4. Who - Who is involved or impacted?

Identify the key individuals or roles related to the problem. This includes: The person who detected the problem, and the operator or process responsible during occurrence.

Example:

• Detected by: J.L. (Customer Plant)
• Occurred under: M.T. (Operator, Warwick Plant)

This doesn't only help describing the problem, but also allows a faster communication and data gathering for further investigation. So even though the failure mode is not about the operator, we can identify the name who was working in the relevant line at that time.

If the issue occurred in a fully automated process, then we can state that "The problem is independent from operator involvement.”

5. Why - Why is this a problem?

This question in 5W2H is often misunderstood. At this stage, we are not asking why the problem happened, this investigation belongs to root cause analysis. Instead, we are justifying why the issue matters by comparing actual status versus required condition. So we ask "Why is this a problem"?

Example:

"Windshield quality requirement is 'no cracks'. Current part has a crack in the corner. Therefore, it is not compliant."

So we identified that why is this a problem here. It is a problem, because actual status (crack) is not in comply with the standard requirement (no crack).

If there are differing requirements between customer and manufacturer, we can capture both here.

6. How - How did the problem occur, and how was it detected?

Describe the sequence of events or process steps where the problem appeared. Highlight if the process was in normal conditions or if there were any deviations. Simply put, we're telling the story here.

Example – Detection: "During car assembly, the operator noticed a small crack in the windshield corner."

Example – Occurrence: "The crack occurred during standard production when the windshield was tempered, causing stress at the corner."

If there’s uncertainty (e.g., could have happened during transport), we should indicate this clearly and need to update this, once more data is gathered.

7. How Much - What is the size / impact of the problem?

Quantify the problem’s size. Is it an isolated case or widespread? Report affected units and any suspected ones.

Example: "1 car affected at customer site. 6 windshields with visible cracks. 400 windshields under suspicion and need inspection."

At this stage, we're reporting the initial known impact. But as soon as more data collected, we should update this section.

Conclusion

By systematically answering these 7 questions, we build a complete definition of the problem. This sets the foundation for effective root cause analysis in a problem solving study.

The 5W2H Problem Definition framework is a simple but a powerful tool. It is very useful to understand all the necessary details for a proper problem definition.

If you want to learn more, you can check out my Udemy course.