- Software selection is traditionally controlled by software vendors, which removes the reality of implementations.
- The best outcomes are obtained from software selection if reality is brought in as frequently as possible.
I have explained how software development and software vendors tend to work in order to help those who perform a software selection to account for these factors and to make better decisions. The first thing that should be recognized is that the buyer will not implement all the functionality or get all of the functionality that they desire to work. A major strategy of vendors is to anticipate every need that a company could have by placing a very complete set of functionality in their applications. However, as this type of software tends to be difficult to implement, companies greatly overestimate their ability to implement the functionality.
Incorrect Assumptions of Software Selection
Software selections are often performed with the incorrect assumption that the buyer will place more resources on the implementation and maintenance of the implementation than they actually are willing to place. To use an example from my implementation experience, when companies select statistical forecasting applications they often are attracted to the functionality of complicated forecasting methodologies (mathematics that drive the forecast). They have much less interest in hiring and paying people with forecasting education and experience to actually run the applications. Some things can be done to simplify forecasting for individuals; however, they should be able to understand what the application is doing. Many forecasting applications have thirty different forecasting methodologies, yet at company after company I see only a few of these methodologies used. There is a way of automatically choosing among the different forecasting methodologies, and even though most companies cannot get this functionality to work, there are vendors for which this type of selection is automatic.
Secondly, there are many more practical areas of the forecasting applications that are just as important to the success of a statistical forecasting application, yet these areas are not emphasized during the software selection. One can’t know what these areas are unless one was to implement and use the software oneself. This is a clear example—and just one of many examples—of how the buyer does not focus on what really matters in an implementation.
Making Realism a Priority!
In the US during the past forty years, the bicycle has been transformed from a practical machine for transportation into a far less practical item that offers more ego-driven functionality (lower weight, aggressive styling, high turnover in design) and less practical functionality (ride-ability, safety, cargo capacity). The bicycle is an excellent example of the effect that marketing can have on an item’s transformation. Marketing can tell a company what will sell, but they have no technical expertise to help a company understand what will work in practical usage. In fact, in most cases, they undermine the design proposed by engineers or developers. If we take the example of the bicycle in the US from the perspective of usability, the redesign has been a failure. How can I say this? Well, it shows up quite prominently in the distances these bikes are ridden per year.
Luckily, research comparing distances ridden per country is available. Countries such as Denmark and the Netherlands are renowned for not riding US-style bikes and for retaining their older designs. A visit to Amsterdam will quickly make evident to the traveler that the styles used by the Dutch are completely different from those used in the US. The Dutch bike is known for its distinctive and traditional design. By having two countries with opposite bicycle designs and by comparing the frequency with which these bicycles are ridden, we can gain a good approximation of how effective the changes to the bicycle have been in the US.
This is for the year 2000. And for that year, the average person from the Netherlands rode 21.2 times farther than the average American. In 2000 the US population was 281,421,906, while the Dutch population was 16,783,092. However, the Dutch as a country still cycled twenty-six percent more miles than the US.
This graphic really cannot be spun in a way that favors the US design of bikes. What is clear is that in the US, marketing influenced the design approach, which concentrates primarily on the “coolness factor” of the bicycle—that is a bike that is designed to be sold rather than ridden. This leads to a large number of bicycles that sit in the garage, not being ridden. In the US, the average bicycle is ridden forty miles per year at an average speed of just fifteen miles per hour (meaning that the average rider rides for two hours and forty minutes—over an entire year). Furthermore, it should be remembered that bicycles are a much easier “selection” decision than the selection of enterprise software. However, the transformation away from usability on these consumer items, which are tested directly before purchase, demonstrates how marketing and impracticality can affect product development.
Poor Software Selection as a Contributing Factor to the High Failure Rate of Enterprise Software Implementations
Finding the root cause for the high failure rate of enterprise software implementations has been the subject of much questioning. Poor software selection is one of the causes. In fact, while the reasons are elementary and quite easy to adjust, they will not be changed because this is simply how companies have chosen to operate and entrenched interests and ways of doing things often do not change. Buyers are frequently more interested in factors outside of implement-ability and thus you cannot rely upon enterprise software to be designed for implement-ability. Some people have a hard time seeing why this is the case, the logic being that software that is not as implementable will eventually lose to those competitors with more implementable software. However, as I have explained earlier in this book, the enterprise software market is not an efficient market.
There are many factors that drive buyer revenues, and the implement-ability of software is only one of the factors. As discussed previously, many large vendors have partnerships with large consulting companies. These large consulting companies recommend their vendor partner’s software because doing so maximizes their revenues. Smaller software vendors will never enjoy this relationship with large consulting companies regardless of how implementable their software is. Software failures are hidden and the feedback loop about software’s implement-ability is to a great degree broken.
While those in marketing will disagree, software cannot be optimized for both sales and implement-ability. Software that is highly implementable means that product management has accounted for the important enhancements but has not put every enhancement request into the product. A major objective of the individuals who support a software selection effort is to ignore much of the marketing hyperbole and salesmanship and instead find the applications that offer the best combination of functionality to match with the buyer’s requirements, while at the same time considering the implement-ability of that functionality. The buyer may not implement all of the functionality that they desire, and the implement-ability of the functionality is as important as whether or not the functionality exists in the vendor’s application.
Financial Bias Disclosure
Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.