SharePoint Support, Service Level Agreements and Rambling
This post is for customers who are looking at getting, creating, or purchasing a SharePoint support agreement (from a third party) or for ISV’s, or providers of support for SharePoint looking to create a support agreement.
I have been really busy and haven’t had the chance to visit the forums as much as I used to, but had the opportunity of trying to answer a question today which I enjoyed. The question was looking for SharePoint Support Agreement pointers, or help. I have decided to post a collection (a bit nicer than my responses) here for anyone else who might have a similar requirement or inquiry.
It is very important to understand the target and who you represent in a support agreement fully. This is because the type of agreement, style, and content will be radically different based on the kind of support you are offering/agreeing to.
Summary of (High Level) Recommendations:
- Understand what your role in the agreement will be.
- Clearly identify the requirements, response times, and processes.
- Represent both parties interests in the agreement.
Summary of (Low Level) Recommendations:
- Identify the browser level support.
- Plan and follow (as best you can) the Best Practices for SharePoint.
- Don’t do it all by yourself. (For the supporter.)
- Create multiple levels or tiers of support.
- Outline methods for measurement and performance monitoring/reporting.
- Outline all the dependencies.
- Outline responsibilities for other parties, the end users, site administrators (or super users), and of course your own staff/support teams.
- Make it easy for the end user to get support.
- The agreement must change, grow, and evolve.
- Don’t forget cost, money, and to sign something in agreement, like the SLA.
My first Recommendation: Understand what your role in the agreement will be.
In any effective SharePoint deployment a governance model will be put into place which should outline technical teams, business drivers, communication plans, training, roles and responsibilities and of course support.
Let’s say that you supply IT support to this organization which uses SharePoint. You must identify whether you would be responsible for training, adjusting permissions, handling user questions such as – How do I move documents around in a document library – or whether you will monitor the server farm (web front ends, sql servers, index servers, etc), upgrade the server farm, work with the organization to improve their model, or improve taxonomy or site structure etc etc.
Even if this is an internal project you can normally gather a large number of requirements and understand the expectations for the group you represent in the service level agreement. It’s these requirements, and expectations which should identify what the content of the service level agreement will be.
Second Recommendation: Clearly identify the requirements, response times, and processes.
This is a big one. Because SharePoint is so large and complex it can do a VAST amount of things for users. While in this case it may seem like you are only using it for document management and communication you might quickly realize many processes are automated or going to be automated in SharePoint via it’s workflows, or that people are going to begin using more and more powerful functionality like excel services, the BDC, KPI’s, document conversion etc. All of these things will have an impact on the configuration of the servers, performance impact, and administration of SharePoint.
As a result it is EXTREMELY important to clearly identify what IS in scope or agreed upon and that anything not outlined is NOT part of the agreement. The agreement must constantly change, grow, and be evaluated in order for it to adequately represent what you are doing.
Third Recommendation:Represent both parties interests in the agreement.
This sounds so simple, but quite a few people can get lost in just representing your interests as the client, or as the supporter of the agreement. Keep in mind that this is supposed to help both of you. While much of what I outline in this article is coloured to help the supporter of the agreement I don’t want to undermine the importance of the client’s needs either.
Those are my big three high level recommendations. Next up my specific recommendations (based on experience).
Identify the browser level support.
This ones simple, and already done by SharePoint, you should re-iterate it in the agreement though so people don’t bother you with questions related to the differences between browsers.
Plan and Follow (as much as you can) the Best Practices of SharePoint.
If you are responsible for the disaster recovery look into the many best practice documents from SharePoint and the community on how best to handle disaster recovery with SharePoint based on the requirements the business has.
Plan for performance and capacity: http://technet.microsoft.com/en-us/library/cc288124.aspx
Plan for data protection and recovery: http://technet.microsoft.com/en-us/library/cc287972.aspx
Keep in mind that best practices also require you to understand the processes for how these are achieved, otherwise they won’t really help you.
Don’t do it all by yourself. (Supporter)
Don’t try and do it all yourself if you can help it. One thing that always helped me and my IT teams when managing SharePoint has been getting ‘super users’ or power users to help train, and answer questions. There are always ‘technical’ people or people interested in learning and empowering themselves with SharePoint. If you can provide more advanced training to these people (as part of the agreement) it can offload and distribute alot of the workload so that many departments can be somewhat self sufficient and keeping you group (if desired) at more of an administrative level.
Create multiple levels or tiers of support.
Identify the technical support ‘tiers’. Always have multiple tiers. Tier one could be the site admin, so they understand the content and context. Tier 2 could be more Help Desk or your group which would also have a set availability and estimated response time. Typically under 1 day.
This also helps illustrate when issues should be escalated, and it’s a good idea to write some measurements for how this can be monitored. You want to make sure your tiers are functioning successfully. If everything just gets pushed up to your experts or top tiers, then this isn’t an effective model. It needs to represent the best interests of both parties ;)
Speaking of measurement…
Outline methods of measurement and performance monitoring/reporting.
Another thing worth pointing out is the importance of a method for measurement. I outlined that evaluating this agreement or support is important, but to do this you need a basis. What I like to do is outline key service indicators. Sort of an availability one which has a target of 99%. And maybe another for customer satisfaction which I normally play it safe with 80%+ as the target.
When you outline these measurements you also can outline how they can be ‘evaluated’. Total availability, or overall availability could be the hours that the service is available in the reporting period divided by the total hours in the reporting period.
It is also crucial to really identify how you will report performance. I like SIMPLE. So I use an honest to god report card format for my performance reports on support. It’s a simple percent grade for all the areas of support based on the measurements I outline in my agreement. Easy to read, understand and based on clear identifiable information.
Outline how change windows, and changes to the system should be done in the support agreement as well if possible. If not taken into consideration you might be dinged as the cause for downtime when it was really because someone changed some network cables, or AD and didn’t have anything to do with your area of support. It’s important to outline that things like this could impact performance and skew your reports.
Outline all the dependencies.
This one is one of those things that can really save your butt. The agreement and your support must always have set dependencies. The response time is expected based on the configuration and set up of the environment. So this should outline the environment dependencies and what I normally call ‘functional dependencies’. These are things like we require at minimum 3 full time support staff, etc. In your case this is external, so it might be more of a we require this much notice of changes, this much notice of issues etc.
Outline responsibilities for other parties, the end users, site administrators (or super users), and of course your own staff/support teams.
I sort of touched on this a couple times earlier. Outline the Other Party’s responsibility. Earlier I mentioned if some ISP or service shuts down you can’t be held accountable. Therefor they should be identified as an other party and it should be outlined that they are aware of this policy in some way (if possible) or that you cannot be held accountable for downtime/issues they cause.
End User Responsibilities: This is where you get to offload work and also create a sort of buffer so that if there is a big issue and the other party hasn’t clearly identified it, or provided you with enough detail you can’t be held 100% responsible. I know a lot of this sounds like I am trying to cover our collective butts, but the truth is this can help make sure that the organization understands what goes into troubleshooting an issue. You can’t be a mind reader, you need information to solve a problem. :)
If you are using super users or site administrators (that aren’t your group) outline their responsibilities here as well. This again helps identify when escalation to your technical or brilliant SharePoint masters will be brought into the loop.
I like to break down my teams so I have an operations team, a configuration team, and a SharePoint Specialist team.
(Bad names, I know) but basically the Operations tean are your general support guys. How do I upload a document, how do I move documents around in a library, how do I delete my alerts? These users should use a large knowledge base (use the wiki libraries of SharePoint *wink wink*.
The configuration team has permissions to create libraries, sites, and basically do configuration work inside of SharePoint to help users. The reason I separate these guys from the operations guys is because I don’t like to give people admin level permission for general stuff, only for when they need to do configuration changes/support (x-files taught me to trust no one, blame it on them). This also allows me to make some super users classified as operational support.
My last team is normally very few people and are those who have passed SharePoint certifications, or just really know SharePoint well. Issues with infopath, excel services or wonky things get passed onto these guys and they know how to search the community for the answers… errr they know how to come up with clever original exciting answers on their own. :P
Make it easy for the end user to get support.
SharePoint provides many ways for you to easily add support. You can add your own help information, you can create a ‘help and support’ site. You can manage tickets, and issues in SharePoint using the issues lists, and the many templates available (http://technet.microsoft.com/en-us/windowsserver/sharepoint/bb407286.aspx)
You can use the built in using access requests for permission issues (http://sharepointkb.wordpress.com/2008/12/11/using-sharepoint-request-access-fully/), or create ‘contact your site adminstrator links, or contact page owner etc.
The agreement must change, grow, and evolve.
Don’t let it become a stagnant smelly gross muck that rusts and erodes that wonderful SharePoint deployment you have put in place. In order for the tool to be successful it should be sharp, honed, and properly cared for. And support is one of those big things that helps care for any SharePoint deployment. So evaluate your agreement on a regular basis, and put this evaluation time line right in the agreement itself. Adding something like an expirey date on an agreement can really help force the organization to review performance and just how successful support has been.
This also provides you as a supporter of the agreement a new opportunity to negotiate more support for hopefully more money, or as the customer, to negotiate more support for less money.
Speaking of money…
Don’t forget cost, money, and to sign something in agreement, like the SLA.
I am sure no one forgets the money part of an agreement but I should note that I recommend a buffer on communication costs as with any support it takes longer to find out what the problem is half the time, than to actually resolve the issue.
It’s also my recommendation to get more than one person to sign the SLA from the customer/client side. This provides more backing in case one of the signer’s leaves. (Since agreements like this are normally not very short term, this happens more than you might think.)
I hope this helps someone successfully support SharePoint in the future. It’s a wonderful product (seriously guys) and does so much work for you, not to mention any support team has the help of Microsoft, the newsgroups, forums, blogging community, and many tools to help administrators and SharePoint end users alike.
Anyways, hope this helps someone,