When you want to create a new site in your SharePoint intranet, this is the page you’re presented with. It’s pretty daunting for an inexperienced site administrator or content owner:

Should I create a team site or a document workplace?
Would a social meeting workplace be more relevant than a decision meeting workspace?
Maybe I need a blog?
Perhaps just start with a blank site and build from there?

This dialog box gives few clues and little guidance. While nothing is ever set in stone, picking the wrong initial choice will reduce the chances of successful adoption and use.

While this kind of complexity is common across many products, not just SharePoint, it generally leads to patchy and inconsistent intranets that are cluttered with under-used sites.

There are three strategies that can be taken:

1. governance
2. site creation workflows
3. training and support

1. Governance

As discussed in Collaboration Roadmap written by Michael Sampson, it’s important to be clear about who has the rights to actually create a new site on your SharePoint intranet. Will every user be able to create a new site, or will this be restricted to a handful of central administrators?

While there is no one right answer, what’s needed in all cases is good governance. This provide a set of basic guidelines and processes that cover:

• creating new sites
• maintaining and ultimately closing sites
• what functionality can be used
• the rights and authorities granted to site owners

The smaller the number of staff able to create sites, the less training and support is required. (Although the result may be a bottleneck that generates widespread frustration.)

2. Site creation workflows

Another approach is to put some structure around creating new sites. This can include a tailored workflow and approval process that guides users step-by-step through the necessary decisions.

Screenshot courtesy of Coca-Cola.

For example, Coca-Cola in the US has created a “Teamsite Wizard”. This asks a number of key questions, with supporting help content. This makes it easier for staff to create a team site, while ensuring that important information is collected about each site.

Screenshots courtesy of Standard Chartered.

Standard Chartered in the UK goes a step further, creating a fully-fledged process that actively guides staff towards the right choices. Governance is covered off early in the process, and then the user is helped to choose the right template. Key details are then collected for the new site, before going into an approval workflow.

These types of approaches help to put structure around site creation, and are particularly appropriate in larger SharePoint intranet deployments where there is inherently less control around creating new areas.

3. Training and support

SharePoint is a new tool for most, and users will be unfamiliar with what it can do, and how to do it. One of the most obvious ways of addressing this knowledge gap is through training and support.

The work done by Transfield Services, showcased in the Governance and support for SharePoint teamsites report, provides a great example.

Extensive training materials are provided online, written in plain language, and supported by short training videos. Following the learning curve of new administrators, information is provided in bite-size chunks, with links to more in-depth materials where required.

While there is a growing body of excellent third-party training materials and books, Transfield chose to create custom documentation to match the specific functionality they’d turned on (and avoiding the features they turned off). This led to a highly successful deployment, with excellent levels of adoption and use.

Consider all three options

The options presented are not either-or. As the size and scale of a SharePoint intranet increases, it becomes vital to establish all three elements. Even when the IT team pre-creates a set of tailored template choices, users can still struggle to choose the right option.

Look for best practices established by other organisations, and set aside resources to make your SharePoint deployment successful, beyond just turning on the technology and hoping for the best.

What have you seen work?
What have you done on your SharePoint intranet?

Content comes in different shapes and context. Some needs ‘locking-down’, other content is ‘open’, while elements develop as it is pushed, modified and enhanced. There is not a ‘one solution’ fits all process flow within each stream, nor within each site area within a community site. Some communities have areas which are controlled by a central team, and no-one else can update/add. They also have areas which are open and require no authorisation or approval to publish and enhance. Other communities are more centrally controlled with some locked-down areas.

Now, wikis are not a silver bullet to our information and content management challenges, and I have argued that a wiki as an intranet is an intranet. That being said, I think content management vendors and intranet teams can learn from wiki products, and can make some simple changes to improve outcomes:

• Intranets were never meant to be updated by just a core group of publishers. Instead, the goal was always to have the “business own their own content”. Wikis should remind intranet teams that having broad engagement in the intranet is necessary for success.
• Intranets, regardless of the publishing tool used, should have a “edit this page” button available everywhere. Staff should then be provided with a simple front-end interface for updating content, without the hassles and complexities all too often imposed by CMS products.
• Workflow should then be turned off for most areas of the intranet (as workflow doesn’t work). Instead, like wikis, there should be universal versioning and a focus on quickly updating content rather than trying to “get it right” before publishing.
• The focus should be on accountability and transparency, rather than security.
• The bottom-up ease of creating new pages in wikis should also be replicated by intranet teams. While wiki advocates fail to look beyond initial organic growth, they can achieve much greater levels of involvement from staff.
• Perhaps most broadly, intranet teams should aim to generate the same culture of content that wikis can achieve. That is, the sense of community and personal involvement in content, rather than the “intranet as corporate repository”.

At the end of the day, I don’t care about the publishing tools that underpin the intranet, as long as they work and are used appropriately. I am also not arguing for throwing away our intranets and replacing them with wikis. That would be naive.

It is, however, a good time to take a fresh look at how we manage and grow our intranets, and to learn lessons from the wider community.

Thoughts, comments?