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

In a globe-spanning manufacturing business, these differences are very obvious: individual countries sell different products; the sales division operates very differently from product development; and field engineers are not office-based designers.

Yet even a hundred-person government agency has important distinctions: each area of the organisation conducts different activities; policy officers are distinct from admin staff; project teams are working on different initiatives.

In all these cases, there is a mix of global information, common information that is shared across all staff, and local information, specific to groups or individuals.

Historically, intranets have tended to focus on global information needs, with the majority of resources devoted to HR, finance, IT, policies and forms.

Unfortunately, while this information is corporately important, it’s not what staff need daily. Nor is it the information that drives the core business of the organisation.

In contrast, local information tends to be tied directly to operational needs and service delivery. While it’s only relevant to a subset of the organisation (by definition), it can have the greatest impact on what the organisation does.

This challenges all intranet teams to find a way of delivering a site that meets both global and local needs.

[December article by James Robertson, read the full article]

Developing navigation to ensure the pathways and language are optimised to steer staff to the information they seek is fundamental to a successful solution. A number of familiar and well established user-centred design (UCD) techniques can be called upon to develop this navigation.

Essential UCD techniques include:

• content inventory and evaluation
• card sorting
• information architecture development
• wireframe development
• usability testing

However if the architecture itself is not tested, significant time invested in wireframe development and site build may be wasted.

Having a simple and effective method for assessing the proposed site architecture, before wireframing, allows the designer to refine and retest the site map before developing site visuals which tend to be more difficult and expensive to rework.

[October article by Stephen Byrne, read the full article]

Last week in London I had the pleasure of presenting at the Interactions 2011 conference. This was the second of my presentations, a 20-minute exploration of the eternal question: user-driven personalisation or targeting/tailoring?

Key points:

• Not all staff needs are the same, and this must be addressed in some way by intranets.
• The overall requirement is to meet both global (common) and local (specific) needs.
• User-driven personalisation treats staff like adults, and allows them to configure their own intranet experience.
• A great idea, but the hurdle to get over: only 5-10% of staff will personalise (as discussed in Designing intranets).
• This hurdle can be overcome if personalisation is essential for work (such as at Framestore).
• The alternative is tailoring/targeting/customising based on what is known about staff.
• There are many ways of doing this, as shown in the sampling of screenshots in the presentation.
• Tailoring is typically done in one of three ways (see Segmenting staff information needs).
• It works, but requires work.
• Do something to better meet staff needs, and start simple.
• And in response to a question: yes, you do have to get Active Directory right first (see Clean up your LDAP or Active Directory).

There are many articles and blog posts out there that measure the value of this UCD technique. This article focuses on a more specific aspect of the technique, which comes out of experience conducting a number of projects using card sorting — the use of offline and online card sorting methods.

What is card sorting?

Card sorting is an activity which asks participants to sort a selection of content — web pages, menu options etc — into categories that make sense to the individual or group.

Conducting this activity provides researchers with a user’s perspective into the groupings, and will typically inform information architecture (IA) designs.

It’s a simple technique, and perhaps the most widely used during intranet and website redesigns. Run with multiple groups of staff, it can provide valuable insights.

(August article by Alex Manchester, read the full article)

Yesterday I was honoured to give a presentation at the monthly meeting of intranet managers organised by NetJMC. These were some of the world’s largest organisations, across a range of industries. There was a lively discussion around my topic: delivering a mobile enterprise.

The key talking points:

• The latest generation of mobile devices have changed the wider world, but what about within our organisations?
• Start by recognising there are four different mobile scenarios.
• Don’t deliver a “mobile version” of your intranet.
• Instead, focus on the six things that staff want on mobile devices.
• Mobile devices are personal devices.
• Starting developing a mobile enterprise strategy.
• In the meantime, start small, and start delivering solutions (like the ones shown in the presentation).

It used to be said that it was too hard to make SharePoint beautiful, but the following selection of examples show otherwise:

Screenshot courtesy of Kiwibank.

Screenshot courtesy of Bennett Jones.

Screenshot courtesy of Bennett Jones.

Screenshot courtesy of Bupa Australia.

Screenshot courtesy of Commwealth Bank.

(Whether you think all — or any! — of these designs is “beautiful” is naturally a matter of taste. The key thing is that each has a clear design and brand, beyond the out-of-the-box SharePoint look-and-feel.)

SharePoint 2010 provides much better tools for tailoring the design of sites, including a range of point-and-click options. These are OK, but limited, and most intranet teams will want to go beyond this.

Lynne Warneke, an experienced SharePoint implementer, outlines the situation:

Plan carefully and budget accordingly! Branding SharePoint 2010 is ‘easier’ than branding the previous version, 2007, but it’s still a complex and involved process if you want a unique visual design that’s a significant departure from the out-of-the-box look & feel. And, as with all things involving SharePoint customisation, there’s a right way, and a wrong way.

When deploying a new intranet on SharePoint, and developing a visual design, therefore:

• Start with clear brand goals. Start by defining the overall intranet brand, and use this as the foundation for the design process.
• Understand the technology platform. SharePoint has its own way of managing delivering sites, that is more complex and technical than many web content management systems. Like all technologies, the best outcomes are gained by understanding the product well, building on the strengths and avoiding the weaknesses.
• Get the right designer. Visual designs must be designed with SharePoint in mind, so they fit with the technology platform, and don’t introduce bottlenecks and performance issues. (There is little value in a beautiful design that costs a million dollars to implement.)
• Get designers and technologists in the same room. Typical website and intranet design processes involved getting a designer to produce a Photoshop file or HTML template, and then “throwing it over the wall” to the developers. This works poorly for SharePoint, so get both groups in the same room from the outset.
• Target effort for the greatest impact. As shown by the examples above, even fairly small changes to the basic template can have a large apparent effect. These include changing the top banner, updating the colours, and tweaking the standard layout elements.
• Manage the effort. Obsessively tweaking the smallest design elements can be hugely costly and time-consuming in SharePoint, and can impact on upgrade options. So be clear about when to “call it quits” on getting the perfect design.
• Ensure designs are accessible. Within the limits of SharePoint itself, all intranet designs should meet accessibility standards, including basic considerations such as colour contrast.

To wrap up with more advice from Lynne Warneke:

In conclusion, make sure you are working from the outset with people who know what they’re doing with SharePoint, heed their advice, be prepared to accept the application’s idiosyncrasies and work within its ‘limitations’, have enough budget to realise your vision, and within all the constraints, do have fun turning SharePoint’s corporate charcoal interface into something that will appeal to your intranet users. From experience I have learned that a more beautiful SharePoint can positively impact user adoption.

On intranets, ticker tapes can be used for:

• emergency information when major disruptions occur such as storms or branch shutdowns
• notification of IT system outages both planned and unexpected
• hooks or teases for news stories or content
• frequently changing organisational information such as share prices or call volumes

The most common way ticker tapes are implemented on intranet home pages is for emergency information or IT alerts.

Ticker tapes are used by some of the biggest news organisations in the world. For example the BBC news site includes a ticker of the latest news.

[April article by Catherine Grenfell, read the full article]

Despite their enthusiasm, I say:

Don’t rely on vendors to meet your mobile enterprise needs.

Let’s go back in time to when the web became popular. Enterprise apps all started delivering web front ends for use by staff. What did we end up with? A separate ESS portal from the HR vendor, a web login to the ERP system, a separate interface for the online timesheet, and a standalone staff directory.

Multiple logins, completely different interfaces, a clutter of links to badly named systems on the intranet, and confusion for staff. We’ve since spent years trying to untangle all this, to create a simpler user experience and to achieve the holy grail of single sign-on.

Now we could rely again on the vendors to deliver required enterprise mobile functionality, but we’d end up with:

• Oracle app to connect to BI information.
• Salesforce mobile interface for CRM.
• SAP app for HR functionality.
• SharePoint mobile app for reading content and collaborating.
• Confluence app for wikis.
• Yammer app for social functionality.
• … and the list goes on.

Not exactly the nirvana we were hoping for! Instead, we’ll replicate the same desktop mess and confusion on mobile devices. Only this time the difference between enterprise functionality and consumer apps will be even starker, as they’ll sit side-by-side on the one device. Simple, effective and usable.

We know what we want: a simple mobile interface that connects staff to the six things they need, recognising that mobile devices are personal devices. This is our chance to cut through the complexity of the past, and to start from a clean sheet of paper.

For example: an Australian university has delivered a mobile front-end for students. One of the buttons is “exam results”. Not “Login to e-learning system” or “my exam results”, just “exam results”. Sitting alongside the buttons for the bus timetable and student news, this provides the mobile user with their current results, drawn from the LRM behind the scenes.

Do we need the vendors? Yes. We should expect them to provide good integration options, including web services and tailored interfaces. We should demand that they make it easy for us to draw out the information and functionality we need to deliver the mobile solution that staff require.

But let’s not kid ourselves: letting vendors drive our solutions is no more sensible this time around than the previous times…

In this article we’ll look at three intranets from the Intranet Innovation Awards that use metadata and taxonomies to provide classification systems and filtering options to help users drill down effectively and find what they’re looking for. This concept is far from new, and can be found on many public-facing websites and systems. Yet for intranets it’s become something of a lost art. Perhaps because of the complexity of designing such databases, or the general lack of sophistication of intranets themselves, relatively few sites offer such functionality.

Classifying search at AMP

AMP is a well-known Australian financial services firm with a reputation for technical innovation. AMP’s intranet, the Hub, was recently redesigned and won both a 2010 Intranet Innovation Award and a 2011 ‘Best intranet’ accolade from the Nielsen group. In redesigning the Hub, the AMP team embarked on a full user-centred design process and amped up the capabilities of the search tool, while ensuring a consistent user experience that in many ways mirrors the typical web experience. Classification schemes include the following:

• Location: In the same way that you can filter by country using Google or Bing on the web, this search experience allows users to filter results by Australia and New Zealand, where the vast majority of AMP’s staff are physically located.
• Time/Date: Also instantly recognisable from web search is the timeline filtering, seen on the news archive page. Users are able to filter results based on the day, week, month or year.

Beyond time and location, filtering options become more complex:

• Teams and format: Users can sort by business units and teams, and easily find any results by type, for example web pages, documents, spreadsheets, presentations, PDFs, audio and video.
• Colours: Complementing the main search results are colour-coded labels that, where appropriate, match the well-known colour scheme of Microsoft’s Office suite. So, blue is for document, green is for spreadsheet and so on.

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

The intranet can suffer and benefit from this collective organisational shorthand. Good intranet teams need to ensure any jargon used on top level pages such as home page and landing pages is appropriate.

For example, ‘Richard’s blog’ might be highly appropriate when it is owned by the CEO, often referred to and covered during induction training. On the other hand, ‘OSKA’ might be used as the name of the online training system based on the software used, and have no real relevance at all to staff.

The key factor in assessing any jargon-like terms that appear on the intranet is to determine the level of understanding of the terms by all staff. Do not assume that everyone knows what it all means.

How to jargon test

Depending on the size and diversity of the organisation, there are many ways to jargon test the intranet. One of the most effective ways is to review possible jargon words with new starters. This can be as simple as a joint discussion while reviewing the intranet online.

A more sophisticated option is to identify and list possible jargon words and then ask staff to share their understandings of the words. It is very important to ensure that staff do not feel like they are being tested, and they understand they are helping you with testing the intranet. One of the difficulties with this approach can be that words in the list might have different meanings in different contexts.

[November article by Catherine Grenfell, read the full article]

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?