Chapter 10 • Methodologies for Purchased Software Packages 391using internal IS resources. In this chapter, therefore, we
begin by better understanding the overall business and IT
benefits that an organization needs to consider when it has
a choice between purchasing a software application and
but customization can make upgrading the package much
more difficult as new releases occur and may be limited
by what the software license allows for the package to be
supportable by the vendor. Another choice is for the
organization to change its processes to match those sup-
ported by the software. This could be desirable, albeit
painful, if organizational processes are inefficient or not
current best practices. This downside alone means that
organizations should have a very good process in place
that will help them make the best trade-off decisions
about software features and capabilities for the organiza-
tion. As described next, this requires a methodology that
will take into account knowledge of the package’s capa-
bilities as well as informed business and technical
judgments about how well the package will meet the
organization’s needs.
Other issues that play a role in making the make-
or-buy decision are the financial viability of the major or
desired vendors, whether the software fits with the chosen
system software of the organization, whether the vendor
has a vision for enhancement of the package that is com-
patible with the future (not just current) needs of your
organization, the reliability of the vendor in delivering new
releases on time, and the total cost of ownership (i.e., con-
sidering not just the purchase cost but also longer-term
costs to maintain and upgrade the software—an especially
critical factor to consider with open-source packages,
which we discuss later in the chapter).
At the end of this chapter we also briefly discuss the
procurement option that includes contracting with a
vendor to “host” (run) one or more applications (e.g.,
Salesforce.com) for a business firm under a leasing con-
tract (see the section of this chapter entitled “New
Purchasing Option: Application Service Providers”). The
process for deciding on an application service provider is
similar to the process for deciding on a purchased software
package, with some special considerations because of the
remote connection to data and software.Purchasing Methodology
Let’s turn now to the detailed steps of a life-cycle process
for selecting, modifying, and implementing software
application packages. After describing the individual stepsThe Make-or-Buy Decision
The choice between building a custom application and
purchasing (or leasing) a software package—a make-or-
buy decision—should be made jointly by the business
managers who need the software and the IS professionals
who have the knowledge to assess the technical benefits
and risks. For organizations with their own skilled IS per-
sonnel, the three most obvious advantages of packaged
software are (1) cost savings, (2) faster speed of implemen-
tation of quality software, and (3) internal staff available to
work on other applications that were not purchased. A
software package usually costs less than a custom solution
because the software vendor will be selling the package to
many organizations. That is, the companies that acquire
the software will be sharing the development and upgrade
costs of the package. Some additional cost for customiza-
tion by internal staff or consultants is usually necessary
(e.g., to make report headings local, to use company-
specific data names). A software package also typically
can be implemented sooner than a custom application
because it already exists; in today’s fast-changing business
environments, this can be a very important advantage. This
can be important when IT and business staff lack sufficient
experience with the application, thus making a develop-
ment project especially risky. A package may be preferred
to support core, generic business functions on which your
organization does not compete with other organizations
that could also acquire the same technology. Of course, the
real advantage comes from intelligently using the package
in ways competitors cannot. Internal staff can then devote
their time to making all applications interoperate and
developing applications that require local knowledge or
have a competitive advantage.
However, there also are some downsides. One
major downside of buying an application solution is that
packaged software seldom exactly fits a company’s
needs. For the organization that is acquiring a package to
replace an older, custom-developed system, this type of
change can have several important ramifications for the
business. Most commonly, it means that business users
might be asked to “give up” features of the older custom
software that the package does not support. The package
may be able to be customized to add distinctive features,
developing a customized application. Next we will
describe in detail the process steps for selecting, preparing
for, and implementing a software application package, as
well as some of the project team roles and keys to success.