Managing the Systems Development Life Cycle:Systems Evaluation and Selection.

Systems Evaluation and Selection

This phase in the SDLC is a formal mechanism for selecting the one system from the set of alternative conceptual designs that will go forward for construction. The systems evaluation and selection phase is an optimization process that seeks to identify the best system. This decision represents a critical juncture in the SDLC. At this point, there is a great deal of uncertainty about the system, and a poor decision can be disastrous. The purpose of a formal evaluation and selection procedure is to structure this decision- making process and thereby reduce both uncertainty and the risk of making a poor decision.

There is no magic formula to ensure a good decision. Ultimately, the decision comes down to management judgment. The objective is to provide a means by which management can make an informed judgment. This selection process involves two steps:

1. Perform a detailed feasibility study.

2. Perform a cost-benefit analysis.

The results of these evaluations are then reported formally to the steering committee for final system selection.

PERFORM A DETAILED FEASIBILITY STUDY

We begin the system selection process by reexamining the feasibility factors that were evaluated on a preliminary basis as part of the systems proposal. Originally, the scores assigned to these factors were based largely on the judgment and intuition of the systems professional. Now that specific system features have been conceptualized, the designer has a clearer picture of these factors. Also, at the proposal stage, these factors were evaluated for the entire project. Now they are evaluated for each alternative conceptual design.

Informed evaluators should perform the detailed feasibility study. Objectivity is essential to a fair assessment of each design. This group should consist of the project manager, a user representative, and systems professionals who have expertise in the specific areas that the feasibility study covers. Also, for operational audit reasons, the group should contain a member of the internal audit staff. The feasibility factors that were introduced in the previous section provide a framework for identifying the key issues that evaluators should consider.

Technical Feasibility

In evaluating technical feasibility, a well-established and understood technology represents less risk than an unfamiliar one. If the systems design calls for established technology, the feasibility score will be high, say 9 or 10. The use of technology that is new (first release) and unfamiliar to systems professionals who must install and maintain it, or that is a hybrid of several vendors’ products, is a more risky option. Depending on the number and combination of risk factors, the feasibility score for such technology will be lower.

Legal Feasibility

In financial transaction processing systems, the legality of the system is always an issue. However, legal- ity is also an issue for nonfinancial systems that process sensitive data, such as hospital patient records or personal credit ratings. Different systems designs may represent different levels of risk when dealing with such data. The evaluator should be concerned that the conceptual design recognizes critical control, security, and audit trail issues and that the system does not violate laws pertaining to rights of privacy and/or the use and distribution of information.

Operational Feasibility

The availability of well-trained, motivated, and experienced users is the key issue in evaluating the operational feasibility of a design. If users lack these attributes, the move to a highly technical environment may be risky and will require extensive retraining. This may also affect the economic feasibility of the system. On the other hand, a user community that is comfortable with technology is more likely to make a smooth transition to an advanced technology system. The operational feasibility score of each alternative design should reflect the expected ease of this transition.

Schedule Feasibility

At this point in the design, the system evaluator is in a better position to assess the likelihood that the sys- tem will be completed on schedule. The technology platform, the systems design, and the need for user training may influence the original schedule. The systems development technology being used is another influence. The use of computer-aided software engineering (CASE) and prototyping tools (discussed in Chapter 14) can significantly reduce the development time of any systems design option.

Economic Feasibility

The preliminary economic feasibility study was confined to assessing management’s financial commitment to the overall project. This is still a relevant issue. Whether the economic climate has changed since the preliminary study or whether one or more of the competing designs does not have management’s sup- port should now be determined.

The original feasibility study could specify the project’s costs only in general terms. Now that each competing design has been conceptualized and expressed in terms of its unique features and processes, designers can be more precise in their estimates of the costs of each alternative. The economic feasibility study can now be taken a step further by performing a cost-benefit analysis.

PERFORM COST-BENEFIT ANALYSIS

Cost-benefit analysis helps management determine whether (and by how much) the benefits received from a proposed system will outweigh its costs. This technique is frequently used for estimating the expected financial value of business investments. In this case, however, the investment is an information system, and the costs and benefits are more difficult to identify and quantify than those of other types of capital projects. Although imperfect in this setting, cost-benefit analysis is employed because of its simplicity and the absence of a clearly better alternative. In spite of its limitations, cost-benefit analysis, combined with feasibility factors, is a useful tool for comparing competing systems designs.

There are three steps in the application of cost-benefit analysis: identifying costs, identifying benefits, and comparing costs and benefits.

Identify Costs

One method of identifying costs is to divide them into two categories: one-time costs and recurring costs. One-time costs include the initial investment to develop and implement the system. Recurring costs include operating and maintenance costs that recur over the life of the system. Table 13-2 shows a break- down of typical one-time and recurring costs.

One-Time Costs

HARDWARE ACQUISITION. This includes the cost of mainframe servers, PCs, and peripheral equipment, such as networks and disk packs. The cost figures for items can be obtained from the vendor.

SITE PREPARATION. This involves such frequently overlooked costs as building modifications, for example, adding air-conditioning or making structural changes; equipment installation, which may include the use of heavy equipment; and freight charges. Estimates of these costs can be obtained from the vendor and the subcontractors who do the installation.

SOFTWARE ACQUISITION. These costs apply to all software purchased for the proposed system, including operating system software, if not bundled with the hardware; network control software; and commercial applications, such as accounting packages. Estimates of these costs can be obtained from vendors.

SYSTEMS DESIGN. These are the costs that systems professionals incur performing the planning, analysis, and design functions. Technically, such costs incurred up to this point are sunk and irrelevant to the decision. The analyst should estimate only the costs needed to complete the detailed design.

PROGRAMMING AND TESTING. Programming costs are based on estimates of the personnel hours required to write new programs and modify existing programs for the proposed system. System testing costs involve bringing together all the individual program modules for testing as an entire system. This must be a rigorous exercise if it is to be meaningful. The planning, testing, and analysis of the results may demand many days of involvement from systems professionals, users, and other stakeholders of the sys- tem. The experience of the firm in the past is the best basis for estimating these costs.

DATA CONVERSION. These costs arise in the transfer of data from one storage medium or structure to another. For example, the accounting records of a manual system must be converted to digital form when the system becomes computer-based. This can represent a significant task. The basis for estimating conversion costs is the number and size of the files to be converted.

TRAINING. These costs involve educating users to operate the new system. This could be done in an extensive training program that an outside organization provides at a remote site or through on-the-job training by in-house personnel. The cost of formal training can be easily obtained. The cost of an in-house training program includes instruction time, classroom facilities, and lost productivity.

Recurring Costs

HARDWARE MAINTENANCE. This involves the cost of upgrading the computer (for example, increasing the memory), as well as preventive maintenance and repairs to the computer and peripheral equipment. The organization may enter into a maintenance contract with the vendor to minimize and budget these costs. Estimates for these costs can be obtained from vendors and existing contracts.

SOFTWARE MAINTENANCE. These costs include upgrading and debugging operating systems, purchased applications, and in-house developed applications. Maintenance contracts with software vendors can be used to specify these costs fairly accurately. Estimates of in-house maintenance can be derived from historical data.

INSURANCE. This covers such hazards and disasters as fire, hardware failure, vandalism, and destruction by disgruntled employees.

SUPPLIES. These costs are incurred through routine consumption of such items as printer cartridges and paper, magnetic disks, magnetic tapes, and general office supplies.

PERSONNEL. These are the salaries of individuals who are part of the information system. Some employee costs are direct and easily identifiable, such as the salaries of operations personnel exclusively employed as part of the system under analysis. Some personnel involvement, for example, the database administrator and computer room personnel, is common to many systems. Such personnel costs must be allocated on the basis of expected incremental involvement with the system.

Identify Benefits

The next step in the cost-benefit analysis is to identify the benefits of the system. These may be both tangible and intangible.

TANGIBLE BENEFITS. Tangible benefits are benefits that can be measured and expressed in financial terms. Table 13-3 lists several types of tangible benefits.

Tangible benefits fall into two categories: those that increase revenue and those that reduce costs. For example, assume a proposed EDI system will allow the organization to reduce inventories and at the same time improve customer service by reducing stock-outs. The reduction of inventories is a cost- reducing benefit. The proposed system will use fewer resources (inventories) than the current system. The value of this benefit is the dollar amount of the carrying costs that the annual reduction in inventory saves. The estimated increase in sales because of better customer service is a revenue-increasing benefit.

When measuring cost savings, only escapable costs should be included in the analysis. Escapable costs are directly related to the system and cease to exist when the system ceases to exist. Some costs that appear to be escapable to the user are not truly escapable and, if included, can lead to a flawed analysis. For example, data processing centers often charge back their operating costs to their user constituency through cost allocations. The charge-back rate they use for this includes both fixed costs (allocated to users) and direct costs that the activities of individual users create. Figure 13-7 illustrates this technique.

Assume the management in User Area B proposes to acquire a computer system and perform its own data processing locally. One benefit of the proposal is the cost savings derived by escaping the charge-back from the current data processing center. Although the user may see this as a $400,000 annual charge, the organization as a whole can only escape the direct cost portion ($50,000). Should the proposal be approved, the remaining $350,000 of the charge-back does not go away. The remaining users of the current system must now absorb this cost.

INTANGIBLE BENEFITS. Table 13-4 lists some common categories of intangible benefits. Although intangible benefits are often of overriding importance in information system decisions, they cannot be

easily measured and quantified. For example, assume that a proposed point-of-sale system for a department store will reduce the average time to process a customer sales transaction from 11 minutes to 3 minutes. The time saved can be quantified and produces a tangible benefit in the form of an operating cost savings. An intangible benefit is improved customer satisfaction; no one likes to stand in long lines to pay for purchases. But what is the true value of this intangible benefit to the organization? Increased customer satisfaction may translate into increased sales. More customers will buy at the store—and may be

willing to pay slightly more to avoid long checkout lines. But how do we quantify this translation? Assigning a value is often highly subjective.

Systems professionals draw upon many sources in attempting to quantify intangible benefits and manipulate them into financial terms. Some common techniques include customer (and employee) opinion surveys, statistical analysis, expected value techniques, and simulation models. Even though systems professionals may succeed in quantifying some of these intangible benefits, more often they must be con- tent to simply state the benefits as precisely as good judgment permits.

Because they defy precise measurement, intangible benefits are sometimes exploited for political reasons. By overstating or understating these benefits, a system’s proponents may push it forward or its opponents may kill it.

Compare Costs and Benefits

The last step in the cost-benefit analysis is to compare the costs and benefits identified in the first two steps. The two most common methods used for evaluating information systems are net present value and payback.

THE NET PRESENT VALUE METHOD. Under the net present value method, the present value of the costs is deducted from the present value of the benefits over the life of the system. Projects with a positive net present value are economically feasible. When comparing competing projects, the optimal choice is the project with the greatest net present value. Figure 13-8 illustrates the net present value method by comparing two competing designs.

The example is based on the following data:

If costs and tangible benefits alone were being considered, then Design A would be selected over Design B. However, the value of intangible benefits, along with the design feasibility scores, must also be factored into the final analysis.

THE PAYBACK METHOD. The payback method is a variation of break-even analysis. The break- even point is reached when total costs equal total benefits. Figures 13-9(a) and 13-9(b) illustrate this approach using the data from the previous example.

The total cost curve consists of the one-time costs plus the present value of the recurring costs over the life of the project. The total benefits curve is the present value of the tangible benefits. The intersection of these lines represents the number of years into the future when the project breaks even, or pays for itself. The shaded area between the benefit curve and the total cost curve represents the present value of future profits that the system earned.

In choosing an information system, payback speed is often a decisive factor. With brief product life cycles and rapid advances in technology, the effective lives of information systems tend to be short. Using this criterion, Design B, with a payback period of 4 years, would be selected over Design A, whose payback will take 4½ years. The length of the payback period often takes precedence over other considerations represented by intangible benefits.

PREPARE SYSTEMS SELECTION REPORT

The deliverable portion of the systems selection process is the systems selection report. This formal document consists of a revised feasibility study, a cost-benefit analysis, and a list and explanation of in- tangible benefits for each alternative design. On the basis of this report, the steering committee will select a single system that will go forward to the next phase of the construct phase of the SDLC.

In-House Development or Purchase Commercial Software

Two general options are open to the organization in the construct phase: develop the system in-house or purchase commercial software. At this juncture, management should have a good sense as to which option it will follow. Systems that need to meet unique and proprietary business needs are more likely to undergo in-house development. Systems that are expected to support best industry practices may be better suited to the purchased-software option. A third approach, which involves both options, is to tailor the commercial system to meet the organization’s needs. This may require making extensive in-house modifications to the package. The previous analysis of system architecture, TELOS factors, system sur- vey results, and preliminary cost-benefit issues will have revealed to decision makers the suitability of one approach over the other. Both the in-house and the commercial package options are examined in detail in Chapter 14.

ANNOUNCING THE NEW SYSTEM PROJECT

Management’s formal announcement of the new system to the rest of the organization is the last and most delicate step in the project initiation phase of the SDLC. This exceedingly important communique´, if successful, will pave the way for the new system and help ensure its acceptance among the user community.

A new system can sometimes generate considerable political backlash that may threaten its success. For example, not all users may understand the objectives of the new system. In fact, the uncertainty surrounding the system may cause some users to feel threatened. As we have seen, new systems must improve the productivity and efficiency of operations. These objectives sometimes translate into organizational restructuring that erodes the personal powerbase of some users. Because a new system brings about operational changes, some employees may be displaced or may be required to undergo retraining to function in the new workplace.

The fears that take root and grow in this environment of uncertainty are often revealed in acts of opposition, both overt and covert, to the new system. To minimize opposition, top management must quell unnecessary fears and fully explain the business rationale for the new system before formal construction begins. If lower-level management and operating staff are assured that the system will be beneficial, the project’s chances for success are vastly improved.

USER FEEDBACK

The preceding discussion was based on the assumption that the project under development passed through the strategic planning phase presented in the previous section. Not all systems projects should be, or can be, initiated in this manner. Systems maintenance is an integral component of the modern SDLC environment. This function needs to be receptive to user feedback and responsive to their legitimate needs. Therefore, user requests are also directed to the project initiation phase (refer to Figure 13-1). At this point in the SDLC, user requests involve relatively small enhancements to existing systems rather than major retrofits or entirely new systems. The IT budget must, therefore, be flexible enough to accommodate short-term quick hit projects that emerge on a daily basis.