paulchinonline.com

Intranet Spring-Cleaning for 2007

By Paul Chin

Originally published in Intranet Journal (01-Feb-2007)

back back to portfolio


It might seem strange to talk about spring-cleaning when it's -27 degrees in the sun where I live in Canada and I need to peel my toque off my frozen noggin after my mid-afternoon jogs. But with the new year one month old and everyone settled back into the work routine, this is as good a time as any to review the state of your intranet and dust off some old promises.


Neglect Through Complacency?

For all the headaches system bugs cause, they do tend to keep developers on their toes—and they can be a good, albeit frustrating, source for continued improvement. But when an intranet is working smoothly and users aren't making any complaints, new requests, or suggestions, intranet team members can become complacent. They'll bask in their wonderful work and move on to the next project, leaving content owners to manage the system. A system, however, can run status quo for a long time before anyone notices how out of date it is. Just because no one's speaking up doesn't mean the system can't use some improvement.

Unfortunately, unless developers are officially assigned to work on and manage an intranet full-time, it usually takes a rather dramatic catalyst to get the spotlight pointed back the intranet's way. Why wait for that catalyst? Here are some intranet spring-cleaning tasks you can perform to freshen up your system:

Review the intranet's mission statement
What was expected of an intranet back in 1998 when it was first developed isn't always the same as what's expected of it now in 2007. It's a good idea to review your intranet's mission statement whenever a significant amount of time has passed between updates or when there's a dramatic change in the organization's structure and/or business practices and focus.

Don't be surprised at how quickly an intranet can become defunct when everything is changing around it. Unless the system changes in parallel to adapt to the organization's environment and requirements, it can become an albatross in no time. Reviewing the system's mission statement allows intranet teams to ensure that its core function and purpose are still relevant—and if not, to make the necessary adjustments to keep the system up-to-date.

Analyze usage trends
You shouldn't take for granted that users will go to your system, or that regular users will always be regular users. An analysis of an intranet's usage and trends (known as Web analytics) and conducting a user survey are effective ways of seeing who's using the system, where they're going, what the most popular sections are, what sections are used least and require some work, and generally gauge users' overall satisfaction with the system. An understanding of these usage trends will help contribute to future system upgrades and prevent developers from spending time on sections that users don't find useful.

Re-market to raise awareness and grab new users
The initial launch of an intranet will undoubtedly bring a rush of users to the system, drawn in by curiosity or necessity. Over time, after the system's core group of regular users is established, usage will peak out. But when these regular users leave the company there will be a slow decline in usage. Add to that, these users are a big source of word of mouth promotion. With the thinning out of this grapevine, new employees might not be aware of the system. Re-marketing your intranet years after its initial launch can help attract new users and inform older employees of what's new and what's coming up.

Re-organize upcoming initiatives and get rid of those pesky bugs
Every system has a series of non-essential requests waiting in a queue: fixes for non-critical bugs that don't affect core system functionality, additional WIBNI (wouldn't it be nice if) features, and cosmetic enhancements. These types of requests are often put on the back burner because developers are moved onto more critical tasks. But if developers don't revisit these requests (and users don't remind them about them), they might end up never seeing the light of day. Reviewing and reorganizing these lists enable developers to resurrect some things that were promised in the past but were never implemented.

Vacuum up old content
With so much content contained in an intranet, it's very easy for that well-organized library to turn into a dusty attic. Intranet content—originating from multiple points of entry—is usually added daily. Unless content owners make a conscious effort to review their content regularly, it can very easily pile up and get lost or forgotten—especially over the years. Performing a content audit once in a while will do a lot to rid an intranet of old or time sensitive content that's no longer relevant. This will make finding information easier for users and won't clog up search engines that will end up returning irrelevant results.

Revitalize the system's look and feel
Giving your intranet a whole new look and feel can revitalize a system and spark new interest. There are, however, two crucial points to bear in mind before undertaking this type of site wide redesign: Firstly, it shouldn't be done too often or users will tire of the constant change. Secondly, the system has to be fully functional and relatively bug-free. Masking deficiencies and system bugs with a new glossy look is a sure sign of developers trying to skirt true system problems.


Closing Thoughts

There are very few things that can run consistently without the occasional checkup and tune-up. Intranets are no different. They're managed by so many different teams that they require a bit more attention than other systems that are strictly controlled by IT. The occasional spring-cleaning of an intranet will uncover deficiencies, renew outstanding initiatives, and prolong system lifecycle. But in order to keep your sanity, you need to tackle these types of chores when they're still small, and not neglect them and allow them to grow out of control.


Copyright © 2007 Paul Chin. All rights reserved.
Reproduction of this article in whole or part in any form without prior written permission of Paul Chin is prohibited.