<?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: Effective Problem Management</title>
	<atom:link href="http://blog.beetil.com/effective-problem-management/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.beetil.com/effective-problem-management/</link>
	<description>Professional service management without the pain</description>
	<lastBuildDate>Fri, 18 May 2012 05:00:00 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
<xhtml:meta xmlns:xhtml="http://www.w3.org/1999/xhtml" name="robots" content="noindex" />
	<item>
		<title>By: Mark C</title>
		<link>http://blog.beetil.com/effective-problem-management/#comment-846</link>
		<dc:creator>Mark C</dc:creator>
		<pubDate>Mon, 14 May 2012 13:14:00 +0000</pubDate>
		<guid isPermaLink="false">http://blog.beetil.com/?p=22#comment-846</guid>
		<description>*organization</description>
		<content:encoded><![CDATA[<p>*organization</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark C</title>
		<link>http://blog.beetil.com/effective-problem-management/#comment-845</link>
		<dc:creator>Mark C</dc:creator>
		<pubDate>Mon, 14 May 2012 13:13:00 +0000</pubDate>
		<guid isPermaLink="false">http://blog.beetil.com/?p=22#comment-845</guid>
		<description>This is my opinion based on my experiences.  Your mileage may vary.
 
There are incident workarounds and there are problem workarounds.  In my orginization, during a major incident, both Incident and Problem work together to get service restored.  Incident workaround is the action needed to restore service.  For example, a service running on a server hangs.  Incident workaround is to cycle that service and allow processing to continue.  The problem workaround would be to figure out how to keep the service from hanging until the root cause can be determined.  That may be adding capacity, moving the service to a different platform, etc.   </description>
		<content:encoded><![CDATA[<p>This is my opinion based on my experiences.  Your mileage may vary.<br />
 <br />
There are incident workarounds and there are problem workarounds.  In my orginization, during a major incident, both Incident and Problem work together to get service restored.  Incident workaround is the action needed to restore service.  For example, a service running on a server hangs.  Incident workaround is to cycle that service and allow processing to continue.  The problem workaround would be to figure out how to keep the service from hanging until the root cause can be determined.  That may be adding capacity, moving the service to a different platform, etc.   </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Greg</title>
		<link>http://blog.beetil.com/effective-problem-management/#comment-7</link>
		<dc:creator>Greg</dc:creator>
		<pubDate>Mon, 16 Mar 2009 22:19:58 +0000</pubDate>
		<guid isPermaLink="false">http://blog.beetil.com/?p=22#comment-7</guid>
		<description>In reality it will be both the incident and problem management teams who work together to get workarounds in place, but at different times, each with a different focus. Incident management will be more REactive (i.e. fix it now if it&#039;s a high priority), whereas problem management will be more PROactive.

Incident management&#039;s prime focus will be to get the service up and running again (particularly for P1 or P2 incidents). This will likely involve some sort of workaround if the cause of the fault can&#039;t be determined, or it can&#039;t be permanently fixed straightaway. In the real world, incidents with lower priority (e.g. P3, P4 or P5) will likely sit around for awhile (or forever) before being dealt with.

Problem management will take a broader look at common and related incidents, and look to get a workaround or a better workaround to reduce impact on the business. In reality, P1 and P2 incidents will already have some sort of workaround. It may not be a great workaround, and business may still be severely impacted by the fix. Those incidents will be associated with a problem, and the problem management team will look for a better solution to reduce the impact to the business. They will also look for workarounds for collections of business-impacting P3, P4, or even P5 incidents.

That&#039;s how we find it works in the real world anyway. It will vary from one organisation to another and there&#039;s not necessarily a right or wrong way of implementing it either!</description>
		<content:encoded><![CDATA[<p>In reality it will be both the incident and problem management teams who work together to get workarounds in place, but at different times, each with a different focus. Incident management will be more REactive (i.e. fix it now if it&#8217;s a high priority), whereas problem management will be more PROactive.</p>
<p>Incident management&#8217;s prime focus will be to get the service up and running again (particularly for P1 or P2 incidents). This will likely involve some sort of workaround if the cause of the fault can&#8217;t be determined, or it can&#8217;t be permanently fixed straightaway. In the real world, incidents with lower priority (e.g. P3, P4 or P5) will likely sit around for awhile (or forever) before being dealt with.</p>
<p>Problem management will take a broader look at common and related incidents, and look to get a workaround or a better workaround to reduce impact on the business. In reality, P1 and P2 incidents will already have some sort of workaround. It may not be a great workaround, and business may still be severely impacted by the fix. Those incidents will be associated with a problem, and the problem management team will look for a better solution to reduce the impact to the business. They will also look for workarounds for collections of business-impacting P3, P4, or even P5 incidents.</p>
<p>That&#8217;s how we find it works in the real world anyway. It will vary from one organisation to another and there&#8217;s not necessarily a right or wrong way of implementing it either!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jochen</title>
		<link>http://blog.beetil.com/effective-problem-management/#comment-6</link>
		<dc:creator>Jochen</dc:creator>
		<pubDate>Wed, 11 Mar 2009 15:43:55 +0000</pubDate>
		<guid isPermaLink="false">http://blog.beetil.com/?p=22#comment-6</guid>
		<description>To whom it may concern,

to find a workaround to enable restoration of service: is this the responsibility of the problem management? I all always thought it is the responsibility of the incident management so the problem management can focus on root cause analysis and finding a solution. Since we are just in the beginning of defining a IT QM-System that is based on ITIL(R) and works for a small organization, we seek for clarity in the naming of things. So if you can clear up my mind, it would be of great help.

With best regards,
Jochen</description>
		<content:encoded><![CDATA[<p>To whom it may concern,</p>
<p>to find a workaround to enable restoration of service: is this the responsibility of the problem management? I all always thought it is the responsibility of the incident management so the problem management can focus on root cause analysis and finding a solution. Since we are just in the beginning of defining a IT QM-System that is based on ITIL(R) and works for a small organization, we seek for clarity in the naming of things. So if you can clear up my mind, it would be of great help.</p>
<p>With best regards,<br />
Jochen</p>
]]></content:encoded>
	</item>
</channel>
</rss>

