Recently I was lucky enough to work with a small group of business users who were experiencing SharePoint as ‘more than a document library‘ for the first time. Over a period of about a month we ended up growing our SharePoint 2010 Team Site in to one of the better examples that I’ve seen since working with the product from the SharePoint Portal Server 2003 and SharePoint 2007 days. Thinking back on this I was wondering if there was a way of packaging up the approach and techniques that had been successful so that they could be used again and again. Here are my conclusions, followed by some practical advice on things I like to see on a team site.
First, to define a ‘Team Site’. Well, SharePoint gives us a team site template to build new sites from which includes things like a document library and discussion board but what does this translate to in the real world? My view is that a team site is a collection of assets and activities that are united around a common purpose. This can cover a host of scenarios where I think a team site could be needed, e.g.:
- A small departmental unit who perhaps work and collaborate around the practices and processes they own within an organisation
- A working group consisting of members from various organisational units and office locations forming a virtual team with a particular deliverable or purpose
- A classic project team delivering a particular project’s goals and aims
- And no doubt many more
So, on to the areas which I think contributed to a successful team site. I’ve tried to sum these up into the three areas I felt were the most important but obviously this is not intended to be definitive, or that they could apply in every case. In fact, as you’ll see, one of my conclusions has to be that this cannot be prescriptive! The three areas:
For a truly successful team site there needs to exist a reason for being. This is going to be different for every team in every scenario, but common themes could be along the lines of “this is where we keep the project documentation” or “the place to raise issues or get questions answered“.
I actually see this as the most important area when building a team site. Without this users will simply not return after the first couple of visits – resulting in a site that falls quickly into disuse and little value. Getting the users in, and staying in, has to be one of the key goals.
I think in the past people have tried to come up with the one-size-fits-all team site template; to second guess the users needs and present a team site that will automatically meet those needs. The more and more I work with SharePoint the more I realise that this is a pipe dream. All the tools and features exist within SharePoint to meet the majority of a ‘regular’ team’s requirements, but to assume that each team will want a similar configuration of their team site is going to result in whole sections of a team site that fall into disuse, e.g. not everyone wants to use discussion boards.
Instead, I’ve found it a much better option to educate the users and help them to become aware of all the different features and then allow them to discover the features that work for them. Admittedly at first you may end up with the SharePoint equivalent of a kid in a pick ‘n’ mix sweetshop filling their bag with every available sweet (and only really liking the Haribo), but this should settle down over time with some gentle guidance and continued reflection on the success of the site. By allowing the users the freedom to build their own site in this way, not only are you helping ensure that their needs are met, but you’re also creating your own band of evangelists who will make sure the team site continues to be a success long after you are gone.
This is a key tenet for me to ensure success. Things will change. Users will swap in and out, and the world will keep spinning. Therefore it’s important not to put your team site up and say “right, this is how we’re going to work from now on“. Similar to the discovery piece above, let the users go down different routes and paths and see where they end up. Initially the worst thing that can happen is that the site will end up with some superfluous lists and libraries – but hey, so what? The important thing is that the site continues to evolve to meet the changing requirements and needs. It may be that the site starts out as a simple place to store project documents, but grows into the key collaboration tool to enable communication across a globally disperse team. If so, then be prepared to roll with the punches.
A Solid Base
Despite my statement earlier that it’s simply not possible to create a standard team site template and roll it out, I do think it’s necessary to have some ideas in your tool box that you can suggest and try out in order to help a set of users get going with their team site. Here are a few things that I think are good conversation starters for a new team site:
- Public and private document libraries – depending on the organisation my preference is the opt out approach for visibility; hence visitors to a team site should be able to see everything, apart from those things specifically locked down
- Recent documents on the home page – show the last 5 or 10 modified documents on the home page, including who by and when they were modified
- Add a note board – in SP2010 add a note board web part to the team site home page and it can be used as a ‘wall’ for the team site
- Meet the team web part – a simple introduction to the core members of a team site
- Calendar – the difficulty here is to give this a specific purpose, so that there is no ambiguity when comparing it to individual’s personal calendar, e.g. use it for project milestones etc
- Useful links – a simple SharePoint links list goes a long way to helping folks navigate
- Team identity – possibly in the form of a written introduction or an image, but something that distinguishes this site at a glance from other sites. Coming up with this identity could also tie into your user adoption strategy
To conclude, my belief is that to build a successful team site there are a few behaviours that can be seen as the success criteria:
- Users returning to the site regularly
- Users contributing/ interacting with the site regularly (dependent upon size of team)
- The team actively managing and adapting the site themselves
All of the above has been aimed at increasing these behaviours, and as such it’s about doing whatever is appropriate for the team in question. When working on a smaller scale with a specific team it’s possible to apply the above ideas and continuously ‘hand-hold’ the users to help answer their questions and listen to their ideas. A real challenge comes when looking to role out the above in an enterprise where there may be hundreds or thousands of team sites required. That’s a much harder area to look into and involves some serious attention being given to user adoption and end-user training. My thoughts on that for another post perhaps…