Feasible

Editor's Notes

• #2: In today’s business world, it is becoming more and more apparent that analysts must learn to think like business managers. Computer applications are expanding at a record pace. Now more than ever, management expects information systems to pay for themselves. Information is a major capital investment that must be justified, just as marketing must justify a new product and manufacturing must justify a new plant or equipment. Systems Analysts are called on more than ever to help answer the following questions: Will the investment pay for itself? Are there other investments that will return even more on their expenditure? Few topics are more important. Feasibility analysis isn't really systems analysis, and it isn't systems design either. Instead, feasibility analysis is a cross life cycle activity and should be continuously performed throughout a systems project. 643
• #7: Figure C.1 Feasibility Checkpoints in the Systems Development Lifecycle Feasibility checkpoints can be installed into any SDLC that you are using. The figure above shows feasibility checkpoints for a typical life cycle (similar to, but not identical to, the life cycle used in this book). The checkpoints are represented by red diamonds. The diamonds indicate that a feasibility reassessment and management review should be conducted at the end of the prior phase (before the next phase). A project may be canceled or revised at any checkpoint, despite whatever resources have already been spent so far. This idea may bother you at first. Your natural inclination may be to justify continuing a project based on the time and money you've already spent. Those costs are sunk. A fundamental principle of management is never to throw good money after bad — cut your losses and move on to a more feasible project. That doesn't mean the costs already spent are not important. 643-644
• #8: After estimating benefits of solving the problems and opportunities, analysts will estimate costs of developing the expected system. Experienced analysts routinely increase these costs by 50 percent to 100 percent (or more) because experience tells them that the problems are rarely well-defined and that user requirements are typically understated. Do nothing! Leave the current system alone. Regardless of management's opinion or your own opinion of this option, it should be considered and analyzed as a baseline option against which all others can and should be evaluated. Reengineer the (manual) business processes, not the computer-based processes. This may involve streamlining activities, reducing duplication and unnecessary tasks, reorganizing office layouts, and eliminating redundant and unnecessary forms and processes, among others. 643-644
• #9: Operational and technical feasibility criteria measure the worthiness of a problem or solution. Operational feasibility is people oriented. Technical feasibility is computer oriented. Economic feasibility deals with the costs and benefits of the information system. Actually, few systems are infeasible. Instead, different options tend to be more or less feasible than others. Let's take a closer look at the four feasibility criteria. 646
• #19: During the systems selection and procurement phases of systems design, the systems analyst identifies candidate system solutions and then analyzes those solutions for feasibility. We discussed the criteria and techniques for analysis in this chapter. In this concluding section we evaluate a pair of documentation techniques that can greatly enhance the comparison and contrast of candidate system solutions. Both use a matrix format. We have found these matrices useful for presenting candidates and recommendations to management. The rows of the matrix represent characteristics that serve to differentiate the candidates. The breakdown is as follows: TECHNOLOGY — Brief description of the technical solution represented by the candidate system. INTERFACES — Identify how the system will interact with people and other systems. DATA — How will data stores be implemented (e.g., conventional files, relational database(s), other database structures)? How will inputs be captured (e.g., on-line, batch, etc.)? How will outputs be generated (e.g., on a schedule, on demand, printed, on screen, etc.)? PROCESSES — How will (manual) business processes be modified? How will computer processes be implemented? For the latter, we have numerous options, including on-line versus batch processes and packaged versus built-in-house software. GEOGRAPHY — How will processes and data be distributed? Once again, we might consider several alternatives — for example, centralized versus decentralized versus distributed (or duplicated) versus cooperative (client/server) solutions. 656
• #20: Figure C.6 Candidate Systems Matrix Template No additional notes provided. 656-657
• #21: Figure C.7 Sample Candidate Systems Matrix Before considering any solutions, we must consider any constraints on solutions. Solution constraints take the form for architectural decisions intended to bring order and consistency to applications. For example, a technology architecture may restrict solutions to relational databases or client/server networks. A sample, partially completed candidate system matrix listing three of the five candidates is shown in the figure above. The matrix is used to provide overview characteristics concerning the portion of the system to be computerized, the business benefits, and software tools and/or applications needed. Subsequent pages would provide additional details concerning other characteristics such as those mentioned previously. Two columns can be similar except for their entries in one or two cells. Multiple pages would be used if we were considering more than three candidates. 657-658
• #22: Be careful. Not all feasibility criteria are necessarily equal in importance. Before assigning final rankings, you can quickly eliminate any candidates for which any criteria is deemed ``infeasible.'' In reality, this doesn't happen very often. 657
• #23: Be careful. Not all feasibility criteria are necessarily equal in importance. Before assigning final rankings, you can quickly eliminate any candidates for which any criteria is deemed ``infeasible.'' In reality, this doesn't happen very often. 657
• #24: Figure C.8 Feasibility Analysis Matrix Template No additional notes provided. 657,659
• #25: Figure C.9 Sample Feasibility Analysis Matrix A completed feasibility analysis matrix is presented in the figure above. The feasibility assessment is provided for each candidate solution. In this example, a score is recorded directly in the cell for each candidate's feasibility criteria assessment. Again, this matrix format can be most useful for defending your recommendations to management. 657,659