Saving your Intranet

We'll start this section by thinking about the different needs of users in various departments, taking stock control as an example.

In the purchasing department they'll probably want a nice, detailed user interface that allows access to all the data associated with each item: price, stock level, suppliers, SKU, etc. Something like a data grid (a.k.a. spreadsheet) would be ideal here. In the warehouse or workshop however, the most productive user interface will be a touch screen with big chunky buttons designed for big chunky fingers, along with a much simplified set of functions: product in, product out, today's special in the canteen and who's top of the darts league.

Even the needs of desk-based users will vary. We quite often provide different user interfaces for IT and marketing, for example, as IT people tend to like simple design and pages with lots of directly accessible links, whereas marketing people prefer more 'designed' looking pages with far more categorisation. We'd be happy to show a list of 100 links to an IT person, but wouldn't want to show many more than 10 to the marketing department.

Given server-side scripting such as PHP or ASP it's easy enough to provide such multiple user interfaces from the same basic data set: when someone logs into the intranet you'll know their name, and hence be able to look up their required user interface - then simply set a session variable to, say, 'spreadsheet' or 'big buttons' and use this as a switch when building the pages. The data that sits behind these pages will be exactly the same, it's just the way that the user sees it which will be different.

Last month we proffered the advice that content should be owned at the departmental level, and what that means is that each department should therefore employ an intranet editor, responsible for his or her own section. This person will be responsible for publishing content, sourcing the relevant news items, finding competitor data, and generally keeping their section fresh and relevant. If your intranet supports forums then these departmental editors can also act as moderators to keep conversations on topic and edit or remove any unsuitable messages. The important thing is that the editor should have all the relevant departmental skills, so that for example the person controlling the human resources section of the intranet should be someone with an HR background, and the marketing section should be edited and updated by someone who actually understands the complete marketing process.

The key task of the departmental editor is content creation and updating, and while you might get away with updating a Web site only weekly, or even monthly, an intranet needs to be updated daily or even hourly. Remember that you've got to make this into an indispensable tool for your users, and one trick to get them to visit frequently is to make sure that they'll miss something (and know they've missed something) if they don't. Getting the boss to write a weekly column - explaining what he's been doing, where the company is going - is a great idea, because everyone's going to have to read it, just in case they bump into him in the corridor and he asks for their view on his plan to re-model the broom cupboard....

With content ownership, user interface and now editorial control all defined at the departmental level, you'll be reinforcing the existing team relationships that exist within your company, and also providing a platform that naturally encourages the formation of on-line communities. Even though your technical support people might be spread around the country (or even the world) the Tech Support section of your intranet will become their on-line home: a place where they can meet, share tips, build relationships, interact, and help each other out.

Paul's company, CST, has been called upon to rescue a number a dying intranets, and one particular failure we cured very easily was caused by something that was obvious to an outsider but almost impossible to see when working too close to the system. The designers had read the official definition of an intranet as a system running on the LAN or WAN and produced a wonderfully-designed system, accessible from their various offices around the world. They'd avoided most of the mistakes we've detailed above, so why was the system failing? What these designers had completely overlooked was that their company was a predominantly sales based organisation and that at any given time around 30% of its staff would be out of the office, maybe in an hotel room preparing for a major client presentation and needing sales data from the intranet - but with this intranet they couldn't get it. Why? Because it ran on the company's LAN and WAN, but had no Internet access - that wouldn't be an intranet! The system was available on desktops in any offices around the world, but outside access simply hadn't been considered, rendering the intranet useless for the biggest potential user group, the out-of-office salesman.

Once we'd persuaded the company to think slightly 'outside the box', and offer access via the Internet too, usage levels increased dramatically. The obvious security concerns within the company were addressed by Virtual Private Networks and digital certificates to authenticate the users. Soon relatively cheap biometric solutions will make it possible to use, say, fingerprint recognition to gain remote access to the system.

Hopefully the tips we've given here will prevent a few intranet disasters, but more important still than any factor we've mentioned so far, and the most common reason for intranet failure is simple lack of investment. Just as Web site investment is not a one-off hit, but needs an initial development budget plus an ongoing maintenance and update budget, exactly the same applies to an intranet but more so. If you plan to slash your intranet budgets, our best advice is save the electricity too and switch your servers off: better no intranet than a half-hearted one.