<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Kepner Tregoe: Is it useful for ITIL Problem Management?</title>
	<atom:link href="http://blog.kathyreid.id.au/2008/09/03/kepner-tregoe-is-it-useful-for-itil-problem-management/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.kathyreid.id.au/2008/09/03/kepner-tregoe-is-it-useful-for-itil-problem-management/</link>
	<description>Posts on ITIL, Kepner Tregoe, knitting, PHP and other free and open source (FOSS) tools</description>
	<lastBuildDate>Mon, 30 Jan 2012 09:13:41 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: KathyReid</title>
		<link>http://blog.kathyreid.id.au/2008/09/03/kepner-tregoe-is-it-useful-for-itil-problem-management/comment-page-1/#comment-1058</link>
		<dc:creator>KathyReid</dc:creator>
		<pubDate>Thu, 04 Sep 2008 14:05:22 +0000</pubDate>
		<guid isPermaLink="false">http://blog.kathyreid.id.au/?p=55#comment-1058</guid>
		<description>Thanks Christian - your feedback is invaluable - there&#039;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&#039;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 &#039;dig deeper&#039; when undertaking problem analysis. 

You&#039;re absolutely right about asking the correct questions - the flashcards sit on my desk to prompt me. Perhaps the most important question we&#039;ve found in IT has been &quot;When did the deviation first occur&quot; as this tends to help pinpoint changes (and distinctions). 

I&#039;m certainly an advocate - and suspect that I will have much more to write about KT&#039;s applicability in ITIL.

Regards,
Kathy</description>
		<content:encoded><![CDATA[<p>Thanks Christian &#8211; your feedback is invaluable &#8211; there&#8217;s so little out there regarding Kepner Tregoe and specifically how it relates to the IT sector and ITIL specifically.</p>
<p>The foggy film case is a great example of changes having a delayed effect. From an IT perspective one of the things we&#8217;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 &#8216;dig deeper&#8217; when undertaking problem analysis. </p>
<p>You&#8217;re absolutely right about asking the correct questions &#8211; the flashcards sit on my desk to prompt me. Perhaps the most important question we&#8217;ve found in IT has been &#8220;When did the deviation first occur&#8221; as this tends to help pinpoint changes (and distinctions). </p>
<p>I&#8217;m certainly an advocate &#8211; and suspect that I will have much more to write about KT&#8217;s applicability in ITIL.</p>
<p>Regards,<br />
Kathy</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Christian Green</title>
		<link>http://blog.kathyreid.id.au/2008/09/03/kepner-tregoe-is-it-useful-for-itil-problem-management/comment-page-1/#comment-1057</link>
		<dc:creator>Christian Green</dc:creator>
		<pubDate>Thu, 04 Sep 2008 12:47:06 +0000</pubDate>
		<guid isPermaLink="false">http://blog.kathyreid.id.au/?p=55#comment-1057</guid>
		<description>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&#039;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 &quot;right questions&quot; with enough vigor, they can sove most problems.

You&#039;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 &quot;Foggy Film&quot; case from KT training, the film didn&#039;t get fogged until 6 months after the change in vendor and the fact that the vendor changed didn&#039;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&#039;m a believer in KT process.  Good luck winning over those that aren&#039;t yet there!</description>
		<content:encoded><![CDATA[<p>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.</p>
<p>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&#8217;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 &#8220;right questions&#8221; with enough vigor, they can sove most problems.</p>
<p>You&#8217;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.      </p>
<p>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.  </p>
<p>Remember the &#8220;Foggy Film&#8221; case from KT training, the film didn&#8217;t get fogged until 6 months after the change in vendor and the fact that the vendor changed didn&#8217;t become know until they had spent millions chasing false cause.  How useful would that detailed information have been up front?</p>
<p>As you can tell, I&#8217;m a believer in KT process.  Good luck winning over those that aren&#8217;t yet there!</p>
]]></content:encoded>
	</item>
</channel>
</rss>

