Your SlideShare is downloading. ×
  • Like
root-cause-analysis-checklist
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

root-cause-analysis-checklist

  • 3,203 views
Published

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
3,203
On SlideShare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
185
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. YMCA of Metropolitan Milwaukee Checklist Root Cause Analysis INTRODUCTION: Root Cause Analysis The checklist content starts on the following page. What This Is A root cause analysis is designed to help you methodically identify the root cause of a given problem or issue, by asking a series of questions, and by considering the problem from different angles. It allows you to challenge first-reaction thinking, and to consider issues and problems in light of current business realities. Why It’s Useful Root cause analysis is helpful to ensure that valuable time is not wasted by solving the wrong problem, or by developing and implementing solutions to symptoms rather than causes. From the initial conception of a project to identification of a defect or bug within the eventual solution, root cause analysis can be used to get to the source of the problem. How to Use It 1. What’s the problem? Start by stating what you believe to be the problem or issue around which you plan to perform root cause analysis. 2. What’s the method? Gather the appropriate experts given the topic at hand, and be methodical and objective in your root cause analysis, using this checklist to guide you through the process. 3. What’s the proof? Be sure to validate your findings to ensure you haven’t just followed a hunch. It’s helpful if you can find statistics or other clear evidence that you’ve found the right root cause. 4. What’s next? Now move on to finding the right solution for the problem you’ve uncovered. About the Author Sinikka L. Waugh, PMP, is the founder and head coach of the project management coaching firm Your Clear Next Step, L.L.C. Sinikka is an actively practicing project management consultant, known for consistently helping teams find innovative ways to leverage effective project strategies across multiple disciplines and technologies. With over 10 years in project roles (primarily program manager, project manager, and business analyst) Sinikka has successfully applied project and leadership expertise to improve project performance in a wide variety of industries, including publishing, education, product fulfillment and distribution, insurance, event and travel management, human resources, and financial services. As a coach, Sinikka’s down-to-earth, “try this now” approach blends with her passion for helping others improve. Her energetic and engaging style helps make both the art and science of project management accessible to those she works with. Sinikka holds a BA from Central College, an MA from the University of Iowa, and is a certified Project Management Professional through the Project Management Institute. The checklist content starts on the following page. Page 1
  • 2. YMCA of Metropolitan Milwaukee Checklist Root Cause Analysis Root Cause Analysis WHEN TO USE ROOT CAUSE ANALYSIS Root cause analysis can help identify the right problem in any of the following common situations within the project lifecycle:  Problem statement: Frequently, once the problem statement has been defined, it is valuable to conduct a root cause analysis to understand the real reason the problem exists—the source or cause of the problem—to ensure that you’ve identified the real problem rather than merely a symptom.  Gap: Once a gap analysis has identified a gap between the current state and desired state, root cause analysis can help isolate why the gap exists. This, in turn, can help identify the magnitude of the solution required to address that gap.  Issue: When issues arise within the project lifecycle, root cause analysis is a valuable tool to help ensure the project team understands why an issue occurred, so trends or similar issues can be avoided—or at least mitigated.  Change: When changes occur, particularly requirements changes, it’s useful to stop and review the root cause of the change. This will help predict whether further changes can be expected, and can draw them out sooner than later.  Failure of a requirements quality measurement: Taking the time to identify the root cause when requirements quality falls short of acceptable standards will almost always result in a long-term time savings. If the quality fell short due to a lack of training or knowledge, a gap in understanding a particular business or technical topic, or from any other easily-correctible root cause, knowing the problem is the first step towards fixing it. Additionally, once the problem or shortcoming has been identified, it’s easier to put controls and fail-safe measures in place to prevent it from being a problem again—such as peer reviews, probing questions, additional business expertise, training, etc.  Defect or bug: When a defect or bug is found in a developed solution, reviewing the root cause for the defect or failure can shorten the resolution time. Finding the root cause of a single bug might even help to resolve several other open defects, as well as others that have not yet surfaced. GETTING STARTED: PUT THE PROBLEM IN PERSPECTIVE Get your arms around the problem itself. Consider where in the project lifecycle you’re using root cause analysis, and what you hope to accomplish through it.  Identify the problem at hand.  What is the thing that is being analyzed for root cause?  Is it a problem statement, a gap, an issue, a change, a defect, a failed test of requirements quality, something else?  Identify who cares.  Who says there’s a problem?  Who identified it?  Who is impacted by it?  Who is being tasked with solving it? ASSEMBLE A TEAM TO GET TO THE ROOT CAUSE  The person or people with the problem are the best people to help identify its root cause.  If there is more than one person with the same problem, it’s useful to tap into several of them. They bring multiple perspectives and will ensure you are getting to the right root cause versus just one person’s idea. Page 2
  • 3. YMCA of Metropolitan Milwaukee Checklist Root Cause Analysis  Try to limit the group to not more than seven people involved in the discussion, not including the facilitator.  The facilitator of the analysis must remain objective. If you don’t believe you are objective about the problem at hand, ask someone else to help facilitate.  The facilitator of the analysis must remain methodical. If you don’t believe you can effectively keep the participants on track with a methodical approach, ask someone else to help facilitate.  If you’re bringing a group of people together to talk about a problem, be sure to publicize the purpose of the analysis with the participants, so you don’t waste valuable time assigning blame, pointing fingers, or jumping to solutions. PLAN YOUR ANALYSIS STRATEGY Put together a plan on how you will work with the team to analyze the problem and define the strategy you will use to lead the team.  Where will you meet? Locate a room or physical location for the analysis that allows the participants to gather together and to see visual representations of the discussion, such as flip charts or whiteboard notes.  Assume the problem statement doesn’t describe the entire problem or root cause.  Many times the original problem statement is only a symptom and isn’t the root cause.  Frequently, a problem statement includes multiple problems.  Decide which tool(s) you’ll use to complete the root cause analysis. Two principal tools of root cause analysis are discussed below, along with suggestions of when they might be appropriate. THE 5 WHY'S The “Five Why’s” is perhaps the most common, and the simplest, root cause analysis technique. It involves asking “why” approximately five times, in order to ensure you reach the root cause of why a certain problem or issue exists. This approach can be used with just about any stakeholder, with just about any problem statement. Sample Approach to the 5 Why’s Technique Display the problem statement visually for all the participants to see and ask, “Why does this problem exist?” This is the first level of why’s. This part of the discussion begins to probe into the real problem and the root causes. Allow the participants to call out multiple reasons that the problem might exist, but try to keep a close ear out for repetitive ideas. Be sure to leave plenty of white space under each idea for the next level of why’s related to that idea. Use your own words to restate the responses to ensure clarity with the whole group. To keep things manageable, collect about seven ideas before moving on to the next level of analysis. This isn't a firm number; use your judgment. If the team is out of ideas, it's OK to stop at five. Likewise, if the ideas are flying fast and furious, and they're all unique, don't squelch discussion at seven; but you'll want to narrow the field before moving on. (And if you really do have a dozen or more possible causes, consider whether your problem statement is well phrased.) Once you've collected about seven possible causes, move on to the second level of why's. Starting with the first idea, ask again, “Why does this problem exist?” During this part of the discussion, you’ll already start to see common themes, trends, and probably some shared root causes. Again, allow the participants to call out multiple reasons that the problem might exist, but try to keep a close ear out for repetitive ideas so you can capture each concept just one time. At this point, any more than about five ideas for each of your original possible causes will be unmanageable. Once you’ve completed this—if you’ve asked “why” a second time for each of the seven first-level answers and allowed about five different answers for each—you’ll have 35 cause statements visible. Page 3
  • 4. YMCA of Metropolitan Milwaukee Checklist Root Cause Analysis Starting with the first idea named in the second level of why (and eventually for all 35), ask once again, “Why does this problem exist?” This is the third level of why’s, and the process continues to repeat until you’ve identified the right root cause. The five why’s are often depicted as indented rows of answers, forming an outline. If the problem statement is reflected in one line, the first level of causes below it are indented a little, the second-level causes are indented even further, etc. Other questions you might ask include:  “Is this the problem you are trying to solve?”  “Is this the problem or just a symptom?”  “If I fix this, does the problem go away?” The “5” in “5 Why’s” isn’t a magic number. Sometimes you can stop after just a few levels of questions and other times you may go through all five, or more. You'll know you have the right problem if you can answer yes to these questions:  Do I want to fix this problem?  Should I fix this problem?  Can I fix this problem?  If I fix this, does the problem go away? FISHBONE DIAGRAM (CAUSE AND EFFECT) The Fishbone, Ishikawa, or Cause-and-Effect diagram is also fairly common. It involves drawing a horizontal line for the problem (or effect), and angled lines arranged like the bones of a fish showing potential causes. This approach is especially recommended when you suspect that there are multiple root causes for a given problem, because it encourages team members to explore all possible causes of the problem, no matter when they might occur in the process. The fishbone arrangement of the diagram separates major categories impacting the process into different areas. Common category arrangements include "People, Process, Technology," or "Man, Machine, Materials, Method," but the exact categories can vary based on the specific problem being addressed. Man Machine Inadequa te Co de bugs test equip. Late code delivery Excessive time in Slow approval debugging Material Method Partial fishbone diagram showing some potential causes COMMON PITFALLS The following common pitfalls can easily be avoided if you think about them in advance.  Stopping too soon. It’s easy to start running with the first problem, or even the first “why,” but be sure you’ve gone deep enough to identify the source of the problem. If you only fix a symptom, the problem remains, and it will likely show up with new symptoms. Page 4
  • 5. YMCA of Metropolitan Milwaukee Checklist Root Cause Analysis  Running out of time. As the facilitator, your role is to ensure that the discussion stays on track and that your participants stay focused on getting to the root of the problem. Try to help participants move quickly through the identification process so that you don’t run out of time.  Allowing the discussion to get derailed by popular root causes. Listen for anecdotes or stories or rehashing of multiple examples of the same problem. Keep the conversation focused on the productive identification of all of the causes, not just the one people like to talk about the most.  Forgetting to be methodical. When pressed for time or when recovering from a tangent during the process, it’s easy to forget to be methodical. Make sure you look back at your initial problem and all of the connected causes to ensure you’ve explored all of the avenues that will lead to the root cause. NEXT STEPS Validation Once you have what you believe is the root cause of the problem, try to some test cases to validate the root cause. Ask situational "if-then" questions and test to see if the root cause you’ve identified produces the problem you’re assessing. Communication Share the results of the root cause analysis with those who are impacted by the problem or solution. Depending on what point in the project lifecycle you’ve used this technique, you’ll have different next steps. For example, if you were helping to craft the project or business problem statement, then you’ll want to help document the related objectives and business needs of the project. Alternatively, if you were evaluating the root cause of a defect or bug, then you’ll want to communicate your findings back to the solution developers so they can make the appropriate adjustments. Page 5