Chapter 10 • Methodologies for Purchased Software Packages 393is when the package has not yet been fully released and the
purchasing organization contracts with the vendor to serve
as an alpha siteor a beta sitefor the software vendor.
Being involved as an alpha site often means that the
company can play a significant role in determining the
final functionality and user interface design for the new
package; in turn, this is a major commitment to providing
both business and IS resources to work with the vendor.
Being involved as a beta site typically means significant
involvement in a user acceptance test role for the software
vendor (e.g., described in Chapter 9): A vendor does beta
testing with organizations that are not alpha sites in order
to closely monitor the system for potential errors in a
different setting.
The Implementation phase includes the same steps
as in the SDLC. For a purchased system, however, the soft-
ware vendor might be highly involved in the Installation.
Further, the maintenance of the package is usually a task
performed by the vendor. The negotiation of this part of the
purchase contract is therefore a critical step.
INITIATING THE PURCHASING PROCESS Similar to the
decision for customized application investments, organiza-
tions use a number of approaches to decide whether to invest
in a purchased system. Some organizations do not require a
detailed formal request to begin an investigation of a possi-
ble system purchase because there is an assumption that
fewer IS resources are needed. At a minimum, the business
manager prepares a document that briefly describes the pro-
posed application needs and outlines the potential benefits
that the application will provide to the organization.
A high-level cost estimate for a proposed purchase will
need to be developed with both business manager and IS
analyst input. Estimating the system costs involves much
more than identifying the purchase costs of candidate pack-
ages. For example, Figure 10.2 provides a hypothetical
comparison of the costs for a $1 million custom-developed
system using in-house resources (a midsized system) with
the costs for selecting and purchasing an off-the-shelf pack-
age with the same overall functionality. The total cost for the
purchased solution ($650,000) is about two-thirds of the total
cost of building the system in-house. Note, however, that the
software purchase price ($100,000 for purchasing the licenses
to the software package) is less than one-sixth of the total
costs—a characteristic that is often not fully realized by busi-
ness managers who don’t have extensive experience with
purchasing packaged software. Further, in the Construction
phase costs for this example, there is an assumption that no
major modifications to the package are required and that
linkages with other systems are not a part of this project.
As when building the system using the SDLC, a
systems project team should be established and given the
responsibility for acquiring the software. The team should
include representatives from the business units that will
implement the system, IS analysts, and other IS specialists
who will operate and support the packaged system and
other systems that will interface with the package. Some of
the specific team roles will be described later in this chapter.DEFINITION PHASE The Definition phase begins with
the same two steps as in the SDLC process. However, five
additional steps are specific to the purchasing process.Feasibility Analysis
Requirements Definition$ 50,000
250,000150,000
150,000
130,000
120,000150,000$1,000,000—$ 50,000
200,000100,000
25,000175,000
100,000
$ 650,000——Definition PhaseStages
Cost of
Building SystemCost of
Buying SystemSystem Design
Coding and Testing
System Testing
Documentation and ProceduresConstruction PhaseInstallation Planning, Data
Cleanup, and Conversion
Software Purchase PriceImplementation PhaseTotalFIGURE 10.2 Comparison of Costs for Building Versus Purchasing a System