Causal Analysis

I was staring at my ceiling as I had nothing much else to do. I was down with a virus. My son gave me an accusing look that he had to skip a party due to my condition. I was reflecting on how I happened to catch this virus which inevitably led me to my favorite topic, Causal analysis.

The ultimate purpose of doing a Causal Analysis is to improve the status quo - look at the current system objectively and identify what can be done better next time. Humankind has consistently applied these principles in its development – where complex events have been encapsulated into simple adages and proverbs for posterity.

However learning from experience is one of those things that are easier said than done. One has to evaluate the past, understand why something succeeded or failed, device systems to ensure that successes are repeated and failures avoided. As simple as that. But it doesn’t remain that simple when we try to put it into practice in our lives.

It is not very different with organizations. Causal analysis is a critical part of organizational learning and continuous improvement. While there are many easy-to-use intuitive tools, time and again teams fail to come up meaningful, actionable learnings from their experience.

Why does this happen? Based on my in-depth causal analysis of why causal analyses (Can’t you tell I love recursion) fails, here are the Top 4 reasons.

1.      The “When”

Typically we are tempted to trigger a causal analysis session when things go wrong. This timing ensures that the exercise is in futility. Here are my two suggestions on when to do a causal analysis session

a.     Immediately on meeting a milestone – this ensures that the team is on a high and the members are willing to share credit and accept shortcomings. The openness is a critical component of sharing and learning and the psychological factor plays a significant role.

b.     On overcoming a critical obstacle – Projects will run into problems (or challenges, if you prefer that term). That is the absolute wrong time to initiate a causal analysis. The session will be emotionally intense and doing it will only set the team further back. Let them solve the problem on hand with their 100% bandwidth and once the issue is solved, they are neutral and positive. A reflection session at that time has been seen to yield much better results.

I will be much more open to the question if my son asks “Why did you have to fall sick” after I have recovered rather than when I am in that depressing bed. Won’t you be?

2.    The “Who”

 

When you want a team to objectively look at its own success and failure, it is important to create an environment of trust that enables the team members be objective. The intent of the exercise should be completely above board – bring in systemic improvements. If even one of the team members perceive this to be a witch hunting exercise, it is doomed to fail. The outcome of the exercise will be generic in nature – so that the team protects itself.

The best causal analysis exercise is conducted by an external facilitator who has no knowledge of the team/organizational dynamics. I have found that the teams are much more open and frank with external folks who understand how project execution works. The openness results in a lot more ideas and better co-ordination.

I will be more willing to start talking to my uncle who enquired about my health rather than answer obtuse accusations from my 12 year old.

3.     The what

Most organizations accept that failures should trigger a causal analysis, and it makes sense. Causal analysis of failure helps us in not repeating them. But the organizations don’t seem to demonstrate a similar enthusiasm in analyzing success. If failures are caused, why are successes considered to be accidents? Causal analysis of a successful project has multiple advantages. The obvious benefit is that we get to know how the project handled risks and unexpected events successfully, thus recognizing effective management practices leading to positive reinforcement. Secondly, it is a more positive exercise contributing to the team morale when compared to dwelling on failures. Thirdly, it frees the image of causal analysis from being an instrument of “management torture”.

 

4.    The “How”

There are many tools that will help you in causal analysis, each of which is suitable for specific type of problems like Pareto Analysis, Fish bone diagram, Five Why etc. It is important that the right tool is chosen for the specific case in point. I am not planning to do a survey of tools here in this note in the interest of brevity. Instead, we will take up one of the tools (5 Why) and demonstrate what could (and it usually does) go wrong while using the tool.

a.     Enough “Whys”

As a wise old man remarked once – “A fool with a tool is still a fool” and while you have all the tools at your disposal, a little bit of practical knowledge goes a long way in putting those tools to good use.

In one of the badly run causal analysis sessions, a senior leader walked in and asked – Why did this project fail? Why? Why?? WHY? WHYYYYYYY????? He had obviously misunderstood the “5 Why” technique of Causal analysis. The idea is that you keep asking Why to successive answers until you find something trivial or external.

In my analysis of more than 300 cases of RCAs that claimed to use 5 Why technique, I found that the average number of times ‘why’ was asked was 1.5 times. More than half of the cases stopped with one why! If I apply a 2 Why analysis to my personal scenario, it would look like

Why did I catch a cold?

Because I got wet.

Why did I get wet?

Because it rained.

This leaves me with no reason which can be acted on and this is exactly how most of the RCA findings are.

b.      Asking the wrong “Why”

Sometimes teams lose sight of the fact that we are looking for causes that we can act on. So during the analysis we follow the wrong why’s leading to causes that are not in our control. Haven’t we seen enough RCAs getting stuck at causes like attrition, wrong team assigned the job, customer delayed their deliverables, etc.? Sometimes this is done deliberately to externalize the problems so that we are not burdened with the task of finding the solution. Many a times it is just that the team didn’t know better. Let’s continue on our example to illustrate how we can avoid this.

Why did I get wet?

Because it rained

Why did it rain?

Because, it always rains in November in Bangalore, stupid.

Now I am stumped, unless I have the option to avoid wet locations at this time of the year.  I have forgotten the fact that I am not here to solve the rain problem of Bangalore. So ‘Why did it rain’ is not a useful question to ask in the context of this RCA. Let’s try a different approach:

Why did I get wet?

Because it rained

Why did I get wet when it rained?

I did not carry an umbrella and

I could not wait for the rain to stop as I was already late.

Now I have some sliver of hope to work on, making this a much better ‘why’ to ask in this context. This might look like a theoretical problem in the case of the above example. But think of the times when you were stumped when a ‘why’ came up with answers like attrition, customer delay, changing requirements, etc. These are the times when we should rephrase our whys to focus on the project impact of these events.

In a way, this problem of ‘asking the wrong why’ is a result of another problem ‘not asking all the whys’. There are multiple ways in which a ‘why’ can be asked for every answer. In fact, in our example, there was another question that we missed asking at step 2.

            Why did I catch a cold when I got wet?

This is a potent question that can lead us into solutions like drying myself as soon as I reached home, improving my health and immunity, etc.

Now after all this analysis and pontification, do I catch cold less often? Well, I warned you that it is easier said than done!