sking “why” when identifying the relationships between the various possible causes is at the core of RCA. Let me show you an example of how this might work on a software project. The problem is that you have missed the deadline for one of your iterations. All the software was ready except for one module which was the responsibility of one programmer. Start by stating the problem: the delivery date for module x was missed - why? Because the programmer delivered it late - why? Because they couldn’t complete the work in the time allowed - why? Because the estimate wasn’t accurate, or because the programmer lacks experience, or because the programmer didn’t have access to the tools they needed, etc. Once you’ve asked “why” as often as possible and the causes are traced back to every possible cause, you can go ahead with identifying the solution.
There are many tools available to the project manager embarking on an RCA exercise. Many, such as Pareto analysis, Barrier analysis, and Bayesian inference rely on statistics observed over time that the project manager simply won’t have. Kepner-Tregoe also offer a unique approach to problem solving. They’ve been using this unique approach for over 50 years so it does get results if used properly. Using the Kepner-Tregoe approach requires proper training which is beyond the scope of this article. If you’d like to explore using their approach, I’d recommend taking their course so that you’ll become proficient with their methods. The method I will use in this article is based on the Ishikawa or fishbone diagram.
This method requires you to conduct a workshop or brainstorming session. Collect all the information you can about the problem on your own. The method lends itself well to input from various SMEs (Subject Matter Experts) so identify project team members who are experienced enough in the area that the problem arose from to provide information and reserve their time for the workshop. Communicate all the information you have been able to uncover to the SMEs in advance of the workshop. The brainstorming session begins with a fishbone diagram on a whiteboard. The fishbone starts with the body of the fish, aligned with the causes of the problem and ends at the head with the problem statement. The various causes of the problem flow into the backbone which leads to the fish head, or cause. Start out with a standardized fishbone diagram which categorizes the different groups of causes.
The categories used in this example are only suggestions. Choose the categories that make the most sense for your project. The number of categories is also a suggestion. There is no necessity to have 6 categories, you can have as many or as few as you like. Analyze the project environment and choose the categories that best suit the problem.
Ask your team of SMEs to jot down in a few words the causes they believe responsible for the problem in each of the categories on the diagram, then have them go to the whiteboard and paste them in the appropriate category. Take a few minutes to review the notes to detect duplicates, or causes that are similar. Eliminate duplicates and determine with the team whether the similar causes could be combined. Now go through the causes 1 at a time and asking the question “why” trace it back to the source. The idea here is to go from symptom to source and asking “why” until there is no answer is the best way to do this. Record the sub-causes and root causes on the diagram. Complete this exercise for each of the causes on the diagram until you’ve explored them all. Now look for duplicates in the root causes. The more apparent causes the root cause is responsible for, the more effective elimination of that root cause will be at removing the problem. There is no rule that dictates you must identify only one root cause with this exercise, but you shouldn’t come out of it with so many that elimination of them is impossible.
The next step is to identify the actions that would eliminate each of the root causes. There are two basic criteria that an action must meet: it must solve the 