Introduction

1. Introduction • The chapter will address the following questions: • What are the feasibility checkpoints in the systems development life cycle? • What are the four types of feasibility and what is the description of each? • How do you perform various cost-benefit analyses using time-adjusted costs and benefits?

2. Feasibility Analysis - A Creeping Commitment Approach • Feasibility Checkpoints in the Life Cycle • Feasibility is the measure of how beneficial or practical the development of an information system will be to an organization. • Feasibility analysis is the process by which feasibility is measured. • Feasibility should be measured throughout the life cycle. • The scope and complexity of an apparently feasible project can change after the initial problems and opportunities are fully analyzed or after the system has been designed. • Thus, a project that is feasible at one point in time may become infeasible at a later point in time.

3. Feasibility Analysis - A Creeping Commitment Approach • Feasibility Checkpoints in the Life Cycle • Feasibility is the measure of how beneficial or practical the development of an information system will be to an organization. • Feasibility analysis is the process by which feasibility is measured. • Feasibility should be measured throughout the life cycle. • The scope and complexity of an apparently feasible project can change after the initial problems and opportunities are fully analyzed or after the system has been designed. • Thus, a project that is feasible at one point in time may become infeasible at a later point in time.

5. Feasibility Analysis - A Creeping Commitment Approach • Feasibility Checkpoints in the Life Cycle • Systems Analysis - A Survey Phase Checkpoint • At this early stage of the project, feasibility is rarely more than a measure of the urgency of the problem and the first-cut estimate of development costs. • It answers the question: ``Do the problems (or opportunities) warrant the cost of a detailed study of the current system?'' • Realistically, feasibility can't be accurately measured until the problems (and opportunities) and requirements (definition phase) are better understood.

6. Feasibility Analysis - A Creeping Commitment Approach • Feasibility Checkpoints in the Life Cycle • Systems Analysis - A Study Phase Checkpoint • Because the problems are better understood, the analysts can make better estimates of development costs and of the benefits to be obtained from a new system. • The minimum value of solving a problem is equal to the cost of that problem. • Development costs, at this point, are still just guesstimates. • If the cost estimates significantly increase from the survey phase to the study phase, the likely culprit is scope. • Scope has a tendency to increase in many projects. • If increased scope threatens feasibility, then scope might be reduced.

7. Feasibility Analysis - A Creeping Commitment Approach • Feasibility Checkpoints in the Life Cycle • Systems Analysis - A Definition Phase Checkpoint • The next checkpoint occurs after the definition of user requirements for the new system. • These requirements frequently prove more extensive than originally stated. • For this reason, the analyst must frequently revise cost estimates for design and implementation. • Once again, feasibility is reassessed. • If feasibility is in question, scope, schedule, and costs must be rejustified.

8. Feasibility Analysis - A Creeping Commitment Approach • Feasibility Checkpoints in the Life Cycle • Systems Analysis - A Selection Phase Checkpoint • The selection phase represents a major feasibility analysis activity since it charts one of many possible implementations as the target for systems design. • During the selection phase, alternative solutions are defined in terms of their input/output methods, data storage methods, computer hardware and software requirements, processing methods, and people implications.

9. Feasibility Analysis - A Creeping Commitment Approach • Feasibility Checkpoints in the Life Cycle • Systems Analysis - A Selection Phase Checkpoint • The following list presents the typical range of options that can be evaluated by the analyst. • Do nothing! Leave the current system alone. • Reengineer the (manual) business processes, not the computer-based processes. • Enhance existing computer processes. • Purchase a packaged application.

10. Feasibility Analysis - A Creeping Commitment Approach • Feasibility Checkpoints in the Life Cycle • Systems Analysis - A Selection Phase Checkpoint • The following list presents the typical range of options that can be evaluated by the analyst. (continued) • Design and construct a new computer-based system. This option presents numerous other options: • Centralized versus distributed versus cooperative processing • On-line versus batch processing • Files versus database for data storage • Of course, an alternative could be a combination of the preceding options. • After defining these options, each option is analyzed for operational, technical, schedule, and economic feasibility.

11. Feasibility Analysis - A Creeping Commitment Approach • Feasibility Checkpoints in the Life Cycle • Systems Analysis - A Procurement Phase Checkpoint • Because the procurement of hardware and applications software involves economic decisions that may require sizable outlays of cash, it shouldn't surprise you that feasibility analysis is required before a contract is extended to a vendor. • It should be noted that the procurement phase may be consolidated into the selection phase because hardware and software selection may have a significant impact on the feasibility of the solutions being considered.

12. Feasibility Analysis - A Creeping Commitment Approach • Feasibility Checkpoints in the Life Cycle • Systems Analysis - A Design Phase Checkpoint • Because implementation is often the most time-consuming and costly phase, the checkpoint after design gives us one last chance to cancel or downsize the project. • Downsizing is the act of reducing the scope of the initial version of the system. • Future versions can address other requirements after the system goes into production.

13. Four Tests for Feasibility • Most analysts agree that there are four categories of feasibility tests: • Operational feasibility is a measure of how well the solution of problems or a specific solution will work in the organization. It is also a measure of how people feel about the system/project. • Technical feasibility is a measure of the practicality of a specific technical solution and the availability of technical resources and expertise. • Schedule feasibility is a measure of how reasonable the project timetable is. • Economic feasibility is a measure of the cost-effectiveness of a project or solution. This is often called a cost-benefit analysis.

14. Four Tests for Feasibility • Operational Feasibility • Operational feasibility criteria measure the urgency of the problem (survey and study phases) or the acceptability of a solution (definition, selection, acquisition, and design phases). • There are two aspects of operational feasibility to be considered: • Is the problem worth solving, or will the solution to the problem work? • How do the end-users and management feel about the problem (solution)?

15. Four Tests for Feasibility • Operational Feasibility • Is the Problem Worth Solving, or Will the Solution to the Problem Work? • PIECES can be used as the basis for analyzing the urgency of a problem or the effectiveness of a solution. The following is a list of the questions that address these issues: • Performance. Does the system provide adequate throughput and response time? • Information. Does the system provide end-users and managers with timely, pertinent, accurate, and usefully formatted information? • Economy. Does the system offer adequate service level and capacity to reduce the costs of the business or increase the profits of the business?

16. Four Tests for Feasibility • Operational Feasibility • Is the Problem Worth Solving, or Will the Solution to the Problem Work? • PIECES can be used as the basis for analyzing the urgency of a problem or the effectiveness of a solution. The following is a list of the questions that address these issues: (continued) • Control. Does the system offer adequate controls to protect against fraud and embezzlement and to guarantee the accuracy and security of data and information? • Efficiency. Does the system make maximum use of available resources including people, time, flow of forms, minimum processing delays, and the like? • Services. Does the system provide desirable and reliable service to those who need it? Is the system flexible and expandable?

17. Four Tests for Feasibility • Operational Feasibility • How do End-Users and Managers Feel about the Problem (Solution)? • It's not only important to evaluate whether a system can work but also evaluate whether a system will work. • A workable solution might fail because of end-user or management resistance. The following questions address this concern: • Does management support the system? • How do the end-users feel about their role in the new system? • What end-users or managers may resist or not use the system? People tend to resist change. Can this problem be overcome? If so, how?

18. Four Tests for Feasibility • Operational Feasibility • How do End-Users and Managers Feel about the Problem (Solution)? • A workable solution might fail because of end-user or management resistance. The following questions address this concern: (continued) • How will the working environment of the end-users change? Can or will end-users and management adapt to the change?

19. Four Tests for Feasibility • Operational Feasibility • Usability Analysis: • Usability analysis is often performed with a working prototype of the proposed system. • This is a test of the system’s user interfaces and is measured in how easy they are to learn, to use and support the desired productivity levels of the users. • The goal is to identify the areas of the system where the users are prone to make mistakes, processes which may be confusing or too complicated, and also observe the reactions of the user and assess their productivity.

20. Four Tests for Feasibility • Operational Feasibility • Usability Analysis: • How do you determines if a system’s user interface is usable? • There are certain goals or criteria which experts agree help measure the usability of an interface and they are as follows: • Ease of Learning - How long does it take to train someone to perform at a desired level. • Ease Of Use - You are able to perform your activity quickly and accurately. If you are a first time user or infrequent user, the interface is easy and understandable. If you are a frequent user, your level of productivity and efficiency is increased. • Satisfaction - You the user are favorably pleased with the interface and prefer it over types you are familiar with.

21. Four Tests for Feasibility • Technical Feasibility • Technical feasibility can only be evaluated after those phases during which technical issues are resolved — namely, after the evaluation and design phases of our life cycle have been completed. • Technical feasibility addresses three major issues: • Is the proposed technology or solution practical? • Do we currently possess the necessary technology? • Do we possess the necessary technical expertise, and is the schedule reasonable?

22. Four Tests for Feasibility • Technical Feasibility • Is the Proposed Technology or Solution Practical? • The technology for any defined solution is normally available. • The question is whether that technology is mature enough to be easily applied to our problems. • Some firms like to use state-of-the-art technology, but most firms prefer to use mature and proven technology. • A mature technology has a larger customer base for obtaining advice concerning problems and improvements.

23. Four Tests for Feasibility • Technical Feasibility • Do we Currently Possess the Necessary Technology? • Assuming the solution's required technology is practical: • ``Is the technology available in the information systems shop?'' • If the technology is available, does it have the capacity to handle the solution. • If the technology is not available: • ``Can the technology be acquired?''

24. Four Tests for Feasibility • Technical Feasibility • Do we Possess the Necessary Technical Expertise, and is the Schedule Reasonable? • We may have the technology, but that doesn't mean we have the skills required to properly apply that technology. • True, all information systems professionals can learn new technologies. • However, that learning curve will impact the technical feasibility of the project; specifically, it will impact the schedule.

25. Four Tests for Feasibility • Schedule Feasibility • Given our technical expertise, are the project deadlines reasonable? • Some projects are initiated with specific deadlines. • You need to determine whether the deadlines are mandatory or desirable. • If the deadlines are desirable rather than mandatory, the analyst can propose alternative schedules. • It is preferable (unless the deadline is absolutely mandatory) to deliver a properly functioning information system two months late than to deliver an error-prone, useless information system on time! • Missed schedules are bad. • Inadequate systems are worse!

26. Four Tests for Feasibility • Economic Feasibility • The bottom line in many projects is economic feasibility. • During the early phases of the project, economic feasibility analysis amounts to little more than judging whether the possible benefits of solving the problem are worthwhile. • As soon as specific requirements and solutions have been identified, the analyst can weigh the costs and benefits of each alternative. • This is called a cost-benefit analysis.

27. Four Tests for Feasibility • The Bottom Line • You have learned that any alternative solution can be evaluated according to four criteria: operational, technical, schedule, and economic feasibility. • How do you pick the best solution? It's not always easy. • Operational and economic issues often conflict. • The final decision can only be made by sitting down with end-users, reviewing the data, and choosing the best overall alternative.

28. Cost-Benefit Analysis Techniques • How Much Will the System Cost? • Costs fall into two categories. • There are costs associated with developing the system. • Can be estimated from the outset of a project and should be refined at the end of each phase of the project. • There are costs associated with operating a system. • Can only be estimated once specific computer-based solutions have been defined (during the selection phase or later).

29. Cost-Benefit Analysis Techniques • How Much Will the System Cost? • Systems development costs: • Are usually one-time costs that will not recur after the project has been completed. • Sample systems development costs: • Personnel costs • Computer usage • Training • Supply, duplication, and equipment costs. • Cost of any new computer equipment and software.

31. Cost-Benefit Analysis Techniques • How Much Will the System Cost? • The lifetime system benefits must recover both the developmental and operating costs. • Systems operating costs: • Recur throughout the lifetime of the system. • The costs of operating a system over its useful lifetime can be classified as fixed and variable. • Fixed costs occur at regular intervals but at relatively fixed rates. Examples of fixed operating costs include: • Lease payments and software license payments. • Prorated salaries of information systems operators and support personnel (although salaries tend to rise, the rise is gradual and tends not to change dramatically from month to month).

32. Cost-Benefit Analysis Techniques • How Much Will the System Cost? • Systems operating costs: • Variable costs occur in proportion to some usage factor. Examples include: • Costs of computer usage (e.g., CPU time used, terminal connect time used, storage used) which vary with the work load. • Supplies (e.g., preprinted forms, printer paper used, punched cards, floppy disks, magnetic tapes, and other expendables), which vary with the work load. • Prorated overhead costs (e.g., utilities, maintenance, and telephone service). • After determining the costs and benefits for a possible solution, you can perform the cost-benefit analysis.

33. Cost-Benefit Analysis Techniques • What Benefits Will the System Provide? • Benefits normally increase profits or decrease costs, both highly desirable characteristics of a new information system. • To as great a degree as possible, benefits should be quantified in dollars and cents. • Benefits are classified as tangible or intangible. • Tangible benefits are those that can be easily quantified. • Tangible benefits are usually measured in terms of monthly or annual savings or of profit to the firm. • Examples include: fewer processing errors, reduced expenses, and increased sales.

34. Cost-Benefit Analysis Techniques • What Benefits Will the System Provide? • Benefits are classified as tangible or intangible. (continued) • Intangible benefits are those benefits believed to be difficult or impossible to quantify. • Examples include: improved customer goodwill and improved employee moral. • Unfortunately, if a benefit cannot be quantified, it is difficult to accept the validity of an associated cost-benefit analysis that is based on incomplete data.

35. Cost-Benefit Analysis Techniques • Is the Proposed System Cost-Effective? • There are three popular techniques to assess economic feasibility, also called cost-effectiveness. • Payback analysis. • Return on investment. • Net present value. • One concept that should be applied to each technique is the adjustment of cost and benefits to reflect the time value of money.

36. Cost-Benefit Analysis Techniques • Is the Proposed System Cost-Effective? • The Time Value of Money: • A concept shared by all three techniques is the time value of money — a dollar today is worth more than a dollar one year from now. • Some of the costs of a system will be accrued after implementation. • All benefits of the new system will be accrued in the future. • Before cost-benefit analysis, these costs should be brought back to current dollars. • Why go to all this trouble? • Because projects are often compared against other projects that have different lifetimes.

37. Cost-Benefit Analysis Techniques • Is the Proposed System Cost-Effective? • Payback Analysis: • The payback analysis technique is a simple and popular method for determining if and when an investment will pay for itself. • Because systems development costs are incurred long before benefits begin to accrue, it will take some period of time for the benefits to overtake the costs. • After implementation, you will incur additional operating expenses that must be recovered. • Payback analysis determines how much time will lapse before accrued benefits overtake accrued and continuing costs. • This period of time is called the payback period.

38. Cost-Benefit Analysis Techniques • Is the Proposed System Cost-Effective? • Payback Analysis: • How do you determine the payback period? • Adjust the costs and benefits for the time value of money (that is, adjust them to current dollar values). • The present value of a dollar in year n depends on something typically called a discount rate. • The discount rate is a percentage similar to interest rates that you earn on your savings account. • The discount rate for a business is the opportunity cost of being able to invest money in other projects.

39. Cost-Benefit Analysis Techniques • Is the Proposed System Cost-Effective? • Payback Analysis: • How do you determine the payback period? (continued) • The current value, actually called the present value, of a dollar at any time in the future can be calculated using the following formula: PVn = 1(1 + i)n • where PVn is the present value of $1.00 n years from now and i is the discount rate. • Determine time period when lifetime benefits will overtake the lifetime costs. • This is the break-even point.

41. Cost-Benefit Analysis Techniques • Is the Proposed System Cost-Effective? • Return-on-Investment Analysis: • The return-on-investment (ROI) analysis technique compares the lifetime profitability of alternative solutions or projects. • The ROI for a solution or project is a percentage rate that measures the relationship between the amount the business gets back from an investment and the amount invested. • The ROI for a potential solution or project is calculated as follows: • ROI = (Estimated lifetime benefits - Estimated lifetime costs) / Estimated lifetime costs • The solution offering the highest ROI is the best alternative.

42. Cost-Benefit Analysis Techniques • Is the Proposed System Cost-Effective? • Net Present Value: • The net present value of an investment alternative is considered the preferred cost-benefit technique by many managers. • Costs are represented by negative cash flows while benefits are represented by positive cash flows. • After discounting all costs and benefits, subtract the sum of the discounted costs from the sum of the discounted benefits to determine the net present value. • If it is positive, the investment is good. • If negative, the investment is bad. • When comparing multiple solutions or projects, the one with the highest positive net present value is the best investment.

44. Feasibility Analysis of Candidate Systems • Candidate Systems Matrix • The candidate systems matrix documents similarities and differences between candidate systems; however, it offers no analysis. • The columns of the matrix represent candidate solutions. • The rows of the matrix represent characteristics that serve to differentiate the candidates. The breakdown is as follows: • TECHNOLOGY • INTERFACES • DATA • PROCESSES • GEOGRAPHY

47. Feasibility Analysis of Candidate Systems • Feasibility Analysis Matrix • This matrix complements the candidate systems matrix with an analysis and ranking of the candidate systems. It is called a feasibility analysis matrix. • The columns of the matrix correspond to the same candidate solutions as shown in the candidate systems matrix. • Some rows correspond to the feasibility criteria presented in this chapter. • Rows are added to describe the general solution and a ranking of the candidates. • The cells contain the feasibility assessment notes for each candidate.

48. Feasibility Analysis of Candidate Systems • Feasibility Analysis Matrix • Each row can be assigned a rank or score for each criteria (e.g., for operational feasibility, candidates can be ranked 1, 2, 3, etc.). • After ranking or scoring all candidates on each criteria, a final ranking or score is recorded in the last row.