Establishing a Service Level Agreement (SLA) for Exchange 2007

These days almost every company considers E-mail to be a mission critical application. As such, the IT staff is usually under quite a bit of pressure to keep the mail flowing.  In fact, company executives probably expect you to keep the servers up twenty four hours a day, three hundred sixty five days a year.

Service Level Agreements

When service level agreements first began making their way into the work place, I have to admit that I cringed at the idea. After all, the only thing worse than a server crash is having a company imposed deadline for getting the problem fixed. Experience has shown me though that if you are careful, service level agreements can actually be set up so that they work in your favor.

The Nagging Manager

About ten years ago, I was responsible for IT operations at a military base. I remember one particular situation in which an Exchange Server failed on a day when the officer in charge was already in a bad mood. He would come storming into the server room every five minutes or so demanding answers and making threats.

Believe it or not, the Army did not have any service level agreements in place at the time. If there had been one though, I could have used it to get the Colonel  off of my back. After all, a service level agreement typically entitles the IT staff to a certain amount of time to fix the problem.

This is where the part about being careful comes into play. If a service level agreement is already in place, then there is really nothing that you can do other than making sure that you adhere to it. If you are asked to help create a service level agreement though, then it is critical that you make sure to give yourself enough time to complete the repair.

For example, I recently heard a story about someone who told their manager that they wanted the service level agreement to say that they had two hours to recover a failed server. Their way of thinking was that their backup was capable of processing 10 GB per hour, so as long as none of the Exchange databases were over 20 GB, then they should be able to comply with the agreement.

There are several problems with this plan though. For starters, it assumes that the plan is to immediately start restoring data. It doesn’t allow any time for diagnostics, nor does it allow any time to track down the tape, rewind the tape, or to mount the database after the restore operation completes. The service level agreement also fails to address situations in which multiple databases need to be restored.

My point is that a service level agreement can work in your favor, but it can also come back to bite you. Therefore, make sure that you play it smart when drafting such an agreement.

Using Service Level Agreements as a Negotiating Tool

I have also known of plenty of IT managers who have used service level agreements as a bargaining chip. What tends to happen a lot of times is that a company’s executives will make some kind of statement about the level of service that they expect from their servers. In these types of situations, an IT manager can say, “If you want that level of service, then this is what I’m going to need”. By using this approach, you may be able to get redundant hardware or even additional staff members.

One last thing that I want to mention about service level agreements is that I once saw someone get burned really badly on a performance appraisal because they failed to meet a service level agreement that had been put into place. In my opinion this is kind of a bad situation, because it means that the IT staff gets punished for not meeting the service level agreement, but receives nothing for meeting it.

If management is trying to push you into accepting a service level agreement, then I recommend negotiating a bonus for meeting the agreement.

Conclusion

There is no question that service level agreements can be a thorn in an IT Manager’s side. Even so, there are ways that you can make a service level agreement work in your favor.