1. A Tool For Continuous Improvement
PDCA
A Tool For Continuous Improvement *

2. Objectives Introduce Lean Six Sigma (LSS) principles
Identify the steps of the PDCA problem solving model used in a LSS model
Identify and use various quality problem solving tools
Identify an use various team dynamic tools
Standardize corporate wide PDCA process
Notes

3. LSS Yellow Belt
A Lean Six Sigma Yellow Belt is an individual who has a broad understanding of LSS and the basic continuous improvement tools
Yellow Belts participate on improvement teams as well as use the tools, as applicable, in their day-to-day jobs

4. What is Six Sigma
Six Sigma is a business management strategy, originally developed by Motorola, that today enjoys widespread application in many sectors of industry
Six Sigma seeks to identify and remove the causes of defects and errors in manufacturing and business processes. Its primary focus is on process targeting and variation reduction
It uses a set of quality tools, including statistical methods, and creates a special infrastructure of people within the organization who are experts in these methods
Each Six Sigma project carried out within an organization follows a defined sequence of steps and has quantified financial targets (cost reduction or profit increase)

5. What is Lean
“Lean” is a business management strategy, originally called the “Toyota Production System” that was born at Toyota in the early 1950’s

6. 7 Forms of Waste Types of Waste CORRECTION MOTION WAITING
Repair or
Rework
Any wasted motion
to pick up parts or
stack parts. Also
wasted walking
Any non-work time
waiting for tools,
supplies, parts, etc..
Types of
Waste
OVER PROCESSING
OVERPRODUCTION
Producing more
than is needed
before it is needed
Doing more work than
is necessary
INVENTORY
TRANSPORTATION
Maintaining excess
inventory of raw mat’ls,
parts in process, or
finished goods.
Wasted effort to transport
materials, parts, or
finished goods into or
out of storage, or
between
processes.

7. What is Lean Six Sigma (LSS)
Lean Six Sigma is a business management strategy that combines the tools and techniques of Lean Manufacturing and Six Sigma to form an integrated continuous improvement strategy

8. Costs Profit Profit Profit Profit Profit A. B. C. D. E.
Total Product or Service Price to Customer
Profit
Profit
Profit
Budget Constraints and
Competition Drive a Lowered Price
Waste
(COPQ)
Total Cost to Produce or Provide
Profit
Profit
Theoretical Costs
i.e.,
Cost of Doing the Right Things Right the First Time
Waste
(COPQ)
COPQ
Theoretical Costs
Theoretical Costs A. B. C. D. E.

9. What is PDCA Problem Solving
Originally developed by Walter Shewhart in 1930s. Sometimes referred as “Shewhart Cycle”
Solving problems by finding real root causes
Taking action that permanently removes the problem
Part of the Continuous Improvement methodology
Involves two main strategies
Analysis
Action
The purpose of the 8D problem solving process is to solve problems by finding real root causes and taking action that permanently removes it. The two main strategies are analysis and action.

10. PDCA ACT PLAN CHECK DO - Standardize actions
- Continue to collect data and verify goals
PLAN
- Understand gaps between customer’s expectations and what you deliver
- Improve process first by analyzing root causes and identify solutions for these problems
CHECK
- Observe the effect of the change
- Collect data to verify changes are working DO
- Implement solutions using action planning
- Collect data to verify goals

11. What is Root Cause Analysis
Process to arrive at the preliminary causes of a problem
Finding the reason a problem exists and eliminate it with corrective actions
Front-end work
Defining the problem in quantifiable terms
Testing potential root causes
Verifying the root cause
Common Barriers to Root Cause Analysis
Problem described incorrectly
Problem solving effort expedited
Poor team participation
No logical process
Permanent corrective action not implemented
Over-reliance on experience
Root cause analysis is the process to arrive at the preliminary cause of a problem. Root cause is the reason a problem exists and the search for root cause is finding that reason to eliminated it with corrective actions. The process is not unlike the diagnosis of a doctor; if the right root cause is not determined, the patient may be in for a series of frustrating actions that don’t relieve the pain or restore them to health. In the worldwide competitive market place, our problems can hold us back. We need to use the systematic problem solving process for correct and speedy “diagnosis” of root cause to return the product and process to health.
There are specific tools to help in the root cause analysis process. These tools will be discussed throughout this course. The most important tool in finding root cause is your own thought process. Learning to ask the right questions is the key to making the process work. Root cause analysis provides the process and questions to do this.
There is a great deal of front-end work in finding a root cause including defining the problem in quantifiable terms, testing potential root causes and verifying the root cause. But this time spent in the beginning leads to reduction in problem resolution cycle time and better long term result, such as satisfied customers and prevention of the problem recurring.
Finding a root cause is not a simple task. It requires a great deal of disciplined analysis. Fortunately, we have a problem solving process to provide systematic direction and tools to use at each step. When we don’t follow the process, it makes finding root causes more difficult. Some of the most common barriers to finding real root cause include:
Problem described incorrectly: A clear, thorough description of the problem is necessary. A problem must be adequately described and be narrow enough in scope for the team to handle the problem effectively.
Problem solving effort expedited: Steps were skipped in the problem solving process to obtain a quick solution.
Poor team participation: Not all team members participated effectively, so the team failed to consider all the causes of the problem.
No logical process: The team lacks a disciplined system to prioritize, analyze, and review problems.
Permanent corrective action not implemented: A root cause may be identified, but no action taken to implement the permanent corrective actions.
Over-reliance on experience: While experience is the best teacher, it may not be the best problem solver. Experience sometimes limits our view of the overall situation.

12. PDCA Project Status Report
Notes

13. Use a Team Approach Starting out right
Set meetings, procedures, ground rules
Team Membership
Who are the other members?
Why are they here?
What is my role in this team?
WIIFM
Communications
Select a team champion
Select team members
Select team support
Are all areas of technical expertise available?
When a problem cannot be solved quickly by an individual, it is necessary to form a team. The team will engage in the investigation and resolution of the problem. Many factors are critical to establish a group and to ensure that the group can work effectively together. Using a team approach is not just a step in the problem-solving process, but an overriding framework for decision making. It is necessary to reevaluate team membership continually.
Membership is identifying who is on the team, why, and what roles they play. Whenever anyone comes into a group for the first time, there are entry issues that may be determined by management selecting the members to participate or by other team members. The first issues to be addressed are ones of membership.
Establish time and resources to work on project

14. Stages of Team Development
The stages include:
Forming
Storming
Norming
Performing
Each stage is unique and each team experiences it in a different way
Things are always changing
When individuals are forming into teams, it’s natural that they should experience a series of conflicting emotions: excitement and anxiety about being on a new team, uncertainty about learning jobs, and nervousness about working with new team members. If left unattended, these feelings create an undercurrent that can negatively affect the team’s chance of success. Therefore, every team must spend time on activities that build understanding and support in the group in addition to tasks such as meetings and solving problems.
In a work team, everyone’s responsibilities change. Individuals who were formerly just concerned with their job must now become accountable for the work of the entire team. Supervisors who planned, organized and controlled the work must now become accountable for teaching team members to plan, organize and control the work. Team members must learn new jobs while learning how to deal with the interpersonal aspects of working in teams. The transition to work teams requires new learning and understanding of how teams change as they develop.
There are four recognizable stages of team development: Forming, Storming, Norming and Performing. Each stage has a different “feel” to it. Understanding the characteristics of each stage and what to do to move forward is essential for continued team performance.

15. Team Tools: Brainstorming
Select a facilitator
Give everyone 1-2 minutes to silently think about the problem
Invite everyone to contribute ideas
Write down all ideas
Continue until you run out of ideas
Discuss and narrow down ideas using Nominal Group Technique or Multi-Voting
Don’t critique ideas
Use your imagination
Build on others’ ideas
Piggybacking
Aim for QUANTITY
Record each idea

16. Plan: Define the Problem
Objective:
Review existing data
Specify the internal/external customer problem by identifying in quantifiable terms (who, what, when, where, why, how, how many) for the problem.
Use an “Operational Definition” that has a common meaning to everyone who reads it
Use verifiable criteria
Symptoms are often mistakenly used to describe a problem
Identify the internal/external customer expectations
PLAN
DEFINE THE PROBLEM
DEFINE THE GOAL
ROOT CAUSE ANALYSIS
IDENTIFY SOLUTIONS
The problem definition is the basis for solving the problem. The definition is used during brainstorming sessions to identify potential causes of the problem. Potential causes are those likely causes that appear on the surface to be the source of the problem.
It is important that the problem be described in terms that have the same meaning to everyone. This is best achieved through an operational definition. An operational definition consists of verifiable criteria that have the same meaning to the production worker, manager, customer, engineer, buyer, technician, team members, etc., and are used for past, present and future comparisons and analysis.
It is not uncommon for problems to be reported as symptoms. Some examples are noise, won't work, no power, machine down, broken tool, head froze up, contaminated, rough surface, porosity, shortage of parts, rattles, quality problem, won't work, worn out, line stopped, not to specification, labor problem, management problem, too much variation, etc. The problem solving team must then use a systematic approach to define the real problem in as much detail as possible.

17. Plan: Define the Problem
Process
Review existing data
Get team feedback
Go see the problem
Identify process flow
Ask 5W+2H
Are there multiple problems?
Is containment required
Tools
Process Mapping
5W+2H
Operational Definition
Historical Data & Charts
Pareto Chart
PDCA Project Status Sheet
It has been said that there are no new problems, only different manifestations of old problems. In problem definition, it is often useful to quantify the problem in similar situations. The criteria to match similar situations will vary with the type of problem. Identifying effective matches and evaluating the presence of the problem provides useful information to generate potential causes and possible problem solutions. If the similarity analysis identifies a comparable situation where the problem does not exist, the analysis can focus on the differences in where the problem is occurring and where it is not occurring.

18. Tools: Flowchart Flowcharting Symbols
Process Step
Represents functions or steps in the process. A brief description is written in the box.
Decision
Represents a point where there are at least two alternatives for the next step of the process. A question is written in the diamond.
Documentation
Represents a document that is produced as part of the process. A description is written in the box.
Process Start or Stop
Represents the beginning or end of the process. Usually labeled START or END.
Connector
Used to connect flowcharts between pages or long distances. Usually labeled with a letter or a number.
Storage
Represents product storage as finished goods or work in progress.
Inspection
Represents steps where a product is inspected.
However, an in-depth analysis is required to clearly define a problem. There are many examples where the analysis for a complete problem definition results in the solution being identified. The analysis starts with preparing a process flow diagram to define clearly the work process and alternative paths. Also, team preparation of the diagram ensures that all individuals are familiar with the process.

19. Tools: Current & Historical Data
Customer Feedback
PPM charts, SPC/Run charts
Program Timelines
Test Results
Performance Reports/Feedback
Input-Process-Output (IPO)

20. Tools: 5W2H Who? Who is the customer complaining?
What? What is the complaint or opportunity?
When? When did the problem start or occur?
Where? Where is the problem observed?
Why? Why is this problem occurring (known data)?
How? How does the process work?
How Many? How many defects?
The analysis proceeds by quantifying the 5W2H elements. They use key questions starting with "who" (identity), "what" (identity), "when" (timing), "where" (location), and "how many" (magnitude) to get the facts. These key questions are referred to as the 5W's and 2H's (5W2H).
WHO: Identify individuals associated with the problem. Characterize customers/sponsors who are complaining. Which operators are having difficulty?
WHAT: Describe the problem adequately. Does the severity of the problem vary? Are operational definitions clear (e.g., defects)? Is the measurement system repeatable and accurate?
WHERE: If a defect occurs on a system, where is the defect located? What is the location of the customer/sponsor complaint?
WHEN: Identify the time the problem started and its prevalence in earlier time periods. What time of the year/cycle does the problem occur?
WHY: Any known explanation contributing to the problem should be stated.
HOW: In what mode of operation did the problem occur? What procedures were used?
HOW MANY: What is the extent of the problem? Is the process in statistical control? Are there any trends?

21. Tools: Pareto Chart 1st Level Pareto 2nd Level Pareto VALUE
What is the relative importance of each part of the problems?
What should be the starting point for problem solving? Where should we focus our attention?
The analysis proceeds by quantifying the 5W2H elements. They use key questions starting with "who" (identity), "what" (identity), "when" (timing), "where" (location), and "how many" (magnitude) to get the facts. These key questions are referred to as the 5W's and 2H's (5W2H).
WHO: Identify individuals associated with the problem. Characterize customers/sponsors who are complaining. Which operators are having difficulty?
WHAT: Describe the problem adequately. Does the severity of the problem vary? Are operational definitions clear (e.g., defects)? Is the measurement system repeatable and accurate?
WHERE: If a defect occurs on a system, where is the defect located? What is the location of the customer/sponsor complaint?
WHEN: Identify the time the problem started and its prevalence in earlier time periods. What time of the year/cycle does the problem occur?
WHY: Any known explanation contributing to the problem should be stated.
HOW: In what mode of operation did the problem occur? What procedures were used?
HOW MANY: What is the extent of the problem? Is the process in statistical control? Are there any trends?

22. Tools: Operational Definition
Once the problem statement has been identified, an operational definition is developed. An Operational Definition worksheet or IS/IS NOT worksheet will assist in this step of the process.
A definition of the problem can best be developed using approaches that organize the facts to get a comparative analysis. These approaches do this by asking what "is" against what "is not." Then they draw distinctions from this comparison, testing these against the problem definition and forming a statement or description of the problem that must be resolved.

23. Tools: Input-Process-Output (IPO)

24. Containment Actions Is Containment Required?
Define and implement containment actions to isolate the effect of problem from any internal/external customer until corrective action is implemented
Verify the effectiveness of the containment action
The main objective of this part of the systematic problem solving process is to isolate the effects of a problem concern on the customer by implementing containment actions. A problem concern may be poor quality, a marginal product design, or a process or system that is unpredictable. A containment action may be stopping the process of a known source of a problem.

25. Containment Actions Minimize effect of problem on the customer
Temporary SOP’s
100% sorting/inspection
Do/Perform/Make in-house vs outsource
Temporary company policies
Additional approvals (signoff)
Single source
Certified operators/people
Common Problems with Containment Actions
Considered as permanent solution
Costly
Easily forgotten
Typically only address an effect and not root cause
Same problem/effect will surface again
Once a problem has been described, immediate actions are to be taken to isolate the problem from the customer/sponsor. In many cases, the customer/sponsor should be notified of the problem. These actions are typically "Band-Aid" fixes.
Unfortunately, most of these actions will add cost to the product/service. However, it is important to protect the customer/sponsor from the problem until permanent corrective actions can be verified and implemented.
Some interim actions are "temporary short-term" actions taken until a permanent corrective action is defined, implemented and verified. The danger of many interim actions is that they are considered to be a permanent solution to a problem. But in reality, they are "Band-Aids." Many temporary "fixes" are easily forgotten because they are looked upon by many as permanent problem solutions. It is a mistake to treat containment actions as the solution to the problem. They typically address the effect, and should be considered only the immediate "First Aid" which needs to be reviewed quickly and ultimately removed. This misinterpretation leads to a situation where the same problem surfaces again. And in many cases, these problems are disguised as new ones; thereby, they increase the list of concerns. After implementing interim actions, either containment or temporary short term fixes, they must be verified by measuring the effectiveness in quantifiable terms.

26. Tool: Containment Action Worksheet
Notes

27. Plan: Define the Goal PLAN Objective: Identify “What is the end goal”
DEFINE THE PROBLEM
DEFINE THE GOAL
ROOT CAUSE ANALYSIS
IDENTIFY SOLUTIONS
PLAN
The problem definition is the basis for solving the problem. The definition is used during brainstorming sessions to identify potential causes of the problem. Potential causes are those likely causes that appear on the surface to be the source of the problem.
It is important that the problem be described in terms that have the same meaning to everyone. This is best achieved through an operational definition. An operational definition consists of verifiable criteria that have the same meaning to the production worker, manager, customer, engineer, buyer, technician, team members, etc., and are used for past, present and future comparisons and analysis.
It is not uncommon for problems to be reported as symptoms. Some examples are noise, won't work, no power, machine down, broken tool, head froze up, contaminated, rough surface, porosity, shortage of parts, rattles, quality problem, won't work, worn out, line stopped, not to specification, labor problem, management problem, too much variation, etc. The problem solving team must then use a systematic approach to define the real problem in as much detail as possible.

28. Plan: Define the Goal Process Review data
Identify goals that are measurable
Does everyone understand?
Tools
Customer Expectations (Internal/External)
Team Tools
PDCA Project Status Sheet

29. Plan: Root Cause Analysis
Objective:
Identify all potential causes that could explain why the problem occurred
Isolate and verify the root cause by testing each potential cause against the problem description
PLAN
DEFINE THE PROBLEM
DEFINE THE GOAL
ROOT CAUSE ANALYSIS
IDENTIFY SOLUTIONS

30. Plan: Root Cause Analysis
Process
Brainstorm additional data requirements
Analyze data
Identify potential causes
Collect data to isolate root causes
Select potential root cause
Prioritize actions
Tools
Team Tools
Repeated Why
Cause & Effect Diagram
Check Sheets
SPC and Run Charts
Histogram
Process Flowchart
Pareto Chart
Scatter Diagram
Timeline
Root Cause Analysis Worksheet
PDCA Project Status Sheet
Once the problem has been described and the potential causes identified, the team should be evaluated. Are the right members on the team to investigate the potential causes? Is the authority to pursue the analysis of the potential causes well defined? All these questions must be answered to ensure the team will be successful in investigating the potential causes and determining the root cause.
Identify all potential causes that could have been present and may have caused the problem. Once all potential causes have been agreed on, choose several potential causes to investigate. If only one potential cause is investigated, a lot of time may be lost if that potential cause does not cause the problem. To expedite the investigation of potential causes, investigate several causes at the same time. Identifying several potential causes forces the team to address multiple causes rather than searching for a single cause. An implicit part of the problem analysis is investigating potential causes in parallel rather than in series. Many individuals are under the mistaken belief that data oriented problem solving can be accomplished by collecting relevant data on a problem, analyzing the results, and deciding the correct solution. Once data is collected and analyzed, new questions often arise. The data collection for this step in the problem solving process can be as simple as check sheets or as sophisticated as design of experiments. The data analysis can rely heavily on simple graphical techniques; histograms, Pareto or control charts. By using graphical tools, quick comprehension by all participants’ as well as accurately communicated information will result.

31. Identify Potential Causes
Continue to ask the repeated “Why” statements
List potential root causes
Group discussion / Brainstorming session
Cause and Effect diagram
FMEA
If the problem is new, develop a time line
An effectively problem solving strategy includes an investigation into all identified potential causes is a necessity. A cause-and-effect (C&E) diagram can be used to brainstorm all potential causes of the described problem. The more detailed the C & E diagram, the higher the chances the root cause will be included on the C & E. An effective C & E diagram will include input from all team members and will be discussed in detail.
If the problem has not previously been seen, a time line analysis could provide significant data. The time line will identify events occurring about the time the problem developed. If enough documentation is available, potential causes can be further identified. Investigation into the events occurring at the time the problem was discovered could lead to several important potential causes. Determining "what changed, when?" may identify potential causes of a problem.

32. Tools: Repeated Why Stick to the facts The Problem Statement is…….
Poor Quality Parts
WHY? (Because the)
Stick to the facts
WHY? (Because the)
WHY? (Because the)
WHY? (Because the)
WHY? (Because the)
The Problem Statement is…….

33. Tools: Cause and Effect
Typical Categories
Manpower
Machine
Methods
Material
Mother nature (Environment)
Measurement
Cause & Effect Diagrams are a form of structured brainstorming. They are used to find the causes of a specific “effect” in the work process. Since the causes are broken into pre-selected categories, it helps the group focus its brainstorming efforts. Organizations that use C & E Diagrams routinely have a standard set of Categories that they always use. Only if the group uncovers causes that do not fit into one of the standard categories are new ones added.
The standard categories used by most industrial organizations are:
Manpower - Machine - Measurement - Methods - Materials - Environment
Service organizations often use the same categories, or they may substitute one or more of the following:
Resources - Recognition - Requirements - Policies & Procedures
The steps for using a C&E Diagram are:
Determine the problem (effect) to work on.
Determine the initial causal categories.
Brainstorm to generate potential causes under each category.
Analyze the diagram and select the top 3 to 5 likely causes
Collect information to further investigate these causes.

34. Carmen’s World Famous Whoopie Pies
Tools: Check Sheet
VALUE
What facts or data patterns will help us to better understand the problem and its cause(s) ?
How do we translate our « opinions » about the problem into « facts » ?
Check sheets are used to capture factual data from the beginning. They are filled by operators to describe the situation following the data collection plan.
Carmen’s World Famous Whoopie Pies T
ypes of
defects in
finished pies
Data collected by:
Location:
Maine plant
Dates:
June 20-26
Lot size:
200
Defect
SUN
MON
TUE
WED
THU
FRI
SAT
Total
oo much cream
oo little cream
oo crumbly
oo big
oo small
Has a bite in it 24 9 21 13 14
Not chocolaty
enough 6 1
Not sweet
Project:

35. Tool: Histogram VALUE How frequently does a certain effect occur?
What does the frequency distribution look like - a normal curve or some other statistical form ?
How frequently is the process outside of specifications ?
What is the nature of the deviation outside of specifications, e.g., synthetically or not,...
Frequency
Shaft diameter

36. Tools: Histogram Normal Distribution Multi-Modal Distribution
Bi-Modal Distribution
Positively Skewed
Negatively Skewed

37. Tools: Sigma/Distribution Curve
68%
95%
99.7%
–3s
–2s
–1s X
+1s
+2s
+3s

38. Tools: Run Chart

39. Tools: Sigma/Distribution Curve
68%
95%
99.7%
–3s
–2s
–1s X
+1s
+2s
+3s

40. Tools: Run Chart / SPC Control chart
VALUE
In the variation we observe in a problem characteristic or parameter, what part is natural variation (within the process control limits) and what part is due to specific special causes ?
How often does the process go out of control?
Are there any discernable trends that should concern us ? Can any preventive actions be taken based on these trends ?
Control chart
random variation vs. special events
Out of control
USL
Upper control limit
Average
Lower control limit
LSL
Time

41. Tools: Scatter Diagram
Positive Correlation
Negative Correlation
A decrease in y may be
related to an increase in x.
No Correlation
There is no demonstrated
connection between y and x.
Variable 1
4.5
4.0
3.5 x
Variable 2 y
An increase in y may be
VALUE
Confirm that 2 variables are correlated
What is the nature of the relationship between the variables ?

42. Tool: Root Cause Analysis Worksheet
Notes

43. Plan: Identify Solutions
Objective:
Define the best permanent corrective actions
Identify measures to ensure the root cause is eliminated
DEFINE THE PROBLEM
DEFINE THE GOAL
ROOT CAUSE ANALYSIS
IDENTIFY SOLUTIONS
PLAN
After the root causes of a problem are identified, investigate the methods to fix the problem. Evaluate several approaches to solve the problem. A thorough analysis of different approaches to eliminate a root cause is a critical part of the problem-solving process.
One approach to generate potential solutions is to use the cause-and-effect diagram constructed in the prior steps. Have the team brainstorm the solutions, and often several solutions will be identified. One alternative would be to redesign the system or the process. This approach would eliminate the opportunity of the problem recurring.
Another alternative is to ask the opinion of the customer/sponsor. How the root cause is eliminated might impact the customer/sponsor in some unforeseen way. If similar problems have been previously identified and solved, assess those solutions. As part of this investigation, identify similarly engineered parts or organizational processes that may have experienced this problem. The team should also look at new and current technology around an engineered part and/or the process.
The team should remember that the solution needs to be incorporated in future products and processes. Advances for future products can only come from identifying and solving current problems.

44. Plan: Identify Solutions
Process
Identify best solutions
Verify solutions verses root cause
Select best solution
Clearly describe solution
Determine if simple test is possible
Verify measurable
Develop Implementation Action Plan
Tools
Team Tools
Action Planning
Force Field Analysis
Cause & Effect Diagram
Scatter Diagram
Decision Matrix
Root Cause Solution Worksheet
PDCA Project Status Sheet
Once the problem has been described and the potential causes identified, the team should be evaluated. Are the right members on the team to investigate the potential causes? Is the authority to pursue the analysis of the potential causes well defined? All these questions must be answered to ensure the team will be successful in investigating the potential causes and determining the root cause.
Identify all potential causes that could have been present and may have caused the problem. Once all potential causes have been agreed on, choose several potential causes to investigate. If only one potential cause is investigated, a lot of time may be lost if that potential cause does not cause the problem. To expedite the investigation of potential causes, investigate several causes at the same time. Identifying several potential causes forces the team to address multiple causes rather than searching for a single cause. An implicit part of the problem analysis is investigating potential causes in parallel rather than in series. Many individuals are under the mistaken belief that data oriented problem solving can be accomplished by collecting relevant data on a problem, analyzing the results, and deciding the correct solution. Once data is collected and analyzed, new questions often arise. The data collection for this step in the problem solving process can be as simple as check sheets or as sophisticated as design of experiments. The data analysis can rely heavily on simple graphical techniques; histograms, Pareto or control charts. By using graphical tools, quick comprehension by all participants’ as well as accurately communicated information will result.

45. Tools: Action Matrix Big Effect on Root Cause Big Payoff/Easy to do
Big Payoff/Hard to do
PRIORITIZE/PLAN TO IPLEMENT THESE
DO THESE NOW!
HARD
EASY
DO THESE AFTER DOING EVERYTHING ABOVE
SKIP THESE
Minimal Benefit/Easy to do
Minimal Benefit/Hard to do
A simple tool that is used to review solutions from the perspective of payoff versus amount of effort required to implement the solutions.
No Effect on Root Cause

46. Tools: Force Field Analysis
DRIVERS
ISSUE
RESTRAINERS
To take full advantage of their problem solving potential, groups often need techniques to help them stay focused on the problem or issue under consideration. Force Field Analysis is a technique that helps a group focus its brainstorming energies on fully understanding the forces that encourage (drivers) and inhibit (restrainers) the implementation of a specific issue.
When used to assess a current situation, the Force Field Analysis gives the group a visual image of how things are today. Once the current situation is documented, the group looks for ways to reinforce the drivers, minimize the restrainers, or best of all, turn a restrainer into a driver. For example, a lack of management support may be a powerful restrainer, but if the group can gain management support the restrainer can become an equally powerful driver.
When used to evaluate potential solutions to a problem, Force Field Analysis helps a team understand which option will meet with the most acceptance. By looking at the impact of a potential solution before trying to implement it, teams are better able to anticipate the reactions of others and plan accordingly.

47. Tools: Root Cause Solution Worksheet
Notes

48. Do: Implement Action Plan
Objective:
Implement permanent corrective actions
Evaluate results of action plan
IMPLEMENT ACTION PLAN

49. Do: Implement Action Plan
Process
Review action plans
Assign responsibilities
Implement solutions
Conduct training
Establish controls
Verify measurement
Remove containment if necessary
Tools
Action Planning Worksheet
Timelines
PDCA Project Status Sheet
Once the root cause has been identified, the team establishes an action plan on the permanent actions to be taken. Again, the action plan includes who will do what by when. The permanent actions are implemented to solve the problem. And they should answer the question "Why did this problem occur?“ Establish on-going controls on the process to ensure the process remains in control. Once the permanent corrective actions are in place, the on-going controls will verify the effects of the actions.
A systematic approach involves a plan to establish the facts using data or evidence as a requirement for making decisions. Data is obtained by investigations or experiments to test assumptions. Translating customer/sponsor concerns into understandable definitions of what the problem is and relating these definitions of the problem to the product or process identifies these assumptions. These definitions and data are used to verify solutions. Once permanent actions are taken, document the changes. In addition, each customer/sponsor needs to be informed about what actions are taken. In most cases, some type of training is required to institute permanent corrective actions. Another important part is to correct the obvious. This includes correcting defective parts/systems already produced, changing product designs, reworking defective machines and/or equipment, revising ineffective operating systems, or working with and/or replacing suppliers.

50. Tools: Action Planning Worksheet
Core Team Member: ______________________________________________________________________________
Actions/Steps
Resources
Responsibility
Start Date
Complete
Date
Validation Method
Status
Comments
Notes

51. Check: Evaluate Results
Objective:
Verify corrective actions before the actions are permanently implemented
Process capability run
Quality data analysis
Field test
Prototype
Rework report
Document verification results
Update quality documents
Verify the solution with customer
Evaluate Results
By far the most critical step in the problem solving process is to verify that the solution will in fact eliminate the problem. Also, it is often the most difficult step. The most common method to evaluate a problem solution is to wait for implementation of the solution, then see if the problem goes away. However, too much time is lost before conclusive information is available. Verification, wherever possible, should come before implementation.
Several approaches to verification are available. In engineering, design verification and production validation testing provides significant information. In the short term, a bench/lab test can be used to verify. Sometimes, rework reports and conformance audits provide enough information. In some situations, a designed experiment can be part of the verification.
Whatever verifications you choose, a detailed verification/action plan is required to outline who will be taking what actions by when. The action plan should show what data or statistics will be collected and analyzed, who is responsible and track actual progress and scheduled completion.

52. Check: Evaluate Results
Process
Collect data
Analyze data
Are results achieved?
Has root cause been eliminated?
Confirm results with customer
Verify no other issues introduced
Tools
Quality Charts
PDCA Project Status Sheet

53. Act: Standardize and Monitor
Objective:
Validate corrective actions
Evaluate the effectiveness of current measurements to detect failure
Update quality procedures to prevent recurrence of this and all similar problems
STANDARDIZE & MONITOR

54. Act: Standardize and Monitor
Process
Identify and agree to long term validation methods
Identify similar products, product lines, serviced, equipment, and processes that could benefit from these findings and solutions
Update quality documents
Retrain as necessary
Tools
Operating Procedures
PDCA Project Status Sheet
It is important to understand what in the process allowed the problem to occur. To prevent recurrence of the problem, people must understand why their system allowed a problem to develop. The same system will allow future problems to occur.
Operating systems, practices, and procedures should provide support for "never-ending improvement" in all areas and activities. The system should encourage individuals to participate freely in the problem solving process. It should help to understand more about their job and how each individual's effort affects the outcome of the final product. The system should encourage everyone to learn something new. And it should recognize individual and team effort when these new skills are applied.

55. Tool Matrix