Over a career in information technology spanning multiple decades, I have observed that many IT organizations have focused process improvement and measurement almost exclusively on software development projects.
This is understandable, given the business-critical nature and costs of large software development projects. But in reality, IT support services consume most of the IT budget, and they also require the most direct and continuous interaction with business customers.
IT organizations must demonstrate the value of IT support services to business customers, and a primary way of doing this is through service-level agreements. SLAs help IT show value by clearly defining the service responsibilities of the IT organization that is delivering the services and the performance expectations of the business customer receiving the service.
One of the most difficult tasks in developing an SLA is deciding what to include. The following sample SLA structure provides a good starting point.
Introduction: This identifies the service, the IT organization delivering that service and the business customer receiving it.
-- Infrastructure support for a shipping warehouse.
-- Software application support for the payroll staff.
Description of services: This characterizes the services to be provided, the types of work to be performed and the parameters of service delivery, including the following:
-- The types of work that are part of the service (maintenance, enhancement, repair, mechanical support).
-- The time required for different types and levels of service.
-- The service contact process and detailed information for reaching the help desk or any single point of contact for support services.
Description of responsibilities: This delineates responsibilities of both the IT service provider and the customer, including shared responsibilities.
Operational parameters: These may affect service performance and therefore must be defined and monitored.
-- Maximum number of concurrent online users.
-- Peak number of transactions per hour.
-- Maximum number of concurrent user requests.
If operational parameters expand beyond the control of the service provider, or if users of the service exceed the limits of specified operational parameters, then the SLA may need to be renegotiated.
Service-level goals: These are the performance metrics that the customer expects for specific services being delivered. SLGs are useless unless actual performance data is collected. The service being delivered will dictate the type and method of data collection.
It is important to differentiate between goals that are equipment-related and service-level goals that are people- and work-related.
-- Equipment SLG: 99% network availability 24/7.
-- People and work SLG: critical incidents resolved within two hours.
Service-improvement goals: These establish the required degree and rate of improvement for a specific SLG over time. An SIG requires that a performance trend be calculated over a specified period of time in addition to specific SLG data getting captured. This trend indicates the rate of improvement and whether the improvement goal has been achieved.
Service-performance reporting: This states IT's commitment to delivering reports to the business customer on a scheduled basis. The reports detail actual services delivered and actual levels of performance compared to the commitments stated within the SLA.
Sign-off: Signature lines and dates for authorized representatives of the IT organization delivering the service and the business customer receiving the service.
The hardest part of developing an SLA may be getting started. I hope this framework will help you begin to demonstrate IT's value to your customers.
Andersonis director of process development and quality assurance at Computer Aid Inc. Contact him firstname.lastname@example.org .
This version of the story originally appeared in Computerworld 's print edition.
Got something to add-- Let us know in the article comments .