Information Technologies in Organizations

powered by ERPsim

MODULE: IT PROJECTS
Software Selection
Stefan Tams
 MODULE: IT PROJECT

Software Selection

Laura and Pierre, two accountants at Greatcorp Inc., have just been assigned the task of selecting a new accounting
software solution to increase the efficiency of their departmental operations. The two accountants have a positive attitude
toward information technology and believe it can be useful for their department. Unfortunately, they are having a lot of
trouble adequately performing the selection process. They wonder: it is such a complex task – where do we begin? What
are functional requirements, what are nonfunctional ones, how are they related, and why do we need them anyway? How
do we find a good solution, and how can we close the deal?

This vignette illustrates some of the challenges inherent in the software selection process. The questions Laura and Pierre encounter are not
unexpected, as they arise in most software selection projects (Howcroft and Light, 2010; Tams, 2008). Do these challenges imply that the
software selection process is unmanageable? Not necessarily. There is good news: the software selection process can be considered a business
process and, as such, it can be structured so that it is easier to manage.

You will recall that we introduced the term business process in earlier modules; a business process was defined as a collection of structured
activities or tasks required to achieve a particular business goal (e.g., produce a product, serve a customer, and create a purchase order). One
such business goal is to improve process efficiency and/or effectiveness through the use of new software, implying that most of the concepts
we discussed earlier concerning business processes also apply to software selection. But there is more: in this module, we discuss additional
concepts that will give you an even better understanding of how to manage software selection projects effectively.

We begin our exploration of the software selection process by dividing it into a number of smaller and more easily manageable phases and by
discussing the different goals and characteristics of these phases. Afterward, we introduce the notion of functional and nonfunctional
requirements, followed by a discussion of additional considerations for enterprise resource planning systems, which are particularly complex.
Next, we discuss the costs and benefits of open-source solutions. Then, we introduce three contemporary issues in software selection. We
conclude our expedition into the software selection process with some final thoughts.

© 2018, Robert et al. MODULE IT PROJECT: Software Selection Process . 2

 1. Dividing the process into manageable phases

As mentioned above, the software selection process is complex and, hence, full of challenges. To make the process more manageable, we can
divide it into five phases (see Figure 1) (Howcroft and Light, 2010; Rasmussen et al., 2002; Tams, 2008): Planning and Budget Creation,
Requirements Analysis, Vendor Search and Evaluation, Presentations to Management, and Deal Closure.

Deal Closure
Presentations
to
Vendor Management
Search and
Requirements Evaluation
Analysis
Planning and
Budget
Creation

Figure 1: The Five Phases of the Software Selection Process

Planning and budget creation. The first phase of the selection process involves the creation of a project plan and budget (Howcroft and Light,
2010; Rasmussen et al., 2002). To make sure that an optimal software solution will be found by the end of the process, a good project team
must be established. More specifically, a strong project manager and representatives from all functional areas of the business are needed,
since software selection projects often cut across functional boundaries, such as marketing or accounting. Once the project team is established,
the project manager estimates a timeline for the selection process. A timeline is important to keep the project team and the selection process
on track at all times; it allows for continuous evaluations of the progress of the selection project. Perhaps even more important than the
timeline is the budget; the budget requires a careful estimate of the total costs for the software license, the software implementation, and the
software maintenance. License costs are often determined per user or station; implementation costs are the costs of implementing the
software (i.e., the costs associated with launching the software in its live environment); and maintenance costs are those for updates and
support, which typically account for around 20% of the software list price per year.

© 2018, Robert et al. MODULE IT PROJECT: Software Selection Process . 3

Requirements analysis. In the second phase of the selection process, we establish the purpose of the software and describe its functional and
nonfunctional requirements as well as its technology requirements (Gebauer et al., 2008; Howcroft and Light, 2010; Rasmussen et al., 2002).
The resulting requirements document needs to be focused on a few key criteria; otherwise, we may fail to see the forest for the trees, with
detrimental impacts on the project timeline and the quality of our final investment decision. A detailed list of both functional and nonfunctional
requirements is particularly important. Functional requirements are necessary software features that relate to the different functions a
system can perform for the user (Gebauer et al., 2008). By contrast, nonfunctional attributes relate to the acquisition and operation of the
system, not to what it is supposed to do. Since the detailed specification of both functional and nonfunctional requirements is particularly
important for a selection project’s success, we devote an entire subsection to them (section 2).

The technology requirements are based on the currently available technology infrastructure (i.e., currently available hardware and software)
and future acquisition of both hardware and software. The specification of the requirements includes, for example, the preferred operating
system (e.g., Microsoft Windows vs. Linux), the preferred database (e.g., Oracle vs. Microsoft SQL Server or IBM DB2), and hardware
specifications (e.g., requirements for random access memory). Technology requirements are often, but not always, established as part of the
functional requirements.

Vendor search and evaluation. The third phase of the selection process entails identifying the vendors whose solutions best meet the previously
established requirements. In this phase, we first generate a long list of candidate vendors. Next, this list is narrowed down to a shortlist of
three to five vendors on the basis of documented vendor information (e.g., vendor websites, price lists), phone calls, and vendor visits. The
shortlisted vendors are then invited to demonstrate the value of their solutions, including relevant software features, vendor support, and
potential price discounts. It is often useful to establish a detailed protocol for these vendor demonstrations to ease the comparison. Another
important aspect of this phase is testing; the shortlisted software products can be installed in a test environment so that future users can get
a feel for them. Getting a feel for the candidate solutions is important for users because contemporary software tends to be highly interactive
and, therefore, has to be explored in depth before informed evaluations can be made (Burston, 2003).

Presentations to management. In the fourth phase of the selection process, we present the shortlisted solutions to the final decision-makers.
This presentation includes documentation as well as the software- and vendor-related information that has been learned from the vendor
presentations and testing efforts (Howcroft and Light, 2010).

Deal closure. In the final phase of the selection process, management must make a choice among the presented solutions. This decision may
be based directly on the presentations. Alternatively, the choice decision may be based on follow-up vendor demonstrations or visits of
vendors’ headquarters. Decision aids include paired comparison analyses, which directly contrast each candidate software solution with each
other, or traditional cost/benefit analyses (Rasmussen et al., 2002).

© 2018, Robert et al. MODULE IT PROJECT: Software Selection Process . 4

To conclude our discussion of the proposed division of the selection process into five smaller phases, we must admit that this division is
somewhat artificial since – at the end of the day – we need to consider the process holistically to arrive at a good selection decision.
Nevertheless, this division makes sense since selection projects tend to be complex and, thus, full of challenges and managerial difficulties
(Rasmussen et al., 2002). Consequently, an organized approach based on simple, distinct phases can be helpful in deciding on a good software
solution. Note that we could also meaningfully include agile components in this approach; that is, we could iterate among the phases (e.g., we
could repeat Phase two after experiencing testing problems).

2. Functional and nonfunctional requirements

As previously mentioned, the establishment of detailed functional and nonfunctional requirements (or attributes) is a critical aspect of the
second phase of the software selection process (Howcroft and Light, 2010; Rasmussen et al., 2002; Tams, 2008).

Functional requirements are necessary software features that relate to the different functions a system can perform for the user, whereas
nonfunctional attributes relate to the acquisition and operation of the system, not to what it is supposed to do (Gebauer et al., 2008).

As such, functional requirements include software functionality, security, performance, and compatibility. Functionality implies that the
software solution has the required functions to do what the user needs to have done. Software security means that the functions and data can
be accessed only by authorized individuals. This criterion is functional since security is key these days; if an online vendor did not have
appropriate security measures, would we trust it with our credit card information? Thus, the very purpose of a software solution can be
compromised by insufficient security features. Similarly, software performance, such as response time, is often tied directly to the purpose of
the software system. Imagine an online vendor whose website needed to “think” for 30 seconds each time we clicked a button. How many of
us would buy from this vendor? Finally, system compatibility implies that the software solution can work together effectively with our current
and future hardware and software components (e.g., Microsoft Excel, a spreadsheet solution, is compatible with Microsoft Windows, an
operating system).

Nonfunctional requirements include software maturity, vendor financial stability, user training support, general vendor support, and software
price. These requirements are not directly related to the purpose of the software, but they are necessary for us to put a software solution to
effective use. Maturity implies that a software solution has been around for a while so that initial programming-related problems (also called
bugs) have been resolved. A good proxy for software maturity is the version number; a high version number generally points to a mature
product with few remaining problems. Vendor financial stability is important to ensure continuous support; a vendor that is financially
unstable may go out of business relatively soon, thus becoming unable to continue the delivery of updates and other forms of support. It is

© 2018, Robert et al. MODULE IT PROJECT: Software Selection Process . 5

also important for the vendor to be able to offer support for user training. Training users to use a software solution is important to ensure
that they have the confidence and intention to use the software and are able to use it effectively. Another relevant criterion is general vendor
support. Vendors must be able to assist with a variety of aspects surrounding the implementation, continuous operation, and maintenance of
the solution in question. Finally, and perhaps most importantly, the price must be right. It is important for the software solution in question
not to exceed the available budget.

Figure 2: Nonfunctional and Functional Requirements

Figure 2 shows the functional and nonfunctional requirements in context; the nonfunctional requirements surround the functional ones; that
is, they are at the periphery. This is not to say that nonfunctional requirements are not important; they are, but they are not directly related

© 2018, Robert et al. MODULE IT PROJECT: Software Selection Process . 6

to the purpose of the software. The figure also shows that functional and nonfunctional requirements are complementary; meeting functional
requirements is of limited value if the nonfunctional requirements are not met. For example, even if a software solution can do exactly what
an organization needs to have done, it will be of limited value to the organization if it exceeds the budget (i.e., the organization cannot afford
to purchase the focal software solution) or if it suffers from substantial problems related to software immaturity.

3. Added considerations for enterprise resource planning systems

In the case of the selection of a new enterprise resource planning (ERP) system such as SAP R/3, an additional criterion needs to be considered
due to the extreme complexity inherent in such software systems. More specifically, because these software solutions have major impacts on
many aspects of an enterprise, we need to decide whether a complete suite or a best-of-breed solution is best. The former, the complete suite,
refers to an ERP solution that covers the breadth and depth of the entire enterprise. In other words, the entire value chain of an organization’s
transactions is covered when it employs a complete suite of a vendor’s applications. This approach involves the integration of financial,
accounting-related, distribution-related, marketing-related, human-resource-related, manufacturing-related, and other aspects of
organizational life.

By contrast, a best-of-breed solution is not a complete integrated software solution. It, however, emphasizes certain aspects that are of
particular importance to the enterprise (see Figure 3). For example, a company could invest only in the accounting and manufacturing
components of an enterprise system if other aspects of organizational life are outsourced. Moreover, it could purchase these components from
different vendors that are the best in their respective domains, assuming that these components are compatible with each other and with the
organization’s existing and future technological infrastructure. This best-of-breed approach recognizes that not every company needs every
single piece of a complete enterprise system. However, it does not acknowledge the importance of an integrated solution. After all, the division
of an enterprise into several different departments with distinct goals and characteristics is an artificial approach to make the enterprise more
manageable; in reality, all departments should be working together toward a common goal, such as profit maximization.

© 2018, Robert et al. MODULE IT PROJECT: Software Selection Process . 7

 Piecemeal
approach

Emphasis of Best-of-
key areas
Breed Complete Emphasis of
business
Suite integration

Integrated
approach

Figure 3. Distinct Emphases of the Best-of-Breed vs. Complete Suite

Approaches

4. Open-source – Always a cheap alternative?

At some point in the software selection process, we will come across open-source solutions (Maxville et al., 2009), which usually have much
lower licensing costs than marketed solutions, if any. Open-source software is software whose source code is freely available, implying that
these software solutions tend to be free of licensing costs as well. For example, Linux is a free operating system, and Apache Open Office is an
office suite that can be obtained free of licensing costs. Hence, open-source solutions appear to be much cheaper than regularly marketed
software products such as Microsoft Windows or Office – at least on the surface. However, we need to consider that open-source solutions
often have large hidden costs due to the lack of support associated with them. For example, there is usually no vendor support for system
installation in the live environment or user training bundled with open-source solutions. Furthermore, there are generally no guaranteed
updates since no company is required to provide them. This lack of vendor support implies that a strong internal technology department is
needed for any company considering open-source solutions; open-source is not appropriate for companies that have outsourced their

© 2018, Robert et al. MODULE IT PROJECT: Software Selection Process . 8

technology departments or otherwise lack technological expertise. However, open-source solutions can be of substantial value to firms with
idle technological resources and ample technological expertise.

5. Contemporary issues in software selection

A number of additional considerations warrants brief introductions. Especially important are business agility, contextual aspects, and
outsourcing.

Business agility. Today’s fast-paced business environments require organizations in many industries to be flexible in their business operations
and corresponding software solutions so that environmental changes can be accommodated. Hence, business agility is emerging as the next
major factor in the software selection process (Persaud, 2011). For example, in the case of the introduction of a new product line, it is
important for the software solutions to be available to support this change.

Importance of context. We should not overlook the fact that different project teams and users may interpret the costs and benefits of a software
solution for a particular business problem quite differently. Since these interpretations shape all aspects of the selection process, particularly
the requirements analysis, evaluation, and final decision-making, we need to consider structural influences, power asymmetries, and the
economic positioning of relevant social groups in the selection process (Howcroft and Light, 2010).

Outsourcing. Outsourcing is a relationship between a client company and a vendor in which the client asks the vendor to perform all or part
of its software selection activities for it in exchange for a contract fee. While outsourcing often helps companies make a good selection
decision – particularly companies with small information technology departments – it also has important pitfalls that should be considered.
These barriers to successful outsourcing include, first and foremost, language and cultural barriers, but also lack of effective project
management and lack of technical capability (Khan et al., 2011). Such barriers need to be addressed up-front and hands-on by the client
company if outsourced software selection projects are to be successful.

6. Conclusion

We have briefly explored the software selection process and have, hopefully, learned some concepts that may prove helpful in circumventing
some of the challenges inherent in this process. Equipped with this recently obtained knowledge, we can address Laura and Pierre’s
fundamental questions. Of course, we must begin the selection process by creating a project plan, a timeline, and a budget. We proceed with
the requirements analyses, vendor evaluations, presentations to management, and ultimate decision-making. We have also learned that

© 2018, Robert et al. MODULE IT PROJECT: Software Selection Process . 9

functional requirements, including software functionality, security, performance, and compatibility, are related directly to the purpose of the
software. In addition, we have learned that nonfunctional requirements, for example, vendor stability, product maturity, and software price,
are requirements that complement the functional ones. Furthermore, we have looked into a variety of other concepts, equipping us with the
tools necessary to perform a software selection process successfully, from beginning to end.

7. References

Burston, J. (2003). Software selection: A primer on sources and evaluation. CALICO Journal, vol. 21, no. 1, pp. 29-40.
Gebauer, J., Tang, Y., and Baimai, C. (2008). User requirements of mobile technology: Results from a content analysis of user reviews.
Information Systems and e-Business Management, vol. 6, no. 4, pp. 361-384.
Howcroft, D., and Light, B. (2010). The social shaping of packaged software selection. Journal of the Association for Information
Systems, vol. 11, no. 3, pp. 122-148.
Khan, S. U., Niazi, M., and Ahmad, R. (2011). Barriers in the selection of offshore software development outsourcing vendors: An
exploratory study using a systematic literature review. Information and Software Technology, vol. 53, no. 7, pp. 693-706.
Maxville, V., Armarego, J., and Lam, C. P. (2009). Applying a reusable framework for software selection. IET Software, vol. 3, no. 5,
pp. 369–380.
Persaud, D. (2011). ERP trends that affect your success. Tech Trends IMPO, September 2011.
Rasmussen, N. H., Goldy, P. S., and Solli, P. O. (2002). Financial Business Intelligence: Trends, Technology, Software Selection, and
Implementation. New York: Wiley.
Tams, S. (2008). Business intelligence appl. in personnel controlling [Personalcontrolling mit Business Intelligence]. Saarbrucken:
VDM.

© 2018, Robert et al. MODULE IT PROJECT: Software Selection Process . 10