Managing Information Technology

394 Part III • Acquiring Information Systems

The Package

Functional capabilities of the packaged system

Technical requirements the software must satisfy

Amount and quality of documentation provided

The Vendor

Business characteristics of the vendor firm

Vendor support of the package—initial

and ongoing

FIGURE 10.3 Key Criteria for Software Package Selection

Feasibility Analysis Similar to the SDLC, the

objective of this step is to determine whether the proposed

system is economically, technically, and operationally

feasible. When purchasing a system, the feasibility of

purchasing rather than building a system solution is also

being considered. This step would therefore include a

preliminary investigation of the availability of packaged

systems that might be suitable candidates, including a

high-level investigation of the software features and

capabilities provided by the vendors. In this step a more

detailed cost-benefit analysis is undertaken for project

budgeting and monitoring purposes.

Requirements Definition The requirements definition is a

critical step in the SDLC approach. The SDLC deliverable

is a detailed specification of what the system must do in

terms of the inputs it must accept, the data it must store, the

processes it must perform, the outputs it must produce, and

the performance requirements that must be satisfied. It

must be accurate, complete, and detailed because it is used

to design and program the system and because it deter-

mines the quality of the resulting system.

When purchasing the system, this step is equally

critical. In order to select the best software package, one

must first have at least a high-level conceptual understand-

ing of the system requirements. Here, however, the focus is

on defining the functional requirements of the system to

the degree needed for developing a request for proposal

(RFP) from a short list of vendors. The requirements need

to be more fully developed than the basic requirements

used to build a prototype but less detailed than the require-

ments elicited under an SDLC process when they are used

to design the actual system. Research has shown that

uncertainty about an organization’s needs is a significant

barrier to packaged software adoption.

Create Short List of Suitable Packages In this step the

organization’s requirements are used to eliminate all but a

few of the most promising candidate packages that were

identified in the feasibility analysis step. For example,

packages should be eliminated if they do not have particu-

lar required features or will not work with existing

hardware, operating system and database management

software, or networks. Further research on the vendor’s

capabilities can be undertaken to eliminate vendors due to

problems experienced with other users of the package, a

vendor’s inadequate track record or firm size, or other

concerns about long-term viability. Independent consult-

ants with expertise on specific types of applications or

specializing in a given industry can also be key resources

here and might be able to help the project team eliminate

inappropriate candidates.

Establish Criteria for Selection In this step both business

and IS team members need to work together to determine

relevant criteria about the candidate packages and vendors

in order to choose the best one. Some criteria can be cate-

gorized as mandatory requirements, whereas others could

be categorized as desirable features.

Some areas in which detailed criteria (i.e., beyond

cost) should be developed are shown in Figure 10.3. For

example, the vendor’s business characteristics could

include items such as how long the vendor has been in the

software business, the number of employees, financial

reports over the past five years, its principal products, its

yearly software sales revenue, and the location of its sales

and support offices. The packaged system’s functional ca-

pabilities should include the degree to which the package

allows for multiple options and the ease with which it can

be tailored to fit company needs using parameters or other

approaches that do not require system coding.

The technical requirements to be evaluated include

the hardware and system software (system platform)

required to efficiently run the application and the database

requirements for the package, as well as the ease of

installation within a given company’s environment. This

information allows one to evaluate how well the package

will conform to current organizational standards for hard-

ware, software, and networks. The types, amount, and

quality of the documentation provided should also be

evaluated, as well as the quality and amount of vendor

support available, including training, consulting, and

system maintenance.

In addition to detailing the evaluation criteria,

consideration should be given to the measures that will

be used in the evaluation process. It is not uncommon to

evaluate packages using a scale with numbers (e.g., 1

through 10) or qualitative labels (e.g., outstanding, good,

average, fair, or poor). If a scale with numbers is used,

each criterion can be assigned an importance weight, and

a weighted score can be computed for each evaluation