Summary

  1. A feasibility study is conducted to select the best system that meets performance requirements. This entails an identification description, an evaluation of candidate systems, and the selection of the best system for the job.

   2. A system's required performance is defined by a statement of constraints, the identification of specific system objectives, and a description of outputs. The analyst is then ready to evaluate the feasibility of candidate systems to produce these outputs.

   3. Three key considerations are involved in feasibility analysis: economic, technical, and behavioral. Economic analysis (known as cost/benefit analysis) determines whether the adoption of a system can be cost·· justified. Technical considerations evaluate existing headwear-e and soft­ ware. Behavioral feasibility determines how much effort will go into educating, selling, and training the user staff on a candidate system.

   4. There are eight steps in a feasibility study:

   a. Form a project team and appoint a project leadeIr.

   b. Prepare system flowcharts.

   c. Enumerate potential caqdidate systems.

   d. Describe and identify characteristics of candidate systems.

   e. Determine and evaluate performance and cost effectiveness of each candidate system.

   f. Weight system performance and cost data.

   g. Select the best candidate system.

   h. Prepare and report project directive to management.

        Key Words

 Candidate System

 Cost/Benefit Analysis 

 Feasibility Study

 Response Time

 Source Code

 Source Language

Review Questions

  1. What makes up a system performance definition? Select a situation with which you are familiar and explain the steps to prepare the definition.

 2. "Many feasibility studies produce disillusions to users and analysts." Do you agree? Why? Explain.

  3. What considerations are involved in feasibility analysis? Which consideration do you think is the most crucial? Why?

   4. Elaborate on the steps in feasibility analysis. If you were to shorten them to four steps, which ones would you pick? Why?

   5. How important is a project team in feasibility analysis? Is it mandatory in eve!)' study? Where are the exceptions?

   6. Use Table 7-3 as the basis for detemining alternative performance/cost factors between the IBM PC jr. and Apple's MacIntosh systems. Which one would you recommend for the safe deposit department of the bank?

Oral Presntation

The feasibility report is a good written presentation documenting the activities involving the candidate system. The pivotal step, however, is selling the proposed change. Invariably the project leader or analyst is expected to give an oral presentation to the end use. Although it is not as polished as the written redpoll’s, the oral presentation has several important objectives, The most critical requirements for the analyst who gives the oral presentation are (11 communication skills and knowledge about the candidate sys­ tem that can be translated into language und8l'standable to the user, and (2) the ability to answer questions, clarify issues, maintain credibility, and pick up on any new ideas or suggestions.

The substance and form of the presentation depend largely on the purposes sought. The presentation may aim at informing, confirming, or persuading
1. Informing. This simply means communicating the decisions already reached on system recommendations and the resulting action plans to those who will participate in the implementation. No detailed findings or conclusions are included.
2. Confirming. A presentation with this purpose verifies facts and recommendations already discussed and agreed upon. Unlike the persuading
3.
1. Introduction.
a. Introduce self
b. Introduce topic.
c. Briefly describe current system
1. Explain why it is not solving the problem.

2. Body of presentation.
a. Highlight weaknesses of current system.
b. Describe proposed system. How is it going to solve the problem?
c. Sell proposed system.
1. Specify savings and benefits, costs and expenses.
2. Use visual aids to justify project and explain system.
d. Summarize implementation plan and schedule.
e. Review human resources requirements to install system.
f.
3. Conclusion.
a. Summarize proposal.
b. Restate recommendations and objectives of proposal.
c. Ask for' top-level management support. Solicit go-ahead for project.
4. Discussion period-Answer questions convincingly. approach, no supportive evidence is presented to sell the proposed change, nor is there elaborate reasoning behind recommendations and conclusions. Although the presentation ;s not detailed, it should be complete. Confirming is itself part of the process of securing approval. It should reaffirm the benefits of the candidate system and provide a clear statement of results to be achieved.
approach, no supportive evidence is presented to sell the proposed change, nor is there elaborate reasoning behind recommendations and conclusions. Although the presentation ;s not detailed, it should be complete. Confirming is itself part of the process of securing approval. It should reaffirm the benefits of the candidate system and provide a clear statement of results to be achieved
IV. Discussion period-Answer questions convincingly.
approach, no supportive evidence is presented to sell the proposed change, nor is there elaborate reasoning behind recommendations and conclusions. Although the presentation ;s not detailed, it should be complete. Confirming is itself part of the process of securing approval. It should reaffirm the benefits of the candidate system and provide a clear statement of results to be achieved.
3. Persuading. This is a presentation pitched toward selling ideas-at­ tempts to convince executives to take action on recommendations for implementing a candidate system.

,Regardless of the purpose sought, the effectiveness of the oral presentation depends on how successful the project team has been in gaining the confidence of frontline personnel during the initial investigation. How the recommendations are presented also has an impact. Here are some pointers on how to give an oral presentation:

1. Rehearse and test your ideas before the presentation. Show that you <1I'e in command. Appear relaxed
2. Final recommendations are more easily accepted if they are presented as ideas far discussion, even though they seem to be settled and final.

3. The presentation should be brief, factual, and interesting. Clarity and persuasiveness are critical. Skill is needed to generate enthusiasm and interest throughout the presentation.
4. Use good organization. Distribute relevant material to the user and other parties in advance.
5. Visual aids (graphs, charts) are effective if they are simple, meaningful, and imaginative. An effective graph should teach or tell what is to be communicated.
6. Most important, present the report in an appropriate physical environment where the acoustics, seating pattern, visual aid technology, and refreshments are all available.

The most important element to consider is the length of the presentation The duration often depends on the complexity of the project, the interest of the user group, and the competence of the project team. A study that has companywide applications and took months to complete would require hours or longer to present. The user group that was involved at the outset would likely permit a lengthy presentation, although familiarity with the project often dictates a brief presentation. Unfortunately, many oral presentations tend to be a rehash of the written document, with little flare or excitement. Also, when the analyst or the project leader has a good reputation and success record from previous projects, the end user may request only a brief presentation.

Feasibility Report

The culmination of the feasibility study is a feasibility report directed to management; it evaluates the impact of the proposed changes on the area(s) in question. The report IS a formal document for management use, brief enough and sufficiently nontechnical to be understandable, yet detailed enough to provide the basis for system design.

There is no standard format for preparing feasibility reports. Analysts usually decide on a format that suits the particular user and system. Most reports, however, begin with a summary of findings and recommendations, -followed by documented details. Starting with summary information high­ lights the esse/1ce of the report, giving management the option of reviewing the details later. The report contains the following sections:

1. Cover letter formally presents the report and briefly indicates to management the nature, general findings, and recommendations to be considered.
2. Table of contents specifies the location of the various parts of the report.
Management quickly refers to the sections that concern them.
3. Overview is a narrative explanation of the purpose and scope of the project, the reason for undertaking the feasibility study, and the department(s) involved or affected by the candidate system. Also included are the names of the persons who conducted the study when it began, and other information that explains the circumstances surrounding the study.
4. Detailed findings outline the methods used in the present system. The system's effectiveness and efficiency as well as operating costs are emphasized. The section also provides a description of the objectives and general procedures of the candidate system: A discussion of output reports, costs, and benefits gives management a feel for the pros and cons of the candidate system.
5. Economic justification details point-by-point cost comparisons and preliminary cost estimates for the development and operation of the candidate system. A return on investment (ROl) analysis of the project is also included.
6. Recommendations and conclusions suggest to management the, most beneficial and cost-effective" system. They are written only as a recommendation, not a command. Following the recommendations, any conclusions from the study may be included.
7. Appendixes document all memos and data compiled during the investigations. They are placed at the end of the report for reference.

Disapproval of the feasibility report is rare if it has been conducted properly. When a feasibility team has maintained good rapport with the user and his/her staff it makes the recommendations easier to approve. Technically, the report is only a recommendation, but it is an authoritative one. Management has the final say. Its approval is required before system design is initiated. Chapter 9 covers in detail the .design phase of the system .life cycle.

Select The Best Candidate System

The system with the highest total score is judged the best system. This assumes the weighting factors are fair and the rating of each evaluation­ criterion is accurate. According to our safe deposit example in the IBM PC is the best system for the job. Growth potential was the criterion that had the greatest effect on the total score. The HP 100 and the Apple III were given lower ratings than the IBM PC because they were not judged to grow as easily and quickly. Additionally, user training was judged superior for the PC than for other candidate systems.

Most feasibility studies select from more candidate systems than we used in our safe deposit example. The criteria chosen and the constraints are also more complex. In any case, management should not make the selection without having the experience to do so. Management cooperation and comments, however, are encouraged.

Weight System Performance And Cost Data

In some cases, the performance and cost data for, each candidate system show which system is the best choice. This outcome terminates the feasibility study. Many times, however, the situation is not so clear-cut. The performance/cost evaluation matrix in does not clearly identify the best system, so the next step is to weight the importance of each criterion by applying a rating figure. Then the candidate system with the highest total score is selected.

The procedure for weighting candidate systems is simple:

1. Assign a weighting factor to each evaluation criterion based on the criterion's effect on the success of the system. For example, if the usability criterion is twice as important as the accuracy factor, usability is assigned weight 4 and accuracy is assigned weight 2.
2. Assign a quantitative rating to each criterion's qualitative rating. For example, ratings (poor, fair, good, very good, excellent) may be assigned respective values (I, 2, 3, 4, 5).
3. Multiply the weight assigned to each category by the relative rating to determine the score.
4. Sum the score column for each candidate system.

Determine And Evaluate Performance And Cost Effectiveness Of Each Candidate System

Each candidate system's performance is evaluated against the system performance requirements set prior to the feasibility study. Whatever the criteria, there has to be as close a match as practicable, although trade-offs are often necessary to select the best system. In the safe deposit case, the criteria chosen in advance were accuracy, gamut potential, response time less than five seconds, expandable main and auxiliary storage, and user­ friendly software. Often these characteristics do not lend themselves to quantitative mashies. They are usually evaluated in qualitative terms (excellent, good, etc.) based on the subjective judgment of the project team.

The cost encompasses both designing and installing the system, it includes, user training, updating the physical facilities, and documenting. System performance criteria are evaluated against the cost of each system to determine which system is likely to be the most cost effective and also meets the performance requirements, the safe deposit problem is easy. The analyst can plot performance criteria and costs {or each system to determine how each fares.

Costs are more easily determined when the benefits of the system are tangible and measurable. An additional factor to consider is the cost of the study design and development. As shown in Table 7-4, the cost estimate (if each phase of the safe deposit project was determined for the candidate system (IBM PC). In many respects, the cost of the study phase is a "sunk cost" (fixed cost). Including it in the project cost estimate is optional.

Describe And Ldentify Characteristics Of Candidate Systems

From the candidate systems considered, the team begins a preliminary evaluation in an attempt to reduce them to a manageable number. Technical knowledge and expertise in the hardware/software area are critical for determining what each candidate system can ad cannot do. In OUI' safe deposit example, a search for the available microcomputers and safe de­ posit billing packages revealed the information summarized in Table 7-1.

These packages were the result of a preliminary evaluation of more than 15 other packages-all purporting to meet the requirements of the safe deposit billing system. When the number is reduced to three key packages, the next step is to describe in some detail the characteristics of each package. For example, the first candidate system runs on an IBM PC with a minimum of 128K-bytes of memory. The software is written in Pascal, a relatively new language. In case of enhancements, change has to be made through the software house, since the source code is not available to the user. The first package was installed in Jal1ualY 1982. More than 200 pack­ ages have been installed to date.

The next two candidate systems are similarly described. The information along with additional data available through the vendor highlight the positive and negative features of each system. The constraints unique to each system are also specified. For example, in the IBM PC package, the lack of an available source code means that the user has to secure a maintenance contract that costs 18 percent of the Patrice of the package per year. In contrast, the HP 100 package is less expensive and offers a source code to the user. A maintenance contract (optional) is available at 8 percent of the price of the package.

Enumerate Potential Candidate Systems

This step identifies the candidate systems that are capable of producing the outputs included in the generalized flowcharts. This requires a transformation from logical to physical system models. Another aspect of this step is consideration of the hardware that can handle the total system requirements. In the safe deposit case, it was found that virtually any microcomputer system with more than 128K-byte memory and dual disk drive will do the job. It was also learned that a microcomputer can be designed to. Interface with the bank's mainframe. In this design, actual processing is handled by the microcomputer, whereas information such as payments and credits are transmitted to the main computer files for proper adjustment through the customer's checking account. The question here is which microcomputer (IBM, Apple, Digital, etc.) should be selected? This is taken up in step 6 of the study.

An important aspect of hardware is processing and main memory. There are a large number of computers with differing processing sizes, main memory capabilities, and software support. The project team may contact vendors for information on the processing capabilities of the system avail­ able.

Prepare System Flowcharts

The next step in the feasibility study is to prepare generalized system flowcharts for the system. Information-oriented charts and data flow diagrams prepared in the initial investigation are also reviewed at this time.
The charts bring up the importance of inputs, outputs, and data flow among key points in the existing system. All other flowcharts needed for detailed evaluation are completed at this point.

Form A Project Team And Appoint A Project Leader

Form a Project Team and Appoint a Project Leader

The concept behind a project team is that future system users should be involved in its design and implementation. Their knowledge and experience in the operations area are essential to the success of the system. For small projects, the analyst and an assistant usually suffice; however, more complex studies require a project team. The team consists of analyst’s al1d user staff-enough collective expertise to devise a solution to the problem. In many cases, an outside consultant and an information specialist join the team until the job is completed.

Projects are planned to occupy a specific time period, ranging from several weeks to months. The senior systems analyst is generally appointed as project leader. He/she is usually the most experienced analyst in the team. The appointment is temporary/lasting as long as the project. Regular meetings take place to keep up the momentum and accomplish the mission-selection of the best candidate system. A record is kept of the progress made in each meeting.

Regarding the safe deposit case, since the whole user area consists of five employees, the analyst handled most of the work.

Steps In Feasibility Analysis

Feasibility analysis involves eight steps:

1. Form a project team and appoint a project leader.
2. Prepare system flowcharts.
3. Enumerate potential candidate systems.
4. Describe and identify characteristics of candidate systems.
5. Determine and evaluate performance and cost effectiveness of each candidate system.
6. Weight system performance and cost data.
7. Select the best candidate system.
8. Prepare and report final project directive to management.

Behavioral Feasibility

People are inherently resistant to change, and computers have been known to facilitate change. An estimate should be made of how strong a reaction the user staff is likely to have toward the development of a computerized system. [t is common knowledge that computer installations have something to do with turnover, transfers, retraining, and changes in employee job status. Therefore, it is understandable that the introduction of a candidate system requires special effort to educate, sell, and train the staff on new ways of conducting business.

In our safe deposit example, three employees are more than 50 years old and have been with the bank over 14 years, four years of which have been in safe deposit. The remaining two employees are in their early thirties. They joined safe deposit about two years before the study. Based on data gathered from extensive interviews, the younger employees want the programmable aspects of safe deposit (essentially billing) put on a computer. Two of the three older employees have voiced resistance to the idea. Their view is that billing is no problem. The main emphasis is customer service-personal contacts with customers. The decision in this case was to go ahead and pursue the project.

Technical Feasibility

Technical feasibility centers around the existing computer system (hardware, software , etc) and to what extent it can support the proposed addition. For example, if the current computer is operating at 80 percent capacity-an arbitrary ceiling-then running another application could overload the system or require additional hardware. This involves financial considerations to accommodate technical enhancements. If the budget is a serious constraint, then the project is judged not feasible.

Economic Feasibility

Economic analysis is the most frequently used method for evaluating the effectiveness of a candidate system. More commonly known as cost/benefit analysis, the procedure is to determine the benefits and savings that are expected from a candidate system and compare them with costs. If benefits outweigh costs, then the decision is made to design and implement the system. Otherwise, further justification or alterations in the proposed system will have to be made if it is to have a chance of being approved. This is an ongoing effort that improves in accuracy at each phase of the system life cycle. More on cost/benefit analysis is covered in Chapter.

Feasibilit Considerations

Three key considerations are involved in the feasibility analysis: economic, technical, behavioral. Let's briefly review each consideration and how it relates to the systems effort.

Feasibibity Study

Many feasibility studies are disillusioning for both users and analysts. First, the study often presupposes that when the feasibility document is being prepared, the analyst is in a position to evaluate solutions. Second, most studies tend to overlook the confusion inherent in system development-the constraints and the assumed attitudes. If the feasibility study is to serve as a decision document, it must answer three key questions:

1. Is there a new and better way to do the job that will benefit the user?
2. What are the costs and savings of the alternative (S)?
3. What is recommended?

The most successful system projects are not necessarily the biggest or most visible in a business but rather those that truly meet user expectations. More projects fail because of inflated expectations than for any other reason.

Description Of Output

A final step in system performance definition is describing the outputs required by the user. An actual sketch of the format and contents of the reports (layout) as well as a specification of the media used, their frequency, and the size and number of copies required are prepared at this point. Specifying exactly what the output will look like leads to an estimate of the computer storage requirements that form the basis for the file design to be undertaken in the design phase of the life cycle. The analyst is now ready to evaluate the feasibility of candidate systems to produce these outputs.

Identification Of Specific System Objectives

Once the constraints are spelled out, the analyst proceeds to identity the system's specific performance objectives. They are derived from the general objectives specified in the project directive at the end of the initial investigation. The steps are to state the system's benefits and then translate them into measurable objectives. In our scenario, the candidate systems anticipated benefits are as follows:

1. Improved collection schedule.
2. Cost reduction.
3. Physical space reduction.
4. Improved customer service

Each benefit is analyzed and translated into measurable objectives.

1. Collection is improved by billing 30 days in advance of the box renewal date, and one more notice is sent within two weeks. It also improves the accounts receivables payment "float."
2. Cost reduction is realized by reducing the payroll by two employees.
The new online billing system requires less than two hours of labor per day, compared with six hours under the current system.
3. Physical space requirements are reduced by placing the microcomputer in the place of one of the four existing desks. The remaining desks are removed, allowing an extra cubicle for customer use.
4. Customer service is improved by placing master cards and box rental information online, thus educing the waiting time of entry from minutes to 30 seconds.

These objectives are effective in comparing the performance of the candidate system with that of the current system. The information-oriented flowchart, input/output analysis sheet, and data flow diagram (see Chapter 4) produced in the initial investigation lead to the conclusions that (1) the current system is inefficient and (2) a new online, terminal-oriented system would be the solution. This conclusion was reflected in the general project directive submitted to the user for approval. This information is used as a basis for preparing specific objectives for the candidate system:

1. To establish a billing system with six five-day eye! 's per month.
2. To mail customers no later than the close of the billing cycle and no later than 25 days prior to the box renewal date.
3. To mail customers a reminder two weeks after the initial statement for box renewal.
4. To speed collections and reduce the "float" by 40 percent.
5. To examine the availability of boxes by size, rental fees, and location.
6. To examine the availability of boxes by size, rental fees, and location.
7. To produce periodic reports to management on the performance of the safe deposit department.

Statement of Constraaints

Constraints are factors that limit the solution of the problem. Some constraints are identified during the initial investigation find are discussed with the user. There are general constraints that might have a bearing on the required performance of a candidate system. Let's consider our safe deposit billing system to illustrate these points. We described the current billing system and how the department handles billing and customer payments. The result of the fact-finding phase of the initial investigation revealed the following general constraints:

1. The president views safe deposit billing as a low priority. He has a false impression that computers are not needed as long as customers can heave access to their boxes.
2. The senior vice president is worried that a billing system might require the transfer of safe deposit staff to other departments. Considering Florida's level of unemployment and the cost of retraining, a candidate system has' to do more than produce reports.
3. The accounting department has 'been pushing for installing a computer-based general ledger application for months. The vice president of operations, bogged down with auditing and operations problems, continued to shelve the request.
4. Management has a limited knowledge of computers, although it has several applications on the computer: checking and savings, installment loans, commercial loans, and trusts. The president, in his early sixties and interested in "the bottom line" of the financial statement, is traditionally reluctant to spend money on computers
5. Safe deposit, while doing better than breaking even, is not projected to grow as fast as it did in the early 1980s. The community's recent success in controlling burglaries had an adverse impact on the demand for box rentals in general.
6. If an online system is to be installed, it must interface with the existing checking/savings application to allow for the automatic payment of box rentals.
7. A proposed design must be compatible with the bank's Burroughs computer system.

Systm Performance Definition

A system's required performance is defined by describing its outputs in a user-acceptable format and at a higher level of detail than what was described in the initial investigation. This involves three steps:

1. Statement of constraints.
2. Identification of specific system objectives.
3. Description of outputs.

This phase builds on the previous phase in that much of the work may already have been done.