Chapter 10 • Methodologies for Purchased Software Packages 399modified because the business practices they support are
quite standardized and the vendor did not develop the
package with modifications in mind (Rockart and Hofman,
1992). Packaged systems have typically been beta-tested
in companies in the targeted industry before they are sold
on the open market. Despite the fact that the package
might have been thoroughly tested and already used in
other organizations, user acceptance testing still needs to
be conducted to ensure that the system works properly
with the company’s data and on preexisting or newly
installed hardware. This could require significant time and
effort because the purchasing organization is not familiar
with the system’s detailed design. The vendor provides
user documentation for those who will use the system and
technical systems documentation for those who install the
system and operate it. However, new procedures for the
system’s business users might need to be developed to fit
the purchasing organization.
If the package is modified, there might be several
options to consider for how to accomplish the changes: a
contract with the vendor, a contract with a third party, or
modifying the software with in-house resources. Many
vendors routinely contract to make the desired modifica-
tions. If a vendor will furnish only the machine-language
code for the application—not the source code in which the
program was written—the only alternative might be to
contract with the vendor to make the modifications.
If the vendor or another outside supplier makes the
modifications, the purchaser also needs to test them.
User acceptance testing is especially important and typi-
cally requires significant time and effort by the business
users. Revised user and system documentation also needs
to be reviewed. If the purchaser modifies the package, the
system design and building activities in the SDLC method-
ology will likely be followed, similar to the way these
steps would be for traditional custom development.
Because IS staff must devote substantial effort to under-
standing the details of the software package’s design and
structure in order to modify it, it is not uncommon for
the initial estimates of the time and costs for these steps to
be insufficient.
The scope of the project might also include modifi-
cations to existing company systems in order to interface
them with the new package. Creating these interface pro-
grams can be difficult and costly, and integration testing is
typically time consuming. According to Keen (1991), the
total costs of system modifications can be hard to predict
and the total life-cycle costs for a purchased system can be
up to seven times greater than the original estimate.
The previous discussion focused on actual modifica-
tions to the functionality or architecture of the purchased
package (e.g., changing the way inventory is valued in an
accounting package or changing the software to work with a
specific database management system). In contrast, some
modifications and enhancements are not as significant.
Most purchased packages have routines that allow certain
customization (e.g., including your company name and logo
on reports and invoices, or tailoring the layout of standard
reports). Also, the package may include tools to allow the
purchasing organization to build additional reports, display
screens, or data extracts (the latter to assist in interfacing the
purchased system with other “downstream” systems). These
changes do not affect the underlying architecture or code of
the purchased software and tend to be much easier to main-
tain as new versions of the purchased system are released.IMPLEMENTATION PHASE The Implementation phase
of the SDLC involves installation, operations, and mainte-
nance. As seen in Figure 10.1, these are all major activities
in the purchasing life cycle.
Installation The installation stage in the SDLC involves
installation planning, training, data cleanup, and conver-
sion. The installation of a packaged system also includes
all these activities. A key factor in a successful installation
of a packaged system is the quality of vendor support dur-
ing this step (Lucas et al., 1988). The package’s size and
complexity can also greatly affect the installation plan. For
example, large ERP system packages can entail multiple
years of work by in-house IS specialists as well as outside
consultants to prepare for the initial installation of these
integrated systems. This is because not only do these sys-
tems include many optional choices with which to config-
ure the system to fit the organization but also because ERP
systems typically require significant changes in day-to-day
business processes. As a result, the costs for installation
planning, data cleanup, and conversion efforts to install
such packages exceed those for a custom application effort
(see Figure 10.2). In large organizations, especially those
with different types of business units in different geographic
locations, it is also often necessary to implement the pack-
age in phases, which can also increase project costs.
Special attention also needs to be given to the training
needs for a purchased system as part of the implementation
activities. Depending on the extent to which the new system
will require significant changes in how employees currently
do their jobs, the project might require a large investment in
preparing the users for the new system, including in-house
or vendor-led training programs. Business managers and
representative users must be actively involved in these
activities and committed to devoting the time necessary to
anticipate and resolve problems that arise.
To help organizations that will be making significant
changes in the way people do their jobs, many consulting