A Guide to Software Package Evaluation and

Selection
by Nathan Hollander AMACOM © 2000 (344 pages) CitationISBN:9780814405536

Presents a formal methodology for IT departments to follow when determining business

requirements and choosing software vendors and products.

Hollander, Nathan. A Guide to Software Package Evaluation and Selection.

AMACOM. © 2000. Books24x7.
<http://common.books24x7.com.proxy.cityu.edu/book/id_1674/book.asp>
(accessed May 16, 2010)

Table of Contents a guide to Software Package Evaluation & Selection

Introduction Chapter 1 - R2isc Chapter 2 - Current Requirements
Chapter 3 - Future Requirements Chapter 4 - Implementability, Supportability,
and Cost Chapter 5 - Narrowing the Field Chapter 6 - Analyzing the
Vendors' Responses to the Request for Proposal Chapter 7 - The Scripted
Demonstration Chapter 8 - Checking Out the Finalists Chapter 9 -
Contract Negotiations Chapter 10 - Workshops Chapter 11 - Developing
the Plan and Selecting the Team Chapter 12 - Implementation Appendix
A - Ross Systems Renaissance CS Financials Series Appendix B - Sample
GartnerGroup Report Appendix C - Request for Proposal: Elsa Company
Appendix D - Gantt Chart Index List of Figures List of Tables
Introduction
This book is the culmination of fifteen years of my experience in conducting package selections.
It began as a process that took three to four months and evolved into a process that can be
completed in four to five weeks. Unfortunately, I have not been able to shorten the time the
lawyers take to review the contracts. I have reduced the time needed to select the package to the
point where it can now take less time than the final contract negotiations.

When I looked at what's important in selecting a package, I found that there are really only five
important items— which we will call the R2ISC criteria (pronounced "risk squared"). They are:

• Current Requirements: ability of the package to meet the company's current

business requirements and the package's ease of use.
• Future Requirements: ability to modify the package to meet any new
requirements.
• Implementability: ability to implement the package easily.
• Supportability: ability of the vendor to support both the package and the
company in the future.
• Cost: total cost to implement the package and any ongoing maintenance.

This book was written to assist you in selecting a package that affects multiple departments (such
as an Enterprise Resource Planning [ERP] system). However, if you are selecting a package
that affects only a few departments, you can still use the R2ISC methodology. You should merely
reduce some of the formality.

The process starts with the enterprise rating each criteria. The rating depends on the criticality of
the criteria to the enterprise. Each package is ranked by its ability to meet the five criteria, first at
a general level then getting into finer and finer detail. Packages are eliminated at each step until
only the winner remains.

The R2ISC methodology helps reduce problems that might arise upon implementation and cause
the project to fail.

I am often called in by clients and asked to tell them which is the best package for their
company. I tell them that if I pick the package it will become my package and not theirs. By
choosing my suggestion you may save time in the selection part of the process, but it will cost
two to three times that much time in the implementation phase of the project. Choosing my
suggestion can even jeopardize the entire project; when problems arise the users will say "Nate's
package doesn't work," and they will not make an effort to ensure that the package is
successfully implemented. This shows how important it is for a company to have its own people
pick a new package.

Using this Book

The best way to use this book is to read it in its entirety before you start the project. Then you
may find it helpful to refer to each chapter accordingly as you go through the process.

There are many tables in the book that are used to rate the pack- ages. They should be used as a
guide and not as a bible. They should be modified or disregarded as you feel best fits your
individual package selection. The main thing is to use the R2ISC concept.
Chapter 1: R2isc
Overview
This chapter is a high-level overview of the package selection process. The chapters that follow
will discuss the details needed to determine how to analyze each package and determine how
well it meets your requirements.

Companies come in all shapes, sizes, and styles; big and small, wholesale and retail,
manufacturing and services provider, etc. No matter the shape or size, some processes are
identical for all companies (i.e., accounts receivable) whereas others are industry specific (i.e.,
inventory control). The one thing your company has in common with all other companies is that
you will benefit by using the "right" software package to improve your business. On the other
hand, choosing the wrong software package can be a catastrophe.

Even within the same industry, companies can vary widely. For example, some manufacturers
have highly automated their production. Their process begins at one end of the assembly line and
the completed product comes out the other end—with no human intervention. On the other hand,
there are manufacturers whose processes are completely manual and whose parts wait days
between operations. A company that manufactures lift trucks may have more in common with a
company that manufactures computer printers than it does with the lift truck company around the
corner. Likewise, because of subtle and not so subtle differences in their processes, software that
is suitable for one company may not work for another within the same industry.

Companies perform many processes, all of which work together to build a successful business.
Some processes are for customer benefit, whereas others meet government requirements.
Processes can include:

• Accepting a customer order

• Shipping the product to the customer
• Ordering the material to make the item the customer ordered
• Paying for material, etc.

Companies can perform the same process in many different ways. One example of this is
accounts payable. In order to pay for an item, a company may use the traditional method of
matching three pieces of information: the purchase order (quantity ordered, price, and terms), the
receiving report (quantity received), and the invoice (amount owed). This is known as a three-
way match. Other companies, however, feel that matching the vendor's invoice adds little
additional information and only adds additional processing cost. They feel that because they
know how much they owe the vendor based on the terms of the purchase order and price and the
quantity that is on the receiving report that they need only match the purchase order and
receiving report (two-way match). Therefore, the requirements for a process can be very
different. A software package that only performs a three-way match will not work well for a
company that uses a two-way match.

Selecting the wrong package can be worse than not selecting a package at all. The wrong
package can lead to:

• Failing to support an important business process

• Supporting a process inaccurately or inefficiently
• Unhappy customers
• Disgruntled employees
• Loss of sales
• Poor financial performance
• Shelfware (software package that lies on the shelf because it is not being
used)

Selecting a software package is like selecting a house. There are five important criteria—which
we will call the R2ISC criteria (pronounced "risk squared")—that need to be considered. They
are:

• Current Requirements: What do you want in the house? What type of house,
neighborhood, number of rooms, etc.?
• Future Requirements: How easy will it be to make changes to the house? Is it
in a historic district? Is there room on the lot to expand?
• Implementability: How easy will it be to move into the house? Will there be
trouble getting a mortgage? Is the house in move-in condition?
• Supportability: What type of maintenance will the house require (the older
the house the more likely something will need to be fixed)? Is the exterior
wood or aluminum siding, etc.?
• Cost: Total cost of the house including purchase price, mortgage, taxes,
maintenance, etc.

With regard to choosing a software package, the R2ISC criteria can be defined as the following:

• Current Requirements: Ability of the package to meet the company's current

business requirements.
• Future Requirements: Ability to modify the package to meet the company's
new requirements as they become known.
• Implementability: Ability to implement the package easily.
• Supportability: Ability of the vendor to support both the package and the
company in the future.
• Cost: Total cost to purchase and implement the package as well as ongoing
maintenance and support costs. If employees will quit or there will be more
employee absenteeism, the impact should be translated into the dollar
impact on the company.

Although the list may seem simple enough, because of the criteria interaction with each other it
therefore becomes complicated. Your company's goal is probably to have a package that not only
meets all your current and future requirements, but is cheap, easy to modify and implement, and
is fully supported by the vendor. Unfortunately, this is usually an unrealistic expectation. Before
you choose a software package you must determine, based on the company's vision and strategy,
the relative importance of each of the R2ISC criteria.

For example, a company may want a package that meets their future requirements and is easy to
implement. But meeting future requirements often requires purchasing a package that uses the
latest technology. A package that is based on the latest technology can be problematic to
implement. Because the package is new and has not been successfully implemented by other
companies, it will likely contain bugs. This will cause the package to be difficult to implement.

There are different technology choices a company has to pick from when selecting a new
package, just as you may have a few houses to pick from when looking to buy one. When a
company wants to use the latest technology and software it is known as a leading edge or
bleeding edge company. Companies understand that it is hard to implement this type of
technology. If they did not understand it before the project began, they understand soon after
they start implementation. But they believe that the benefits of having an ultra- modern package
gives the company a strategic advantage over its competitors, and therefore far outweighs the
drawbacks (additional effort, cost, and inconvenience).

Other companies want to be close followers. Namely, they want most of the bugs removed
before they implement the package. Even though this removes much of the potential risk and
inconvenience, these companies lose some of the advantage the leading edge company has
gained.

Still other companies, risk avoiders, may want to drastically minimize their risk by using only
proven software. This means there is no competitive advantage.

Just because a company chooses to be bleeding edge in one area does not mean it has to be in all
areas. It can decide that in certain areas bleeding edge or close follower software will give it a
competitive advantage whereas in areas where there is no competitive advantage proven software
is a better bet.