Cause & effect analysis part 2


Published on

Part 2 of the Cause and Effect workshop. Today's class covers application of the Fishbone technique.

Published in: Education
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Welcome Back – hope you are ready for another interesting session tonight.
  • Here’s what I hoped we could cover tonight… I’ll be checking with ConEd to see if I can have the certificates available for undeclared students on Wednesday, but may have to be sent out to you.
  • Last week we looked at Cause and Effect analysis and you may recall that this was seen to be an important opportunity to help you consider problem-solving that may be applied in numerous areas – and in particular to the areas of process engineering, re-engineering and continuos quality improvement or CQI. This workshop is intended to help you understand how to perform C&E for good team efforts for process improvement, but its scope is really limited to getting you familiar with one of the tools – the fishbone diagram. If you are interested there are a number of paths for further training including the CAMC, IIBA, PMI and other associations who articulate professional credentials. We discussed C&E and its tools as being useful in team environments where problems are complex and root causes are unknown and where the team needs to focus on problems and not on people or symptoms. It will help to develop innovative problem solving within functional and especially cross-functional teams.
  • We looked very briefly at a tool that we will be working with more tonight – the fishbone (or ishakawa) diagram and had a chance to practice two of the necessary skills to completing a fishbone – brainstorming and the five-why’s.
  • Please note that we will be using a smaller set of cause classes in our exercises – using the 4P’s or 4M’s. 4 P’s: Process, People, Plant/Equipment, Policies 4 M’s Manpower, Methods, Machinery, Materials We’ll also look at a different approach and in fact we’ll use a different classification scheme altogether tonight in the case study – even though the basic process will stay the same.
  • Briefly – and I believe this is in your guide on page 6 – the process always starts off with a definition of the problem. This may seem pretty straightforward, but it sometimes gets complicated – especially if all the tem doesn’t agree it is the problem! Based on your team situation, the nature of your business and the nature of the problem you next need to make a determination of the best way to categorize the causes. We will look at a couple of these methods shortly. Next you brainstorm all the possible causes you can identify, and assign them to the cause categories. These should then be questions for deeper causes until the desired level of detail is achieved, after which the team is ready to analyse the causes to find root causes or bottlenecks that can be addressed. Finally action is planned to address the problem by fixing the root causes. Keep in mind that the actual implementation of those improvements don’t fall inside of this process, but they do in the overall scheme of CQI. So now we are ready to try some application.
  • You were asked to read the case study and to begin highlighting some of the issues with an eye to two key questions – what is the central or net problem? And what are some of the causes you can see of this problem? Take a moment to review the case and your notes and we’ll begin the case study shortly…
  • OK – ready? So here’s what we will do. Teams are… The process will look like this: facilitator – I’d like to have a different facilitator for each of the next three major steps 5 minutes to generate and agree on a problem statement
  • Don’t overwork this – but try to get it down to a few words that concisely says – here’s the problem, something that si happening or not happening that causes us a problem being successful at what we are trying to do. Five minutes – then we’ll share our problem statements
  • OK I’d like another member of the team to try to facilitate this next step – brainstorming is an important skills and the ground rules are important – don’t judge suggestions, just get as much down as you can. Facilitators should try to ensure everyone has a chance to participate – many people are reflective or deep thinkers or may be introspective, but they very often have some of the best contributions… Let’s try to get at least 8-10 ideas about problems that lead directly to the problem statement you came up with – remember it should be a direct cause to the problem at this level. If it doesn’t, then hold that thought and instead try to come up with what it affects that leads to the problem.
  • Major Cause Categories There are two major methods we will discuss tonight, but your team may be able to come up with a better set of cause categories. 4Ps are effective for service type businesses or problems, while 4Ms is better in manufacturing, industrial and construction type situations.
  • One way that may work even better for many teams – especially if they are all close to the process is to use process classification: This will be unique for every process of course so the design here is just an example of a process classification – in this case for problem involving late pizza deliveries. You can see how the various major process categories are broken out. In the case, it ends with the major categories having been specified by Bob, the manager and that’s where you will begin your work of assigning causes to the major process areas.
  • In dispersion analysis you might see the same item across numerous categories – less so for process classification. Go Ahead and do your assignment now
  • Cause & effect analysis part 2

    1. 1. Using a Fishbone Diagram: Part 2 PROG 1026: Logic & Problem Solving
    2. 2. Agenda <ul><li>Review </li></ul><ul><ul><li>Workshop Introduction </li></ul></ul><ul><ul><li>Cause & Effect Introduction </li></ul></ul><ul><ul><li>Brainstorming Exercise </li></ul></ul><ul><li>Cause & Effect Practice </li></ul><ul><li>Cause & Effect Follow-up </li></ul><ul><li>Wrap-up and Exam Prep </li></ul>
    3. 3. Workshop Introduction <ul><li>Why use C&E? </li></ul><ul><li>Workshop Scope </li></ul><ul><li>Objectives of C&E </li></ul><ul><ul><li>Root causes </li></ul></ul><ul><ul><li>Teamwork </li></ul></ul><ul><ul><li>Problem Solving </li></ul></ul><ul><ul><li>Innovation </li></ul></ul><ul><li>Ground Rules </li></ul>
    4. 4. Intro to C&E <ul><li>Definition: A Cause and Effect Diagram is a tool that helps a team to identify, explore, and display in increasing detail, all of the possible causes related to a problem or condition in order to discover its root cause(s). </li></ul><ul><li>Practice Basics Weekend Procrastination? </li></ul><ul><li>Define/ Assign Cause Categories </li></ul><ul><li>Brainstorm more detailed causes </li></ul><ul><li>Choose a cause and ask “Why?” 2-5 times </li></ul><ul><li>Share lowest level causes and look for patterns </li></ul>Problem Statement
    5. 5. Constructing a Fishbone Diagram <ul><li>Velaction Video </li></ul>
    6. 6. Process Flowchart <ul><li>Problem Definition Critical </li></ul><ul><li>Format/ Cause Categories </li></ul><ul><li>Brainstorming! </li></ul><ul><li>Analysis </li></ul><ul><li>Action on Root Causes </li></ul>
    7. 7. Case Study <ul><li>The Case of the Missing Deadline </li></ul><ul><ul><li>What is the central problem? </li></ul></ul><ul><ul><li>What are possible causes of the problem? </li></ul></ul><ul><li>Take a moment to review and reflect on the case study </li></ul>
    8. 8. Process <ul><li>Select a facilitator </li></ul><ul><li>Phrase the problem statement (5 min) </li></ul><ul><li>Generate causes (10 minutes) </li></ul><ul><li>Construct the diagram (15 minutes) </li></ul><ul><ul><li>Dispersion Analysis </li></ul></ul><ul><ul><li>Process Categorization </li></ul></ul><ul><ul><li>Break down causes to find root causes </li></ul></ul><ul><li>Analyse Causes (15 minutes) </li></ul><ul><li>Follow up on root causes (debrief – 5-10 minutes) </li></ul>
    9. 9. Step 1: Select a Facilitator <ul><li>A facilitator is expected to: </li></ul><ul><ul><li>Make sure that the problem is clearly understood by everyone. </li></ul></ul><ul><ul><li>Get the team to participate in the current step. </li></ul></ul><ul><ul><li>Manage the time so that each task is finished in line with the training schedule. </li></ul></ul><ul><ul><li>Make sure that any and all ideas are recorded accurately. </li></ul></ul><ul><ul><li>Summarize the team’s conclusions based on the consensus of the team and the specific assignment. </li></ul></ul>
    10. 10. Step 2: Problem Statement <ul><li>Facilitator provides opportunity for team to contribute </li></ul><ul><li>Statement should normally be 4-8 words or less </li></ul><ul><li>A problem is an issue that represents a gap between desired and actual performance/results and is an observable effect of one or more contributing causes </li></ul><ul><li>Discuss in team and come up with a statement – write it large on a sticky note and place at far right middle of the chart </li></ul><ul><li>5 MINUTES </li></ul>
    11. 11. Step 3: Generate Causes <ul><li>General to specific? </li></ul><ul><li>Specific to general? </li></ul><ul><li>Brainstorm </li></ul><ul><ul><li>no judgment, just try to get as many ideas as possible </li></ul></ul><ul><ul><li>Facilitator, ensure everyone has a chance to participate </li></ul></ul><ul><li>10 MINUTES </li></ul><ul><li>Next: Major Cause Categories </li></ul>
    12. 12. Step 3: Dispersion Analysis <ul><li>4 Ps </li></ul><ul><ul><li>Process/Procedure </li></ul></ul><ul><ul><li>People </li></ul></ul><ul><ul><li>Policy </li></ul></ul><ul><ul><li>Plant/Equipment </li></ul></ul><ul><li>4 Ms </li></ul><ul><ul><li>Methods </li></ul></ul><ul><ul><li>Manpower </li></ul></ul><ul><ul><li>Materials </li></ul></ul><ul><ul><li>Machinery Equipment </li></ul></ul>Problem Statement Process People Policy Plant/ Equipment
    13. 13. Step 3: Process Classification <ul><li>Define major steps in the Process </li></ul><ul><li>Establish causes relative to the process </li></ul>Late Pizza Deliveries on Friday Nights Assembling Pizza Baking Pizza Taking Orders Delivering Pizza
    14. 14. Step 4: Construct Diagram <ul><li>Assign Causes </li></ul><ul><ul><li>Assign to one category if possible </li></ul></ul><ul><ul><li>If not possible, consider rephrasing relative to the cause </li></ul></ul><ul><ul><li>Repeating causes in multiple categories may be a good sign of a root cause </li></ul></ul><ul><li>Facilitator works to ensure consensus of assignment </li></ul><ul><li>15 MINUTES </li></ul>
    15. 15. Step 5: Analyse Causes <ul><li>Look for repeating items, patterns </li></ul><ul><li>In Process Classification, repeating is rare </li></ul><ul><ul><li>Look for items that create bottlenecks </li></ul></ul><ul><li>Ask “Why?” 2-5 times </li></ul><ul><li>Ensure it is cause and effect or it is a new cause </li></ul><ul><li>Facilitator – manage process to ensure you go far enough and not too far; build consensus on patterns, root causes </li></ul><ul><li>15 MINUTES </li></ul>
    16. 16. Step 6: Next Steps <ul><li>Recommendations Document </li></ul><ul><li>Process Improvement Suggestion </li></ul><ul><li>Request for Decision </li></ul>
    17. 17. Other Issues <ul><li>When do you use a tool? </li></ul><ul><li>Choosing C&E Format </li></ul><ul><ul><li>Dispersion Analysis? </li></ul></ul><ul><ul><ul><li>4Ms </li></ul></ul></ul><ul><ul><ul><li>4Ps </li></ul></ul></ul><ul><ul><ul><li>Team Generated </li></ul></ul></ul><ul><ul><li>Process Classification </li></ul></ul><ul><ul><ul><li>Process Driven </li></ul></ul></ul><ul><ul><ul><li>Team Generated </li></ul></ul></ul>
    18. 18. A Word on GOAL/QPC <ul><li>Memory Jogger </li></ul><ul><ul><li>Books </li></ul></ul><ul><ul><li>Flash Drives </li></ul></ul><ul><ul><li>Training </li></ul></ul><ul><ul><li> or </li></ul></ul><ul><ul><li> </li></ul></ul>
    19. 19. Wrap-up <ul><li>Problem Solving </li></ul><ul><li>Logic </li></ul><ul><ul><li>Math – the Language of Logic </li></ul></ul><ul><li>Algorithms & Programmatic Problem-Solving </li></ul><ul><li>Tools & Techniques </li></ul><ul><ul><li>IPO </li></ul></ul><ul><ul><li>Flowcharts </li></ul></ul><ul><ul><li>Pseudocode </li></ul></ul><ul><ul><li>Fishbone/ C&E Diagram </li></ul></ul>
    20. 20. Final Exam <ul><li>20 M/C Questions = 40% </li></ul><ul><ul><li>Hint: focus on Class Notes/ slides on site </li></ul></ul><ul><li>1 Application = 60% </li></ul><ul><ul><li>Either </li></ul></ul><ul><ul><ul><li>1 programming problem </li></ul></ul></ul><ul><ul><ul><ul><li>Flowchart, pseudocode and Ruby procedures </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Approach is worth more than code </li></ul></ul></ul></ul><ul><ul><ul><li>Or, Business Case </li></ul></ul></ul><ul><ul><ul><ul><li>Complete Fishbone with brainstorm, classification, and analysis </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Approach is worth more than quality of analysis </li></ul></ul></ul></ul><ul><li>Good luck! </li></ul>