Home �   ITIL�  Index

Service Level Management Is The Hinge

By Darreck Lisle The SLM process is the hinge for the Service Support and Service Delivery processes. It cannot function in isolation as it relies on the existence and effectiveness of other processes.
Aug 7, 2005

ITSM Watch Staff

By Darreck Lisle

The most overlooked process, the Cinderella of all Processes, is the Service Level Management (SLM). Service Level Management is the process of planning, coordinating, drafting, agreeing, monitoring and reporting on Service Level Agreements (SLAs), and the ongoing review of actual service achievement to ensure that the required and cost-justifiable quality of service is maintained and improved.

The SLM process is the hinge for the Service Support and Service Delivery processes. It cannot function in isolation as it relies on the existence and effectiveness of other processes. SLM is focused on INTEGRATION - how well the Service Support & Service Delivery processes function together.

SLM is responsible for ensuring SLAs and Operational Level Agreements (OLAs) or underpinning contracts are met. Ensuring that any adverse impact on service quality is kept to a minimum also falls with in the relm of SLM. SLAs provide the basis for managing the relationship between the Customer and the Provider. An SLA without measurable and defined expectations for each of the support processes is useless, as there is no basis for validation of the level of service expected.

Most consideration to SLM is given during the Request for Proposal (RFP) phase. At that time, repeatedly only one part of SLM becomes important - the Service Level Agreements (SLA). But, soon after the bid has been awarded the guidelines of the SLAs are no longer written in stone and up for interpretation. This comes to the detriment of the customer and the service provider.

Today there is a disturbing trend propagating itself through ITSM implementation efforts both in the Government and Civilian sectors. ITSM implementers are viewing Service Level Management as a necessary evil and not as the asset that it truly is. For the purposes of this article I will be referencing some examples from an ongoing Contract that we have been supporting for over four years.

This is a Service Delivery contract were a Customer outsourced the IT services to a Prime contractor. This Customer historically had all of its internal IT requirements and delivery left to individual business units (silos). It means that every silo had its own budget, requirements, and tools to conduct their business independently. This practice equated to having several hundred-disparate networks with their own unique flavor of how they should conduct business, and not as service offerings.

During the SLM portion of the RFP the SLAs were written in such a way that they did not establish accountability, capture expectations, or provide escalation of compliance issues. They were written from a governance/oversight role without specifying what data is to be made available to the Customer and defining Intellectual Property that should be rightly protected by the Service Provider.

As soon as the Contract was signed, both parties began to interrogate the SLAs for what they could use to protect themselves. The Service Provider, instead of figuring out how the SLAs can help the Customer benefit from the best solution, classified everything as Intellectual Property, and the Customer began to ask for detailed reports and data sources that deemed to be outside the scope of a Customer purchasing IT services. The contract specified numerous SLAs and three levels of service for each one. These levels of service had a cost associated with it based on the delivery time. At the same time, the SLAs were written so poorly that there were no consequences outlined for failure to comply with the thresholds.

    1 2 >> Last Page