Go to page: 1 2 

Printer Friendly Version

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

Resources -- The amount of human resources (and their level of technical expertise) available versus the list of proposed upgrades.

Schedule -- How much time do you have to implement the upgrades? How and when you deploy upgrades is highly dependent on user expectation (described below).

Effort -- The amount of work required for development, testing, and deployment of the upgrades.

User expectations and perception -- Making a lot of upgrades at once will provide users with a more significant step up from their current system, but it will take longer to develop and deploy. And if it takes too long, users may lose interest or grow weary of hearing "It's coming soon." Taking baby steps, on the other hand, will give users new features quicker, but may cause user upgrade fatigue.

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 lose faith in a development team that continuously fails to deliver on what they promised.

Intranet Upgrade Triage Board
Listed from highest to lowest priority
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.

Paul Chin (www.paulchinonline.com) is an IT consultant and a freelance writer. Previously, Paul worked as an intranet and content management specialist in the aerospace and competitive intelligence industries.

Go to page: 1 2 

Printer Friendly Version