Skip Navigation
Technology at Your Fingertips
Chapter 1: Knowing What to Do

Chapter 2: Knowing What You Need

Chapter 3: Knowing What You Have

Chapter 4: Knowing What to Get

Chapter 5: Knowing How to Implement Your Solution

Chapter 6: Knowing How to Train Users

Chapter 7: Knowing How to Support and Maintain Your Technology Solution

What Provisions Should Be Made for Ongoing Oversight?

How Do You Plan for Providing Ongoing User Support?

How Should You Monitor Regular Usage of Your System?

What Kind of Ongoing Technology Maintenance Will Be Needed?

How Do You Monitor Your System's Users' Needs?

What Do You Need to Do About Upgrades to Software?

What Do You Do About Replacement and Redeployment of Equipment?

Should You Accept Donations?

When Should You Use Volunteers?

How Do You Find Qualified Help When You Need It?

Is That All There Is To It?
Chapter 7: Knowing How to Support and Maintain Your Technology Solution

Decisions about upgrading software should depend upon the goals and plans of the organization and the risks of getting too close to the "bleeding edge" of technology.

What do you need to do about upgrades to software?
When dealing with commercial software packages, the vendor typically offers a stream of new releases of their product on a semi-regular cycle. As previously mentioned, new releases are more recent versions of a software application that the developer has published, either to enhance features and functions or to correct problems in an earlier release.

If your organization has been keeping up its maintenance payments, it has the right to upgrade to new releases when they become available. However, this does not necessarily mean that you must, or that you should, upgrade to new releases. Weighing whether it is worthwhile can be a tricky process that requires considering several factors. One thing to keep in mind is that upgrades should be assessed in relation to the organization's system architecture, network architecture, and other relevant guidelines. An upgrade should be consistent with established standards and contribute to progress toward the overall vision for technology.

If an upgrade does pass the first test in that it meets established standards, you still need to approach upgrades to a new release of a software application with caution. Too often, the definition of an upgrade is: take old bugs out, put new ones in. New releases are often distributed before all the problems are resolved. When that is the case, those using a new release become participants in the debugging process.

Another consideration to take into account is whether the new release of application software requires changes to other elements in your organization's technology environment, such as the operating system, hardware, or network software. Also, if major changes are included, the new release may be published as a new "version" or edition, which may require a purchase beyond your organization's current maintenance payments.

Some organizations adopt a philosophy that they will never be the first to install a new version of a software application. Others tend to stay one release behind the "leading (or bleeding) edge" to avoid the risks. Generally, such rules lower risk but may delay the benefits of a useful upgrade.

To decide whether or not to upgrade, you and your Technology Oversight Committee need to evaluate whether the changes in the software provide benefits beyond the potential risks. Benefits should be assessed based on:

  • Impact on user productivity.
  • Ongoing costs/savings.
  • Addition of useful functions.
  • Addition of recent content.
Risks and costs should be based on:
  • Costs for potential temporary loss of productivity.
  • Costs for retraining.
  • New hardware, operating systems, or networks required by the upgrades.

<< back    >> next

Top of Page