398 Part III • Acquiring Information Systems
Instead, many purchasing companies have decided
to take the middle alternative in Figure 10.6: Change
Procedures. That is, they decide that it is better for the
company to change its own procedures to match the way
the software package operates than to modify the package.
A company might in fact even find that the procedural
assumptions incorporated into the package are better ways
of doing things than those specified by the company during
the Requirements Definition step of the process. This
could occur if the software vendor has worked with one or
more leading organizations in the same industry in order to
develop the software package. For example, the vendors of
today’s large ERP packages might have worked with
industry consortia to develop modules around industry-
specific processes, and then the vendors can market their
packages as having “best practices” for the industry
embedded in their software package.
The decision to purchase a system is therefore not only
a commitment to purchase the best of the available systems
but also a commitment to whatever organizational changes
(sometimes compromises) need to be made in order to imple-
ment the system. Packaged software is a vendor’s solution to
a problem that is perceived to exist in a significant number of
firms. In many cases, the solution implements best prac-
tices—at least best for many organizations. Thus, it is likely
that discrepancies between the organization’s needs and the
package’s capabilities will exist. Before finalizing the pur-
chase decision, the project team should ensure that the
relevant business managers support the decision to buy the
selected package and agree that they will do whatever is nec-
essary to implement it successfully. Similarly, the project
team should ensure that the IS specialists agree that the
system can operate in the current environment and that they
can satisfactorily support it in-house as required.
Negotiate Contract The deliverables from this stage are a
legal contract with the vendor of the selected software
package and a detailed plan for the remainder of the
life-cycle steps. The contract with the software vendor
specifies not only the software price, number of licenses,
and payment schedule but also functional specifications,
acceptance-testing procedures, a timetable of the delivery
process, protection of trade secrets, repair and mainte-
nance responsibilities, liabilities due to failures, required
documentation, and options to terminate the agreement
(Gurbaxani and Whang, 1991). Another important element
of the contract is the rights of the customer to future
upgrades of the package—including the cost, and whether
upgrades can be skipped yet a prior release will still be
supported by the vendor.
Contract negotiations should be an integral part
of the purchase process. When working with vendors to
determine how to reduce the discrepancies between the
company’s needs and the packages’ capabilities, one is
actually prenegotiating a contract with the selected vendor.
Many organizations have software purchasing spe-
cialists who work with system project managers in the con-
tract writing and negotiation steps. Because the contract
will be the only recourse if the system or the vendor does
not perform as specified, the use of an attorney also
reduces the likelihood of future legal wrangling or a loss of
rightful claims. Once the project is under way, the project
manager needs to be familiar enough with the contractual
agreement in order to know whether an unanticipated need
for vendor services will require a formal change to the ven-
dor contract.
The contract type also has implications for the risk
level of the purchasing company. For example, under a
fixed-price contract, the buyer knows in advance the total
price that will be incurred for a specified product and ven-
dor services. Under a cost-reimbursement type of contract,
in which the buyer agrees to pay the vendor’s direct and
indirect costs, the purchasing company assumes a much
greater risk.CONSTRUCTION PHASE In the SDLC process, the
Construction phase includes three steps: system design,
system building, and system testing. With purchasing, the
extent to which the first two steps are needed depends on
whether or not the purchased package is modified, as well
as the complexity of the package itself.
Significant savings in time and money might be real-
ized if no major modifications are made to the package’s
code. Some packages, especially those sold to a mass mar-
ket, are considered “turnkey,” and they cannot be modified.
Looking back at the cost comparisons in Figure 10.2, the
Construction phase costs are the major source of the total
cost savings from purchasing a package versus building a
custom application: Even when adding in the software
purchase price itself (shown under Implementation Phase),
the costs for the Construction phase of a purchase package
are less than half as great as the Construction costs for the
customized solution. However, as stated earlier, the exam-
ple in Figure 10.2 assumes that no major modifications to
the package are required and that linkages with other
systems are not a part of this project. The $350,000 differ-
ence in total costs between the cost of building and the cost
of purchasing this particular system could therefore quickly
vanish if the assumption of no system modifications does
not hold true.
If no modifications to the system are to be made, the
firm can move to the system testing step after the purchase
contract is signed. Many off-the-shelf packages for single
functions, such as accounting applications, are often not