Chapter 10 • Methodologies for Purchased Software Packages 401example, if an RFP is sent to vendors, a purchasing special-
ist will help prepare or at least review the RFP document
before it is distributed to vendors. Firms with prior software
purchasing experience might have developed boilerplate
sections to be adapted to the type of purchase. Purchasing
specialists are also skilled in negotiating contracts that pro-
vide for contingency actions that can reduce financial and
other business risks for the purchasing company. For exam-
ple, many of today’s contracts include specific agreements
about levels of service during an installation period (see the
section entitled “Service Level Agreements” in Chapter 13).
As described earlier under the negotiate–contract
step, attorneys (who may also be purchasing specialists)
should oversee the writing and approval of the external
contract with software vendors. All associated licensing
agreements should also be reviewed in order to minimize
the associated costs and risks for the business.
Managing a Purchased System Project
Purchased system projects are successful when the organi-
zation has selected a product, and a vendor, that is able to
satisfy the firm’s current and future system needs. This
requires an effective project team with members who have
the business and technical skills and knowledge needed,
including the skills and knowledge needed for the project
team roles described previously. Unlike the traditional
SDLC process in which a long Construction phase buffers
the Definition phase from the Implementation phase, the
purchase of a software package might entail large capital
expenditures by the company within just a few months
(unless other terms are negotiated with the vendor). The
right business managers, end users, and IS specialists need
to be a part of the project team to ensure that the best pack-
age is purchased from the best vendor and that both techni-
cal and business risks have been adequately considered.
A typical problem with managing the life cycle of a
purchased system project is ensuring that adequate atten-
tion is given to the steps in the initial Definition phase. A
common mistake is that business managers learn about a
particular packaged solution from another company or a
salesperson at an industry conference and they begin nego-
tiating with the vendor without adequate attention to the
functional requirements definition step. Project teams that
do not do a good job identifying their requirements will not
be able to do a good job assessing the discrepancies
between the company’s needs and the capabilities of candi-
date packages. This increases the short-term and long-term
investment risks, because a contract with an external
vendor is not as easily changed as a project agreement
between users and internal IS developers. It is therefore
critical that the Definition phase be performed well.
For the project team members from the business side
who also have implementation responsibilities, it is also
imperative that they be representativebusiness managers
and users. Steps should be taken to ensure that they are
committed to the project goals at the outset, including the
time schedule and budget.
The success of the Implementation phase also
depends on how well the Definition phase was performed,
because this is where the team members assessed the
organizational changes needed to successfully implement
the purchased system. As discussed earlier, users of the
packaged system might be asked to make significant
changes in how they do their jobs in order to conform to
a package’s features. This requires a well-planned instal-
lation step under the leadership of committed business
managers who are very knowledgeable about the needed
changes.
In addition, purchased system projects introduce sev-
eral new types of risks. First, the success of the project is
highly dependent on the performance of a third party. The
quality of the implemented system will depend not only on
the vendor’s software engineering capabilities but also on
how well the implementing organization understands the
package’s capabilities and on the vendor’s training and
installation capabilities. As discussed earlier, a key aspect
of the vendor selection process is the accurate assessment
of the vendor’s capabilities, not just an evaluation of the
current software package.
The project’s initial success, as well as the long-term
effectiveness of the system being installed, is also highly
dependent on the contract negotiation process. In most sit-
uations system, implementation does not simply involve
“turning the key.” Vendor expertise might be required to
install the package, build interfaces to existing systems,
and perhaps modify the package itself to better match the
purchasing organization’s needs. Service expectations
between the purchaser and vendor need to be a part of the
contract developed at the end of the Definition phase.
The contract will be the only recourse for the purchaser if
the system modifications, vendor training, or the imple-
mentation of the package do not go well.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.