Project managers, business analysts and project team members often find themselves performing root case analysis to determine the underlying source of a problem. This structured technique is used to examine a situation in order to establish the root causes and resulting effects of a particular problem. On my projects, I have found that brainstorming is a great starting point for the project team to generate insights and options to kick off their root cause analysis efforts. Brainstorming complements root cause analysis efforts by allowing the group to consider a full set of possibilities. There are two common methods project teams use to perform root cause analysis: the fishbone diagram and the five whys.
Fishbone Diagram. A fishbone diagram allows you to show the causes of a problem or an effect. Fishbone diagrams are also called Ishikawa or cause-and-effect diagrams. This diagram allows you to see all possible causes of a result in a structured way and to make sure that everyone understands the problem or cause that is being addressed. Fishbone diagrams are usually constructed in a group setting, where key players brainstorm the categories and the possible causes in each category. Typical categories include things like people, methods, machines, materials, measurements, and environment. After the diagram is built, the team will analyze the results and hopefully determine the actual cause of what is taking place.
Five Whys. The five whys is a questioning technique that asks “why” repeatedly in order to get to the root cause of a problem. This technique can be used alone or used with the fishbone diagram technique. This is a very simple and effective facilitation tool. Many project teams customize their use of this tool by asking how instead of why or alternating between the two terms. Often the root cause is identified before the five questions are asked.
Be careful when you use the Five Whys technique! I was in a meeting once where the meeting facilitator really annoyed the senior user by repeatedly asking “why?” in order to determine if automating an existing process would improve customer service. The senior user ended up throwing a powdered sugar doughnut at the facilitator, making a big white spot right on the front of the facilitator’s black suit jacket. It was one of those classic moments in project meeting history, I will never forget it.
Are there other techniques that you find successful when identifying, defining and solving problems on your projects? Please share them with us here and tell us why they worked for you.
Happy problem solving!