Why Software Becomes Shelfware, and How to Avoid It

Imagine: A company invests a small fortune in a new software tool, going through the entire procurement process, onboarding and pilot rollout.

Fast forward a year, and the tool is collecting dust. The business moves on. The software becomes “shelfware” that’s barely used, representing lost time, effort and resources that few companies can afford to waste.

In our experience at The Luminous Group, this issue is rarely a software problem. Instead, it’s a leadership problem, and one that can be avoided with a little forethought and planning. 

New Research: Are Leaders and Frontline Teams Aligned?

The Real Reason Software Becomes Shelfware

Over the last few years, changes in automotive quality standards have introduced new requirements around failure mode and effects analysis (FMEA). The result has been more complex FMEA software that’s created new hurdles in terms of getting people to complete FMEAs.

Here we see a common pattern: a manufacturer brings on a new software tool thinking it’s going to fix things. But as soon as there’s pushback or performance dips, leadership walks away. They say, “See? It was never going to work.”

While on the surface this seems like a software failure, at the core it’s actually a leadership failure.

People, Process, Tools — In That Order

Leaders have to recognize real ROI doesn’t come from tools. It comes from the activities those tools enable.

Think of it this way: When you walk into a plant on Saturday, all the machines are sitting there. The raw material is there. Everything’s ready to go. But you don’t make a dime until your people show up on Monday and start using your machines, tools, and processes.

The problem is that companies focus on the tool as if it’s the solution, when in reality it’s the people who are the solution. What’s more, they think they are going to manage their people, but you can’t manage people. In our experience, you can only lead them.

That’s where the real challenge lies: learning to lead our people and manage our process.

Using People–Process–Tools to Get It Right

Time and again, leaders ignore prevailing wisdom and try to delegate leadership to a piece of software. The problem is that leading change successfully demands aligned people, a stable process, and only then the right tool.

Let’s break that down.

• Do People Understand the Why? If your team doesn’t understand why a tool is being implemented, they’re not going to buy in. But if they do understand the why—if they see the payoff—they’ll take ownership and do what it takes to make it work. 
• Is Your Process Stable? If your process isn’t optimized, software won’t save it. There’s no point in digitizing chaos.
• Tool Comes Last, Not First Aligning your people and process should come before any tech implementation.

5 Ways to Avoid the Shelfware Trap

Let’s look at five best practices that can help lay the foundation for a smoother rollout and maximum ROI.

1. Provide Active Leadership Support from Start to Finish

Leaders must recognize that rolling out new software is always a disruption. It can be positive or negative, but it inevitably shakes up the status quo. 

That’s why leadership needs to actively support the requirements process, the transition itself, the training, and the follow-up. Throughout the process, they should be actively assessing whether the results are actually faster, better, or more satisfying for users and for the business.

2. Communicate to Manage Change

A successful software implementation starts with communication as part of a larger change management strategy. Conversations should address questions such as: 

• What is the problem we’re trying to solve?
• How is the tool going to contribute to that?
• What does a successful outcome look like?
• What happens when there is a setback or problem?

You’ll also want to engage champions early in the process, including from operations (not just quality).

3. Expect Friction, and Lead Through It

Any time you ask people to change, there’s going to be resistance. You’re also likely to see a dip in productivity at the beginning while your team learns how to use the tool. 

The critical question becomes, what will leadership do when that dip happens?

If you’re asking someone to be temporarily less productive, will they get dinged on their annual review? Or do they feel safe enough to take the risk of learning something new?

People need psychological safety to adapt to change. They need to know their leaders will support them and won’t bail when things get hard.

4. Pilot Small, Prove Fast

In the beginning, you want to demonstrate what the tool can do. If you start small — think one cell on one production line — and can show results, people will buy into the change.

If you start with a list of 200 problems and can’t solve them all, people will think you lied to them.

What you want to show during the pilot is consistency and commitment to working through any problems that come up in the process. 

5. Fix the Process First

I once saw a robotic assembly line where every third part had to be reoriented by hand. Eventually the operator was just standing there fixing part so the robot could find it. It begs the question, why have the robot at all?

The lesson here is that if the process isn’t stable, don’t throw software at it. You first need to fix the process before bringing a tool on board.

In the end, leadership is the most important element of success. A leader’s role is to motivate and empower their team, creating an environment where their people can be successful.

It’s what you do to lead change, including through the rocky parts, that determines whether or not software becomes shelfware.