The classic texts of project management outline the importance of initial planning and design activities. While they only consist of 10-30% of the project, they lay the groundwork for everything to come.

This is no different in the world of SharePoint intranets. Quite the contrary: with the breadth of SharePoint, and the effort and cost often required, it’s even more important to start with a clear plan.

Based on our experience across many organisations, this is our rule of thumb:

Spend 10-15% of the budget of SharePoint intranet projects on planning and design.

What does this mean in practice? Let’s explore a range of projects at different scales, with some example activities (these lists are not compreshensive):

Small, mostly out-of-the-box deployment

Total spend: $25k
10-15% on planning & design: $3.5k

The goal is to deploy a simple intranet using out-of-the-box SharePoint capabilities wherever possible, using configuration rather than development or customisation. Software licenses may be minimal, with external developer support around deployment and setup.

Planning and design activities should include:

• determine an overall scope (what will the intranet do?)
• confirm what SharePoint functionality will be most useful and successful
• learn lessons from past intranet projects

Medium-sized corporate intranet

Total spend: $150k
10-15% on planning & design: $20k

A typical intranet project, deploying SharePoint as the platform for a redesigned corporate intranet. Core SharePoint features are supplemented with development to deliver key capabilities. Typically involves a mix of publishing and collaboration.

Planning and design activities should include:

• uncover and confirming staff needs
• determine an overall intranet strategy and scope
• develop a concrete project plan (beyond just technical aspects)
• select key SharePoint functionality required
• target customisation and development activities
• apply best-practice techniques to determine navigation and design
• establish simple but effective governance and ongoing management

Strategic intranet project

Total spend: $500k
10-15% on planning & design: $75k

Larger intranet projects, either deploying SharePoint in big organisations, or aiming to go beyond a “standard” intranet. Significant amounts of customisation and development will be used to meet specific business needs, and to provide a strong foundation for future growth. Significant use of all aspects of SharePoint, including integration with other systems.

Planning and design activities should include:

• create a common vision amongst all stakeholders
• determine an overall intranet strategy and scope
• create a roadmap for short- and long-term activities
• establish pilots for leading-edge features
• conduct a full user-centred design process for the intranet
• establish the best project team
• build in-house intranet expertise and knowledge
• execute a change management and adoption plan
• establish robust governance
• draw on global intranet best practices

10-15% of planning doubles the business benefits

While getting the technical deployment of SharePoint right is obviously crucial, the best implementation in the world is worth nothing if it misses the mark when it comes to business and staff needs.

To often, implementation starts before the most basic of questions are answered (such as: what will the intranet actually do?). Without an overall vision, plan and scope, it becomes very difficult to make the hundreds of practical decisions that are involved in deploying a SharePoint intranet.

For this reason, this is our experience:

The 10-15% spent on design and planning doubles the business benefits delivered by a SharePoint intranet project.

Time and time again, we’ve seen a small amount of up-front planning and design work have a huge impact on SharePoint intranet projects. The project progresses faster, with less stress and uncertainty, delivering a result that works well for staff and the business.

We do the 10-15%

Step Two have been the leading experts in the intranet space for over a decade. Our role is to know what works (and what doesn’t), and to provide practical methodologies for intranet teams to follow.

In a SharePoint project, we don’t deploy or write code (there are plenty of people who do). Our role is to work with or alongside the geeks, providing the 10-15% of planning and design activities that ensures project success.

We draw on our unique experience, insight into intranet projects across hundreds of organisations, and a clear understanding of the SharePoint platform. Bringing this together, we provide the techniques, answers, examples and screenshots that maximise the value of SharePoint investments.

We can also provide ongoing support, to keep things on track, and to see the project through to a successful conclusion.

Want to know more? Get in touch

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?

Reviewing and rewriting content is a big job and cannot be done by the intranet manager alone. But training authors to write great content is a challenge, as most have never learnt to write for a specific audience.

This article outlines ways to help authors write content that is easy to find, easy to read and easy to use.

Conduct in-house training

More organisations are now recognising the importance of good quality content and are using professional trainers to conduct in-house workshops for intranet authors. This demonstrates the organisation’s commitment to the intranet and the role authors play as well as giving authors another skill to add to their resumes.

[September article by Rebecca Rodgers, read the full article]

This frees up the intranet team to focus on the big picture, but they still have a key role in teaching staff on how to deliver effective content.

Depending on the skills of the authors within the organisation, intranet teams may conduct training in:

• writing for the web
• the publishing process
• how to layout pages
• governance of the intranet

The intranet team may also run a community of practice, have specific sites for author support and provide ongoing ad-hoc support. Many of these options are discussed in an earlier article How to empower authors. But another way to support authors is with a drop-in centre.

A drop-in centre is regular forum for authors to seek advice without interrupting the intranet team or making an appointment.

The informal atmosphere makes learning easy, especially for those whose authoring responsibilities only form a small part of their role.

(June article by Catherine Grenfell, read the full article.)

One question that often arises early in the process is whether the same CMS should be used for the website and intranet, or whether two solutions should be deployed.

Historically, this question was often driven by a desire to reuse the public-facing CMS for the intranet. These days, the question is equally likely to relate to reusing the intranet solution (such as SharePoint) for the website.

While there are advantages to having a single solution, this is not a ‘slam dunk’ option as this article will explore.

[May article, read the full article]

This support must encompass content owners and authors, who are confronted by a new site structure and the requirement to deliver better content.

Training must also be provided on the new technology platform, which offers some complex and unfamiliar capabilities. These may include collaboration and social tools, which aim to change how staff work together.

Many organisations fail to put in place the necessary training and support for an improved intranet, and adoption levels suffer as a result. In the worst cases, the entire intranet project may be considered a failure when content publishers and end users alike rebel against the site changes.

These challenges make the work done by the Department of Education, Employment and Workplace Relations (DEEWR) particularly impressive.

In the context of the merging of two federal government agencies and major changes in the Freedom of Information (FOI) Act, the DEEWR team established comprehensive training initiatives and support materials.

Members of the Intranet Leadership Forum (www.steptwo.com.au/ilf), DEEWR have been generous in sharing examples of their approaches and deliverables.

[May article by Alex Manchester, read the full article]

The problem is, not only do these simplistic approaches not work, they often make the situation worse. A few examples:

1. Let’s limit email inboxes to only 20meg

The problem: staff use their email programs as long-term storage mechanisms, clogging up servers with an immense amount of old email. The simplistic solution: limit email inboxes to a small size (say 20meg), and then delete any excess on a regular basis.

We’ve seen an organisation do this. The result was that staff saved all their old messages into Outlook “saved mail” (PST) files. When an audit was done of server space, it was discovered that 12 out of 20TB was being used by these files. They can’t be indexed, searched, or virus-checked. Chances are, they will never be opened again by the staff who saved them.

So the inboxes are beautifully small, but the overall space used is larger, and information management is worse.

2. Blow up shared network folders

The problem: there are an immense number of files stored on corporate file servers, across thousands of folders in hundreds of shared drives. The files are poorly named, hard to find, and often duplicated. The simplistic solution: install SharePoint (Lotus Notes, etc), turn off network folders, and force everyone to store their files online instead.

Faced by the prospect of files shares being turned off, staff invariably copy everything they’ve got directly into SharePoint document collections (etc). Files aren’t reviewed, documents aren’t renamed, and little old content is removed. Instead, a one-to-one copy of files simply replicates the same problems in a new space.

The result? A new technology, but the same content and information management problems. And in the process, search is broken, because every search term now returns hundreds of irrelevant files and duplicates.

3. Let’s fully centralised, or fully decentralise

The problem: intranet content is very inconsistent in its quality, currency, relevance and structure. This generates a huge amount of staff (and stakeholder) dissatisfaction. The simplistic solution: fully centralise intranet publishing, so all content is created by a central team with professional skills. Alternatively: fully decentralise, so all content is owned by the business, with no involvement from the central team (if one is left).

The difficulty is this: fully centralised is always a bottleneck; fully decentralised is always anarchy. Neither extreme will deliver a successful intranet, and a mix of strategies will be required, including both centralised and decentralised where appropriate.

4. Three clicks rule

The problem: staff can’t find information on the intranet. The simplistic solution: staff “don’t like to click”, so ensure that all pages are no more than three clicks away from the homepage.

The reality is that this simply doesn’t work, not just because you can’t fit an entire intranet into a structure three levels deep. The underlying assumption is also false: staff are perfectly happy to click as long as they are confident they’re heading in the right direction.

Beware excessive simplicity

I could share a dozen other examples of simplistic approaches, and why they don’t work. The only valid simple rule is this: “The simpler the principle, the more likely it is to be wrong” (hmm, I may be breaking my own principle there).

We should always strive to elegance and simplicity where we can find it, but not to the extent that simplistic approaches actually make the problem worse. At the end of the day, it’s our job as professionals to find strategies that work in our complex organisations, and to constantly adapt these to match changing circumstances.

What are the simplistic rules you’ve seen, and what problems did they cause?

Lagging somewhat behind, enterprises delivering services to staff will also be hugely changed by these new devices. Based on previous technology adoption patterns, we believe there will be four stages of enterprise mobile adoption:

1. Access
2. Delivery
3. Targeting
4. Optimisation

1. Access

The starting step is the most basic one: make sure that staff can access enterprise services while using devices not physically located within the office environment. In many organisations, the natural starting points are field workers and mobile sales staff, who use laptops to access the intranet and business systems.

From there, enterprise-focused devices such as the Blackberry are an obvious next step. Mobile adoption only really starts to happen, however, when staff using a range of mobile devices such as iPhone and Android can access enterprise systems. First and foremost, this is a question of enterprise infrastructure and corporate security policies.

2. Delivery

Once these devices can be used to access enterprise platforms, what will staff be provided with? Even on modern mobile phones, it quickly becomes apparent that simply providing the same intranet and business systems will not suffice. Only staff desperate for information will make use of the pinch-zoom method of navigating a site optimised for 1024×768 screens.

The easiest way to close this gap is to provide mobile-aware page designs and CSS. Stripping out headers, footers, graphics and intensive navigation, the intranet can easily be made more useful on mobile devices. Making the same changes, however, to enterprise systems such as ERP solutions, is much harder.

3. Targeting

Even when the design of the intranet and business systems is tailored to match mobile devices, only half the job is done. When out in the field, staff don’t need to access all 50,000 pages of the intranet, or all 500 functions of the ERP system.

More mature mobile solutions therefore target the specific needs of mobile audiences. This might include:

• cut-down navigation options on the intranet
• key tasks surfaced to the top of sites
• true mobile versions of the staff directory
• tailored functionality within enterprise applications

These are the first truly “mobile” solutions, designed to be used from a variety of devices, quickly and easily.

4. Optimisation

Looking at the ever-changing array of “apps” available on mobile devices, it becomes clear that these are not just smaller versions of desktop tools. Phones now contain built-in GPSs, compasses, and accelerometers. Mobile apps routinely interact with the gestures of their users, and their location in the physical world.

These principles can be applied in many ways to enterprise applications:

• applications that are country and location aware, such as providing policies and tools tailored to the local working environment
• integration between enterprise systems and the mobile devices, such as staff directories that take advantage of the devices’ own built-in address books
• new ways of getting information into (and out of) enterprise systems, such as seamless integration between a phone’s camera and the safety incident reporting tool
• augmented reality tools that draw on corporate asset management databases
• true enterprise “apps” that provide rich interfaces that equal or surpass desktop equivalents

We are on a journey

The current proliferation of devices makes it hard for enterprises to quickly deliver solutions. Few organisations provide a standard phone to all staff, exposing enterprise projects to the full complexity of the mobile market. Legacy applications and security considerations also slow the delivery of mobile functionality.

Most of all, the ultra-rapid evolution of mobile devices and applications means the goalposts keep changing. What is experimental one day becomes standard practice the following day, with new territory constantly being explored.

Only the largest and most tech-savvy organisations will be able to afford to create their own mobile-focused solutions. This creates a marketplace opportunity, and our prediction is that the coming 1-2 years will see a proliferation of third-party and commercial solutions that will act as a middleman, or provide out-of-the-box functionality.

Regardless of the approach taken, this is an exciting time for enterprise tools, and one that may usher in as great a change as the move away from the typewriter.

What stage is your organisation at?

I am more cynical about quantitative methods of evaluating vendors. It makes me think of people who buy wine simply based on what The Wine Spectator rating is (without considering the food they might drink it with, or what they actually like vs. what Mr. Wine Critic likes), or my single friends who have a checklist of what they will or won’t accept in a mate. “He must be this tall, have this color eyes, and make at least this level of salary.” Well, the world simply doesn’t allow you to pick partners based on a checklist, perhaps unless you’re Tiger Woods.

Consider the many factors of a successful CMS migration, including:

Migration Steps: Vision, Plan, Pilot, Implement, and Maintain

Implementation Plan: Staffing, Detailed Content Migration Plan, Tracking Metrics, and Project Schedule

CMIS (Content Management Interoperability Specification) has been ratified as a standard by OASIS. What is it and what does it mean to buyers and users of ECM and Document Management technology? Well put simply, CMIS is the most important new standard in the ECM world in decades; it is critical for any enterprise scale RFP.

We strongly advocate a test-based approach to procurement, based on the value of scenarios; nevertheless, many enterprises want to apply a quantitative, spreadsheet-based assessment approach. In some cases these can become really quite complex. We have advised on dozens of scoring spreadsheets, and like to think we have seen them all.

This is a good post, and I agree completely with Alan’s recommendations. In the work that we do, we encourage our clients to use a super-simple scoring approach. This is enough to put some shape around the evaluation, without falling into the trap of over-complex formulas.

We have a tool which checks content every day and informs publishers 4 weeks before the review date expires to review and update or remove the content. Failure to do this results in the content being removed and if no action still taken automatically deleted. This means people can’t use out of date information and make bad decisions because of it.

I can’t tell you how many times we’ve seen organizations buy a CMS, take their same content structure, and simply distribute authoring ownership to every far flung corner of the organization. And let’s not entirely blame the organizations. It’s how CMS is sold. And it’s a myth, straight up.

ECM is an aspirational term for many, one that suggests a single layer/platform/system/methodology that will address your enterprise content needs no matter how complex, diverse, or voluminous. Some major vendors promote this approach, and buyers for such systems also exist, but they make up only a small minority in this market. So, though it may seem a little dull by comparison, from now on we will use the terms Document Management and Records Management where they apply, and will reserve the exotic ECM moniker for that rare breed of big, complex, and typically very expensive platforms that actually merit such a grandiose term.