User adoption of SharePoint solutions is a challenge for many organizations (and consultants). I've done conference presentations on the topic and Michael Sampson wrote an entire book (which is excellent, by the way). I often talk about what I guess I'd call "macro" adoption strategies - larger scale, company-wide initiatives. Recently, I've been working with clients on more "micro" strategies - specific strategies for individual teams that are almost like service level agreements (SLAs) for team members.
What is in a team SLA? It's essentially the behaviors we agree to follow on our team. (For the purpose of this discussion, it's the SharePoint behaviors I'm focused on.) I've worked on many teams where these behaviors are implicit, but when users are new to SharePoint or online collaboration in general, I think it might be a good idea to make these shared behaviors more explicit - in the form of a written team Service Level Agreement. I've also worked on teams where the behaviors were explicitly defined but not written down - so not everyone followed them. Here are my suggestions, several of which are very much aspirational. I'm not sure that they are all possible at all times. But, the idea is to establish a set of shared expectations for how you want to use SharePoint to work together more effectively so that you can achieve both your project and organizational collaboration objectives. Below is an example of content that might be included in your team's SharePoint SLA.
For our project team:
- We will use the team site template that's been used on other projects - the one that we are either already used to using or will start seeing on everything that we are working on.
- We won't email documents to one another - we will just send links to documents in our team site.
- We will make sure that all of the work for the project, even documents that are not finished, are stored in the team site.
- We will all make sure to use the Status attribute when we share documents, indicating whether a document is a Draft, Ready for Review, or Final.
- We will use Ratings to indicate whether a document is potentially reusable or a candidate for a best practice example. (In other words, this is the framework we will use to apply document ratings - this is what ratings mean for our team.)
- When we are assigned a task to review a document for a colleague, we will review the document and update the assigned task.
- We will tag content as it is added, even if the attributes aren't required!
- We will let the team leader/project manager know if the metadata scheme needs to be adjusted.
- We will use a Meeting Workspace for agendas and minutes and we will upload meeting presentations to the workspace at least 4 hours in advance.
- We will use the Discussion Board instead of email to post questions and solicit feedback from each another.
- We will each agree to complete our user profile.
- We will share key project milestones in our status updates in our My Site.
- We will be accountable for checking the team site regularly - either by setting up alerts or using any other approach that fits within our personal work process.
I don't think that each of these items will be equally important to every team so it's important to only include the items that the people can be expected to accomplish. I would also make a point of asking everyone to acknowledge the agreement formally and even contribute items to the list - at the project kick off or during a team meeting - that way, the entire team is accountable for making sure that all of the members live up to the agreement.
I'd love some feedback from anyone who has tried something similar. Is there anything else you would add?
Update 11/17/2011: Michael Sampson suggested another much term for this shared team agreement - a "team compact." I like this term a lot so if SLA doesn't quite work for you, try "team compact" and see if that works better!