Why oh Why oh Why oh Why oh Why?

I am IT support for my mum. As first, second and third line support, the issues tend to be raised as follows:

Mum — “My computer isn’t working”
Me — “What do you mean, it’s not working?”
Mum — “It’s not working”
Me — “It’s not turning on?”
Mum — “No.”
Me — “No?”
Mum — “I can’t get my emails.”
Me — “Okay, so it’s turning on, you just can’t get your emails?”
Mum — “Yes.”
Me — “Can you access other websites?”
Mum — “I don’t know. I haven’t tried”
Me — “How are you trying to read your emails?”
Mum — “I’m just going to the saved thing on my web browser”
Me — “Does it work from your phone?”
Mum — “I don’t know. I was trying to use the computer.”

…30 minutes later

Me — “Okay, it’s working now?”
Mum — “Yes. Thank you.”

The problem that is first presented, isn’t it always the root of the problem. There are often deeper issues to identify and resolve.

Five Whys is a technique that originated at Toyota which helps us get to the root of the problem*. It’s an iterative approach wherein we look at the cause of a problem and then repeat with each of the related problems. By the fifth ‘why’ it is thought that we will have reached the root of the problem.

Problem: Emily wakes up late each day.
Why? Because she oversleeps.
Why? Because she sleeps through her alarm.
Why? Because she‘s tired.
Why? Because she goes to sleep too late.

(Further whys may have led to late after school afternoon naps… 😏)

The technique is simple and has widespread uses but is often under-utilised.

What is the problem?
Why did this problem occur?
Why did this problem occur?
Why did this problem occur?
Why did this problem occur?
Why did this problem occur?

A business example that I’d observed was where a team was being disrupted most days by another team. This was looked at as an annoying distraction from their planned activities. Aside from this there was often back and forth to collect all the information (similar to the ‘computer isn’t working’ situation described above). A basic template was put in place to gather all required information up front. The buy-in for this didn’t really happen and that team just went privately to developers instead circumventing ‘the solution’.

What had not been done was the five why process, i.e. rather than seeing the team as a distraction nobody thought about ‘why’ it was happening.

Using the five why process later it became quite clear (and should really have been obvious) that:

The team with the issues had nobody to support them.
…because the product team had allocated their entire sprint to new work.
…because the features/bugs were seen as important and they’d not considered that supporting others was a priority.
…because it always had been done that way, and nobody had considered changing it.

Root cause reached in 1 what and 3 whys.

Putting a process in place to ensure there was support available meant that:
a) The team that needed support got it.
b) The team supporting were planning their work effectively and had thus planned in the right contingency to support ‘their customer’.
c) Both teams were now more effective in getting the job done.

As I wrote above, this technique is applicable to so many situations but is not followed. In a business all too often people don’t consider ‘why’ they are doing something. What is the reason, it’s got to be more than ‘because my manager told me to do it’. Considering ‘why’ we do something is sound business thinking to ensure that we are focusing on what adds value, as opposed to simply doing things because that’s what we’ve always done.

*Although the five why technique is used to help get to the root of the problem the original Sakichi Toyoda’s development of this was to consider why a new feature was being built, i.e. to identify the problem that was being solved.**

**Yes, the spelling is correct. Sakichi’s son created Toyota, and the company used a T rather than a D as it reduces the number of strokes require to write the letter in Japanese, 10 rather than 8, the latter being a lucky number in Japan.