Many people are shocked by the statistic that Americans waste 30% to 40% of food produced in the US every year. What is less well known, but also shocking, is that the same amount of waste exists in the software industry. Here estimates range from 20% to 45% depending on the sector and type of software being considered. Regardless of the actual numbers, it is clear the problem is rampant. So rampant in fact that this wasted software has been giving its own name: Shelfware.

Despite the pervasiveness of shelfware and constantly shrinking budgets in both the private and public sectors, software waste is still often regarded as the elephant in the room. It’s seldom discussed much less addressed.

With over 20 years of experience in the industry, I’ve seen many software implementations go incredibly well and achieve the desired results of saving time, increasing accuracy, and/or decreasing external dependencies. Unfortunately, I’ve seen at least as many go poorly and end up producing nothing but frustration and disappointment.

In order to better serve our customers, I’ve spent a lot of time researching, reading, and reflecting on the shelfware phenomenon. What I discovered was that all the successful projects have three things in common. 

1. They clearly defined the problem.

2. They competently selected the correct solution

3. They consistently set accurate expectations for the project.

This blog series will explore each of these in more detail. In this post, I want to briefly introduce the concepts and explore how they affect the overall success of a solution.

Accurately Defining The Problem
While this may seem like an obvious step, trust me it’s not. In fact, I can say without any hesitation that failing to accurately define the problem is the most common reason projects fail. Ironically, it is the supposed simplicity of this step that causes us to skip it! We either don’t consider it at all, or we jump immediately to a shallow, overly simplistic, or just plain inaccurate problem. The most common of these artificial problems I have seen is the need to “go paperless.” What’s so terrible about paper? Oh and BTW, since everyone decided their agency needed to go paperless, the paper industry has experienced a dramatic increase in production, so whatever the reason we are trying to rid ourselves of paper, it isn’t working.

Selecting the Correct Solution
Selecting the incorrect solution is often a direct result of failing to define the problem. However, I’ve also seen many situations where a customer has accurately defined the problem(s), and still failed to select the correct solution. After decades building technical solutions, I can tell you this: not all problems call for a technical solution. Shelfware can result from buying software when what you really needed was a better process, stronger relationships, or some other people-related solution. For example, if your accurately-defined problem is lack of communication or poor teamwork, you might not need new tech. Anyone who has built a successful department knows that disciplines such as communication and teamwork have more to do with leadership and culture than they have to do with databases and websites. It pays to decide what you really need before you buy it.

Setting Appropriate Expectations
The final—and in my experience the most frustrating—reason projects fail is that leaders set inaccurate expectations (or failed to set expectations at all). Projects that seemed to be going so well met an unfortunate demise when users complained that the system did not save them any time. But all along the goal (which apparently leaders knew and users didn’t) was to increase accuracy and data integrity! No matter how much the leaders tried after the fact to reassure the users that the system was doing exactly what it was intended to do, it was too late. In an absence of well-communicated expectations, the users created their own. And when the system didn’t meet those expectations, the users did use it, and the system died a slow agonizing death. Changing expectations once a system is in place is almost impossible, so you have to set accurate expectations at the beginning.

Over the coming weeks, I will explore each of these areas in greater depth, providing specific examples to demonstrate the point. If you can’t wait for the next post because you’re in the middle of product discovery for a new system right now, I’ve got one simple suggestion. Ask your team, “Why are we doing this? What precise problem are we trying to solve?” You may get dirty looks or you may be met with genuine concern and curiosity. Either way, you can rest assured you are doing your part to steward a successful system integration.