Root cause analysis is useful in defining the goals for a project and the project scope. Project leaders and project managers can use The Five Whys which was developed by Toyota, and Fishbone Diagrams or Ishikawa diagrams to study a challenge or opportunity and identify the root cause that the project should address.
- It's really hard to explain the vision for a project if you haven't defined the problem that you're trying to solve. But accurately defining the right problem or opportunity for a project to address can be harder than it seems. It often requires a root cause analysis. This video will introduce you to two root cause analysis techniques that can help you move beyond describing what is happening to try to figure out why it is happening. Think of root cause analysis like a doctor who uses a patient's symptoms, vital signs, and lab results to diagnose a disease.
It's really important to have an accurate diagnosis to correctly understand the root cause before you prescribe a treatment. Two of the most useful techniques for root cause analysis are fishbone diagrams and the five whys. These tools use different thinking styles. The five whys is a verbal exercise while the fishbone diagram is visual, but they work beautifully together. We'll start with the fishbone diagram.
Fishbone diagrams are sometimes called Ishikawa diagrams because they were made popular in the 1960s by a professor named Kaoru Ishikawa. They provide a graphical way to analyze a problem and to show the issues that cause or contribute to that problem. First, we illustrate the problem you're trying to solve by drawing a horizontal line that looks a bit like the spine of a fish.
Then, any issue that might cause or contribute to that problem becomes a diagonal line that connects to the spine. These are the bones of the fish. You can expand it further by listing things that cause the causes, and so forth. This simple graphical technique is a powerful tool for capturing the problem and the root causes in a way that is easy to understand, analyze, and explain.
I've put an example of a blank fishbone diagram in the Exercise files for you. Another powerful tool for root cause analysis is a verbal exercise called the five whys. This technique was developed by Toyota as a way to help teams analyze problems. If you have children or have spent time around young kids, you've probably experienced the five whys already. They ask a question, you give an answer, and the next question is why? And no matter what your answer, they again ask, why? It may seem annoying, but that's because it forces you to explain things that you currently take for granted.
The powerful observation from Toyota is that asking and answering the question five times in a row will often lead to insights about the real root cause of a problem, insights that were hidden from everyone because of an assumption they were all taking for granted. You can do the five whys informally, but I've found that it works better, especially for teams, when you actually write it down. It's a great way of uncovering new insights and it can be a handy reminder as you move forward with the project of why you're doing it in the first place.
One last point. It's pretty easy to draw the whys from a five whys exercise into the fishbone diagram. Or, if you're using a fishbone, you might want to pull out the causes that you identify and do a five whys exercise for each of them. So those are two really useful tools that work well together for defining your vision for the project. Like a doctor trying to uncover the root cause of their patient's symptoms, you can use the five whys exercise and the fishbone diagram as a part of your diagnosis.
They are both really useful tools for defining the problem that you're trying to solve.
- Name who is responsible for approving the resources for the project.
- Recall what the spine of a fishbone diagram represents.
- List characteristics of the environment.
- Identify the tools used for mapping processes.
- Recognize what needs to be captured on the action item list.
- Recall what project metrics should be related to.