Intranet Upgrades: Milestones or Millstones?

By Paul Chin

Originally published in Intranet Journal (17-Nov-2006)

back back to portfolio

If you follow the news you've probably been hearing the term "cut and run" a lot. It's an expression that has come to mean a cowardly retreat. Stripping it of its negative connotation—a term originating in nautical usage meaning to cut the anchor line and run the ship downwind—the term simply means to withdraw.

To many, however, withdrawing may seem counterproductive. Perhaps, through the misguided pressures of having to succeed and advance in our careers, we've been conditioned to believe that any form of withdrawal as a sign of weakness and failure. In a corporate environment—where these pressures are compounded by the need to prove ourselves to our superiors—anything short of forging ahead seem unacceptable.

But there's a difference between persistence in achieving a goal and stubbornly going forward when there's little-to-no chance of success.

Major intranet upgrades involving multiple departments, sub-sites, and timetables requires a careful balance of accomplishing what you hope to in a given time and the user community's expectations. When you end up trying to do too much at once, upgrades can easily become a detriment to progress. Sometimes we need to take a step back in order to advance.

Interconnection of Intranet Components

There's a tremendous amount of interconnectivity within an intranet—not only in terms of technology and functionality, but also with all the developers, designers, and content owners tasked with building and managing the system. All of this interconnectivity is to make an intranet appear as one seamless whole rather than a cut-and-pasted collage of departmental sites and systems. With this interconnectivity, however, it can sometimes get a bit tricky to make a major change to one intranet component without it affecting another component in some form or another.

Upgrading is a fact of system life. But, in order to ensure that some intranet upgrades don't end up bottlenecking system progress, intranet managers need to understand the inter-dependency of deliverables and their effects on schedules—all the while staying in tune with users' expectations. Major programmatic changes need to go through the whole process of development, testing, user testing, and deployment. Attempting to tackle too much at once can delay the entire chain of planned upgrades.

A Gentle Balancing Act

The software industry is always trying to convince us that we, as consumers, must have the latest and greatest. Software vendors try to pack their products with so much that release dates are constantly pushed back—sometimes by months or years. When was the last time a major revision of Microsoft Windows was actually released on the originally announced launch date? How often can release dates be changed before users simply stop listening or lose interest?

The art of upgrading is a balancing act of several factors:

Intranet developers and content owners sometimes need to keep their enthusiasm is check—to scale back what they want to do and concentrate their efforts on what they need to do within the confines of time and available resources. Bug fixes and system patches are no-brainers. These are essential fixes hat take precedence over any functionality upgrade. They're needed to ensure the security and integrity of the system and must be addressed as soon as deficiencies are found. Non-essential upgrades need to be triaged based on the factors I mentioned above.

Intranet Upgrade Priorities

Upgrades come in many forms; they need to be prioritized properly and deployed piecemeal if necessary so that system evolution doesn't get stalled. Intranet managers must be able to triage all these upgrades and try to accommodate users' demands.

But before any promises are made, upgrades must be weighed against whether they will delay other, more important, deliverables such as bug fixes. Keep in mind, though, that you should never promise anything unless you're absolutely sure you can deliver on time. Users will loose faith in a development team that continuously fails to deliver on what they promised.

Intranet Upgrade Triage Board
Update type
(highest to lowest)
Security patches Security patches and fixes take the highest priority. They affect the overall integrity of the system and must be developed, tested, and deployed immediately to ensure continued operation.
Functional bug fixes (Essential) Fixes that affect the essential operation of the system such as program logic errors or system crashes after users perform certain actions.
Functional bug fixes (Non-essential) Fixes that don't affect the system's basic operation such as cosmetic problems or expanding form fields.
Functional upgrades Additional features that were promised to users but not included in the current production system due to time constraints, lack of expertise, or lack of technology.
WIBNI's Wouldn't It Be Nice If's. Additional features that are thought up by users during day to day operation (and not discussed at any point during system planning and development) of the system. WIBNI's must be brought to the attention of the intranet committee for consideration.

Closing Thoughts

Systems need to undergo regular upgrades to keep a loyal user base and keep up with changes in business processes. Users simply expect new things from their systems. But upgrades are usually more challenging than developing a new system because you're working within an existing framework. You don't want your changes to negatively impact other system components and push your deliverables schedule back to the point where users just get tired of hearing about phantom features. Advancing forward does us little good if we're standing on a ledge.

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