SharePoint Service Level Agreement
Introduction Service Provision References Schedule of Service Provision
This document is a 'how to' on the development of a SharePoint Service Level (SLA) Agreement, that can be used at the start, during and following the implementation of a SharePoint solution.
From WikiPedia, the definition of an SLA is as follows:
"A service-level agreement (SLA) is a part of a service contract where the level of service is formally defined. In practice, the term SLA is sometimes used to refer to the contracted delivery time (of the service) or performance. As an example, internet service providers will commonly include service level agreements within the terms of their contracts with customers to define the level(s) of service being sold in plain language terms. In this case the SLA will typically have a technical definition in terms of mean time between failures (MTBF), mean time to repair or mean time to recovery (MTTR); various data rates; throughput; jitter; or similar measurable details."
SLAs can definitely and should be applied to SharePoint. The scope of the SLA can be attributed to the provision of a SharePoint site solution meeting a specific objective when various tools, the provision of a SharePoint environment to provide specific services to a group or groups within a company or even the implementation of a full SharePoint farm.
Service Level Agreements back up the user adoption model in SharePoint. That said, you do not need to define them at every level of your SharePoint solution. Generally, you only need two:
A SharePoint farm SLA - this covers the all web applications, connected and integrated products. This is organisational and related to ensuring the resiliency and availability of the entire company SharePoint production environment.
A SharePoint web application SLA (
The key on Service Level Agreements in SharePoint is to keep everything simple - it is not there to turn off people using SharePoint! Its purpose is to teach, inspire confidence in the availability of the platform; it and outlines support details. It also enforces that everyone involved with putting one together gathers and understand all pieces of the jigsaw that make up the solution.
There are quite a few groups of people needed to create an SLA. These groups are comprised of the business which have requested and will therefore consume the relevant SharePoint solution, and those who are responsible for providing and supporting the service; SharePoint Administrators, Architects, Developers - generally anyone involved in the day to day operation of the relevant SharePoint solution.
So, the benefit on creating this document is knowledge of what the product entails, its premise in the organisation, acting as an enabler for user adoption, and ensures the availability and stability of the product is within the bounds of agreement by both parties.
Further information concerning the nature of SharePoint is here:
When reading this document, each section gives a 'pointer' and 'what you need to do' paragraph. The pointer gives a statement of what the section is for, and the 'what you need to do' details the tasks you need to achieve to complete the section. Once you have followed all of these you should have a fully functional SLA.
Please note - and this is a repeat, that you should not over-egg the details of the SLA, since it is a document that needs to be understood by the client. If you find that you need to collate detail ensure these are in separate documents and use the References section to list those dependant documents.