If there is an underutilized software package in your organization, and if you’re listening, you’ll likely hear a complaint or two about it. These complaints are symptoms that, if undiagnosed, will fuel negativity and friction.
Let’s consider the lifecycle of a typical software package:
A piece of software is implemented with the expectation that it will boost productivity, reduce inventory, provide a competitive advantage, or foster other strategic benefits. These hopes sadly fade under the pressure of the implementation effort. After some struggle, the software is stabilized and more or less adopted. Then it goes into hibernation. The organization shifts its focus to new investments.
Over time, some internal users find ways to use the programs’ features. Some find ways around it. Eventually the software asset becomes a part of daily life, but the general consensus is that the investment was worthless. Calls for replacing the software grow in volume. But the cost of such a bold move is hard to justify.
(Generally, at this point, I feel sorry for the software. It isn’t intrinsically bad. It’s probably underappreciated!)
The more complex, ambitious, or expensive a failing software package, the greater the chance it is simply underutilized. The software itself is usually not at fault. Organizations can often boost ROA from the software in a few months without spending a fortune.
First, gather the issues from the people who experience them. The more comprehensive the list of complaints, the easier it will be to prioritize corrective actions.
You will hear 4 types of complaints—some more actionable than others:
Most of the complaints about software are nonsense. They are actually excuses for why people aren’t doing their jobs. People will say data is unreliable, functions don’t work, information goes missing, and more. Of course, in some cases these claims are legitimate. But usually, after some research, we find there is no ground for the complaint.
Don’t ignore the noise. In fact, it is very satisfying to ask more questions and learn that an issue is just a matter of perception. After a thorough interview, complainers often back down from their initial positions.
Some complaints will reveal quick fixes that will make a huge difference.
Quick fixes may have little to do with the software itself. For example, a security configuration is causing significant delays and overhead to complete a particular transaction. A small internal policy change would relieve serious pain.
Address the low-hanging fruit, but also make sure there is an ongoing process for constructive folks to propose new ideas to management, i.e. a continuous improvement process. This will enable the organization to implement quick fixes consistently (and perhaps avoid implementing ineffective processes in the first place).
A thorough research effort will turn up real gems—actual opportunities to get significant value from an underutilized piece of software.
Typically, approximately 10% of complaints fall into this category. Some opportunities will cost real money to implement, but they will make a substantial difference, extracting hidden value from an asset you already own.
About 20% of suggestions you’ll hear are ideas that yield little or no benefit. Some are marginal improvements that require unjustified effort to achieve. Others may bring an improvement in one area, but cause issues downstream.
People easily overlook deficiencies of their own suggestions because not everyone is a software implementation expert. Communicating the reasons why some complaints are deemed off base is a great way to promote more constructive input.
Although only two types reveal issues worth pursuing, all complaints are worth documenting and sorting into the above categories. With reasonable effort you will be able to quiet the noise, pick the low hanging fruit, expand the vision of wishful thinkers, and leverage real opportunities for improved outcomes from your underutilized digital asset.