paulchinonline.com

Keep Your Intranet Off Life Support, Part 2

By Paul Chin

Originally published in Intranet Journal (31-Mar-2008)

back back to portfolio


Last month, I identified some symptoms that can eventually lead to system-threatening ailments including a steady decline in usage, a loss of support from team members, and content atrophy. Here, I continue the discussion by exploring three more ailments that, if not treated properly, can potentially put your intranet on life support.


Ailment: Fractured intranet standards

Intranet test: Perform regular intranet audits and reviews.

Symptoms: Your intranet is becoming host to a motley crew of technologies and tools that don't conform to the standards established by the intranet governing committee.

Intranet section leaders discover new technologies and use the production system for R&D purposes, or they download ready-to-use widgets that can be easily installed with minimal technical expertise. While most of these cases are often benign and can be fixed relatively easily, there are some rare cases where intranet section leaders try to hijack the system for their own personal interests by intentionally breaking standards.

Rx: Intranet standards are what separate a true intranet from a loosely connected assortment of internal department websites. Intranet stakeholders go through great pains to establish these standards in order to create a unified system—for the sake of appearance, development, and manageability. But when intranet section leaders consciously or unconsciously undermine these standards by using or installing non-standard technologies or tools, an intranet can quickly become fractured.

Although all members of the intranet governing committee should have a say when it comes to establishing system standards, intranet section leaders should be primarily concerned with the management of their content and defining their business processes. Anything that affects intranet standards or the functionality of the system as a whole must be brought up with the entire intranet governing committee. And anything dealing with development technologies and tools, security measures, and network infrastructure must be discussed with the intranet's technical teams. Nothing should ever be decided unilaterally by any one group.

The governing committee should take the following steps to minimize the possibilities of a fracturing an intranet:


Ailment: Infection by unsanctioned content and applications

Intranet test: Conduct occasional intranet surveys to gauge user satisfaction. Hold regular meetings with all intranet section leaders to find out if users' needs have changed or if they have any major complaints about the system. Symptoms: Content that should be on your intranet is starting to appear in other formats or systems completely outside the intranet; or worse, unsanctioned applications created by non-IT developers are appearing on departmental servers.

Causative factors: There are many causes for this: Your intranet isn't meeting users' needs so they wind up looking elsewhere; there's a lack of response from the official intranet team regarding previously requested features or system fixes; highly technical, non-IT personnel who don't want to bother with IT or don't agree with established standards build their own solutions for their users.

Rx: Most users will use whatever works. They're not concerned with standards or infrastructure issues—they just want to get their job done. As intranet owners it's your responsibility to make sure the intranet meets users' needs. If it doesn't, don't be surprised when they look elsewhere for a solution, or even build their own.

Renegade development and unsanctioned applications can be very dangerous to an official intranet because they have the potential to create duplicate or incomplete content. Some users will work within the intranet and others will work with various alternative applications. There's also another threat.

Unsanctioned applications built by departmental developers outside IT's knowledge almost always end up orphaned when its creator leaves the company, gets transferred to another department or group, or gets involved in other projects. IT will then be forced to adopt a system they had nothing to do with. This will undermine the efforts of other intranet teams and the system itself. It can also create friction and animosity between IT and content owners.

The best way to curb this is to be responsive to users' needs in as timely a manner as possible—don't brush them off. It's unrealistic to expect users to wait months for system deficiencies to be fixed. There's only so many times they can hear the words "we're working on it" before they stop believing you and take matters into their own hands.

And if you do notice the early stages of renegade development, try to get those non-IT developers involved in the intranet process. Don't get territorial and simply forbid them from coming up with a solution for their users. This can have the opposite effect. Instead have IT work with them on integrating the application with the intranet.

Last month, I identified some symptoms that can eventually lead to system-threatening ailments including a steady decline in usage, a loss of support from team members, and content atrophy. Here, I continue the discussion by exploring three more ailments that, if not treated properly, can potentially put your intranet on life support.


Ailment: Technology or tools become obsolete

Intranet test: Review your intranet TO-DO and future features list and see whether your current technology backbone is limiting your ability to update your system.

Symptoms: You're finding it more and more difficult to implement new features with old technologies and tools—in some cases it might even be impossible.

Causative factors: "If it ain't broken, don't fix it." This is the mentality taken by everyone from management to intranet section leaders. But sticking with obsolete technologies and tools will eventually render the intranet obsolete as well.

Rx: Updating an intranet to reflect changes in organizational structure or business processes is a no-brainer. But deciding on upgrades to your intranet's technology backbone is a bit trickier—even a gamble at times.

While it's dangerous to blindly accept bleeding edge technology, failure to adapt to new technological standards and tools can shorten your intranet's lifespan. Systems based on old technology or obsolete proprietary tools can make it increasingly difficult to manage your intranet, implement new features, and find suitable personnel to support the system.

You should stay apprised of all the new technologies and tools in the industry, and trust enough in your IT staff to make the right call. They will know how to separate new technology standards from here today gone tomorrow fads. Although your intranet may not be broken, updating its obsolete technology backbone can greatly increase its life and give you the ability to implement features that might not have been possible in the past.


Time For Your Checkup

No matter how well your intranet is doing right now, it doesn't mean there's nothing you can do to make it better. Allowing something to operate for any length of time without an occasional checkup would be inviting disaster. The key to long intranet life lies not only in your ability to fix problems, but also in your ability to keep them from happening in the first place. Prevention, after all, is the best medicine.


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