Why you REALLY need a Service Level Agreement (SLA)
Many of my customers have a serious fear of defining service level agreements for SharePoint. The apparent belief is that SLAs are created by letting customers and senior management dream up lofty, unattainable goals that the system owners are then held accountable for. While this may be the unfortunate experience for some groups, it is absolutely not how an SLA should be defined.
Done well, a Service Level Agreement is two things: a negotiation tool to balance the user demands against the resources available. After this negotiation is complete the SLA serves as the definition of reasonability. For example, it may or may not be reasonable for an end-user to demand you maintain backups for 5 years, depending on your SLA. In absence of an SLA, it is possible for you to be held accountable for NOT maintaining that backup for 5 years… not because you should have, but because the fact that you don’t wasn’t known, agreed to, or communicated.
Ultimately, an SLA provides more benefit to the SharePoint administration team than it does anyone else.It should describe:
- What the service you’re offering IS, and what it IS NOT. For example, it clearly communicates that it IS NOT a replacement for network file shares, providing substantiation for limiting storage consumption and feature utilization (mapped drives via Explorer View, for example).
- What security goals are, and what they ARE NOT. For example, clearly defining that your implementation has only rudimentary security monitoring and that it might not be the best place for the storage of medical records or other PII. (Note that you should not describe exact details of your security infrastructure no matter what it might be).
- What the APPROPRIATE method of support and escalation is, and what it IS NOT. For example, calling your local support desk is a good idea… calling you personally every time they need to know how to upload a document is not).
- What your uptime and availability targets are, and what they ARE NOT. For example, while you do everything you can to keep the environment up, the company has chosen not to invest in multi-site replication technologies… meaning the system is not “business critical” and building your primary revenue stream into it might not be the best idea.
- What your disaster recovery, backup, and requested restore processes are, and what they ARE NOT. For example, clearly indicating that you only keep 3 months worth of backups, and only 1 week onsite, so that request to recover content from 6 months ago is impossible.
- What your performance targets are, and what they ARE NOT. For example, that the list containing 2 million items in a single view is either going to take a very long time to load, or isn’t going to load at all… or that 3 seconds to load the intranet homepage is not “slow”.
For any SharePoint administrator, the above list of examples should be unfortunately familiar… so the need to clearly communicate what you ARE doing and what you ARE NOT doing is hopefully obvious.
Of course, you are also now shaking your head in disbelief or refusal and muttering under your breath “We could never do this… if we were to try to do this our customers would revolt”, to which I say “GREAT!!”.
No, I’m not crazy.
Remember that the above list is something that has been agreed to by your customer’s management. This means that if your customer doesn’t like the service level being provided, they can talk to their management. Their management will either push back on them (unlikely, I know), or tell you that the service level is unacceptable and must be increased. Of course, you’re already operating on a shoestring budget, so increasing the supportability of the environment is impossible without additional investment. At this point you have done all of the homework, so you can offer Mr/s. Executive one of two options:
Accept the service level as-is, or GIVE US MORE MONEY to meet the new desired service goals. There simply is no other alternative… you’ve clearly documented the maximum support level you can commit to with your current infrastructure, configuration, and staffing. They may choose to share the cost across several investment groups (businesses, departments, divisions, whatever), or fund it themselves (though use caution… with the exception of increased priority, it is generally not possible to increase service levels for one group without benefiting several).
As I said… the SLA provides more benefit to the SharePoint team than any other. It provides an opportunity to set reasonable expectations for the current service level and the current funding model, and an opportunity to adjust both of those if the need on one side changes.
There is one HIDDEN DANGER in the SLA process: The Hidden SLA. This is the result of someone saying that the SLA cannot be communicated to the end-user audience. That doing so would be dangerous, uncomfortable, would cause backlash or negative response. The critical factor to realize is that the only reason for backlash would be if end-user expectation exceeds the service level defined. This is exactly what the SLA is designed to defeat: inappropriate end-user expectation of service level. It should be posted on the front page of your website, on the front door of your office, set as your desktop wallpaper, nailed to your forehead (kidding), etc. Anyone that implies that the SLA cannot be communicated is intentionally allowing an inappropriate expectation to be set with your end users, is demonstrating that they do not support the SLA, and will not back you up when end-users provide push. There’s a quick way to test this: Print the SLA, and have them sign it. Do it for everyone who’s commitment you need for the SLA. Either they sign it (willingly or not), or you clearly need to have a discussion about what isn’t appropriate in the SLA and what needs to change… but you cannot have people verbally agreeing to the SLA, but communicating something different to their employees. This situation it to be avoided at all costs.
Unquestionably, the SLA will be the most political item you can possible build for SharePoint… but solving the politics once, and on your own terms, will prevent thousands of other political battles in the future.
Coming soon: a sample Service Level Agreement (some examples do exist, but don’t provide enough detail… more TBD).