Seven Principles for Selecting Software Packages

Around the mid-1950s, in the early years of commercial use of computers, all software systems were developed in-house. There was no software industry in existence at that time.¹⁵ As the software industry formed over the next few decades, many organizations outsourced their software development to specialized software suppliers. Most software products were, however, still developed as unique systems for each organization; that is, there was little standardization. The next step occurred when that software producers developed their own proprietary software in order to capture economies of scale in developing the software once and then selling it to multiple customers.² This standardization process also benefitted software buyers by lowering transaction costs and risks, as it was now possible to choose among a proven set of applications. Moreover, standardization gave both producers and buyers of software a way to capture and black-box best practices by embedding it into the standardized components of the systems.¹⁶ Next in the standardization process was a step away from proprietary standard systems that essentially locked customers to a single software producer to open software standards.³⁷ In principle, software built on open standards allowed customers to source from any supplier that could supply software in accordance with open standards (for example, Java- and XML-based systems).

Open standards meant that prices dropped and functionality was enhanced, which resulted in a mass market for many software application types. In addition, software producers had enough resources to make their software even more general-purpose oriented with larger feature sets that were organized into a product.⁸ Software became even more standardized, and in the process, many local markets were annexed into global markets. For example, word processing software was no longer produced specifically for a particular profession or industry or nation;²⁶ instead, an almost universal office suite emerged, such as, Microsoft Office. The generalized software products could be configured in various ways (for example, program parameters, macro functionality, language support, and so on) to suit special needs among customers. These highly configurable general purpose software products came to be known as software packages.²³

Until recently in the IS academic community, there has been a tendency to focus on traditional studies of software development and implementation of large custom-made systems.^20,24 This has been despite the leading trend that organizations use "shrink wrapped" systems³¹ where the core functionalities of the software are identical across all implementations in dozens, thousands or even millions of different organizations.¹⁵ When it comes to managing the process of identifying and evaluating packages, the IS academic community has been almost silent.

The aim of this article is to provide practitioners with a grounded set of principles to guide the selection of software packages. By principles, we mean a set of fundamental ideas that summarize important insights in software package acquisition that are not (yet) embedded into the practice of buying software. The principles are interdependent and together they form a whole that is larger than the sum of the parts. Similar to Klein and Myers' argument,¹⁹ the use of all principles is not mandatory, but in each case it must be judged whether, how, and which principles apply to a specific situation.

Full article: https://cacm.acm.org/magazines/2010/8/96615-seven-principles-for-selecting-software-packages/fulltext