Monthly Archives: January 2012
The 16 step M.E.N Problem Solving Process Approach ©
1) Identify the problem (What is the gap)
2) Describe the problem in detail (Provide detailed information)
3) Select potential containment methods (stop the bleeding) (Plan)
4) Decide on best containment action (cost/ benefit analysis/ test method) (Plan)
5) Implement containment actions (Try it out/ test it) (Do)
6) Verify the effectiveness/ Decide (Will it do what you want it to) (Check/ Act)
7) Select potential root causes (Plan)
8) Decide on most likely/ feasible root cause/s to address (Do)
9) Collect data to verify which of the decided upon root causes are correct (check)
10) Decide on the actual root cause/s (based on data collected to verify) (Act)
11) Select potential permanent corrective action (cost/ benefit analysis/ risk) (Plan)
12) Decide on data collection methods to verify corrective action will work (Plan/ Do)
13) Review data/ verify permanent corrective actions will work as planned (check)
14) Implement permanent corrective actions (Act)
15) Verify effectiveness of permanent actions (check – again)
16) Implement preventive actions (standardize/ communicate/ audit for ongoing effectiveness) (Act)
The PDCA (Plan-Do-Check-Act) is not just another quality tool or quality notion. The PDCA cycle is sometimes linked with PDSA (Plan-Do-Study-Act) which basically are both the same in my eyes. The PDCA/ PDSA cycles are not merely quality tools but are how we deal effectively with life. PDCA is used in more areas than most of us think. For example – in getting to work in the morning we must PLAN what time we need to get up, the best route to get there and prepare our needed items in advance. Next comes the DO which merely means we implement our plan and get to work (car, bus, etc…). The 3rd step is to CHECK (or study) the effectiveness of the results. Did we get to our destination on time and safely? Lastly comes ACT which means that – based on the results of our planning and implementation efforts we either correct the results or possibly refine/ improve how we will do it the next time. If we did not meet the goal we call it corrective action. If we did and we look to improve the results it is called continual improvement. Either way action based on data/ results is taken.
This can be applied to other life processes as well such as cooking dinner. In this case we (PLAN) the meal (what, when, how many people, etc…), We (Do) prepare the meal after which we (CHECK) the results by eating it and then (ACT) decide if we need to either make it over, add some seasoning or make it different next time.
The PDCA is also commonly usd in the quality field as an improvement tool. After an opportunity for improvement is selected a definitive PLAN is developed to attack it. The plan is again implemented (Do) and the results verified (Check) for effectiveness. Did we achieve the goal (reduce an event from occurring, remove a defect, increase the throughput of a process, etc…). At this point we either determine we need to reformulate our plan or conclude that we achieved the goal and move onto improve the process further or move onto another process altogether.
As you can plainly see the PDCA/ PDSA cycle is not just another “Quality tool”. It is how we effectively deal with life and improve things.
Here is to effective problem solving.
Problem Analysis – 1st critical step – Gathering data
An often occuring issue in many problem solving efforts is the failure to gather adequate data about the issue and failing to look at the issue from the “eyes of the process”. All too many problem solving efforts take place from a meeting room table and without gathering enough data about the problem at the site where it occurred. The Japanese call this Gemba.
Once you have gathered the background information about the problem it is time to go out to where the actual issue occurred. Initial questions to ask for example are as follows:
a) When did it occur?
b) Where did it occur specifically? (plant/ machine/ line/ area)?
c) How frequently/ to what extent/ etc..?
d) Who was involved?
e) What exactly occurred and what is the problem specifically in the eyes of the customer and the process itself?
When you go to the worksite itself it is very helpful to interview those involved. Another useful task is to “try the process”. Many problem solvers are afraid to “get their hands dirty” by actually trying the process steps themselves. In doing so many potential root causes may reveal themselves that are “under the radar” of management. I also try to look at the process and the issue from the eyes of the person working within the process as well as understanding how their specific strengths, weaknesses, and personality may have influenced the issue occurring. Many times I have seen problem solving teams try to disregard the “people’ side of the equation which is not wise (in my opinion).
You also need to look outside the process with the eyes of an outsider as well.
My approach to problem is to get as many potential questions on the table as to what may have caused the issue and that means going to the process (I refer to it as the eyes of the process) vs merely looking at the issue from a high level alone.
Here is to good problem solving.