How to (and how not to!) perform effective SLA reporting...

Hello,

The experience based guidance provided in this posting although intended for Service Level Agreement (SLA) reporting, is in the large applicable to many of the reports management are tasked with. 

The IT Organisation of today is positioned all the more as a layer between the Customers and Users (beneficiaries) of the service on one side & the internal organisations and external providers on the other. 

The SLA therefore represents the capabilities of the service provider to meet agreed service levels.

The agreement written in a language intelligible to the customers and users, the SLA contains as a minimum the following:

• A description of the services being provided;
• Agreed targets for delivery and support, and
• Responsibilities of both the service provider and customer.

Following are some tips to help obtain value from your SLA reporting:

• Take time to understand who will be reading the report and what they need to know. One method is to sub-divide the report across multiple layers of abstraction. If the reader wants more detail, they should have the option to drill down thru further levels. Consider views of the report customised for each customer group.

• Keep in mind human nature; when information is processed by the recipient, they're constantly asking 'so what?' - address his/her concerns. Your SLA report need to elucidate  what happened, what was done to rectify where service levels were breached & what actions are being taken to prevent recurrence.

• Beware of misinterpretation; a picture is worth a thousand words, but are you portraying the right words? The staff collecting the data and the staff preparing the final report need not be the same. The former ensure timely and completeness. The latter ensure the end-to-end service reporting is relevant and complete & conveys the intended message without leaving any room for ambiguity.

• A historical perspective of performance is important as it shows trends and helps demonstrate the value of the processes and the impact of their implementation on service quality over time. More importantly, use the report to showcase how IT dealt with historical issues and managed to resolve them effectively.

• Reports need to be future looking as well as historical; this is achieved through development of sensible targets and the measurement of actual delivery against these planned and agreed targets. Consider using 'agreed' targets and 'stretch' targets; the latter help emphasize where IT went the extra mile and delivered a fair bit beyond what was agreed.

• Provide a reference section that provides definitions of all terms used, the basis of calculations, the reporting schedules, report distribution and meeting schedules (to present the report).

• Use tools to help automate and streamline the process, but keep in mind the intent of Bill Gates when he said that 'automation applied to an inefficient operation will magnify the inefficiency'. My advice when it comes to tools is always to start with people, ensuring they understand why it's important, their role and clarify how the measures are to be understood or interpreted. Once these foundation aspects have been achieved, the transition to powerful reporting technologies is far more effective.

• Depending upon the frequency of reporting, meet with your customers/users to present the report. Tweak the report to meet their needs, while at the same ensuring no important areas are neglected.

SLA reporting and infact ITIL and ITSM overall is a journey, it isn't a project. It's about building a culture where we each person is a cog in the machinery. They need to comprehend their area and perform it to a level such that the overall machine can function and deliver what has been agreed and promised in the SLA.

Comments most welcome on musabqureshi4@yahoo.co.uk.

Best regards,

Musab