I’ve recently been joined by a new colleague, who will be taken over Problem Management duties while I’m seconded to something else (improving video conferencing). In chatting with him, he mentioned that Kepner Tregoe is quite a dated model, and that it isn’t all that useful. Ever since doing my KT training in 2007, I’ve tried to find ways to apply it – to the ITIL Problem Management process itself, or to everyday rational decision making. Personally I find it quite a useful tool, and so am always interested to explore further when someone quite passionately takes the opposite stance.
One of the key tenets of Kepner Tregoe is that changes cause problems. Alterations in supplier, materials, personnel, work practices, equipment, raw materials etc can lead to a defect (or in KT terms, a ‘deviation‘). This is particularly applicable in the IT world – as configuration changes, hardware changes, script changes etc can all lead to a deviation. Although we have quite a mature Change Management process, and in most cases a clear audit trail of all Changes made to a Configuration Item, there are times when the ‘changes cause problems’ mantra, while valid, is of limited value. For instance, let’s take the principle where a problem caused by a change can first occur at any point after that change. What if the change occurred a while ago and in the interim there have been several other changes? It then becomes more difficult to try and identify how a change has contributed to a problem.
This is a downside of KT problem analysis – so the question becomes how then to avoid being unable to determine which change caused a problem. ITIL Change Management can contribute partially to this – by helping to bundle changes into change windows, and eventually reduce the rate of change. If the dependencies of a Change and the Configuration Items involved are adequately identified, this can also provide better information to link a change with a problem.
Another downside we have seen with KT in recent weeks is that it is still very dependent on specialist (subject matter expert – SME) knowledge to identify the most probable cause. Even after comparing similar objects to identify distinctions, and reviewing changes to see how these could account for the defect or deviation, in many cases there is still a great deal of technical knowledge required to formulate a probable cause. One wonders if this is a true downside – as it would be fair to assume that in a specialist technical field, it will be the specialist who undertakes root cause analysis. After all, would it be appropriate to have a dentist find out why you have a pain in the stomach?
I suspect I will have many more interesting Kepner Tregoe conversations in the coming months…
I have had quite a bit of experience with the KT problem solving methodologies as both an instructor and an user of the process and have heard the concerns listed above many times in many variations.
KT as a simplistic or dated methodology? The basics of good problem solving skills remain unchanged as time goes on. Using specific factual information to identify realistic most probable cause and testing before implementation of a solution are the building blocks of many popular problem solving methodologies in use today. KT can be as simple or as complex as need be. I’ve seen long standing problems soved by asking the proper What and When questions only versus seemingly simple problems resolved only after detailed analysis of the trend information over long periods of time. The key is to logically (systematically) work through the usually convuluted mass of information available around an issue. Many people have trouble accepting the concept that if they answer this seemingly small number of the “right questions” with enough vigor, they can sove most problems.
You’re absolutely right about using SMEs to answer the questions. They are absolutely a necessity. Remember that you need to consider where to get the information that you need when answering the process questions. Many times the best source infornmation has to be an SME.
One pice of advice about using changes to identify possible causes is to conider combinations of distinctions and changes and to be as complete / specific as possible when identifying the changes and specifically the timing of the changes.
Remember the “Foggy Film” case from KT training, the film didn’t get fogged until 6 months after the change in vendor and the fact that the vendor changed didn’t become know until they had spent millions chasing false cause. How useful would that detailed information have been up front?
As you can tell, I’m a believer in KT process. Good luck winning over those that aren’t yet there!
Thanks Christian – your feedback is invaluable – there’s so little out there regarding Kepner Tregoe and specifically how it relates to the IT sector and ITIL specifically.
The foggy film case is a great example of changes having a delayed effect. From an IT perspective one of the things we’ve found is that although Changes are logged, the information and level of granularity in them is not as specific as is often needed to ‘dig deeper’ when undertaking problem analysis.
You’re absolutely right about asking the correct questions – the flashcards sit on my desk to prompt me. Perhaps the most important question we’ve found in IT has been “When did the deviation first occur” as this tends to help pinpoint changes (and distinctions).
I’m certainly an advocate – and suspect that I will have much more to write about KT’s applicability in ITIL.
Regards,
Kathy