Printer Friendly Version

Whenever you've owned a piece of technology — computer, software package, cell phone, PDA — for any considerable length of time, you'll inevitably be attacked by the upgrade bug. It's the condition that urges you to cast your outdated wares into a volcano in a sacrificial ceremony in favor of the one rotating slowly under a spotlight.

And this bug isn't limited to the world of technology either. It strikes when you decide to turn your basement into a workshop topped with power tools you know you'll never use beyond building a lopsided birdhouse; when you custom fit your car with a roll cage, off-road suspension, and knobby mountain tires but live in hundreds of miles of prairie grassland; and when you add a $4,000 power amp to your stereo because you insist that the full range of the Beatles' White Album can't be fully appreciated without it.

But before investing time and money in all manner of retrofits and upgrades, you must determine whether you're doing it because of a real need for improvement or whether you've simply fallen prey to rampant consumerism fueled by an unwavering onslaught of marketing glitz.

An intranet, because it's so scalable, can too easily become a victim of this type of chronic upgrading. Special care must be taken to prevent a svelte and efficient intranet from mutating into a lumbering and bloated monster that trips over its own stubby feet. However, intranets do need to evolve in order to survive; the trick is to separate those upgrades that are truly warranted from those that are merely superficial trinkets.

Reasons for Upgrading

Every IT implementation has a system lifecycle. Some have a very short lifespan, perhaps put into place temporarily to meet the requirements of a specific project or in preparation of a special event, and then discarded once it has served its purpose. Other systems are in it for the long haul with an indeterminate lifespan, lasting for as long as it remains relevant and given the proper TLC from its owners.

Intranets usually fall into the latter category; but they never looks after themselves. The only way to maximize the longevity on your intranet implementation is to ensure that it evolves and grows to meet the demands and constant changes in business and business processes. Failing to do so may force users to butt heads with an obsolete system in order to gain access to current and valuable information — this is a combination that doesn't play out well for most IT users.

As important as it is to maintain fresh and relevant information, you also need to make sure that your intranet — the mechanism that serves up this information — reflects the quality of the content it houses. To do this, you need to be in tune with the needs of the user community and the new trends in technology. Something that seemed trivial during the initial stages of requirements gathering may turn out to be a necessity after several months of real-world usage. Or perhaps, new technology arises that enables you to add functionality you deemed undoable in previous versions.

Upgrading your intranet is a crucial part of its lifecycle. Your system should never be allowed to become stagnant, forever stuck in a version 1. But intranet upgrades come in all shapes and sizes, ranging from minor cosmetic tweaks to new version releases.

While intranets are upgraded for all sorts of reasons, most result from:

• Known deficiencies or bugs in the current version

• Features that couldn't be implemented in earlier versions (due to time constrictions, lack of human and/or technological resources)

• Input and feedback from the user community

• Changes in business processes

• Implementation of additional functionality

How Much, and When?

Intranets, like all IT implementations, rarely remain static. They change over time to meet new requirements and fluctuations in business environments. Improvements are made to early incarnations of the system and patches are applied when problems are discovered.

Knowing how much to change and when to implement these changes is vital in keeping your user community's faith in the system. If it changes too frequently, users will grow weary and frustrated with having to constantly adjust to the changes. However, if it remains static over a long period of time with no visible improvements or new functionality, they will become tired and bored with the same thing day after day.

But not all intranet upgrades are created equal; they vary in size, scale, and importance. The timing of your upgrades will depend on which of the two classifications they fall into: bug fixes or system enhancements.

Although most system bugs will be caught by programmers during the development and testing phases of a project, some may still be discovered in production during day-to-day usage — but this is normal. As good a tester as your developers may be, it's extremely difficult to foresee the permutations of every usage situation, hardware and software configuration, and user interaction with the system. Patches and bug fixes are a fact of software development life and help to maintain the overall integrity of your intranet. These type of modifications must be addressed as soon as possible and taken care of in order of severity.

System upgrades, on the other hand, are wide-ranging and may consist of everything from adding new features to a full cosmetic overhaul. Intranets must be upgraded occasionally to remain relevant, to reflect process and environmental changes, and to provide users with functional improvements as newer technologies are discovered. While patches are implemented to fix some type of deficiency in an intranet, system upgrades and enhancements go primarily toward user experience and satisfaction.

It should be noted that critical bug fixes and patches always take precedence over non-essential feature enhancements and must be released into the production environment as soon as they have been tested since they affect the stability and reliability of the intranet and its content.

The timing for the release of major upgrades and non-essential patches — those that don't impact the overall usability and integrity of the system — require a little more planning.

First, you need to be sure that what you're adding has value to the user community (as opposed to trivial bells-and-whistles) and won't impact the schedule of other, more important deliverables. Secondly, you need to determine whether you're going to release your upgrades as a single accumulation of fixes and enhancements, or whether you're going to release them piecemeal, as they become available.

Although an accumulation of upgrades may be looked upon by users as a more substantial jump from the previous version, smaller piecemeal upgrades can minimize the impact on the user community. Deliverables will also have shorter turnaround times since individual changes are not dependent on the readiness of other upgrades.

Some upgrades, such as changing the entire graphical look-and-feel of your intranet, can only be released as a single collective rollout. Otherwise you'll be dealing with an intranet design where some sections are new while others — those that have yet to be changed — still reflect the old design.