paulchinonline.com

Your Next Move: Planning Intranet Upgrades

By Paul Chin

Originally published in Intranet Journal (10-Nov-2004)

back back to portfolio


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 life cycle. 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 look after themselves. The only way to maximize the longevity of 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 life cycle. 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:


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. They 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.


Staggering Your Upgrades

While minor intranet bugs can be initiated by users via e-mail or discovered by the developers themselves and can be taken care of immediately, formal specs are required before undertaking any major system enhancements and fixes.

Requirements gathering during upgrades is no less important than requirements gathering during initial project development. Not only do formal system specs define a framework to follow, it also acts as a "stopper" when the upgrade bug strikes and blurs the line between ambition (what you would like to do) and practicality (what needs to be done).

Unless there's a serious deficiency or problem with your intranet or an immediate need for an additional feature, you should always allow a suitable amount of time to pass between major upgrades. You want to avoid releasing a whole new intranet version when the last one was only put into production three months ago. Frequent upgrades over a short period of time will disorient users, not allowing them adequate time to adjust to the last batch of changes.

It's not fair, or professional, to place the burden of technological guinea pig on the users, forcing them to have to deal with overzealous developers who want to use a production intranet as a test bed for new technology (read more on this in my article Beware the Bleeding Edge and Feature Creep).

It's also important that your upgrade requirements are actually... required. It must be a justified decision based on necessity rather than for the sake of busy work or to test new technology. Although developers may think a certain set of upgrades is necessary, the users may not—and they're the ones who rely on the system most. So users should always play a large role in determining the direction of the intranet and its future upgrades (an upcoming article will discuss the role the user community plays on system upgrades and how to use surveys and user feedback as a tool for requirements gathering).


Defining a Migration Path

Implementing major upgrades is often trickier than initial system implementation. When designing a new system, you're working in a completely controlled environment with a clean slate; when you're implementing a major upgrade, you need to work within the confines of a live system and live data. It's the difference between laying out a brand new stretch of highway and performing road repairs on an existing one—angry motorists and all.

A pre-defined migration path—the stages a set of upgrades must pass through before reaching company wide usage—is essential in ensuring that proposed changes will not have negative impacts on the integrity of the production system, creating even more problems than there were before the upgrades.

While a migration path will depend highly on the size and complexity of your intranet as well as the scale of the proposed upgrades, most follow this general path:

Stage 1: Development
Requirements are gathered, upgrade specs are defined, and development takes place in an controlled environment separate from production with the use of test data.

Stage 2: Developer Testing
After completion of the proposed enhancements and fixes, all upgrades are tested by the developers in a controlled environment with test data.

Stage 3: User Testing & Quality Assurance
Once the developers finish their tests and iron out the bugs, the upgrades are made available to a small control group of users—content owners and those who requested the upgrade—in a controlled environment with test data. During this stage users can approve the upgrades or send them back to development for additional changes and tweaks.

Stage 4: Production
If all the proposed upgrade requirements are met and signed off on by the user test group, developers will release the upgrades into the production environment with live data. This is often done during off-peak hours to minimize disruption on the user community.


Final Thoughts

Applying patches to fix problems and implementing feature enhancements go a long way toward increasing the overall lifespan of your intranet. But make sure that you know what needs to be done, how much of it, and when; otherwise, you may find yourself installing a surround sound home theater system while completely ignoring the rising floodwater in the basement.


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