1	Introduction to Basic Problem Solving Jacquline Stanley, LPN Problem Investigator, Senior Associate Six Sigma Project Lead American Red Cross
2	AGENDA Benefits of an Organizational Culture change Impact of NOT having an Organizational Culture change Definition of Problem What is a Problem? Common managerial approach to problems Definition of Problem Solving 2 ways to solve problems Paradigm Paralysis Paradigm Shifts Paradigm Exercise (groups/organizations) Common Cause Variation vs. Special Cause Variation (examples) Problem Solving Methodologies Easy Problem Solving Steps/Tools (any methodology) Problem Statements Scoping out the problem Process Mapping and Baseline Data Tribal knowledge vs. Raw Data (hypothesis testing) Developing solutions to the problem statement Implementing Improvements (pilot vs. full scale) Control Plans WIP Exercise Questions ???
3	Positive impact of a CULTURE CHANGE An organization with a culture built around a systematic problem solving approach will be able to… Dramatically improve quality, reduce waste, reduce cycle time, and speed up innovation Achieve competitive advantage through significant cost reduction and customer satisfaction Set the standard in innovation, quality, and service Solve persistent, recurring problems permanently
4	Negative impact of NOT instituting an Organizational Culture Change Recurring problems, in spite of efforts to suppress them. Decreased morale and commitment because of the frustration of dealing with recurring problems. Significant resources poured into implementing solutions without being clear about what the problem really is. “Band-aiding” problems without getting to root cause Choosing the “tried and true” approaches that usually achieve minimal improvements, instead of achieving breakthrough results through innovative solutions.
5	Definition of a Problem 1. A question to be considered, solved, or answered 2. A situation, matter, or person that presents perplexity or difficulty 3. A misgiving, objection, or complaint
6	What is a problem? A problem is an opportunity for improvement. A problem is the difference between your current state and your goal state. A problem results from the recognition of a present imperfect and the belief in the possibility of a better future. (Challenges can lead to problems…)
7	Typical managerial approach to problems Managers Tend to Deal with Problems in One of Three Ways: Avoid them - refuse to recognize that a problem exists Solve them as necessary - deal with the urgent (reactive) Seek them out - anticipate and face now in order to avoid urgencies (proactive) Objective: Make the third our usual approach to problems
8	Definition of Problem Solving The act of defining a problem; determining the cause of the problem; identifying, prioritizing and selecting alternatives for a solution; and implementing a solution.
9	Two approaches to Problem Solving Systematic Problem Solvers: They prefer a logical and rational approach to problems. They reach for a narrow and focused problem, step by step processes, rules that must be followed, and computer programs that grind to a recommendation. (MiniTab statistical software) Intuitive Problem Solvers: They are more comfortable with solutions that just "come to" them. Compared with systematic problem solvers, intuitive thinkers find: data less important, complexity less bothersome, continuous change expected, and being more or less right is less scary than being precisely wrong. Note: Both systematic and intuitive problem solvers can be successful managers
10	Paradigm/Paradigm Paralysis Definition: A paradigm is the strongly held beliefs and assumptions that we all use to "filter" incoming information. It does not necessarily describe reality, but it does describe a certain aspect of it. Paradigm paralysis is failure to change our beliefs and assumptions when new information shows us a change is needed. Example: A lady had a tumor removed from her brain. The part of the brain removed affected her ability to taste. However, she continued to taste food. This was because she used ‘old data’ to provide this sensation. This is the power of expectations!
11	Paradigm shifts… One simple question can cause a ‘paradigm shift’… “There has to be a better way!” Put a ‘fresh’ set of eyes on the problem… maybe a new employee or someone new to the process!?! Put someone that knows the current paradigm but isn’t smitten by it. The outcome… a ‘new’ paradigm. Innovation comes to life!
12	Paradigm Exercise Step 1. Select an industry or organization with which you have extensive experience. (form groups) Step 2. List three paradigms from this industry or organization. (5 minutes) Step 3. For each one of these old paradigms, list a new paradigm that could replace it. (5 minutes) Step 4. Each group select one person to present the Paradigms Reminder: A paradigm is a strongly held belief or assumption we use to "filter" incoming information. A paradigm is the eyeglasses through which a manager "sees" problems and potential solutions to these problems.
13	Common-cause vs. Special-cause Variation Common-cause variation characteristics: Phenomena constantly active within the system; Variation predictable probabilistically; Irregular variation within an historical experience base; and Lack of significance in individual high or low values. The outcomes of a roulette wheel are a good example of common-cause variation. Common-cause variation is the noise within the system. Note: Walter A. Shewhart originally used the term chance-cause. The term common-cause was coined by Harry Alpert in 1947. Shewhart called a process that features only common-cause variation as being in statistical control. This term is deprecated by some modern statisticians who prefer the phrase stable and predictable. Special-cause variation characteristics: New, unanticipated, emergent or previously neglected phenomena within the system; Variation inherently unpredictable, even probabilistically; Variation outside the historical experience base; and Evidence of some inherent change in the system or our knowledge of it. Special-cause variation always arrives as a surprise. It is the signal within a system. Note: Walter A. Shewhart originally used the term assignable-cause. The term special-cause was coined by W. Edwards Deming.
14	Common-cause vs. Special-cause Variation—EXAMPLES Common Cause variation is created by many factors, that are commonly part of the process, and are acting totally at random and independent of each other. Their origin can usually be traced to the key elements of the system in which the process operates. Materials Equipment People Environment Methods If only common causes of variation are present, the output of a process forms a distribution that is stable over time. Common cause variation represents approximately 80-85 percent of all variation. Special Cause variation is created by a non-random event leading to an unexpected change in the process output. The effects are intermittent and unpredictable. They are referred to as “Assignable” causes. Operator error Broken tools Machine settings drift If Special Causes of variation are present, the process output is not stable over time and is not predictable. All processes must be brought into statistical control by first detecting and removing the Special Cause variation.
15	EXAMPLES of Problem Solving Methodologies Six Sigma Lean (eliminating waste) Lean Six Sigma (eliminating waste/process improvement) Deming Cycle of PDCA (Plan, Do, Check, Act) Deming Cycle of PDSA (Plan, Do, Study, Act) Joiner 7-step method
16	Problem Solving Steps-Tools for each step Steps: 1. Define the project goals and customer (internal and external) deliverables. 2. Measure the process to determine current performance; quantify the problem. 3. Analyze and determine the root cause(s) of the defects. 4. Improve the process by eliminating defects and or waste. 5. Control future process performance. Tools: 1. Charter, SHA, SIPOC, VOC, AD, CTQ trees 2. Prioritization Matrix, Cycle efficiencies, Time Value analysis, Pareto charts, Run charts, FMEA. Gauge R&R, VOP, Benchmarking 3. 5 Why’s, C&E Matrix, Brainstorming, AD, Fishbone, Control Charts, Flow diagrams, Pareto charts, Regression analysis, Scatter Plots, Histograms, Hypothesis tests 4. Brainstorming, Flow charting, FMEA, SHA, 5 S’s (Lean- sort, straighten, shine, standardize, sustain), Kaizen (focus/grow people), DOE 5. Control Charts, Flow diagrams, Pareto Charts (before/after), Control Plan (what if action plan)
17	Problem Statement A key element of any project charter is the problem statement. The problem statement is a clear and concise statement that describes the symptoms of the problem to be addressed. Benefits of a problem statement: creates a sense of ownership for the team focuses the team on an accepted problem describes the symptoms in measurable terms
18	Guidelines in creating a Problem Statement Define the problem - In the problem statement, team members define the problem in specific terms. They present facts such as the product type and the error made. Identify where the problem is appearing - Identifying where the problem is appearing, or manifesting, as specifically as possible helps the team focus its improvement efforts. Describe the size of the problem - The size of the problem is described in measurable terms. Describe the impact the problem is having on the organization - The description of the problem's impact on the organization should be as specific as possible.
19	Common pitfalls to AVOID in any Problem Statement The problem statement should not address more than one problem. The problem statement should not assign a cause. The problem statement should not assign blame. The problem statement should not offer a solution. Note: The more specific the statement is the better the chance that the main problem will be addressed.
20	Problem Statement Examples Fifteen percent of the “Lazy-Dayz” system updates we applied last month had to be back out. This has caused a 25% increase in service desk issues. World hunger continues to rise. This has caused more and more children to die. There has been an 8% rise in RBC discards this year. This has caused BloodBankers-R-US to lose 10% of their customers.
21	It’s ALL about the SCOPE… What to keep in mind when scoping out the problem Time and Cost are not determined in the scoping, they are the outcome of the scoping process. When defining the scope, we are talking about developing a common understanding as to what is included and/or excluded from the project. If the project scope is TOO large you may not have enough time or resources to complete the project within the budget. If the project scope is TOO small you may fail to meet the Process Owner’s needs and miss the project goal.
22	Process Mapping (current state) Step 1: Determine the Boundaries Step 2: List the Steps Step 3: Sequence the Steps Step 4: Draw Appropriate Symbols Start with the basic symbols: Ovals show input to start the process or output at the end of the process. Boxes or rectangles show task or activity performed in the process. Arrows show process direction flow. Diamonds show points in the process where a yes/no questions are asked or a decision is required. Usually there is only one arrow out of an activity box. If there is more than one arrow, you may need a decision diamond. If there are feedback arrows, make sure feedback loop is closed; i.e. it should take you back to the input box. Step 5: Check for Completeness Step 7: Finalize the Flowchart
23	Baseline Data Baseline data is basic information gathered before a program/process change begins. It is used later to provide a comparison for assessing program/process change impact. If the goals and objectives are vaguely defined or undefined, you will find it difficult to know what kind of baseline data to gather. (refer to problem statement)
24	Tribal Knowledge vs. Data Tribal knowledge is any unwritten information that is known within a group but often unknown outside of it. This term is used most when referencing information that may need to be known by others in order to produce quality product or service. The information may be key to quality performance but it may also be totally incorrect. Unlike similar forms of artisan intelligence, tribal knowledge can be converted into company property. It is often a good source of test factors during improvement efforts. Collecting ‘Raw Data’ Can be captured in the past, present, or future. In a very broad sense, ‘raw data’ can be numbers, characters, images, or other outputs from an observers observation. This disorganized measurable ‘data’ eventually becomes organized ‘information’ through data sorting and analysis. The ‘information’ can be translated into scientific and/or practical conclusions.
25	Solutions Must address the problem statement Must be within the projects budget and time constraint Must be well organized before executed Must have the teams ‘buy in’ Must be sold to the Process Owner (and have their buy-in) Must be carried out by the Process Owner and the team Must be followed by the Process Owner for future hand-off.
26	Implementing Improvements Pilot: Small scale improvement plan over a short period of time. Often used for large projects and to prove the ‘new’ process will work system wide. Full scale: All improvements are made over a short period of time. Can be used for both large and small projects. Requires much more effort and resources. All or nothing implementation process. If doing a DOE, this could be expensive if the improvement fails and the team needs to go back to the drawing board.
27	Control Plan The intent of a process control plan is to control the product characteristics and the associated process variables to ensure capability (around the identified target) and stability of the product over time. The process Failure Modes and Effects Analysis (FMEA) is a document to identify the risks associated with something potentially going wrong (creating a defect - out of specification) in the production of the product. The FMEA identifies what controls are placed in the production process to catch any defects at various stages on the processing. Note: Every completed project should have not only a control chart (if applicable), but a control plan. This ensures that the process doesn't revert to the way it previously operated.
28	WIP Exercise… Acronym for Work in Progress/Process Unfinished product of a process and or many sub processes that has value added from labor or any other additional processing. PLAY CARDS…
29	QUESTIONS…