Intranet Haymakers: Potential Knockout Punches

By Paul Chin

Originally published in Intranet Journal (10-Jul-2006)

back back to portfolio

An intranet, like a heavyweight prizefight, can be highly unpredictable. A fighter can do everything right—run five miles a day, work on the bags from sunrise to sunset, and spar with the best trainers money can hire—but regardless of how good a shape he's in and how well he's trained, all it takes is that one jaw-breaking uppercut to catch him on the chin and he'll be sucking canvas.

The same thing can happen to an intranet. In my article Top 10 Ways to Lose Your Intranet Users, I highlighted some of the common mistakes committed by intranet owners that can affect the success of a system. But even if everything is done properly on the intranet team's side, an intranet can still get KO'd by things beyond their control. Regardless of careful planning, a strong team, and solid infrastructure, an intranet can be laid flat by that one solid haymaker. Can anything be done to prevent this from happening? Sometimes yes, sometimes no.

Understanding the potential knockout punches and seeing the hit coming before it lands can increase your chances of getting up off the mat before the end of the 10-count. The following are three deadly knockout punches that all intranet owners should not only be aware of, but also expect as a potential intranet killer:

Major Organizational Changes

As an employee of an organization you probably have little-to-no control over its future direction despite every effort by HR to convince you that you're a member of a large corporate family. Every organization will eventually undergo some huge change—whether in personnel or business direction. Business units can be sold off or eliminated, and departmental restructuring can change the very way in which the company operates. The most you can do in these situations is to hold on tight and hope for the best.

Many companies mirror their intranet content to the structure of the organization and its business—at least at a high level. When the company has a major restructuring such as shifts in core business direction or new management, its intranet will be forced to undergo a similar restructuring or risk being defunct. Way back when intranet's were in their infancy, content management systems (CMS) were little more than a static collection of HTML pages. Management of these pages involved manually moving, adding, deleting, and editing these pages. But intranets have come a long way since those early days.

System retooling isn't the chokehold it used to be when Web technologies were in their infancy and little information was available about intranet content structure methodologies. So much has been written about the subject since then that restructuring and retooling is part and parcel of an intranet's system lifecycle. Take advantage of intranet maturity—in terms of technology, information, and resources—by creating a system that's not overly dependent on external circumstances. Regardless of your company's current organizational or business structure, never count on it staying that way forever. An intranet's content structure must be flexible enough to adjust to changes—big or small. However you decide to classify and arrange your content, taxonomy should never restrict a system's ability to adapt to changes.

The simplest way to avoid being backed into a corner is to plan for the inevitable: change. A modular or database-driven intranet structure allows stakeholders to add or offload entire sections of a system in response to any external organizational changes (my articles Back to the Intranet Future: Planning for Tomorrow and Intranet Content Organization goes into this in much greater detail) with minimal impact on the production system and its users. Your ability to weather these changes will be the difference between success and failure.

Core Team Members Leave

An intranet, unlike many other IT implementations, is owned and managed by a multi-disciplinary committee rather than a single department. Every member of this intranet governing body, and their respective teams, play a vital role in the day-to-day operation of the system. And while each person in an intranet team is a valued resource, we can't allow any one single person's departure—no matter how important they are—threaten the integrity of the entire system.

In mid-1990, one of the first high-volume intranets I ever worked on, I was the sole person responsible for an entire system. Nobody else in IT knew what I was doing or even had any interest in what I was doing. Content owners were happy to have relevant content at their disposal with minimal effort on their part. But if I had decided to leave, the intranet would have been left in limbo.

It's not always easy to fill the shoes of vital team members when they leave—especially if the person, or persons, leaving doesn't have any adequate backup personnel who can take over their responsibilities. This is why it's so important for intranet team members to share valuable knowledge with their colleagues. The goal here isn't to create redundancy, but rather to have several people beside the primary person with enough knowledge to take over with minimal supervision should the primary leave (see Knowledge Sharing: The Facts and the Myths, Part 1 and Part 2 for more).

Superficial System Replacements and Upgrades

Perfectly healthy systems can sometimes be ruined when an intranet is unnecessarily toyed with—or in some extreme cases, replaced altogether. It usually starts with either IT wanting to experiment with new technologies and tools, or someone in senior management reading an advertisement or favorable review of a product in a trade magazine and thinking "Hey, we should have one of those."

Sometimes when new technology emerges, those in positions of power or influence may allow curiosity to take precedence over common sense and necessity. Time and time again, I've had to put the brakes on overly enthusiastic developers who wanted to overhaul a production intranet simply to try out new technologies and tools. But there's a difference between taking the incremental steps (over a period of time) required to keep up with new technologies and jumping in wildly with little understanding of the consequences of using bleeding edge technology (see Beware the Bleeding Edge and Feature Creep for more on this).

It's your responsibility to keep this type of blind enthusiasm in check. A production intranet should never be used as a test bed for new technology or tools because it causes too much of a disruption for users and forces them to be unwilling guinea pigs. They will eventually harbor a deep resentment for those who are causing them to have to constantly modify the way the work. There's always a price to pay in using new, untested technology in a production environment; it can cost you your user base and system at the same time.

Adopting a canned, off-the-shelf solution as a replacement for an in-house built system can also pose a potential threat. In-house built intranets are developed from scratch based on corporate specs, but off-the-shelf solutions have a pre-determined feature set and might not have the ability to accommodate very specific corporate needs. This might lead to a huge development no-no: removing previously available features. Replacing one system with another is supposed to be a step up, but if useful features in the original are no longer available in the new version users will view this as a downgrade and lose faith in the intranet.

Closing Thoughts

The success of an intranet is determined not only by how well you develop and manage a system, but also how well you can adapt to external factors influencing and affecting its eventual outcome. If you tie an intranet too tightly into current conditions or allow those who aren't involved in its day-to-day operation dictate its direction, you might find yourself in a heap of trouble. Even if one of these blows lands, being prepared to respond will greatly increase your chances of getting up with all your teeth intact.

Copyright © 2006 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.