e 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 problem and it must be possible for the team to perform. Ask the team to suggest actions in the areas they are most familiar with and control. You should take ownership of any Management related actions. Compare each action against these criteria and eliminate any that don’t meet both. Team members should be prepared to explain why they believe an action does not meet the criteria. The team should also agree with a decision to remove an action from the list of candidates.
This exercise may reduce the list to the point where all of the actions would be feasible in which case your exercise is over. If not, ask the team to rank each action against each of the criteria, using a scoring system that assigns a score for feasibility and effectiveness at correcting the problem. You can use a cardinal or ordinal system and you can either average scores or pick the score that receives the most votes. This will identify the actions that will have the greatest chance of eliminating the problem and you can select one or several to implement, depending on the need and your resources.
The final step is to implement the identified actions and observe their effectiveness at removing the problem. You may have to repeat this exercise in order to identify the real root cause and eliminate it, so don’t throw away any of your artifacts, such as the sticky notes, until you have verified that your problem is solved.
You won’t need to use Root Cause Analysis to resolve every project problem, you will be able to identify the causes for most and the ability to resolve them. Problems that defy your ability to solve, or problems you aren’t familiar with will lend themselves to Root Cause Analysis. When the entire team agrees that the problem exists RCA has the advantage that you can use the collective expertise of the team to augment your own and the actions that are identified are identified by the entire team so support for their implementation is much more likely.
Dave Nielsen is a principal with three O Project Solutions, the vendors of A