Go to page: 1 2  Printer Friendly Version

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.

More From Jupitermedia

Intranet Journal Announces 2008 Product of the Year Winners 10 Open Source Apps for Enterprise Users Why Ubuntu Linux Tops Debian IDM Dreamweaver Tutorial Creating a PHP-Based Content Management System Top Intranet Trends: Usability, Access, Personalization The 2008 IT Salary Guide If you want to comment on these or any other articles you see on Intranet Journal, we'd like to hear from you in our IT Management Forum. Thanks for reading. - Tom Dunlap, Managing Editor. FREE IT Management Newsletters bITa Planet CIO Update Intranet Journal Update Datamation IT Management Careers Datamation IT Management Update Grid Computing Planet HTML E-Security Planet HTML DRM Watch HTML

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

Intranet standards must be formally established and written, not set up on the fly with a series of casual e-mails; Any group wishing to join the intranet must understand and uphold the established standards; Make use of communal resources such as a universal search engine to avoid duplication; Use templates and/or style sheets to maintain overall look and feel and system brand; Limit access and to the internal workings of the system by providing intranet content managers with a front end content management tool; Administrator rights should only be granted to the technical team.

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.

Go to page: 1 2  Printer Friendly Version