The good old Team Site is a staple of any SharePoint implementation. Whether on SharePoint 2010, 2007 or 2003 the Team Site is commonly used as a catch all site to encourage ‘collaboration’. Therein lies the problem. For the normal user the word ‘collaboration’ has as much meaning as the word ‘Team Site’. Collaboration, as pointed out by luminaries such as Paul Culmsee, is a means to an end. You don’t collaborate for the sake of collaboration, you collaborate to solve a business process, issue or provide some tangible outcome.
The same applies for Team Sites. I am sure that Microsoft didn’t think that customers would be having these types of conversations:
End User: So what site template should I use if I want to run my project, answer a RFP, communicate information to people, have a like minded group of users exchange ideas, process an invoice, create a new procedure or …
SharePoint Guy: Oh yeah that’s easy just use a Team Site.
End User: Team Site? But a team of what? Sports team? A teamsters union? And when I create one there is just generic stuff that doesn’t apply to me. It contains a tasks list but is this a tasks list that relates to tasks I assign to people in the RFP process or tasks that I assign to others in my department?
Why don’t team sites work that well?
The answer is context. Team Sites provide no working context to users in much the same way as you handing me a document and telling me ‘This is a document’. I *know* its a document, but what the hell should I do with it? Let me give you another example. Let say that I work in a large organization and I use a file share:
This simple folder structure provides a very simple information architecture to our users that at least gives them a guideline to how they should start working. If I was looking for an Invoice chances are I would start browsing in the ‘Invoices’ folder. The same with goes for RFP Proposals. One thing that you don’t see in fileshares are folders called ‘Stuff’ or god forbid ‘Shared Documents’.
So why do we provide our users with out of the box Team Sites that contain a bunch of senseless containers for information that offer no guidance as to what they should be doing with these things (Shared Documents, Discussions, Tasks, Announcements and so on)? A SharePoint Site is simply a medium with which to accomplish a business goal, outcome or process. You need to provide your users with clear guidance around what function the site will serve. Simply telling them to use a Team Site is not going to provide clear context to users working within.
Further exacerbating this is that now not only do users not have any idea where to store things, they now have little idea about how to store them. With the new capabilities that SharePoint offers beyond that of a simple fileshare users are further confused about what is the best medium for their content. So should be they putting a team meeting in the shared calendar, or should it go in the announcements list or maybe they should email out to everyone and store it in a document library?
The Fix?
The fix is to inject the context that users need into the sites that you create. To accomplish that you need liberal doses of Information Architecture, an understanding of user requirements, an appreciation of the processes they are using all combined with the SharePoint configuration options that leverage this (metadata, content types, document and list naming, navigation and so on).
Now let me ask you to imagine a world without the Team Site template! Before I get hate mails and you spit out your coffee on your keyboard stay with me on this. If you deleted the Team Site template in SharePoint what would you replace it with? Well it would be a set of templates that are specific to a set of outcomes. In our example above we would have the following:
- RFP Proposal Site
- Project Site
- Invoice Payment Site
- Community of Practice
- Engineering Proposals
So lets take a look at a standard SharePoint 2010 Team Site template:
Now what if we simply took the Team Site template and did 15 minutes of tweaking and provide additional context to a RFP Proposal Site:
Do you see what I have done here?
What I have done is kept the same elements that a Team Site has ( Calendar, Tasks, Documents and Discussions) but now have provide some context to users to they know exactly that this document library isn’t for random documents, its for RFP working documents, the calendar isn’t a random calendar it’s a calendar to store events and milestones specific to the RFP process. I also removed that horrible photo (I think that they should get the models at the next SharePoint conference) and changed the title of the homepage. Simple steps but all of a sudden you can easily tell where information should be stored and how it should be stored.
How about we go one step further, another 15 minutes and add some other pertinent information that already comes with this base template:
Now all of this with 20 minutes of out of the box configuration. However I assure you that if you navigated to this site, or worked within it, you would instantly be aware of the purpose of the site, where content should be located and what business process, goal or objective this site is meant to facilitate.
Although this seems like a trivial example it provides tremendous value to users on a number of levels:
- You provide context to the site. No longer is this just a site, its a site for specific purpose, goal or objective.
- It allows you to use the nomenclature of your organization ensuring greater adoption and easier training
- It gives the site added purpose. There is a clear definition of what the site is supposed to do, users do not have to hunt around and determine what they are looking at or what they are supposed to do.
- As the site templates are specific to the business end users are under the impression that a custom solution has been built to their needs. It has, but is so simple to do!
The truth is that by providing your users with generic Team Sites it means that you are not understanding the business issue that they are trying to solve. Not only that you assume that users will determine on their own accord of the best way to use the site. You can create specific Site Templates for business problems as suggested above or you can use the Team Site template as a base and then configure it to users needs. What you should never do however is provide an out of the box Team Site and hope that it will be sufficient to the many business problems your users will face.
So my friends take the challenge and throw off the shackles of Team Sites. Seek to understand the business problems your uses are trying to solve and then craft a solution to their needs. You will see great adoption, better business results and a solution that provides real value.
This article was originally posted here, on the SharePoint Analyst HQ blog.
