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