The short answer is by being different. The longer answer requires work. Quite a bit of work.
Every team site is different. Very different. Different needs, different uses, different audiences, different goals, different requirements, different processes and so on and on.
So how can you build a proper team site that works?
I’ve built hundreds of team sites on SharePoint 2007 and 2010 in two different companies and I can honestly say they have all been different (sorry!). No two were the same in terms of how they looked or how they performed.
Right, what the components of creating a great team site?
- All the Ws: Why/who/what/where/when
- Objectives & goals
- Owners & users
- Content & processes
- The build
- The home page & navigation
All the Ws: Why/who/what/where/when
We could call this requirements gathering and it’s not a million miles from that. When someone approaches me for a new site the first thing I ask is ‘why?’ Nothing about your requirements. Just ‘why do you want a team site?’ It is important too that I talk to them face to face (or over the phone, IM, whatever). But you must talk. Yes they can fill in a request form which is normal admin and proper governance but doesn’t really tell me the ‘why’.
So I ask questions. Lots of them.
Why do you want a team site? What content is going to be in it? Who will use it? Is it to be locked down or restricted? What about business processes? Is there to be any tracking or requests? How will documents be handled? What sort of properties are they going to have? And so on.
After a good discussion, you can usually see what they need and be able to offer suggestions that when put to them, they realise: ‘I hadn’t thought of that, you can do that in SharePoint?’
Bingo. We have solved a business problem. Well, we’ve identified a possible solution using SharePoint. One of the most successful business process sites I built was for an underwriting referral process which came about because I was asking the team questions about how they worked and what they needed to track. They were only looking for a document site initially. Then using the OOTB issue tracking list, the referral system was born and very successful it was too in tracking for quality control purposes.
Objectives & goals
It’s always a bit harder to identify these. Ideally they should be SMART objectives but that is not always possible in a team site.
– Only document repository for a department. All documents will be managed and controlled on SharePoint and not on shared/network drives
– Use an issue tracking list to manage and control issues within a business area
A team site must have a clear purpose. It must have a reason to exist. “All the other departments have one so we should have one too” is not a good enough reason. How many times have you been building a team site or seen one where slap bang on the home page is a message from a department manager (plus photo) and a ‘Welcome to….blah blah’? Yes, we are guilty of that one though I have learned over time how to kick that one to touch. How? Put it on the home page for 2 weeks then move it to the side and then remove as more useful content takes its place.
Owners & users
Without either, we have nothing. Owners need to own their content, they need to be updating it on a regular basis, they need to be monitoring the site (visitors metrics are useful), controlling who gets in. They also need to be trained and supported by the main SharePoint person (ahem, that would be me).
The users too are important. They usually don’t have time to figure out the finer points of a SharePoint quick launch or document management. It is up to you and the site owner to make sure people can find the content they need as easily as possible. Or if they are coming to the site to complete a task, they should be able to do it as quickly as possible. That gets back to the first part of all the W’s, especially ‘why are we here?’ They are on the site to do something. Make sure they can.
Content & process
The meat and two veg of a site. It’s why we are all here. It’s what a user is in the site to do.
This of course is a huge element of the site and much thought and work goes into how you design, build and present the content of the site.
Key things here are views, metadata (document properties), web parts and navigation.
Web parts and they views they show are crucial as how the content of the site is presented. And this is very dependent on the metadata of documents (or lists).
The home page & navigation – the very last thing to do
Almost without exception, any initial requirements documents for new sites that I get has a layout of a home page. And almost with exception it is completely wrong and not fit for purpose.
I always tell site owners that the home page is the last thing to built (along with the quick launch navigation). They can never get their head around that as they think everything should lead off from the home page. I tell them that we get the content correct first and then we build the home page and navigation based on that. It is usually not what they think but when you show them options the light bulb usually switches on and clarity comes shining through. Eventually. Sometimes they come with a copy of a site home page – can our site look like this one?
Eh, no. Your site is unique to you. It will match your needs and those of your users not Department X.
Sidebar and small rant: I call it ‘iconitis’. It’s where someone puts a load of icons/buttons on a site for navigation purposes. They are all over the web. However on an intranet or SharePoint site there has to be consistency of imagery and even icons. A user cannot go from site to site and see different types of icons all over the place. It’s a poor user experience and poor design. So pick an icon style that fits your brand and culture, it will pay off.
Finally, let’s get back to the ‘why’. If after it’s built or near completion, you and the site owner need to look at it and ask that question. And does the site as it stands now answer the question and answer it clearly? If so, well done. If not, well….you know what to do, don’t you?
Really Useful Link Alert
Ellen van Aken (@EllenvanAken) has a great series of article about using team sites for various business processes.