How to Understand Software Sellability Versus Implementability

Executive Summary

• Many applications are designed more to be sold versus to be implemented.
• This impacts the implement ability of applications.

Introduction

The reader will also understand why the marketing literature reads the way it does and why they need to ignore the “sell-ability” parts of it and seek instead documentation that reflects the “implement- ability” of the software. They will better understand the types of questions they need to ask of references and check whether they consider the reference to be one the company provided merely to add to their “sell-ability.” By understanding the difference between sell-ability and implement-ability, it’s easier to know where the real interest lies for the entities that provide information to the selection process. Many pressures cause the software to be developed into what you see as the final product. This information sets the stage for the end of the chapter, which will focus on how to select the most implementable solution. It would, of course, be quite lovely if the software were always designed to be functional rather than sold. Vendors have a limited amount of resources that they can apply to the development of their products. There is a general misimpression that software development occurs along the lines of what is desired by customers, which should lead to desirable outcomes. This sounds plausible enough.

However, the reality of software development (and this applies to all enterprise software to varying degrees) is that there are competing agendas. Not only the customers’ agenda but also the vendor’s and even those of third parties such as IT analyst firms. The more significant software vendors exacerbate this problem was the most substantial incentives exist to throw things over the wall. I recall having a discussion on this topic with representatives from the vendor PlanetTogether. I asked them why their software seemed so much more usable than other software in their software category. And one example they gave was that the company was just too small to throw things over walls and develop functionality that had little practical implementation value to get a sale. The smaller the entity, the more affiliation each has with other individuals, the more they know them—can receive negative feedback for aggressively perusing one’s agenda at the expense of others.

Impressing the IT Analysts

So far, I have only explained the agendas internal to the vendor; however, it does not end there. Because vendors want to score well in IT analyst ratings, they are under pressure to match the vision that the IT analysts have for their software category. The same issue applies to software investors. Software investors have a particular story that they find more appealing to investing. For instance, Adobe is well-known for its suite of design applications that includes Photoshop and Illustrator. However, Adobe decided to move to a SaaS-based solution, which meant that users now rent the Adobe creative products for a monthly fee. While there were several reasons for this change, one stated purpose was to stabilize the company’s revenues (moving to a monthly charge rather than seeing its revenue bunched up after their upgrades are released). This made Adobe more appealing to stock analysts who prefer to see stable revenues.

However, was this the best-combined solution if customer’s interests were accounted for? Many people that use Adobe’s creative products don’t think so. Even if we limit our discussion to just the vendor and buyer, multiple people in multiple departments often have competing objectives. If we take only the vendor’s competing goals, for instance, one of the pressures comes from the need to have implementable software that buyers can use. However, other influences come from the need to sell software. The agendas of those who sell software and make software implementable may sound complimentary, but in fact, they are not at all complementary and are a significant source of friction within vendors.

The Case Study of i2 Technologies

I once worked for a software company called i2 Technologies, which is a textbook example of what happens when marketing and sales completely co-opt product development. Not only did i2 Technologies come out with too many new product enhancements, they just came out with too many new products. I2 Technologies fell victim to Enron Syndrome—too much confidence in one’s innovation, too much focus on the stock price rather than the business, and accounting irregularities (necessary to keep continual improvements in earnings). Most of i2’s best products were the first ones they developed before the media created an echo chamber for them, and Enron Syndrome took hold. I found out first hand as a consultant implementing projects the new products were universally the problem applications. Few of these products worked, and it eventually brought down i2 Technologies, once a thought leader in its space. The company was acquired cheaply by JDA. I worked in consulting within i2 Technologies, and there was a great deal of friction between marketing/sales and consulting because we were not able to deliver reference-able accounts because the new software was essentially not implementable.

Functionality Creep

An essential component of how companies rate software is how many areas of functionality the software includes, which in turn encourages vendors to add more and more functionality. However, this continually-added functionality also increases maintenance and quality problems. That is, it is easy for a software vendor to bring out more functionality than it can reasonably maintain. Vendors do this because Marketing and Sales repeatedly go to Development and say, “If we only had this area of functionality, we would get this big client.” Buyers who have purchased software already always ask vendors for adjustments to the software, and in most cases, they are not willing to pay for these improvements but want them rolled into the next version of the software. However, buyers have a self-centred view of the software, only seeing the things they want to do in the software.

Generally, they do not understand the vision of the software. They are mostly unconcerned as to whether or not other buyers are also interested in using the software in the same manner. In essence, clients would like to turn a software vendor into their custom-development shop, while vendors need to make sure that the functionality they develop can be sold to multiple clients. Sales and Marketing know what they can sell. But are frequently inconsiderate of how adding new functionality can negatively impact the maintainability of an application. Therefore, the buyer, sales, and marketing, with their focus on adding functionality, have a much more limited view of the software product than does Product Management.

Poor Product Management

The product management process maintains this list of product enhancements (some driven by customers, some internally driven, some inspired by sales). Estimates how much the enhancements will take in terms of time and money, and prioritizes the enhancements that have the best potential to “improve” the software so that these are worked on first. I used the term “improve” in quotation marks because it is a subjective term. To sales, improvement means it will make the software sell better. To the buyer, it is something that will allow them to meet their particular business requirement better. To an implementation consultant, an improvement means the software will be easier to implement. To the product manager, “improve” may say that the change is consistent with the long-term vision of the product. Therefore, the definition of the term “improve” very much depends upon who you are and your incentives and motivations.

The Dynamic Nature of Software

Software is like a living organism in that it is continuously growing and changing and has a particular life cycle. The lifespan of software is relatively short compared to other products, some reasons for which I have listed below:

1. Application software relies upon underlying layers. These layers include things like databases, operating systems, and hardware. When these underlying layers change, the software must also change. For instance, if an operating system falls out of favour, the software must be ported to the new operating system. The software is designed to work on a particular category of hardware. When the hardware changes, the software must be rewritten. For example, there has been a movement from single-processing servers to multi-processor servers. When this occurred, some vendors (particularly those who sell high-performance applications) did not place porting multi-threaded processing high enough on the development prioritization list, so they are still only using single processors.
2. Software is a rapidly evolving product category. Applications must be continuously updated, or they become outdated. There can be classic cars—cars that you wish they still made—but standard software is just uncompetitive software. If you were to go back and review software from a decade ago, you would notice that the software appears dated compared to current designs. Much of the software we use has not been around that long, and while an application may have the same name as what was sold as the same product a decade ago, it is a very different animal.
3. More significant vendors often acquire successful and innovative small vendors. When this happens, the most common outcome is for the acquired vendor to stop being a leader in their category. The acquiring vendor procures the smaller vendor’s customers and stops innovating with the product. Many of the employees of the acquired firm, particularly those most responsible for product innovation, leave the merged company. Acquisitions are one of the prime causes of a software product becoming irrelevant.
4. Under constant pressure to add functionality, applications can become so high-maintenance and demanding to use that they lose their primary benefit and become vulnerable to less complicated products that work more efficiently. The blogging platform WordPress recognized this phenomenon. WordPress is the most popular blogging platform in the world, and powers many of the blogs and websites that we all read. I have been working with the software since 2007. This highly respected software is free and has grown enormously since it was initially introduced. Mainly, WordPress receives an unlimited number of requests to add functionality to its software. However, early on it decided not to develop the product to meet all of these requests, but instead to allow plug-ins. WordPress allows merely its software to interoperate with third-party software vendors (most of them do not charge for the software they create). In this way, WordPress is not responsible for developing or maintaining those plug-ins. This system has been extraordinarily successful and has allowed WordPress to continue to grow with a seemingly unending number of plug-ins. WordPress is not distracted and instead can concentrate on what it does best, which is continuing to develop the core WordPress software.

Unfortunately, enterprise software does not work like this, and therefore can quickly grow unwieldy under the new functionality, which results from constant requests for improvement.

Adjusting the Software Selection Approach to be Focused on Implementation

I have explained how software development and software vendors tend to work 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 primary strategy of vendors is to anticipate every need that a company could have by placing a complete set of functionality in their applications. However, as this type of software tends to be challenging to implement, companies greatly overestimate their ability to apply the functionality. 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 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 drives the forecast). They have much less interest in hiring and paying people with forecasting education and experience to 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 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 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 useful item that offers more ego-driven functionality (lower weight, aggressive styling, high turnover in design) and less useful 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 traveller that the styles used by the Dutch are entirely different from those used in the US. The Dutch bike is known for its distinctive and traditional design. By having two countries with varying designs of bicycles and by comparing the frequency with which these bicycles are ridden, we can gain a good approximation of how effective the changes to the bike 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 favours 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 bike 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 simple “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. While the reasons are elementary and quite easy to adjust, they will not be changed because this is 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 on 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. The enterprise software market is not efficient. Many factors drive buyer revenues, and the implement-ability of software is only one of the elements. 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 significant degree, broken.

Conclusion

While those in marketing will disagree, the software cannot be optimized for both sales and implement-ability. Software that is highly implementable means that product management has accounted for the crucial enhancements but has not put every enhancement request into the product. A primary 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. The overall theme of this chapter is that vendors have, in many ways, optimized their products to be sold rather than implemented effectively. More significant vendors are more prone to doing this than smaller vendors.