It is not unusual for an internal organization to be looking for Service Level Agreements (SLA) with IT. Typically, this stems from the customers/users being unhappy with the service they are receiving and as a result, they are requesting SLAs. The question to ask is this: Will a written signed list of promises really resolve the issues?
Is the issue really the lack of a Service Level Agreement or is it the inability to meet the needs of the customers/users?
Let’s start with some high level definitions:
If we only had users and no customers, the user would expect IT to perform everything now. Does this sound familiar?
Is the issue really the lack of the written promised targets? Would an internal organization still be asking for SLAs if they knew their issue would be solved in a matter of days, without the need to CC their people manager and their people manager’s manager every time something wasn’t working?
Before creating and agreeing to Service Level Agreements with the customers and users, take a look at the Service Desk. Do they have what they need to resolved *ALL* incidents and service requests immediately? Sounds silly doesn’t it? Of course they don’t–not all of them, anyway.
Is there good communication and follow-up between the Service Desk and technical escalation points, such as desktop, server group, application, network, telecomm?
Do you keep track of issues? Are they logged somewhere? Do you measure how long it takes from a reported issue until it is resolved?
If the answer is, “No,” or “Not really,” or “Does email count?”, then Service Level Agreements may not be the answer.
The place to start is with understanding what the Service Desk does. How many calls do they receive? How do they escalate to other groups? Is someone always available to answer the phone or does it often go into voice mail?
When the Service Desk escalates to second line support, is the second line group responsive or too busy working on projects?
If any of these sound familiar, the answer may not be SLAs, but rather formalizing the roles and responsibilities of the IT groups and formalizing the incident management process.
Define priorities of incidents and put an IT target on each one. For example a Priority 1 – Critical infrastructure issue should be resolved within two hours (90% of the time). A Priority 2 – High infrastructure issue, should be resolved within, let’s say 24 hours, or whatever amount of time you specify, and so on.
Finally, to get started, publicize this to IT. Not the customers and users. Let the IT staff know what their expectations are and don’t forget to let them know how they are doing.
What do YOU think? Is it necessary to use SLAs? Share your feedback and stay tuned for more on ITIL®.
*ITIL® is a registered trade mark of the Cabinet Office