• Business Intelligence
• Collaboration
• Compliance
• Enterprise content management
• Enterprise Search
• Enterprise Portal
• Information lifecycle management
• Intranet
• Outsourcing
• IT Security
• News

Feature

posted 17 Jan 2006 in Volume 2 Issue 7

The intranet post-mortem

Part I

Don’t you hate it when someone smirks and says, “You should’ve ducked,” after you just got nailed on the head by a football? There’s always a list of things you should have done once they have already happened – after all, hindsight is 20/20.

While it’s impossible to foresee every outcome in every situation, we need to be able to at least predict possible outcomes and have contingency plans for when things don’t quite turn out the way we planned. A failed intranet, however, will result in much more than a simple bump on the noggin (although that’s certainly a possibility, and often self-inflicted). It will damage not only the credibility of the intranet team, but will also cause the user community to lose faith in its ability to deliver on a promised solution. It will also make it much more difficult to get personal and financial support for future projects from members of senior management.

Before we can determine how to rebuild or resurrect an ailing intranet we need to understand what caused it to fail in the first place. In this first workshop of a four-part series on intranet post-mortems, I’ll be discussing some of the main contributing factors to intranet failure.

Causes of intranet failure
It just doesn’t seem fair that the margin for failure is so much wider than the margin for success, but such is life. It’s much easier to miss a target than to score a bull’s eye. The key is to understand why it failed, what can be done to fix the problem, and to prevent it from happening again.

Unfortunately, we can’t pinpoint intranet failure to a single cause because of all the variables involved: organisational environment; team and workgroup dynamics; specific project requirements; rapidly changing business processes; corporate culture and politics, and even single individuals. Minor stumbling blocks that seem benign on their own can accumulate and bring an intranet to a standstill.

There is, however, a difference between intranet failure and intranet death. A failure is highly subjective; one person’s success can be another’s failure. It can encompass a wide range of situations from an intranet that deviates too far from original project specification to an overrun budget or missed milestones. Intranet death, on the other hand, is complete project cancellation – end of story. There’s no discussion about how to rebuild or correct past failings. The system, in whatever state it’s in, is abandoned outright.

The list of causes for intranet failure or death is a long one and can occur at various stages of a system’s lifecycle. The most common are listed below:

Unclear project scope
One of the leading causes of pre-production intranet failure is a project goal that is either poorly defined or constantly changing. Project scope helps define milestones and a finish line where an intranet ultimately reaches the production environment. But if this finish line is constantly in motion, or if the intranet team itself doesn’t even know where it is, how will anything ever get done?

Two of the most common afflictions to hit project scope are:

Defining an over-ambitious scope
As with any type of development, there’s always a compromise between what you would like to do and what you are able to do. Factors such as limited financial and human resources, tight deadlines or lack of expertise can severely affect what intranet teams are able to deliver.

Problems will arise when, despite these limitations, intranet teams set goals that far exceed their ability to carry them out in a timely manner. This is when they go into survival mode. Rather than thinking through what needs to be done, they are running for dear life and trying to push ahead with the project simply to have something to show for all the time, money and effort that was already invested. This often leads to a dodgy system that was rushed into production (that’s if it actually makes it into production) in order to meet a deadline the team never had a chance of making to begin with.

It’s crucial to set feasible goals, limiting intranet specifications to core functionality while allowing room for future expansion. This is the lesson all intranet developers need to learn: there is a future. An intranet doesn’t stop growing once it hits the production environment. New features and functionality can be added to the system in subsequent versions. It’s never advisable to try pushing everything through in a single release. This will put a strain on both schedules and personnel.

Feature creep
Feature creep is a close relative to setting an over-ambitious project scope. It occurs when an intranet’s scope is broadened beyond what was originally planned for in initial project specs. Additional features are often added on an ad hoc basis when users initiate the infamous ‘WIBNI’ (wouldn’t it be nice if…) and amass a growing wish list of system features. Developers also contribute to feature creep when they see an opportunity to “improve” upon the system or test bleeding edge technologies.

Falling prey to feature creep can cause missed milestones, an ever-expanding production deadline, and unnecessary system complications and bugs (since all WIBNIs are done on-the-fly rather than carefully planned out).

Avoiding feature creep is just a matter of discipline – knowing when to say “no”, or at least, “not yet”. As with setting an over-ambitious scope, intranet teams and users need to understand that new, non-critical features can always be added in later versions without adversely affecting pre-planned deliverables.

No development methodology
A development methodology is an intranet roadmap from conception to deployment. Since an intranet involves so many multi-disciplinary personnel, it’s easy to become overwhelmed by the scale of what needs to be done.

A development methodology allows developers and content owners to take structured steps rather than attempt to do everything at once. Without a methodology, intranet teams will be forced to make too many on-the-fly decisions based on gut, or emotional, reactions rather than analysis. This will ultimately affect the longevity of the intranet, resulting in a system that lacks focus and seems disjointed.

Although every intranet is different and will require a tailored methodology to suit the project type and teams involved, they should all have three core phases: planning, development, and deployment.

Poor user input
Intranets, more so than many other IT implementations, are community-driven. This means that the health, longevity, and success of an intranet are highly dependent on the involvement, feedback and satisfaction of those who use it. Nowhere is this community’s involvement more important than during the requirements-gathering stage, whether during initial development or during system upgrade stages.

Even though initial development will be carried out mostly by IT, content owners and users still have a very important role to play: to help define an intranet’s basic foundation and feature set. The lack of user-side input will leave too many things open to interpretation. IT will end up delivering its own view of what users want, rather than what they truly need.

Lack of user acceptance
On paper, an intranet could be the most technologically advanced system to date, putting others to shame. But if no one bothers to use it, all its technological success and innovation becomes a moot point.

The success of an intranet is measured by the acceptance and satisfaction of the user community, never by the technology used to build it. Technology is a mere facilitator, a means to an end. In this respect, an adequate, widely-used intranet can be considered more successful than a technologically advanced intranet that’s never used.

If intranet teams neglect user awareness and usage monitoring during post-production, systems can slip away without them even realising it. User awareness can be created through marketing, promotion and training; and intranet usage and user satisfaction can be monitored with a combination of web-analytics software and user surveys.

However, never rely on the results gathered during the first few weeks after an intranet hits the production environment. This is not an accurate indication of intranet usage. There will always be a spike in system usage because of the novelty factor. The majority of an organisation’s user community will flock to the system to see what it’s all about, but will trail off as time goes by. The goal here is to turn casual visitors into regular users.

Poor content quality and organisation
Content is the lifeblood of an intranet. Regardless of the technological bells-and-whistles, it all boils down to fulfilling the need for information. Although the medium carrying this information has changed over time, the need remains at the forefront of all businesses and industries. With this in mind, it’s not surprising that poor content leads to intranet failure or death.

Intranets are developed to consolidate information into a centralised environment so that users don’t have to search through multiple disparate sources. Users need to be able to find what they are looking for quickly and without a lot of effort. But if the intranet ends up being the digital equivalent of a junk drawer – forcing users to sift through mounds of irrelevant content for that one piece of useful information – it defeats the whole purpose of the system. Common content ailments include:

• Irrelevant content;
• Duplicate content (either identical documents or the same message conveyed by different sources/authors);
• Conflicting content where facts differ from one source/author to another;
• Unclear or poorly written documents;
• Unintuitive content organisation and taxonomies (which leads to a poor site navigational structure).

Steep learning curve
Most users understand that there is a learning curve with the introduction of any new system, but not all users are created equal. Some are more technically inclined than others, and some won’t have the patience or inclination to get over this learning curve. And once these users are lost, it will be very tough to win them back.

Getting over the initial learning curve is an intranet acceptance deal-breaker. It’s the do-or-die moment when users decide whether to go on or abandon the system. If the learning curve is too steep and the intranet is too difficult to use, the system becomes a liability. The key is to design an intranet that’s simple enough to use without compromising the system’s intended functionality. It must conform to the natural ways in which humans work regardless of their technical abilities.

Lack of managerial support
Intranets are corporate solutions requiring the long-term participation and commitment of multiple departments and personnel. With a system such as this, support must come from senior-level managers of all departments actively involved in intranet development and management.

Managerial support lends credibility to an intranet. It’s what separates an officially sanctioned corporate system from what may be perceived as some niche group’s own personal pet project. Without an official mandate from senior management it will be next to impossible to recruit personnel to participate, because of their pre-existing commitments. Potential recruits have their own priorities and roles to play within their department. And any effort put into an unsanctioned intranet will be minimal at best, unless they are officially assigned to work on it by their immediate supervisors.

Negative corporate culture
In order to succeed, an intranet involves the cooperation and coordination of multiple departments and personnel, both during development and on-going management. But what if the organisation’s overall culture lacks the sense of community and knowledge sharing that is required for an intranet to thrive?

We always try to encourage and promote a team atmosphere in the workplace, but there are some corporate cultures that are dominated by a clock-in/clock-out attitude, are openly resistant to change, or simply won’t share information with others. Intranets can’t survive in these types of environments. When employees start to hoard information – whether for job security, personal gain or because of internal rivalries – an intranet’s growth will be stunted, if not ceased altogether.

Don’t lose your cool
Through experience we know that things don’t always work out perfectly. Whatever the cause, we must not allow promising systems to fall prey to preventable problems. But if they do, resist the urge to play the blame game. This will only lead to infighting and resentment. Instead, review what happened and try to narrow down the cause, or causes, for failure.

Having a good understanding of why an intranet went sour is crucial to ensuring that the same thing doesn’t happen again should attempts be made to resurrect or rebuild the system. The last thing you want is to be lying on the ground with a huge welt on your head, staring up at the sky in a daze and wondering, “What just happened?”

In the next part of this series, I’ll be looking into what should be done once an intranet comes to the end of its life: retrofit the existing system or rebuild from scratch?

Paul Chin is an IT consultant and freelance writer. Previously, Paul worked as an intranet specialist in the aerospace and competitive intelligence industries. He can be contacted at post@paulchinonline.com