ITIL Version 3 Chapters

C. Kepner-Tregoe

Charles Kepner and Benjamin Tregoe developed a useful method to analyse problems. In this appendix, their method is presented as an example of a Problem Analysis method.

Kepner and Tregoe state that Problem Analysis should be a systematic process of problem solving and should take maximum advantage of knowledge and experience. They distinguish the following five phases for Problem Analysis (described further below):

Defining the problem
Describing the problem with regard to identity, location, time and size
Establishing possible causes
Testing the most probable cause
Verifying the true cause.

Depending on time and available information, these phases can be realized to a greater or lesser extent. Even in situations where only a limited amount of information is available, or time pressure is high, it is worthwhile adopting a structured approach to Problem Analysis to improve the chances of success.

C1. Defining The Problem

Because the investigation is based on the definition of the problem, this definition has to state precisely which deviation(s) from the agreed service levels have occurred.

Often, during the definition of a problem, the most likely problem cause is already indicated. Take care not to jump to conclusions, which can guide the investigation in the wrong direction from the beginning. In practice, problem definition is often a difficult task because of a complicated IT Infrastructure and nontransparent agreements on service levels.

C2. Describing The Problem

The following aspects are used to describe the problem, i.e. what the problem IS:

Identity. Which part does not function well? What is the problem?
Location. Where does the problem occur?
Time. When did the problem start to occur? How frequently has the problem occurred?
Size. What is the size of the problem? How many parts are affected?

The 'IS' situation is determined by the answers to these questions. The next step is to investigate which similar parts in a similar environment are functioning properly. With this, an answer is formulated to the question 'What COULD BE but IS NOT?' (Which parts could be showing the same problem but do not?).

It is then possible to search effectively for relevant differences in both situations. Furthermore, past changes, which could be the cause of these differences, can be identified.

C3. Establishing Possible Causes

The list of differences and changes mentioned above most likely hold the cause of the problem so possible causes can be extracted from this list.

C4. Testing The Most Probable Cause

Each possible cause needs to be assessed to determine whether it could be the cause of all the symptoms of the problem.

C5. Verifying The True Cause

The remaining possible causes have to be verified as being the source of the problem. This can only be done by proving this in one way or another - for example by implementing a change or replacing a part. Address the possible causes that can be verified quickly and simply first.