This week I have been pleasantly surprised. One of the Lean techniques I was taught was to ask "Why" five times. By asking "Why" many times (five is a good rule of thumb), you can peel away the layers of symptoms which can lead to the root cause of a problem. This technique is called the 5 Whys.

Madeleine Du Toit, the guest author of this post, then surprised me by telling me that asking "Why" can sometimes be harmful. She then introduced me to the technique outlined below. Here we go.

Is your problem analysis technique creating conflict or delivering value?

In the world of personal life coaching, it has long since been discovered that confronting a person with the question “Why?” can well… come across as confrontational. This of course leads to participants becoming defensive and protective, leaving you with less than desirable results.

Have you noticed your resources doing this when you start analysing problems in your team or with your code or technology using the famous 5 whys technique? In the IT industry this often results in the aptly named “blame-culture” so many of us battle with.

There is however another technique available to us - well known in the business world but perhaps not so well known to the average IT professional – Kepner-Tregoe Root Cause Analysis.

Kepner Tregoe was first established about 60 years ago and they developed what is now known as the KT Clear Thinking Process. You can read more about the company here http://www.kepner-tregoe.com.

The KT Clear Thinking Process is not about providing rigid templates, but rather getting resources to think differently about how to approach a problem or situation.

I would encourage you to delve deeper into the 4 key processes of KT Clear Thinking:

• Problem Analysis – Conduct root cause analysis (RCA) on complex problems.
• Decision Analysis - Make tough decisions aligned with operational priorities.
• Situation Appraisal - Identify and plan for the resolution of high-priority issues.
• Potential Problem/Opportunity Analysis - Understand and proactively manage risks and opportunities.

However, may aim for this post is to provide you with a quick overview of the Problem Analysis process to perhaps wet your appetite slightly and to get you started on a new approach when “confronting” a problem.

The basic premise of KT - Problem Analysis is to describe the problem factually before exploring possible solutions. Have you ever noticed how we desperately try to solve something we actually know very little about?

Well, using KT we describe the problem by asking questions in 4 key areas:

• What – What is the actual problem and what is experiencing the problem?
• Where – Where did the problem occur?
• When – When did the problem first occur?
• How much – What is the extent of the problem? Is it growing or getting smaller?

And then to further expand, we don’t only look at what is broken but also what is not broken. This unconventional way of describing the problem allows us to eliminate possible causes later on.

For example:

• What – Is that the only problem? Are others experiencing similar problems?
• Where – Are other areas fine?
• When – So before that time/date, it was working fine?

Once we have described the problem factually, we can hypothesise about potential causes and then use the documented facts to test the hypothesis further before honing into finding the true cause.

I have found with KT, that teams are less defensive when exploring (or rather describing) the problem and by looking at what is working (in conjunction with what is broken) it creates a narrative where we can easily eliminate possible causes before “putting the horse before the cart” so to speak.

This was a guest post by Madeleine Du Toit. Madeleine is a Certified Kepner Tregoe trainer for Foster-Melliar. She is a Service Management expert with vast experience in improving organisations’ Service Management processes. As a trainer and facilitator she specialises in ITIL, KT, HDI and COBIT.

If you are stuck in your career try our Coaching for Corporate Athletes.