When you do and don't want Shelfware

No matter the size of your organization, you can be sure you have old software sitting on a shelf somewhere. Robert Bogue talks about how to reduce the shelfware in your company.

Every organization has "shelfware" (software that has been put on a shelf). Whether an organization has 100,000 people or only one person, you can be sure there's software sitting on a shelf somewhere in the building. In some ways, shelfware is like cholesterol. There's a good kind of shelfware and a bad kind of shelfware. The trick is to increase the good shelfware and reduce the bad shelfware.

How does shelfware become shelfware?

There are actually a few different kinds of shelfware, some shelfware was never used or never returned the value that was intended. Other shelfware was retired to its position only after it had performed its service and was no longer needed.

Tips in your inbox
TechRepublic's free Strategies that Scale newsletter, delivered on Tuesday, covers topics such as how to structure purchasing, when to outsource, negotiating software licensing or SLAs, and budgeting for growth.
Automatically sign up today!

For example, I once licensed a program called LinkBot Pro from Watchfire that validates web references. This tool was invaluable in helping me validate links in older versions of Que Publishing's Official Internet Yellow Pages. I bought the license, used it for the project, and then it became shelfware. This is a good form of shelfware --software that more than provids its value and is then peacefully put out to pasture.

On the other hand, I once purchased a copy of The Macromedia Flash MX with the idea that I would use it to create a kind of personal multi-media marketing message which showed writing samples, a resume, and snapshots of projects. While this was a great idea and I spent tons of time learning Flash and starting the development of the idea, ultimately the software landed on the shelf because I couldn't make it do what I wanted it to do in the time that I had to invest. (In Macromedia's defense, it probably had a lot more to do with me than it did the product.)

Creating the good shelfware

The purchase price of software should be measured against the value it can return, as in how much money it can make the organization (as my experience with LinkBotPro) or how much time it can save. If you measure it against the length of time that you'll be using it you may not be creating enough good shelfware in your organization.

Limiting bad shelfware

Bad shelfware is software that didn't return the value of its cost before being placed on a shelf. This could be the fault of the software, the organization, or the individual. Bad shelfware drains the organization of cash and drains IT of both time and money resources resources that it needs to help move the organization forward. It also seems to accumulate at a great speed. Here are some ways that you can reduce the occurrences of bad shelfware.

Use trials

Sometimes low barriers to purchasing software can be a bad thing. If the barriers to purchasing software are too low, it may not seem reasonable to install and test a trial version of the software. Instead you just purchase it and, if it doesn't work, it becomes shelfware.

Learni to use trials to verify that a feature or aspect of a program works. It can be an important step in eliminating shelfware.

When you can't use trials, use a return policy

Some software doesn't have a trial version, or the trial version is so severely crippled that it's not possible to use it to properly evaluate whether the software will do what you need. That's when you should purchase with a plan for returning the software if it doesn't work out.

This means keeping a close eye on all of the documentation needed to return the software in the event that it doesn't work. This might be the original order number, the invoice number, or other information from the time of purchase.

Consider a performance-based contract

A performance-based contract generally requires a larger software purchase and requires that the software work in your organization or you don't pay for it. Performance based contracts are more prevalent in larger software purchases and can be used to reduce the chances that your new implementation will be a bad experience.