Design Matters

By consolidating a diverse intranet, you're probably going to be making some radical changes to the way that people are able to work. For the users you're going to offer greater effectiveness, for the content provider a different way of working that they may find more restrictive. What matters here is the way you design the interface to cope. Remember that you started on the exercise because the intranet was overgrown, remember this in your design.

Change Perceptions

While building your content, don't be afraid to challenge things - you may find multiple systems actually doing the same thing. Several people may well have attempted to write jargon busters and duplicated certain elements. Combine them into one list by all means, but you should credit the original authors.

You may also find that, especially on some of the larger departmental sites, there is a lot of irrelevant content. Note it and discuss it, but you are not compelled to take it. Set up some monitoring to find out who is visiting that part of the site. If it is, as you suspect, no one, then you have the evidence you need to archive it. If it has activity, as long as it is not just activity for the sake of it, you were wrong.

Standards

You will have probably considered standards for your re-engineering in your design process - and this book has already covered the basics of standards-based implementation. If you decide to adopt web standards in the shape of separating content and presentation ((X)HTML and CSS stylesheets) you will find that the size reduces considerably; 40% is not uncommon in pages that I've converted. This holds true unless all your other page authors have adopted web standards - a pretty unlikely eventuality.

Your Ambassadors

We've already talked about involving your key audience, the existing publishers. In order to implement this new strategy you'll have to ensure that they are trained in the technology, whether in the CMS or to your standards of writing web pages. Likewise you'll have to select content publishers and content authors and train them to your standards. These are your prime ambassadors.

If you create an online area for current developers and encourage them to populate it with whatever they like, it becomes both their test bed and their online presence. Make it public both as a reward and as a self-policing mechanism. If they know it can be seen by everyone in the company, excesses may well not occur. Keep it a little bit exclusive - not everyone gets to play with the public intranet. If you have people who want to learn web technologies you can create an area that's not public and set them projects - when they've proved themselves then they can be rewarded by being allowed to publish in public, as it were.

The others you've recruited may not have an initial responsibility for creating web pages, but initially they can become centers of questions for their local areas or departments. Encourage others to direct questions at them and if they're unsure they contact you. That way you ease the initial support load when you start making things public.

The ambassadors and developers will have to know about and be able to communicate:

• The business rationale and why it's key to have a consistent intranet. They'll also have to have knowledge about standards and why it is important to keep to them.

• Moving from just 'publishing' to 'managing content' - and why - this applies to both CMS and non-CMS installations.

• And why it's important that they realize that they're creating an asset for the organization, and that they themselves are facilitators.

In return, you can ensure that you both understand their motivations so that you can assist where necessary and have what they're doing written into their job specifications. This will ensure that they get recognition for their efforts.