The primary purpose of intranets is to support staff in doing their jobs, to help them complete common business tasks.

In practice, however, this can be very frustrating on many intranets. Policies are located in one section, procedures in another section, and forms in a third. Information then needs to be hunted out in order to complete even simple activities.

The effectiveness of intranets can be greatly enhanced by bringing together all of the information and tools relating to a task or a subject, and presenting them in a single location.

This is the basis for the “all together” rule for intranets: aggregate content together, to help staff to find required information, and to complete key business tasks.

This article explores some of the issues currently experienced on intranets, and discusses alternative models that can be put into practice.

Evolving intranets

Intranets have evolved in an organic way over time, with content published by many different areas of the organisation.

This naturally leads to intranets becoming structured along organisational lines, with each business unit maintaining a separate intranet section or sub-site.

Without an overall plan for the intranet, and limited coordination between publishers, there is significant impact on how information is delivered. It is this lack of coordination between content areas that generates much of the frustration with intranets.

In practice, it often means that information on a single subject ends up being published across multiple areas of the site.

There is also a natural division between content owners and application developers, which leads to situations such as having the policies on taking leave in one location of the intranet, completely separate from the leave forms themselves (which are accessed via the ‘HR self-service’ application).

This fragmentation of information and functionality has a major impact on the usability (and usefulness) of the intranet.

There is often a division between content and systems

The “all together” rule

Addressing these issues can have a significant effect on the usage and value of the intranet, by making the intranet more user-focused (rather than publisher focused).

This is the basis for the “all together” rule, which states that information (and tools) should be brought together, to help staff find required information, and to complete common business tasks.

For example:

• Information on a single topic should be published in the one location.
• Business systems, and the information required to use them, should be delivered in the one interface.
• Intranet features and tools have greater value and effectiveness when they are aggregated in a single location, rather than scattered throughout the intranet.

The “all together” rule has wide applicability on intranets, and can create a useful perspective when coordinating intranet stakeholders and intranet owners. It also provides a simple roadmap for future improvements to the site.

Good and bad examples

The following sections provide a number of good (and bad) examples of how content and applications can be delivered on the intranet:

• Bad: content across many locations
• Good: task and subject-based information
• Bad: ten different calendars
• Good: one corporate calendar
• Bad: policies here, applications there
• Good: content and applications integrated

These are used to highlight common issues with existing intranets, and to provide some practical tips on how better solutions can be delivered.

Content is often structured along organisational lines

Bad: content across many locations

In any large intranet, there will be many content owners and authors, and a wide range of stakeholders.

In this situation, it is very easy for information to become scattered throughout many locations, making it difficult for staff to find.

For example:

• Information is divided up by content type instead of subject or task. Content is published in multiple sections: ‘policies & procedures’, ‘reports’, ‘HR’, ‘forms’ and ‘useful tools’.
• Content is structured along organisational lines, with key information published according to business unit. For example, the travel forms are found in the ‘finance’ section.
• Required details are locked up in large policy ‘manuals’ published to the site. Alternatively, there may be many individual policy documents, with few cross-links and limited navigation.
• The intranet consists of multiple sub-sites, published by different business units and each geographic region.

In all these cases, staff have to have an in-depth understanding of the intranet (and the organisation) in order to find information.

(See the earlier article Why are intranets structured like the organisational chart? for further discussion on why these situations commonly arise.)

Good: task and subject-based information

Following the “all together” rule, all of the information on a specific subject or task should be consolidated in a single location.

This should focus on providing at-a-glance details first, along with answers to common questions. Further links should then be provided to more in-depth information, and underlying policy (or even legislation).

This also involves breaking groupings according to document type, and pulling together policies, procedures and forms.

Practical suggestions on how to manage this restructuring of information can be found in the earlier article Escaping the organisation chart on your intranet.

Policy manuals also need to be revisited, and restructured into pages that are better targeted at helping staff complete common tasks. For more on this, see the article More than just finding policy documents.

Business areas compete for traffic to their sub-site

Bad: ten different calendars

In larger organisations, the same functionality can be delivered many times, in different areas of the intranet.

A common example of this can be the many different corporate calendars published to the intranet, each maintained by a separate business area.

For example:

• Main corporate calendar on the home page of the intranet, containing key organisation-wide events.
• Calendar of upcoming training provided by HR, published on the HR home page.
• Upcoming training sessions provided by IT, published in the IT section.
• Training provided by the library, listed on the library sub-site.
• Regional events, published in the sub-sites maintained for each major geographic area.
• Events organised for the public, published to a separate calendar on the external corporate website.

In part, this is a natural reflection of the different business areas publishing their own information, each focusing on the content in their control.

This situation can also be a by-product of the desire for each business unit to ‘promote’ their intranet sub-site or section. The goal being to provide ever-changing ‘value-added’ content on their section’s home page, with the goal of generating greater traffic to their area.

In practice, however, this does not succeed. Staff are often unaware of the different calendars published by the various business units, and therefore miss out on key events and training.

It also assumes that staff will take the time to regularly visit every one of the different calendars to keep abreast of all the activities and events that are happening. This is optimistic, to say the least.

The net result is often that none of the calendars reaches a ‘critical mass’ of usage, and therefore few (if any) deliver real benefits.

Good: one corporate calendar

The obvious alternative is to publish a single corporate calendar, and to aggregate all the events and activities into this one location.

Following the “all together” principle, this provides staff with a single location they can visit to see everything that is happening in the organisation.

As the volume and breadth of events grows, so does the value of the corporate calendar. This in turn generates more usage, and greater benefits for the individual business units.

This is not to say that there aren’t challenges with this approach. As the volume of entries grows, events need to be categorised. Filtering then becomes necessary, to ensure that each staff member only sees events that are relevant to their job role and geographic location.

What is most needed to make this approach work is greater coordination between intranet stakeholders and content owners. Instead of ‘competing’ for traffic, business areas should work together to deliver a single solution that provides benefits for all.

The same approach can obviously be taken for corporate news, and a range of other services (including the centralisation of online forms).

Bad: policies here, applications there

Most intranets have a ‘policies’ section. This may contain a few large policy manuals, or a long list of individual policy documents.

These policies outline how to apply for leave, how to order stationary, or the process for developing a tender.

In most cases, the associated forms have been converted to PDFs and published to the intranet. Better yet, forms that can be filled in online have been created for key tasks.

(See the earlier article Step-by-step: implementing online forms for more on this.)

In too many cases, however, these forms are published to a separate ‘forms’ section, with few (if any) cross-links between the policies and related forms.

Any applications delivered on the intranet are also published separately. At worst, there may be large self-contained applications with a separate login, as well as very different appearance and navigation.

The most common example of this is ‘HR self-service’ delivered as part of large ERP projects. These are often entirely self-contained, with no connections to the rest of the intranet.

This confronts staff with a considerable challenge. While they may be able to find the relevant policy on leave, the actual leave form itself remains elusive.

Alternatively, when working within the HR self-service applications, there is no information on how to complete the forms, or on when leave can be taken.

In the end, many users abandon the intranet in frustration and ring a local administrative staff member for help.

Start by cross-linking policies directly to related forms

Good: content and applications integrated

The simplest starting point to delivering a better solution is to cross-link between the policies and their associated forms.

If a policy makes reference to the annual leave form, then link directly to that form. Not just to the forms section, or even to the forms starting with ‘A’, but to the actual form itself.

Much more can be done beyond this, however, as shown in the diagram included in this article.

The next step towards delivering a better, more user-focused solution is to start to break down the concept of an ‘application’.

Staff don’t understand the distinction between applications, and are simply interested in completing a given task.

As outlined above, delivering stand-alone applications (particularly where they require a separate login) is a poor solution.

Instead of this, key forms and functionality should be extracted, and placed directly beside the relevant policy or instructions.

In this way, the user can read the general instructions and guidelines, and then go directly to filling in the required form.

Better yet, as the staff member has already logged onto the intranet as a whole, relevant fields in the form are pre-filled (such as name, email address, etc).

Perhaps the best solution is to dispense with the policy document entirely. Instead, when the staff member fills in their leave details, they are provided with context-sensitive help giving guidance on relevant policy information.

In this way, staff are provided with the key information they need, directly at the point when they need it. The need to switch to another window, or to jump to a different page, has been completely eliminated.

This is particularly powerful in environments such as call centres, where staff are commonly using front-line applications and have little (or no time) to lookup details on separate intranet pages.

This approach is not new. In fact, it is generally called ‘performance support systems’, and it pre-dates the web. While it is not widely known these days, it is a fairly mature discipline with research to backup best-practice approaches.

Provide staff with information directly at the point of need

Putting this into practice

The biggest challenges in delivering these improvements are not technical. Rather it is in the coordination of activities across business units.

To deliver information along task and subject lines, there must be a carefully considered design and structure for the intranet. Content authors and owners must then work together to deliver information that is structured in a way that is convenient for end users, rather than for publishers.

(The earlier article Establishing an intranet community of practice discusses a practical and effective approach for achieving this level of coordination.)

Beyond this, closer ties need to be established between the intranet team and IT (where the intranet is not run out of the IT area).

The goal of this must be to better integrate the delivery of online applications and content, to ensure that the two are combined to support user tasks and activities.

Even when it is not possible to formally link the intranet team and IT groups, there are many opportunities for more informal collaboration between the two areas.

Summary

Staff can be better supported in their daily work if the information and tools that they need are delivered in a way that matches how will be using them.

This means bringing together all of the information needed to complete a given task into the one location. It also means combining policies with the actual forms and applications used.

This is the basis for the “all together” rule, and it provides a simple mechanism for planning how to further improve the design and structure of intranets.

It is also a useful concept when building consensus amongst stakeholders regarding the ideal design of the intranet, and how best to manage the site.

While this vision will not be achieved over night, there are many incremental improvements that can steadily bring information and tools “all together” into a single location.

Acknowledgements

Thanks to Elton Billings and Lukas Karrer for prompting my thinking on this topic, as a result of stimulating conversations at the KMWorld & Intranets conference in San Jose, California.

(For an overall methodology for developing or redeveloping an intranet, see the Intranet Roadmap.)