SharePoint Intranets: Are We Communicating or Collaborating?

Imagine if you are going to buy a new sofa, and instead of entering a showroom you are taken straight into the workshop. Inside there are rolls of fabric, wooden frames of part-built sofas, others that look nearly finished but you can’t quite tell. You pick out one that you like only to be told that it’s last year’s model and no longer available. How frustrating would that be?

The reason we have showrooms is that they make a clear demarcation between production and offering something for consumption. We need to think about SharePoint in the same way; too often we frustrate employees with sites that contain a mix of final products and work in progress without any clear differentiation.

The biggest culprits are team sites that belong to departments, where they often play multiple roles:

• Communication of news such as announcements relevant only to department members

• Communication of information e.g. policies intended for all staff

• Collaboration on work in progress like internal presentations on an ongoing project

Getting clarity around the distinction can help employees find the right information more easily, and also reduce the risk of people making decisions based on outdated information, or sources that are misleading out of context. In SharePoint that clarity comes down to good governance, implemented through access control, training and appropriate templates.

The SharePoint Pyramid

We can think of SharePoint content as falling into a pyramid (see figure).

At the top is the company-wide intranet, typically for news, navigation and links to reference information.

Below this is the ‘Peer’ level, for a division or department. Underneath this fit team sites for closed-group collaboration on individual projects.

And lastly, there is personal work, which may take place on a My Site, though more typically this still resides on a personal drive.

Let’s look at a typical scenario to see how the pyramid works:

1. Joe in HR is asked to draft a new paternity leave policy. He’ll typically keep this on his local drive until he’s ready to show it to others (the bottom pyramid layer).

2. When he’s worked on it for a while he puts it in a private team site and asks a small group of colleagues to contribute to it (the 2nd pyramid layer).

3. Hopefully they will add some extra sections and revise it until the point where it is ready to be disseminated: version 1.0. This is the point where things can go horribly wrong.

4. The temptation is to change the permissions on the collaboration area and publish a link to it. But what this does is bring everyone into a working space, and there may well be other working copies or even the draft policy v1.1 that you don’t want people to use by mistake.

5. Recognising this, Joe may decide that as it’s an HR document, it should go on the HR Department Site (the 3rd pyramid layer). But this has two drawbacks:

i) The HR Department site should be for people working in HR. This means information relevant to everyone gets buried in more specialist content such as updates on employment law or detailed grievance-handling procedures.

ii) It requires that employees know who produced a document in order to find it. For a paternity policy this may be OK, but what if you want to order a new laptop. Is that IT? Finance? Perhaps Procurement?

6. What really needs to happen is for Joe to ask himself where the audience already goes to and publish the document there. As it is aimed at all employees, this would be the company-wide intranet (top of the pyramid). In recognising that publishing step, he is going from a collaboration mode into a communication mode. Clarity about this transition prompts him to ask not “where would I keep it?” but “where would my audience look for it?” This is the equivalent of Joe taking the sofa out of the workshop and into the showroom.

It is fair to say that this scenario is by no means specific to SharePoint, however the breadth of SharePoint’s functionality seems to make it more common. When intranets were largely based on a dedicated CMS and collaboration mostly happened via email attachments, then it was more common for people to reach a step where they would request something be published on the CMS when the policy was complete (and if they didn’t the same pattern appeared within a mess of shared drive folders or attachments emailed to the entire company).

SharePoint Governance in Practice

In practical terms, what can you do to encourage the right approach?

1) Govern where it matters most. The higher up the pyramid you go, the stricter the governance should be in terms of quality controls and locked-down templates.

2) Have a policy that makes collaboration areas restricted by default. This is hard to enforce automatically in SharePoint because site owners can add the “everyone” group to the permissions, but it can be done through education and policing.

3) Get your information architecture right. This should state how the different sites fit together. In particular, it needs to specify where content by a department for its own members (e.g. HR for HR) lives compared to content aimed at everyone (e.g. HR for employees) – one is the workshop, the other the showroom.

4) Design templates for each level in the pyramid that reinforce appropriate behaviour. This applies in particular to the “Peer” and “Team” levels. SharePoint provides many templates out of the box, but the vast majority of implementations seem to use only a few templates, such as “Publishing Site” and “Team Site”. For Department sites there is some ambiguity, so don’t be mislead by thinking that the templates map neatly onto a collaborationcommunication distinction:

• For small departments, a team site may provide appropriate functionality so long as it is not visible outside the department. Within-department communication is typically served by an Announcements or Blog web-part. It can be seen as the equivalent of the workshop notice board: informal, but fine for a restricted area.

• For larger departments, it may make more sense to use a publishing site for department-wide announcements and resources – in effect the “staff showroom”, with multiple team sites underneath that may be closed even to other department members (so that they don’t refer to a draft paternity policy by mistake, for example).

What About 2-Way Communications and Social Media?

Much of the hype around social media claiming to improve enterprise collaboration has only added to the confusion. Most social media tools such as commenting on news, blogs, microblogs etc. excel at supporting two-way communication, but that’s all. Clearly communication does need to happen as part of the collaborative process, but the difference is that the talking is not the end goal in itself.

What defines collaboration is that multiple people work towards an end goal. So collaboration tools should invite people to add to or modify an outcome. Wikis are the honourable exception in that participants actually modify the content, whereas comments on blogs do not change the original post. Therefore, the same principles apply when thinking about how to govern the experience at each level. On the group intranet, by all means encourage people to comment on a company-wide announcement, but it needs to be clear where the announcement ends and the comments begin.

Want to learn more? See our range of in-house workshops and consulting services for SharePoint communication and collaboration.

This post originally appeared as a guest article on Simply Communicate