Using Root Cause Analysis When Your Project Fails
It’s common to see people point fingers and play the blame game after a project fails. These blame games not only hurt the team members but also impact their morale as well. Is there a way to avoid these hurtful situations while focusing on improving process and identifying the failure’s root cause?
The answer to that question can be found with root cause analysis (RCA), which helps to divert attention from people to process improvement.
Typically, agile teams are recommended to do an RCA session in response to issues raised during retrospectives. Shamefully, many agile teams skip RCA and continue to struggle in a whirlwind of issues.
RCA is not rocket science—especially when we have such a simple tool as the five whys. Eric Ries has elaborated on RCA with some practical examples from his lean startup journey. Here’s an example of a simple Excel spreadsheet that shows how to conduct RCA using the five whys; you can download a ready-to-use spreadsheet here.
Even with a simple approach like the five whys, people make mistakes, and the following article from Business Process Inc. provides some great tips to avoid mistakes.
The five whys system has its share of critics. Some say that an in-depth analysis needs to be combined with this technique. According to Mike Cohn, this is not suitable for solving complex problems; I recommend checking the comments section to this piece.
The Ishikawa (aka fishbone, cause and effect) diagram is an alternate method for identifying the causes of the issues. You can read four simple steps for constructing and running a fishbone session here, and you can find real world examples of fishbone diagrams here.
XMind is an open source tool that can be used to draw fishbone diagrams. There are macros available for Excel that could be helpful to facilitators deriving fishbone diagrams.
I have noticed that novice users of the fishbone method always end up deriving the six m’s (machines, method, material, maintenance, man, and mother nature) for every context. However, there are other variations of this—the four m’s and seven m’s—which you can use depending on the context, nature of the problem, and industry.
You should be aware of the advantages and disadvantages of fishbone diagrams before attempting to use them. Keep in mind that having these tools doesn’t excuse the operator to run them in an ad-hoc fashion; in fact, there are five critical skills an RCA facilitator should possess before delving into the session.
Does your team perform root cause analysis? Share your thoughts in the comments.
