STRUCTURED QUALITY IMPROVEMENT: Problem Diagnosis
I believe: Quality Improvement requires left-brain and right-brain thinking.
As discussed in Quality Capsule 5, chronic problems can be solved using a structured quality improvement methodology.
There are four key steps in the quality improvement methodology:
1. Problem Definition
2. Problem Diagnosis
3. Problem Remedy
4. Locking the Improvement.
In Quality Capsule 5 we expanded on Problem Definition.
In order to reinforce the importance of Problem Definition, here is an example of an effective problem statement:
About 22% of the purchase order forms that our organization generates are returned to us for additional processing. This involves correcting errors, filling in missing information, etc. The related corrective effort translates to Rs 45,000,000 per annum.
The mission for the project team is to halve the errors in our purchase order forms, by March 2021.
This is a good problem statement.
- It clearly relates to performance since we must do additional processing.
- It indicates the consequential COPQ impact.
- Further, it is clear and measurable.
- Also, it seems manageable because it concerns purchase order forms that our organization generates.
- It does not imply blame, cause or solution.
Here are a few insights:
- Left-brain is logical. It involves empirical thinking.
- Right-brain is creative. It involves creative thinking.
- Quality tools are in good supply for facilitating empirical and creative thinking.
- A quality improvement project is a chronic problem scheduled for solution.
Problem Diagnosis
This step for structured Problem Diagnosis involves:
1. Analyze Symptoms
2. Formulate Hypotheses of Causes
3. Test Hypotheses
4. Identify Root Causes.
The first step for a quality improvement project team is to collect and analyze data on the symptoms of the problem. Symptoms are any observable phenomena arising from and accompanying the problem.
Quality Tools: Pareto analysis; flow diagram; data gathering.
Having established a common understanding of the problem and its visible symptoms, the team must now focus on ideating for the causes of the problem. These are hypotheses.
Quality Tools: Brainstorming; cause-effect diagram; flow diagram; stratification.
A hypothesis is merely an unproven assertion as to reasons for existence of the problem and symptoms. The team must now gather data to test these various hypotheses.
Quality Tools: Flow diagram; data gathering; stratification; pareto analysis; histograms; scatter diagrams; box plots.
The goal of all this data gathering, analysis, and hypotheses testing is to identify the vital few root causes.
Quality Tools: Flow diagram; data gathering; stratification; pareto analysis; histograms; scatter diagrams; box plots.
Exercise: Identify the thinking involved in the above mentioned quality tools: empirical? or creative?
I will discuss Problem Remedy in the next edu-blog on Wednesday, 19 August.
Now, refer to the question I had asked last week in Quality Capsule 5: What are the quality tools that top management must know?
My simple response is: Top management must know flow diagram; and pareto analysis. These two are mandatory. Knowledge of any additional tools can be an additional asset.
My question to you this week is: Which quality tool is most misunderstood?
Additional Reference: Quality Improvement Toolbox, Juran Institute Inc.
To order, please follow https://www.qimpro.com/store/ToolBox/p – STOCK CLEARANCE SALE
Cause n effect
In the testing of hypotheses for root cause identification:
One of the dimensions is that the hypothesis must fit not only the the ‘failure data’. I should also fit the success/no-problem events.
On the surface this would appear to be a moot point. However, in my experience, it the most commonly missed item. Thus I share.
Vinay…You seem to be an accomplished Quality / Reliability Engineering professional.
Your thinking is aligned with Quality by Design. You will waltz with the FMEA tool.
Quality Improvement assumes you have existed for a period of time and institutionalized chronic problems. The aim is to reduce the problem project-by-project.