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

“If we gave you a team site, would it be useful to you?”

We’ve said before that the breadth of SharePoint is both its strength and weakness. Intranet and project teams now have a powerful new tool to help the organisation work better, but what features to deploy?

The classic technology-centric approach is to talk to stakeholders in each business area, asking questions such as:

• What additional capabilities do you want on the intranet?
• Which of the following features would be useful to you?
• If you had (feature), how could you make use of it?
• What can we do with the new version of SharePoint?

These questions don’t work. Both our books, What every intranet team should know and Designing intranets, make the point “whatever you do, don’t ask staff what they want”. When tackling a new SharePoint intranet, it leads to numerous problems:

• Staff, unfamiliar with SharePoint’s capabilities, are unsure what they need.
• Stakeholders, enthusiastic about future possibilities, ask for features they won’t end up using.
• Excessive functionality and complexity impacts on adoption and use.
• Limited project resources are spent on “bells and whistles”, rather than key aspects.
• The new intranet misses the mark, and a great opportunity is lost.

Working out what to deliver

There are five fundamental approaches for determining the functionality of a new SharePoint intranet:

1. Understand staff needs. Conducting effective intranet needs analysis quickly builds up a picture of staff requirements and points of pain, and where the intranet can help. In just a week or two, the intranet or project team will know where to focus efforts.
2. Understand patterns of work. The biggest benefit of new technology is enabling new ways of working, which is hard to get shape around. Use scenarios, case studies, stories and examples to uncover how SharePoint can enable new behaviours and activities.
3. Get everyone on the same page. “SharePoint” means different things to different people, and all stakeholders must meet in the middle with a shared understanding, definitions and priorities.
4. Learn what works. Thousands of organisations have implemented SharePoint intranets, so there is no need to reinvent the wheel. Learn what it likely to work for you (and what isn’t), and use this insight to guide decision.
5. Start simple. Deliver an intranet that is simple, usable and easy to navigate. Add new SharePoint functionality as the organisation becomes familiar with what’s possible, never adding more than what’s really needed.

There is always time to work out what to deliver before implementation starts. Even a few days or weeks spent uncovering business and staff needs will save months of deployment work, ensuring that the new intranet hits the mark.

Most of all, don’t fall into the trap of starting with SharePoint features, and working back to the project scope. Even with the best will the world, it’s easy to get caught up in technology discussions and decisions, losing sight of the overall objectives and outcomes.

(Need help with all this? As our client list shows, we’ve consulted to hundreds of organisations on their intranets, and most of our current clients are deploying SharePoint.)

Last week in London I had the pleasure of presenting at the Interactions 2011 conference. This was my opening keynote, outlining a vision for the role that intranets should play within organisations.

Key points:

• There are three broad “life stages” for intranets (see Introducing the essential intranet, noting that “new intranets” are now called ad-hoc).
• Intranet teams start asking lots of “what” questions (what is the intranet for?), then “how” questions (how do we make search work?), and eventually “why” questions (why do we have an intranet?).
• Clear business value and impact can only be demonstrated when intranets are essential.
• I then gave a tour of some of the recently-announced 2011 Intranet Innovation Award winners, including Framestore, UK Parliament, QUT and CRS Australia.

Alongside brand-new “social intranets” are traditional intranets still focusing on the fundamentals.
What we’re seeing is a landscape of two-speed intranets. While there is plenty of overlap between the go-fast and go-slow intranets, there are also many differences. If we’re to close the gaps, we need to recognize that there is no one-size- fits-all approach.

Stealing approaches from the public web, the enterprise space is becoming much richer and more vibrant. Collaboration tools of all kinds are being tried and adopted, introducing new ways of connecting staff members. In some cases, organizations are ditching old intranets and replacing them with social intranets that democratize participation.

Beyond the purely social and collaborative space, modern approaches dramatically simplify developing enterprise applications. This has enabled innovative teams to deliver business solutions targeting key needs in months rather than years. This has transformed go-fast intranets into powerful business tools.

While these intranets are the ones that you hear about at conferences, the reality is that they’re still very much in the minority. In these early stages, the right conditions need to be in place to enable this type of innovation. The challenge for these new intranets is to avoid throwing the baby out with the bathwater. In some cases, the lessons hard learned over the past decade have been forgotten, on the idealistic assumption that new technologies trump old problems.

[Editorial in Intranets magazine, read the full post]

Well, Intranets2011 is over! It went very well by all accounts, and the energy in the room was remarkable. Many thanks to all the speakers and participants.

As the first of a few follow-up posts, here are the slides from my closing keynote. They’re pretty sparse, so you’ll have to see me present them in person to get the full effect!

At a basic level, intranets based on SharePoint are just like every other intranet. The same questions of design, structure, management and governance arise, regardless of the technology used to publish the site.

As discussed in the earlier article Promoting the intranet as a service, the intranet should be considered a service, underpinned by a technology product.

SharePoint does, however, introduce some new questions into the intranet planning process. The greatest strength of SharePoint is its breadth of functionality, from content publishing and collaboration, to CRM and application development.

It is this wide range of capabilities that can be so daunting for many teams. Without a clear plan, the results can become a little bit of everything, but no one clear and compelling success.

This article outlines a best-practice methodology for planning SharePoint-based intranet projects. Drawing on the Intranet Roadmap™, it provides a step-by-step approach that every team can take.

The result is confidence from the outset that the project will deliver clear benefits, and an approach that brings together business needs and technology considerations.

Intranet projects on SharePoint need a clear direction

Challenges and opportunities

Intranet projects are not easy at the best of times. Often replacing sprawling legacy sites, they have to meet the needs of a diverse audience with a limited budget and constrained resources.

SharePoint intranets are just like any other technology platform in this respect. Independent of the underlying product, the new intranet needs to be usable for staff, valuable for the business, and easy for the intranet team to maintain.

SharePoint does introduce, however, some particular issues of its own, both positive and negative.

[April article, read the full article]

Like any technology, however, it has strengths and weaknesses. And while SharePoint-based intranets are still intranets in the classic sense, there are some particular considerations for intranet teams.

The key thing is for intranet teams to understand the key strength and weakness of SharePoint:

• Strength: breadth and flexibility. SharePoint provides a remarkable range of functionality, and is supported by an active industry of specialists and a rich ecosystem of third-party components. This can greatly help intranet teams to deliver a “next generation” intranet.
• Weakness: breadth and flexibility. The sheer range of capabilities, only some of which are relevant for intranets, can be overwhelming. SharePoint is also relatively heavy on customisation and development, which can either deliver big business benefits, or waste a lot of money.

To ensure success at the outset of a SharePoint intranet project, intranet teams need to do two things: understand the platform, and have a clear vision and direction.

Understand the platform

Like any technology offering, SharePoint has huge strengths and equally huge weaknesses. The goal, as always, is to maximise the benefits from the strengths, and to avoid the weaknesses like the plague. You also want to “go with the grain” of the solution, deploying an intranet that is a natural fit for SharePoint’s underlying architecture and philosophy.

Thankfully there is a lot of good product and technical information available for SharePoint, much more so than even two years ago. This includes books, websites, articles and blogs (all too numerous to list here).

Now I’m not saying that business or comms folks should aim to become honorary geeks and start buying t-shirts from Threadless or desk ornaments from ThinkGeek. Instead, the goal should be to:

Have enough product knowledge to have meaningful discussions with IT, and to make business decisions informed by technology considerations.

Don’t wait until the developers start coding to realise that what you want to do will require $100k of development, or that you entirely overlooked a great out-of-the-box opportunity!

Have a crystal clear vision and direction

The flexibility of SharePoint means that deployments can easily lose their way. In far too many cases, we’ve seen organisations 2-3 years on from deploying SharePoint end up with a spaghetti mess of “stuff”, with no clear successes. This is not a technology or product failure, it’s a failure of planning.

Just because the SharePoint project started in IT, it doesn’t mean that all the standard (and vitally important) planning and design steps can be skipped.

Before jumping into development and deployment:

1. understand business and staff needs
2. develop an overall strategy and direction
3. choose the functionality required
4. create a clear project plan
5. develop new page layouts and navigation, using user-centred design techniques

Make sure that you’re going into the project with a completely clear idea of what you want delivered, and then shape the technology to fit the business and user needs.

Ensuring success

Intranet teams should be excited by the opportunities presented by SharePoint, and there’s no question that intranets will be transformed as a result of this new technology. Let’s just make sure they’re transformed for the better, and not for the worse.

The introduction of a new technology platform is a two-edged sword for intranets. On the positive side, a good technology solution will bring much-needed improvements and features, both of which can underpin the delivery of a great intranet.

On the negative side, however, a new solution can lead to an unhealthy focus on the technology. Too often, we’ve seen intranet redesigns get highjacked by technology, leading to an excess of new features and an impact on usability. In the worst cases, the new intranet can be harder to use for staff, cluttering the site with unnecessary complexity and solving few real problems.

The more complex the intranet technology, the harder it can be for the intranet team to retain a focus on the most important aspects: user needs, site design, navigation, usability and content.

It doesn’t need to be this way.

Intranet teams can help themselves by capturing the “high ground” at the outset of the project. The (very rough) mockup above shows one possible way.

A concrete vision for the intranet is powerful, particularly when spelled out in a picture. By incorporating new features into the site in the best way, it can help slot in the technology aspects of the project “underneath” the desired user experience, rather than letting the design be dictated by the technology.

We’ve done this very successfully for a few recent projects, and it works even in big and complex organisations. The key is to find the right balance between incremental improvements and sufficient “razzle dazzle” to engage the technology folks and senior management.

Be warned: these mockups can also be problematic. There may not be an opportunity to test the design with users in the early stages of the project, and the project can rush straight to implementation. So manage expectations from the outset, making it clear that this is a “sketch” or “concept” rather than a completed design. And leave enough time to conduct a proper user-centred design process, as outlined in Designing intranets.

How have you used sketches or mockups?