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.
By answering each of these systematically, we ensure a holistic understanding of the issue, which is essential for effective problem-solving. Let’s walk through each element of this method with practical insights and examples. We will ask some questions 2 times for both problem occurrence and detection.
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.
Mete Kilic 
Leave a Reply