Join AITSM Co-Op, A community for those who ♥️ AITSM (ITSM, ITIL, AI and Automation for ITSM)

How To Solve Your IT Problems Effectively (Part-1) - Using Kepner-Tregoe Problem Analysis(KTPA)

April 28, 2022

How To Solve Your IT Problems Effectively (Part-1) - Using Kepner-Tregoe Problem Analysis(KTPA)

AITSM Show - Special Bytes - How To Solve Your IT Problems Effectively (Part-1)

Using Kepner-Tregoe Problem Analysis(KTPA)


How To Solve Your IT Problems Effectively (Part-1)

Using Kepner-Tregoe Problem Analysis(KTPA)

Learn and Grow, With AITSM Show!!!

Transcript

Anand Tambey: Welcome back to the AITSM Show.

In this series of episodes, we will try to demystify one area of ITSM: problem management.

In problem management, the crucial part is problem analysis and resolution. We will introduce some methods and structured ways of attacking the problems here.

First of all, we will attempt to decipher Kepner Tregoe's method of problem analysis, popularly called KTPA, which is a standard method for IT professionals to resolve technical problems and issues.

The first step of KTPA is stating the problem in the right way.

So, while describing the problem, are you referring to symptoms? Are you referring to general emotions? Why is this happening this time only? And likewise. That is not the right way to state the problem. 

A problem should be stated with either delays or deviation. Whenever a problem is stated like this, you will be sure that you are attacking the problem, and it will be helpful for further analysis.

Suppose your problem is that users cannot access one application for some time.

You will state the problem as the payroll application was not accessible between 10:00 AM to 1:00 AM.

Simple. Isn't it?

We're not trying to solve multiple problems and adding multiple problem statements here.

The next step of KTPA is to specify the problem in detail in four dimensions.

So, the first dimension is WHAT. What is the object it has impacted? What is the deviation we are having? And what are the specific delays we are observing here? So that part will come in WHAT.

The next dimension is WHERE. Where this problem has occurred, in which area? Which segment of users is experiencing the issue? And likewise.

The next dimension is WHEN. When the problem has occurred, it is between 10 AM and 1 AM, but whether it has happened in the past? And what are the patterns? So, whether it is morning hours, afternoon hours, or evening hours. So that kind of time or patterns we will observe here.

The next dimension is EXTENT, or the magnitude of this problem. So, the magnitude in terms of how many users are affected, maybe within this user segment, only 20% of people have observed this. Or, like some areas where this problem had occurred, it may have extended three hours or four hours. And likewise.

Now the magical part of KTPA comes here. What you will be tracking is like, IS and IS NOT for these four dimensions.

The payroll application is experiencing this problem, but the other HR applications are still working fine. So, this application only has the problem.

You're going to have a basis for comparison now. What IS, and what IS NOT? Whenever we track WHAT, WHEN, WHERE, and EXTENT, we compare it with WHAT IS THERE and WHAT IS NOT THERE.

Say, we will be tracking WHERE. So, if it is for London users or US users. Or it is for Indian users. So, it is not for Southeast Asia or other areas. It is not there.

So, you will compare how the problem has occurred in this area. And you are just segregating in some other area, which is isolated from the problem. So, it will increase your focus on the issue. Right.

So now we have specified the problems in four dimensions. And we have the comparison basis of IS and IS NOT.

Now we have a typical board, which we are looking at. And the next step, we'll say whether something is standing out? Or there is something which has been changed during this problem event.

So, the first is like what has been standing out here. Right? Say you are having the problem only with Europe users. Right. For this is standing out there. And if there is, this problem happens only in the afternoon. So that is standing out for you, right? So now that is the distinction, or what is standing out here? Right.

Now. What has been changed? During the event. Before the event. Or maybe in the last few months towards the event. So if some change happened in, say, some modules, some applications, some networks Or perhaps a way where users are operating in different patterns here, like for European users experiencing this problem.They have started to use the mobile application more. And they are not using the desktop application. Right. And there may be a peak usage there for them. Right. There may be these kinds of possibilities there. Right. So, what has been changed there?

So, once you have what is standing out and what has been changed. Now, you will have some idea about the cause of the problem.

The next step now is you have four dimensions, IS and IS NOT. And then you have identified changes. And you have identified what has been standing out. Now you can have some potential causes there.

So, if change and standing out statement for this problem is because European people are using it on mobile more. And during the afternoon, the usage is the most. So, because of that, this problem is occurring. So, why is it happening like that? Right.

Then you come to know there was a change, which has happened in mobile application, which establishes the connection, but does not destroy it. Right. That change has been applicable just before that event. One or two days back. Right.

And when people started using more and more mobile applications. The system is not able to handle those connections and that volume of connections. Right. So that could be a possible cause. We are still in the hypothesis. We are still in the like possibility of the causes here. So, we can say this is the possible cause. There might be two or three causes based on these dimensions, this data, and the pattern, right. There could be three possible causes.So next step, what will we do?

We will do a kind of experiment. We will see whether this cause is associated with whatever specific is happening or not, so if we can establish that link. We are sure that maybe this possible cause is affecting this issue.

But sometimes, it may not happen like suppose if European users are having issues. And we have not been able to identify the changes, so we cannot establish the link here. Right? So, if there is a link and there is a specificity of that cause and impact as this event. Then probably, your hypothesis may be correct.

So now you have to experiment. You have to fix that cause first and then try to see whether or not, it happens in your test environment. Or maybe you can do some certain kind of performance testing, generating user load on mobile applications. And likewise. Maybe utilizing some APIs and all. Then you will be sure that this problem will be resolved. Right. 

So, that is the full way of actually attempting this problem; as you know, right from the start, we have just given one specific problem in one statement, and then we have specified the problem in four dimensions.

And most importantly, IS or IS NOT for comparison. These are pretty crucial steps, and basically, this is so magical that you can even find many of the causes or the root causes here itself. The next part is equally important where you can have what is standing out? And what are the changes made in the system? Maybe in the past, perhaps that time or that day. Or some few days back or for that user segment, right? So that way, KTPA attempts to resolve a problem by identifying the root cause. And as a process, it will try to fix it and implement a kind of hypothesis there. Right? 

Okay. By fixing this, maybe this problem will be resolved. Right. Suppose it resolves in your testing systems and likewise. You will be pretty sure that it has been resolved, right?

Thanks a lot for listening. And here, your host Anand Tambey is signing off.

I hope it has been very helpful to you.

And you will have more courage and a more structured way of problem-solving, in your toolkit by having this KTPA method.

And in the following episodes, we will explore more and more problem-solving methods.

And it would be interesting to see how even the latest methodologies, or even some methodologies apply to any other areas. Also, it could be used in ITSM to solve the problem. Yes, it would be an interesting path ahead. Please be with me for the next episodes. And please share it generously if you like it. And let us know what we could add more? What are the topics we can touch upon?

Thanks. B-bye.

Anand Tambey Profile Photo

Anand Tambey

Host-AITSM Show | Head - AITSM Co-Op