Evaluate Vendor Responses to RFP and Choose Package In this step, the vendor responses to

the RFP are evaluated and additional actions are taken to evaluate the candidate packages and
their vendors. The overall objective of the evaluation process is to determine the extent of any
dis-crepancies between the companys needs as specified by the requirements and the
weighting system and the capa-bilities of the proposed application packages. Aggregate
evaluations (scores) need to be calculated for each set ofcriteria and for the overall package.
The team then uses these figures to discuss the major strengths and weakness-es of the
candidate packages. This can be a large data col-lection and analysis task and might involve
independent evaluations by all project team members. Both IS and busi-ness team members
might need to confer not only with other project team members but also with other members
of their departments.
In addition to evaluating the vendors responsesfrom the formal RFP process, two other types
of datacollection are commonly pursued, at least for the leadingcandidate packages. First,
demonstrations of the leadingpackages can usually be arranged. Sometimes it is feasiblefor
the vendor to set up a demo on-site at your organiza-tion; at other times, another location is
requiredeither ata vendor location or at another company that has installedthe package.
Second, references from users of the software pack-age in other companies are usually
obtained. Each vendormight be asked to provide a reference list, to your specifi-cations, as
part of the RFP. You might ask for referencesfrom similar-sized organizations, some
geographicallyclose, who have a mix of experience (e.g., some recent andsome long-term
purchasers), or from similar businesses.You might even want to talk with a reference that
chose notto purchase the package. One especially effective tech-nique is to require the vendor
to provide the names of usersas well as IS specialists for each customer organization ontheir
reference list.
Negotiate Contract The deliverables from this stage are alegal contract with the vendor of the
selected softwarepackage and a detailed plan for the remainder of thelife-cycle steps. The
contract with the software vendorspecifies not only the software price, number of
licenses,and payment schedule but also functional specifications,acceptance-testing
procedures, a timetable of the deliveryprocess, protection of trade secrets, repair and maintenance responsibilities, liabilities due to failures, requireddocumentation, and options to
terminate the agreement(Gurbaxani and Whang, 1991).

CONSTRUCTION PHASE In the SDLC process, theConstruction phase includes three steps:
system design,system building, and system testing. With purchasing, theextent to which the
first two steps are needed depends onwhether or not the purchased package is modified, as
wellas the complexity of the package itself.
If no modifications to the system are to be made, thefirm can move to the system testing step
after the purchasecontract is signed. Methodologies for Purchased Software Packages
399modified because the business practices they support arequite standardized and the
vendor did not develop thepackage with modifications in mind (Rockart and Hofman,1992).
If the package is modified, there might be severaloptions to consider for how to accomplish
the changes: acontract with the vendor, a contract with a third party, ormodifying the software
with in-house resources. Many vendors routinely contract to make the desired modifica-tions.
If a vendor will furnish only the machine-languagecode for the applicationnot the source
code in which theprogram was writtenthe only alternative might be tocontract with the
vendor to make the modifications.
IMPLEMENTATION PHASE The Implementation phaseof the SDLC involves installation,
operations, and mainte-nance.
Installation The installation stage in the SDLC involvesinstallation planning, training, data
cleanup, and conver-sion. The installation of a packaged system also includesall these
activities. A key factor in a successful installationof a packaged system is the quality of
vendor support dur-ing this step (Lucas et al., 1988).
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 companys 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 downside, however, is that the purchasing company becomes totally dependent upon the vendor for
future system changes. (This is especially true for so-called proprietary softwarebut, as we

discuss in a subsequent section, open-source software is built on a different purchasingmaintenance 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.
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
systems capabilities and the organizations 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.
Managing a Purchased System Project

PURCHASING SMALL SYSTEMS The discussion in this chapter has focused on the
purchasing process for large, complex systems. If a smaller, simpler system is being
considered, the time and effort put into the process can, of course, be scaled back. However, a
small system can still be a major investment for a small business. Unfortunately, many small
businesses have limited experience with and knowledge of evaluating and installing such
systems. The services of a hardware vendor, a local software supplier, as well as external
consultants might therefore be needed.