<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xml:base="http://www.itskeptic.org"  xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
 <title>The IT Skeptic - Comments for &quot;In ITIL, an SLA is a set of SLTs&quot;</title>
 <link>http://www.itskeptic.org/itil-sla-set-slts</link>
 <description>Comments for &quot;In ITIL, an SLA is a set of SLTs&quot;</description>
 <language>en</language>
<item>
 <title>SLA = SLTs ++</title>
 <link>http://www.itskeptic.org/itil-sla-set-slts#comment-3725</link>
 <description>&lt;p&gt;Go Skeptic!&lt;/p&gt;
&lt;p&gt;Yes, an SLA typically includes a bundle of Service Level Targets...but wait!  There&#039;s more!  In fact, arguably, the most important aspects of an SLA extend beyond the SLTs which make up the SLA.  &lt;/p&gt;
&lt;p&gt;Here&#039;s the scoop:&lt;/p&gt;
&lt;p&gt;The end goal of Service Level Management is to strengthen the relationship between customer and provider.  Service Level Agreements are the primary instrument by which we achieve that goal...or not.  Clearly, they&#039;ve got to include clear and measurable Service Level Targets, hopefully covering the basic aspects of utility and warranty, etc.  &lt;/p&gt;
&lt;p&gt;But clear targets alone don&#039;t serve the purpose of fostering or safeguarding the customer-provider relationship.  In fact, clear targets alone don&#039;t even suffice to help us sort out specific performance challenges that might arise.  So, what&#039;s missing?&lt;/p&gt;
&lt;p&gt;Basically, what&#039;s missing is all of the SLA &#039;header&#039; information required to get the right parties to the table, on a regular basis, speaking a common language, so that not only can specific challenges be met and bested, but also so that the SLA achieves its goal of strengthening the overall relationship.&lt;/p&gt;
&lt;p&gt;I&#039;ve seen plenty of SLAs go to contract dispute even where SLTs were spelled out.  The reason?  Poor definition of metrics.  Poor definition of points of contact.  Poor definition of terms.  Poor definition and observance of review cycles.  All of those items are usually covered off on in the &#039;header&#039; section an SLA before the mention of specific SLTs.&lt;/p&gt;
&lt;p&gt;Good SLM is experienced by the parties involved as a series of interactions that are mostly positive or at least productive.  This happens because reviews happen whether or not there&#039;s an &#039;issue&#039;, because expectations are carefully established and revisited frequently, and most of all because the overall goal is clearly understood as one of improving the relationship between provider and customer.  (Relationships have vastly more value potential than individual contracts...imagine that!)  By contrast, narrowly technical applications of SLM often devolve into painful exercises in compliance, extraction of value, etc. and are experienced by the parties involved as &#039;bad news if it&#039;s them calling again.&#039;&lt;/p&gt;
&lt;p&gt;Here&#039;s taruu to you!&lt;/p&gt;
</description>
 <pubDate>Wed, 19 Nov 2008 19:49:38 +0000</pubDate>
 <dc:creator>david.stucky</dc:creator>
 <guid isPermaLink="false">comment 3725 at http://www.itskeptic.org</guid>
</item>
<item>
 <title>Meaning of SLA</title>
 <link>http://www.itskeptic.org/itil-sla-set-slts#comment-3716</link>
 <description>&lt;p&gt;I thought SLA stood for Service Level Assumptions anyway :-)&lt;/p&gt;
&lt;p&gt;Regards&lt;br /&gt;
Peter Lijnse&lt;/p&gt;
</description>
 <pubDate>Wed, 12 Nov 2008 23:06:38 +0000</pubDate>
 <dc:creator>PELIJN</dc:creator>
 <guid isPermaLink="false">comment 3716 at http://www.itskeptic.org</guid>
</item>
</channel>
</rss>
