The 5 Whys – problem-solving for CSMs

Most of us have been confronted with either our own or other peoples’ small children repeatedly asking ‘Why…?’. This can be frustrating, but it can also make us question our own assumptions. For example:

“Why are those people standing in a line?’

‘It’s a queue’.

‘Why are they doing that?’

You know it’s the fairest way to wait for something, but when you hear yourself explaining it to a small child, you may begin to question your own norms.

That’s the strength of the “5 Whys” technique; in 5 or so steps, you can look a little deeper into a situation, think about what you have always taken for granted, then hopefully reach the root cause of a problem or issue.

This example from Wikipedia illustrates the technique:

Your car will not start.

1. Why? – The battery is dead. (First why)

2. Why? – The alternator is not functioning. (Second why)

3. Why? – The alternator belt has broken. (Third why)

4. Why? – The alternator belt was well beyond its useful service life and not replaced. (Fourth why)

5. Why? – The vehicle was not maintained according to the recommended service schedule. (Fifth why, a root cause)

With a little adaptation, this iterative approach can be usefully employed as a problem-defining and problem-solving solution.

Let’s look again at Wikipedia’s problem and how we can adapt it to our needs.

Step 1 Define the problem – The battery is dead. (1st Why)

Step 2 Define the process – The alternator isn’t working. (2nd Why)

Step 3 Identify possible causes – The alternator belt has broken. (3rd Why)

Step 4 Identify/Implement Solution – It was over its working life, so replace it. (4th Why – the Root Cause)

Step 5 Test for resolution – does the engine start (5th Why)

I’m sure you get the idea. And by the way, although this problem-solving technique to uncover the root cause of a problem is called the “5 Whys” it does not have to contain five questions. Sometimes you might need fewer “Whys” and sometimes more. Whatever the case, you simply keep asking “why?” until you get to the bottom of the chain and uncover the underlying or root issue.

Root cause analysis is covered in more detail in the Practical CSM Academy program, but let’s look at each step more closely.

The first step is defining the problem. Focus on the facts, not opinions or emotions. At this stage, investing some time in describing the problem in detail can be worthwhile, and try not to jump into ‘solution mode’ immediately.

None of us lives in an ideal world where customers will put their plans and schedules on hold while the CSM analyses things, so think about offering a short-term solution or ‘work-around.’ For example, it could be arranging temporary hosting for a mission-critical software application, or sourcing additional production facilities whilst the usual facilities are being serviced.

In step 2 you will be engaging with the customer to gather more information. This can take various forms, for example, visiting a production facility and speaking to people on the ground or working with IT engineers to understand their issues. But remember, business capacity has three elements: people, processes, and tools. People often get the blame when the process or the underlying training is the real issue. This can also be an excellent time to sit down with the customer and create some form of process mapping.

Step 3 is looking for possible causes. Once you have all possible causes documented (for example by using a fishbone analysis), sit down with the customer and rank them from most to least likely. It can be helpful to do this in a group setting, getting input from a more diverse group, and reaching a consensus.

As mentioned, you may want to employ a ’cause and effect’ diagram (sometimes called a fishbone or Ishikawa). This is a visual technique that helps you to identify all of the likely causes of the problem(s) you’re facing.

In step 4, you start thinking about countermeasures or solutions, and as in step 3, if you find more than one option, you can rank them from most likely to succeed to least likely.

You must take a holistic approach here, remembering to include the cost of the intervention in your calculations, the need for, and impact on, resources, and the time it will take to implement it. Be flexible in your approach, and as we mentioned earlier, consider including temporary solutions in your thinking. It’s not ideal (we don’t live in a perfect world), but it can give you and your customer more time to design a better long-term fix.

Once you have agreed on your plan, assigning roles, responsibilities, and deadlines is a good idea. This will give everyone a clear sense of what needs to be done, when, and how it fits into the bigger picture. Now is also a good time to agree on what success looks like; whatever measures you decide on, it could be setting agreed KPIs or success gates, make them concrete, simple, and easy to identify.

Now we arrive at step 5. This is where you test the solution. In the Wikipedia example we were looking at engine failure, so now that this issue has been fixed we can ask ”does the engine start?”

If it works well, great! If it fails, we’ll move to trying the next solution on your list.

This is when the time you spent thinking about cost and resources can come in useful, as there may be some overlap (the same resources needed) for different solutions. Only try one potential resolution at a time. Otherwise, you will not know which of your resolutions was the one that actually fixed the issue for you.

Built into your plan should be a contingency period; it could be a day or a week. Use this time to check for unintended consequences. From time to time, what looks like a perfect solution causes some disruption in another workflow or process – this is where creating a broad discussion group in step 3 can pay dividends. It may turn out that the group only identified some of the issues, but by being involved earlier in the process when you bring them back together, they will be aware of the initial problem and how the flawed solution arrived.

One last thing – document everything. Not only will this help with future problem-solving, but it will also be helpful to refer to if a dispute occurs.

Is this how your company deals with problem-solving? Do write in to let us know!