Service Level Agreement: Setting Rules
It is often overlooked that ground rules need to be set up for a successful working relationship. What needs to be done is to not focus on the agreement, but on the process for how the teams will work together to create the Service Level Agreement.
Subjects up for discussion include the division of responsibility for tasks, scheduling challenges and any constraints that need to be identified. By identifying similarities and differences right up front, you have a better chance of having an effective agreement in place.
The Downside of a SLA
Dissatisfied business users may hope to use an SLA as a hammer with which to club the IT organization whenever service slips. Before engaging in SLA efforts, the objectives must clearly communicate the impact of the faulty service and the changes needed. The organization must also try to understand what the IT organization can and cannot accomplish.
When a relationship is plagued by distrust and finger pointing, it is not the right time to establish an SLA. First fix the underlying problems, and then establish the SLA.
When Is a SLA Really Not an Agreement?
Defining the services and the managerial tasks are necessary if an SLA is to be effective. Many times we miss the managerial elements in the SLA, for example: the business impact and revenues that are impacted as a result of a downtime. This will result in having an SLA that really doesn’t add the value that both, the IT organization and the business, hope for.
A useful agreement requires more than entering the elements into an SLA template. The process of planning, establishing, and implementing an agreement is a time consuming process of information gathering, analyzing, documenting, presenting, educating, negotiating, and building consensus. If your business users are not part of developing the SLA, it's not an agreement and will never be followed or honored.