Problem-solving techniques for a high-performance team

While most people associate lean with tools and principles such as value stream mapping, one-piece flow, kanban, 5-S, Total Productive Maintenance and kaizen events, few people think about the more mundane aspects of lean. Problem solving is one of the keys to a successful lean implementation because it empowers all of those involved.

Lean manufacturing has a unique way of solving problems. It does not just look at the effect of the problem and try to cover it with a Band-Aid. Rather, the root cause of the problem is identified and the root cause, as well as all contributing factors, is eliminated from the system, process or infrastructure in order to permanently solve the problems. What is the difference in these two approaches? Simple, when you find and rectify the root causes, the problem will be solved forever. Even other problems occurring due to these root causes will be eliminated in this effort.

It is very clear now that we must find out the root causes of the problems before we think about rectifying them in lean manufacturing environments. So, how should we do this? What are the tools available to perform these tasks? Let’s look at what problem solving is about. We’ll begin by asking the question: “What is a problem?” A good definition of a problem is a variation from a recognized standard. In other words, you need to know how things should be before you can recognize a possible cause for them not being that way. After a problem has been recognized, a formal problem-solving process should be applied.

 

High performance work teams typically use four problem-solving tools:
1. Plan, Do, Check, Act (PDCA)
2. 5-Why Analysis
3. Ishakawa (Fishbone) Diagram
4. Simplified Failure Modes and Effects Analysis (SFMEA)

Plan, Do, Check, Act (PDCA)
The Deming PDCA cycle provides effective guidelines for successful problem solving. The cycle
includes:

Plan
Clearly Define the Problem (P1)
“A problem clearly stated is a problem half solved”. Although it seems like a trivial step, the team should not take this step lightly. It is important to begin this problem-solving journey with a clear, concise problem statement. If this is not done properly, it could lead to one of the following: excessive time in cause identification due to a broad problem statement, predisposing the team to a particular solution, or problem solving turns into solution implementation rather than root-cause identification and remedy.

Collect Evidence of Problem (P2)
This activity focuses on obtaining information/data to clearly demonstrate that the problem does exist. In the case of team problem solving, this should be a quick exercise since the reliability engineering function must have been looking at data in order to create the team. The output of this activity will be a list of evidence statements (or graphs) to illustrate that the problem exists, its size and the chronic nature of it.

Identification of Impacts or Opportunities (P3)
This part of the Plan segment focuses on identifying the benefits if this problem solving is successful. This activity needs to be thought of in two different perspectives because Project Team work can take the form of control work, e.g. fixing a problem that stands in the way of expected results or pure improvement (attempting to take results to a new level of performance). In each case the output of this activity will be a list of statements. The impact statements and opportunity statements should be stated in terms of loss of dollars, time, “product”, rework, processing time and/or morale.

Measurement of Problem (P4)
Before problem solving proceeds, it is important for the team to do a quick check on the issue of how valid or reliable the data is on which the team is making the decision to tackle the problem. For the parameter(s) that are being used as evidence of the problem, is there any information known by the team that would question the validity, accuracy or reliability of the data? This question should be examined whether we are relying on an instrument, a recorder or people to record information or data. If the team suspects that there are significant issues that “cloud” the data, then these measurement problems need to be addressed, fixed and new measures obtained before proceeding with the other segments of PDCA.

Measure(s) of Effectiveness (P5)
At this point, the team needs to identify how they intend to measure success of their problem-solving efforts. This is one of the most important steps in PDCA and one that certainly differentiates it from traditional problem solving. The strategy is to agree on what and how, to obtain the benchmark “before” reading, perform the PDCA activities and re-measure or obtain the “after” measure. At that point, the team will need to decide whether they need to recycle through PDCA in order to achieve their pre-stated objective.

Do
Generate Possible Causes (D1)
To avoid falling into the mode of solution implementation or trial and error problem solving, the team needs to start with a “blank slate” and from a fresh perspective lay out all possible causes of the problem. From this point, the team can use data and its collective knowledge and experience to sort through the most feasible or likely major causes. Proceeding in this manner will help ensure that the team will ultimately get at root causes of problems and won’t stop at the treatment of other symptoms. The best tool to facilitate this thinking is the Cause and Effect Diagram done by those people most knowledgeable and closest to the problem.

Broke-Need-Fixing Causes Identified, Worked On (D2)
Before proceeding to carry out either an Action Plan (for Cause Remedies) or an Experimental Test Plan, there are often parts of the process that are “broke”. This could take on many different forms.

Write Experimental Test or Action Plan (D3/4)
Depending upon the type of problem being worked on, the PDCA strategy will take one of two different directions at this point. The direction is based on whether it is a “data-based” problem or “data-limited” problem. Shown in the table below is the distinction between these two strategies and in particular, the difference between an Action Plan and Experimental Test Plan. Note that in some cases, it will be necessary to use a combination of Action Plans and Experimental Test Plans. That is, for some cause areas an Action Plan is appropriate and for other causes within the same problem, carrying out an Experimental Test Plan is the best route.

Write Action Plan for Cause Remedies (D3)
In order to get to the point of writing the Action Plan, the team needs to brainstorm possible solutions or remedies for each of the “cause areas” and reach consensus on the prioritized solutions. This work can be carried out as a team or split into sub-teams. Either way, the entire team will have to reach agreement on proposed remedies and agree to the Action Plan. The Action Plan will be implemented in the Check segment.

Write Experimental Test Plan (D4)
The Experimental Test Plan is a document which shows the experimental test(s) to be carried out. This will verify whether a root cause that has been identified really does impact the dependent variable of interest. Sometimes this can be one test that will test all causes at once or it could be a series of tests.

Note: If there is a suspicion that there is an interaction between causes, those causes should be included in the same test.

The Experimental Test Plan should reflect:

• Time/length of test

• How the cause factors will be altered during the trials

• Dependent variable (variable interested in affecting) of interest

• Any noise variables that must be tracked

• Items to be kept constant

Everyone involved in the Experimental Test Plan(s) should be informed before the test is run. This should include:

• Purpose of the test

• Experimental Test Plan (details)

• How they will be involved

• Key factors to ensure good results

When solutions have been worked up, the team should coordinate trial implementation of the solutions and the “switch on/off” data analysis technique.

Resources Identified (D5)
Once the Experimental Test Plan or the Action Plan is written, it will be fairly obvious to the team what resources are needed to conduct the work. For resources not on the team, the team should construct a list of who is needed, for what reason, the time frame and the approximate amount of time that will be needed. This information will be given to the Management Team.

Revised PDCA Timetable (D6)
At this point, the team has a much better feel for what is to be involved in the remainder of its PDCA activities. They should adjust the rough timetables that had been projected in the Plan segment. This information should be updated on the team Plan, as well as taken to the Management Team.

Management Team Review/Approval (D7)
The team has reached a critical point in the PDCA cycle. The activities they are about to carry out will have obvious impact and consequences to the department. For this reason, it is crucial to make a presentation to the Management Team before proceeding. This can be done by the team leader or the entire team. The content/purpose of this presentation is:

• Present team outputs to date

• Explain logic leading up to the work completed to date

• Present and get Management Team approval for

− Measure of Effectiveness with “before” measure

− Priority causes

− Action Plan (for Cause Remedies) or Experimental Test Plan

− Revised PDCA timetable

Check
Carry out Experimental Test or Action Plan (C1/C2)
Depending upon the nature of the problem, the team will be carrying out either of these steps:

• Conduct Experimental Test Plan(s) to test and verify root causes or

• Work through the details of the appropriate solutions for each cause area. Then, through data, verify to see if those solutions were effective.

Carry out Action Plan (C1)
In the case of Action Plans, where solutions have been worked up and agreed to by the team, the “switch on/switch off” techniques will need to be used to verify that the solutions are appropriate and effective. To follow this strategy, the team needs to identify the dependent variable – the variable that the team is trying to impact through changes in cause factors.

Carry out Experimental Test Plan (C2)
During the Check segment, the Experimental Tests to check all of the major prioritized causes are to be conducted, data analyzed and conclusions drawn and agreed to by the team.

Analyze Data from Experimental or Action Plan (C3)
Typically, one person from the team is assigned the responsibility to perform the analysis of the data from the Test Plan. When necessary, this person should use the department or plant resource available to give guidance on the proper data analysis tools and/or the interpretation of outputs. The specific tools that should be used will depend upon the nature of the Test Plan.

Decisions-Back to Do Stage or Proceed (C4)
After reviewing the data analysis conclusions about the suspected causes or solutions that were tested, the team needs to make a critical decision of what action to take based on this information.

Implementation Plan to Make Change Permanent (C5)
The data analysis step could have been performed in either of the following contexts:

• After the Action Plan (solutions) was carried out, data analysis was performed to see if the dependent variable was impacted. If the conclusions were favorable, the team could then go on to develop the Implementation Plan.

• The Experimental Test Plan was conducted; data was analyzed to verify causes. If the conclusions were favorable (significant causes identified), the team must then develop solutions to overcome those causes before proceeding to develop the Implementation Plan. (e.g., It was just discovered through the Test Plan that technician differences contribute to measurement error.)

Force Field on Implementation (C6)
Once the Implementation Plan is written, the team should do a Force Field Analysis on factors pulling for and factors pulling against a successful implementation – success in the sense that the results seen in the test situation will be realized on a permanent basis once the solutions are implemented.

Management Team Review/Approval (C7)
The team has reached a very critical point in the PDCA cycle and needs to meet with the Management Team before proceeding. This meeting is extremely important, because the team will be going forward with permanent changes to be made in operations. The Management Team not only needs to approve these changes but also the way in which they will be implemented.

Act
Carry out Implementation Plan (A1)
If the team has written a complete, clear and well thought through Implementation Plan, it will be very obvious what work needs to be done, by whom and when to carry out the Act segment of the PDCA cycle. The team should give significant attention to assure communications and training is carried out thoroughly, so department members will know what is changing, why the change is being made and what they need to do specifically to make implementation a success.

Post-Measure of Effectiveness (A2)
After all changes have been made and sufficient time has passed for the results of these changes to have an effect, the team needs to go out and gather data on all of the Measures of Effectiveness. The data then needs to be analyzed to see if a significant shift has occurred.

Analyze Results vs. Team Objectives (A3)
In the previous step, the team looked at whether the Measure(s) of Effectiveness had been impacted in any significant way by the permanent implementation of the changes. The team cannot stop here. If the answer to that question is favorable, then the team needs to verify if the amount of improvement was large enough to meet the team objective.

Team Feedback Gathered (A4)
Once the team decision has been made that the PDCA cycle has been successfully completed (based on Measure of Effectiveness change), the team needs to present this information to the Management Team. Before this is done, the team leader needs to gather feedback from the team. This feedback will be in the form of a questionnaire that all team members (including the team leader) should fill out. The results will be tallied by the team leader and recorded on form A3.

Management Team Close-out Meeting (A5)
Before disbanding, the team needs to conduct a close-out meeting with the Management Team. The major areas to be covered in this meeting are:

• Wrap up any implementation loose ends

• Review Measure of Effectiveness results, compare to team objective

• Ensure team documentation is complete and in order

• Share team member feedback on team experiences (standardized forms and informal discussion)

5-Why Problem Solving
When you have a problem, go to the place where the problem occurred and ask the question “Why” five times. In this way, you will find the root causes of the problem and you can start treating them and rectifying the problem.

5-Why analysis is a technique that doesn’t involve data segmentation, hypothesis testing, regression or other advanced statistical tools, and in many cases can be completed without a data collection plan. By repeatedly asking the question “Why” at least five times, you can peel away the layers of symptoms which can lead to the root cause of a problem.

Here is a simple example of applying the 5-Why analysis to determine the root cause of a problem. Let’s suppose that you received a large number of customer returns for a particular product. Let’s attack this problem using the five whys:

1. Question: Why are the customers returning the product?
Answer: 90 percent of the returns are for dents in the control panel.

2. Question: Why are there dents in the control panel?
Answer: The control panels are inspected as part of the shipping process. Thus, they must be damaged during shipping.

3. Question: Why are they damaged in shipment?
Answer: Because they are not packed to the packaging specification.

4. Question: Why are they not being packed per the packaging spec?
Answer: Because shipping does not have the packaging spec.

5. Question: Why doesn’t shipping have the packaging spec?
Answer: Because it is not part of the normal product release process to furnish shipping with any specifications.

Using the five whys in this case revealed that a flaw in the product release process resulted in customers’ returning of a product.

Ishikawa Diagram
In some cases, a problem can be due to more than one root cause or may have multiple forcing functions that either singularly, or in combination, will result in the problem. The 5-Why process may not provide the ability to address these more complex problems. The pictorial representation of this root cause analysis can be achieved using an Ishikawa or Cause and Effect Diagram. Because of its shape, this process is also called a Fishbone Diagram. This helps people communicate the root cause and the potential contributing factors and/or forcing function in a simple, straightforward graphic format. This method is very clear way of representing the relationship between the root cause of the problem and all of the possible factors that may be associated with the problem.

The Cause and Effect Diagram or Fishbone Diagram is a graphical tool for identifying the relationship between a problem and its potential causes. One of the most effective ways of constructing such a diagram is to brainstorm potential causes in a team environment. For example, a cause and effect diagram might be used to determine possible causes of a recurring defect in a manufacturing process.

The Fishbone Diagram is drawn to resemble the skeleton of a fish, with the issue (problem or process condition) on the right side. The major cause categories are written in the boxes on the left side of Cause and Effect Diagram. Summarize the major causes under the categories. These categories are usually Methods, Measurements, Machines, Materials and People.

Under each category, identify potential causes for the problem relating to the category. For example, if the fact that incorrect parts are being delivered to the assembly is a potential cause for the problem being addressed, that would be listed as a branch under “Materials.”

Both Fishbone Diagrams and the Five Why analysis are simple, very useful methods for problem solving. One of the first steps to creating a Lean culture is to turn every employee into a problem solver. This should begin with teaching the use of “The Five Why’s” on a regular basis.

Simplified Failure Modes and Effects Analysis
Simplified Failure Modes and Effects Analysis (SFMEA) is a top-down method of analyzing a design, and is widely used in industry. In the U.S., automotive companies such as Chrysler, Ford and General Motors require that this type of analysis be carried out. There are many different company and industry standards, but one of the most widely used is the Automotive Industry Action Group(AIAG). Using this standard you start by considering each component or functional block in the system and how it can fail, referred to as failure modes. You then determine the effect of each failure mode, and the severity on the function of the system. Then you determine the likelihood of occurrence and of detecting the failure. The procedure is to calculate the Risk Priority Number, or RPN, using the formula:
RPN = Severity × Occurrence × Detection

The second stage is to consider corrective actions which can reduce the severity or occurrence, or increase detection. Typically, you start with the higher RPN values, which indicate the most severe problems, and work downwards. The RPN is then recalculated after the corrective actions have been determined. The intention is to get the RPN to the lowest value.

Conclusion
These four tools can be effectively utilized by natural work teams to resolve most problems that could confront them as part of their day-to-day activities. None require special skills. Instead, they rely on native knowledge, common sense and logic. The combined knowledge, experience and skills of the team is more than adequate for success.

Daily problem-solving tips in a lean organization:

• Keep what may seem like ‘little problems’ from adding up and becoming big problems in the future. The only way to work on tomorrow’s problems is to work on the problems today while they are still small.

• Use visual management and standard work tools to catch problems before they start adding up.

• Build the skills, tools and systems needed to deal with those problems as soon as possible.

• Start using 5-Why analysis. Continue asking “Why?” at different stages in order to dig deeper into the root cause of a problem.

• Use Plan-Do-Check-Act, or PDCA. Without fully understanding the cause of what is happening in a situation, an organization will not have the control in its processes in order to sustain lean.

• Understand that the small problems are a valuable contribution for future results.

About the author:
Keith Mobley is a consultant with Life Cycle Engineering. He has earned an international reputation as one of the premier consultants in the fields of plant performance optimization, reliability engineering, predictive maintenance and effective management. He has more than 35 years of direct experience in corporate management, process design and troubleshooting. For the past 16 years, he has helped hundreds of clients worldwide achieve and sustain world-class performance. Mobley is actively involved in numerous professional organizations. Currently, he is a member of the technical advisory boards of: American National Standards Institute (ANSI), International Standards Organization (ISO) as well as American Society of Mechanical Engineers (ASME) and others. He is also a Distinguished Lecturer for ASME International. To learn more, visit www.LCE.com.