SharePoint Ireland | Enterprise Social Intranets

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?

1. All the Ws: Why/who/what/where/when
2. Objectives & goals
3. Owners & users
4. Content & processes
5. The build
6. 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.

Some examples

-       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.

Showing people how to use SharePoint either as site owners or just as general users has always been a tricky thing at the best of time. Whether it’s the SharePoint ribbon, the interface itself or just end user impatience, it’s always being a challenge for any intranet or SharePoint manager.

One solution I came up was to create quick guides to using SharePoint as an Announcements list. It only contains 7 items dealing with the most popular uses of SharePoint (uploading documents, setting alerts, integrating with Outlook and so on). More can be added of course. There are two options as to how you can implement it on your site.

Option 1: Save the list as template
This list is then saved as a template in the team sites site collection and can be added to any team site by a site owner to help their own end users and have quick access to help guides when they are in the site. Because the content is fairly fixed and we deal with a small number of sites, updating the template and re-doing it on a site is not a big issue.

Of course, you can have a large help section on a site, but I’ve found from experience that most people don’t use it. I worked on a large global SharePoint intranet which had an extensive help section, a Q&A discussion forum for queries but the Google Analytics metrics told me the visitor numbers were low. Perhaps it needed to be more visible and promoted on a regular basis! Probably.

Where I currently work we have a lot of team, project and business process sites (a new intranet is being built) where people would spend their time. If they have a quick guide in a site it’s easier for them to find and site owners can promote it to their users.

Option 2: For those with bigger sites and more updates
Another option for more control and regular updates is to use a basic web page and the page viewer web part. The help page could be located in one area and is regularly updated or changed. Site owners can be then link to this page using a page viewer web part on their site.

But what about navigation and branding, you say? That won’t work too well in a page viewer web part.

The solution is fairly simple, create a blank web part page with no branding.
1.    Open SharePoint Designer in the site where you want to create the main help page.
2.    Create a new ASPX blank page File > Add item > More pages (it will be saved in your Site Pages folder)
3.    Insert a web part zone on the page.
4.    Into that web part zone, insert a Data view web part of the original SharePoint guides announcements list onto the page and remove any unnecessary columns.
5.    Save and go to the page in your browser, you can edit the views of the web part, in my case I used a grouped view of the list to display it in the page viewer.
 
So, that way the Intranet Manager, trainer or SharePoint Admin can update the main list and have it distributed throughout many sites. It can be used for many other things such as FAQs, helpdesk support, Microsoft Office guides, systems training, HR updates/forms, etc. where you have broader information that you want to show people but want to keep them within a team site and not necessarily clicking elsewhere. So you have one information source but it can be used anywhere.

You could say, why not just provide a link to a help page? You could but it’s all about the user and the information they need (in this case quick guides to using SharePoint). If the information they need is right there on the page then that is what is needed. If they have to click to another site then they have to navigate back to their site again. So keep them on the same page as much as possible. It makes a lot of sense for  the user. And that is a good thing. It is. Trust me.

Some of my favourite bloggers and experts on SharePoint, intranets and enterprise social networking. There are many, many more.

Jeremy Thake
http://www.jeremythake.com/

James Robertson
http://www.steptwo.com.au/columntwo/

Christian Buckley
http://www.buckleyplanet.com/

Ellen van Aken
http://mydigitalworkplace.wordpress.com/

Bjorn Furukknap
http://blog.furuknap.net/

Richard Harbridge
http://www.rharbridge.com/

Wendy Neal
http://www.sharepointwendy.com/

Well it’s been an interesting few weeks in the SharePoint world with a few articles discussing the demise of SharePoint in its various forms and subsequent debate in the SharePoint community. Though this discussion has been on-going for some time, there has been more attention on it for some reason recently.

So why the debate? Much of it comes from the Microsoft pushing its cloud based services (Office 365) and SharePoint is part of it. It is also about cloud versus premises. Do you host SharePoint (and everything else) on your own network servers or do you host it externally in the cloud? Or do you mix it?

Yammer is central to this as it is hosted in the cloud and it is doubtful, indeed highly unlikely, whether there will be an on-premises version.

But to me, SharePoint on the premises is not going anywhere and Microsoft are not going to get rid of it. Not anytime soon. There are three key points about all this:

1. Scale

2. Choice

3. Security & control

Scale

If you are a small business (SME) this scale varies from country to country. Here in Ireland, most businesses would be classified as SME’s. In the USA our large companies would be SME’s!

The point is do you want the cost, hassle and effort of managing an on-premises server farm and all the applications on it or do you outsource that to the cloud?

Choice

Microsoft are providing options to organisations. Do you want cloud? Well here’s Office 365 and Azure. Do you want on-premises servers? Well, here’s Windows Server, Dynamics, SharePoint, Exchange and so on. And yes, it can be a mixture.

Security & control

It goes without saying almost that organisations like their data and information under their own management and control on their own servers. And there are legal and regulatory reasons for this too. And the less said about the NSA the better.

So to unfortunately paraphrase Mark Twain: “SharePoint’s death has been greatly exaggerated.“

Anyway, here’s two opposing views of the debate, see what you think.

Why Yammer and Office Make SharePoint ‘User Adoption’ a Dying Concern

Why I don’t think on-premises Exchange is dead

I will be doing my first SharePoint presentation to the Irish SharePoint User Group on the 24th of October 2013.

Here’s the blurb. And here’s the link on Everbrite.

Join us for two talks on Thursday 24th November in Temple Bar Hotel, Dublin:

Is Ireland ready for Social Enterprise and State of SharePoint BI (Power BI, PowerView, PowerPivot, PowerQuery, PowerMap)   
 
Yammer and SharePoint have been getting a lot of attention in the past 12 months or so. Andrew Gilleran will discuss the ins and outs of using social in an Organisation, how to measure its impact and how you organisation can take advantage of it

State of SharePoint BI (Power BI, PowerView, PowerPivot, PowerQuery, PowerMap)   
Microsoft has been producing a slew of products for Business Intelligence including the latest Power BI for Office 365. Colin will walk through all the Power products and how they relate to SharePoint OnPrem and also Office 365.