Printer Friendly Version

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