400 Part III • Acquiring Information Systems
firms have developed an expertise in what is referred to as
“change management.” Some of the change management
activities are specifically designed to help overcome resist-
ance by business users to the new system being imple-
mented. For projects implementing complex enterprise
systems, for example, the systems budget for change man-
agement activities can be greater than the budgeted cost for
the initial software purchase. (See the section entitled
“Managing Business Change” in Chapter 11.)
Operations Ongoing operations tasks for a new application
are similar whether the company purchases the system or
builds it using the SDLC. However, a key to success in the
initial days of operation for a new packaged system is good
lines of communication with the vendor in order to quickly
resolve any problems. Long-term success depends on the
degree to which the organization has successfully integrated
the system into the company’s ongoing operations.
Maintenance As described previously, it is common for a
vendor to do package maintenance, and this needs to
be specified in the software purchase contract. A well-
designed contract can lead to considerable cost avoidance
to a firm over the life of the system. The potential down-
side, however, is that the purchasing company becomes
totally dependent upon the vendor for future system
changes. (This is especially true for so-called proprietary
software—but, as we discuss in a subsequent section,
open-source software is built on a different purchasing-
maintenance business model). Because the vendor must
balance the desires and needs of all the organizations that
use the system, a purchasing company might not get all the
changes it wants, and it might even have to accept some
changes it does not want. The worst-case scenarios here
are as follows: (1) the purchased system has a significantly
shorter useful life than originally intended, so the system
costs may exceed the expected benefits for the company
that purchased the software, or (2) the vendor goes out of
business before the company achieves its expected return
on the packaged software investment.
If the original package was modified, the installation
of a vendor’s new version of the package might not be the
optimal solution for the purchasing organization. With the
vendor’s help, the company needs to compare the function-
ality of the new version of the package with its current
modified version and then decide on the best way to deal
with these discrepancies. The choices are similar to those
shown in Figure 10.6, except the “do nothing” choice,
which means that the organization might be left operating
a version of the package that the vendor might or might
not continue to support. If the organization modified the
original package in-house or built extensive interfaces to
the package’s earlier version, the implementation of a new
version of the package can also result in considerable
maintenance costs for the organization.
In the case of large ERP system packages, the
purchasing organization needs to anticipate that new
releases of the software might be relatively frequent, and
the vendor might continue to support prior package releases
only for a certain time period. When implementing a sys-
tem upgrade that includes significant new functionality, the
company will need to decide whether to first implement
the new version of the system and then initiate projects to
make better use of the business capabilities supported by
the new release or whether to implement the new business
capabilities as part of the system upgrade project.Project Team for Purchasing Packages
Successfully implementing a packaged application typically
requires a major commitment on the part of business man-
agers and users because of the extensive changes in busi-
ness processes and procedures that are needed to effective-
ly implement the purchased software. As a result, it is not
uncommon for business managers to be asked to take a
project managerrole for a packaged application system
project. However, because IS expertise is still required in
order to manage the technical aspects of implementing a
package, IS managers also need to play project leadership
roles. As mentioned previously, small organizations that
have no IS specialists will need to rely on the software
vendor or outside consultants, or both, to provide the
necessary IS expertise.
The software vendor initially provides information
on the package capabilities in response to an RFP. Vendors
of leading packages might then be asked to provide a
demonstration and to consult with the purchaser about
potential system modifications or new interfaces to older
systems. The vendor company might also be contracted to
perform modifications to the package prior to implementa-
tion in order to reduce mismatches between the packaged
system’s capabilities and the organization’s needs after a
careful assessment of the benefits and risks of doing so.
The vendor could also play a major role in the system
installation, as well as provide ongoing maintenance sup-
port for the purchasing organization. In the case of large
enterprise system packages, it is also common for compa-
nies to contract with a consulting firm (that might have
been certified by the software vendor) as a third-party
implementation partneron the project.
Because of the initial and ongoing dependence on the
software vendor, purchasing specialists (contract specialists)
within the purchasing company can also be critical to
the success of a packaged system implementation, whether
or not they are formal members of the project team. For