<ch12 toc ch14>

13 The feasibility study

13.1 Purpose
13.2 Strengths, weaknesses, and limitations
13.3 Inputs and related ideas
13.4 Concepts
13.4.1 The cost of a feasibility study
13.4.2 Types of feasibility
13.4.3 The steps in a typical feasibility study
13.4.4 The feasibility study report
13.5 Key terms
13.6 Software
13.7 References

13.1 Purpose

A feasibility study is a compressed, capsule version the analysis phase of the system development life cycle aimed at determining quickly and at a reasonable cost if the problem can be solved and if it is worth solving. A feasibility study can also be viewed as an in-depth problem definition.

13.2 Strengths, weaknesses, and limitations

A well-conducted feasibility study provides a sense of the likelihood of success and of the expected cost of solving the problem, and gives management a basis for making resource allocation decisions. In many organizations, the feasibility study reports for all pending projects are submitted to a steering committee where some are rejected and others accepted and prioritized.

Because the feasibility study occurs near the beginning of the system development life cycle, the discovery process often uncovers unexpected problems or parameters that can significantly change the expected system scope. It is useful to discover such issues before significant funds have been expended. However, such surprises make it difficult to plan, schedule, and budget for the feasibility study itself, and close management control is needed to ensure that the cost does not balloon out of control. The purpose of a feasibility study is to determine, at a reasonable cost, if the problem is worth solving.

It is important to remember that the feasibility study is preliminary. The point is to determine if the resources should be allocated to solve the problem, not to actually solve the problem. Conducting a feasibility study is time consuming and costly. For essential or obvious projects, it sometimes makes sense to skip the feasibility study.

13.3 Inputs and related ideas

The feasibility study begins with the problem description (# 12) prepared early in the problem definition phase of the system development life cycle. Often, the feasibility study report is the primary input to the steering committee that authorizes further work on the project.

The feasibility study is, in essence, a preliminary version of the analysis phase of the system development life cycle. Depending on the nature of the problem, the analyst uses various tools from Parts II, IV, and V. The information collected during the feasibility study is used during project planning to prepare schedules, budgets, and other project management documents using the tools described in Part III. Prototypes (# 31) and simulation models (# 19) are sometimes used to demonstrate technical feasibility. Economic feasibility is typically demonstrated using cost/benefit analysis (# 38).

13.4 Concepts

Developing a new system is a form of investment. Any investment carries risk, and it makes sense to investigate the likelihood of success before committing resources. Thus, problem definition is often followed by a feasibility study, a capsule version of the analysis phase of the system development life cycle aimed at determining quickly and at a reasonable cost if the problem can be solved and if it is worth solving.

Note that the feasibility study is optional. On some small or obvious projects it is a waste of time. Other jobs simply must be done. For example, if federal income tax rates change, a firm has no choice but to update its payroll system. Fixing a bug in a critical program is another example. There is little point trying to prove feasibility when the problem must be solved (although the analyst might want to investigate the relative feasibility of alternative approaches). However, doing a feasibility study should be the default, and the burden of proof should be on skipping this step.

13.4.1 The cost of a feasibility study

The point of the feasibility study is to determine, at a reasonable cost, if the problem is worth solving. Thus the cost of the feasibility study should represent a small fraction of the estimated cost of developing the system, perhaps five or ten percent of the scope.

13.4.2 Types of feasibility

Four types of feasibility are considered:

  Technical feasibility—Is it possible to solve the problem using existing technology? Typically, the analyst proves technical feasibility by citing existing solutions to comparable problems. Prototypes (# 31), physical models, and analytical techniques [such as simulation (# 19)] are also effective.
  Economic feasibility—Do the benefits outweigh the cost of solving the problem? The analyst demonstrates economic feasibility through cost/benefit analysis (# 38).
  Operational feasibility—Can the system be implemented in the user’s environment? Perhaps a union agreement or a government regulation constrains the analyst. There might be ethical considerations. Maybe the boss suffers from computer phobia. Such intangible factors can cause a system to fail just as surely as technology or economics. Some analysts call this criterion political feasibility.
  Organizational feasibility—Is the system consistent with the organization’s strategic objectives? If the answer is no, funds might be better spent on some other project.

Note that not all organizations consider all four types of feasibility.

13.4.3 The steps in a typical feasibility study

The steps in a typical feasibility study are summarized in Figure 13.1.

Starting with the initial problem description (# 12), the system’s scope and objectives are more precisely defined. The existing system is studied, and a high-level logical model of the proposed system is developed using one or more of the analysis tools described in Part IV. The problem is then redefined in the light of new knowledge, and these first four steps are repeated until an acceptable level of understanding emerges.

Given an acceptable understanding of the problem, several possible alternative solutions are identified and evaluated for technical, economic, operational, and organizational feasibility. The responsible analyst then decides if the project should be continued or dropped, roughs out a development plan (including a schedule, a cost estimate, likely resource needs, and a cost/benefit analysis), writes a feasibility study report, and presents the results to management and to the user.


Figure 13.1  The steps in a typical feasibility study.

13.4.4 The feasibility study report

Assuming that one or more feasible solutions exist, the analyst prepares a feasibility study report that identifies several alternatives and recommends a course of action. Table 13.1 shows a typical feasibility report outline.

Table 13.1 An Outline of a Typical Feasibility Study.


1.  Title page—Project name, report title, author(s), date.
2.  Contents—A list of report sections with page numbers.
3.  Problem definition—A clear, concise, one-page description of the problem.
4.  Executive summary—A clear, concise, one-page summary of the feasibility study, the results, and the recommendations. Include necessary authorizations, key sources of information, alternatives considered, and alternatives rejected. Highlight the costs, benefits, constraints, and time schedule associated with the recommended alternative.
5.  Method of study—A description of the approach and procedures used in conducting the feasibility study. Mention sources and references; identify key people; and briefly describe the existing system (if appropriate). Much of the detail belongs in the appendix; include only those facts directly relevant to the study or to your conclusions.
6.  Analysis—A high-level analysis of the proposed logical system. Include an expanded statement of the system objectives, constraints, and scope; include a logical model (data flow diagram, and entity-relationship model) and perhaps a preliminary data dictionary for the proposed system; and identify key interrelationships with other systems.
7.  Alternatives considered—For each alternative seriously considered, include a statement of its technical, economic, operational, and organizational feasibility, a rough implementation schedule, and a high-level system flow diagram or other system description. Note: Much of the detail belongs in the appendix.
8.  Recommendations—Clearly state the recommended course of action. Provide material to support and justify your recommendation. In particular, provide a cost/benefit analysis.
9.  Development plan—Include a projected schedule and projected costs for each step in the system life cycle, assuming that the recommended course of action is followed. Provide detailed time and cost estimates for the analysis step.
10.  Appendix—Charts, graphs, statistics, interview lists, selected interview summaries, diagrams, memos, notes, references, key contacts, acknowledgements, and so on; in short, the details that support the study.

13.5 Key terms

Economic feasibility —
Proof that the likely benefits outweigh the cost of solving the problem; generally demonstrated by a cost/benefit analysis.
Feasibility study —
A compressed, capsule version of the analysis phase of the system development life cycle aimed at determining quickly and at a reasonable cost if the problem can be solved and if it is worth solving.
Operational feasibility —
Proof that the problem can be solved in the user’s environment.
Organizational feasibility —
Proof that the proposed system is consistent with the organization’s strategic objectives.
Steering committee —
A committee consisting of representatives from various user groups that accepts, rejects, and prioritizes information system proposals.
Technical feasibility —
Proof that the problem can be solved using existing technology

13.6 Software

Not applicable.

13.7 References

1.  Clifton, D. S. and Fyffe, Project Feasibility Analysis: A Guide to Profitable New Ventures, John Wiley & Sons, New York, 1977.
2.  Davis, W. S., Business Systems Analysis and Design, Wadsworth Publishing, Belmont, CA, 1994.
3.  Fitzgerald, J., Fitzgerald, and Stallings, Fundamentals of Systems Analysis, 2nd ed., John Wiley & Sons, New York, 1981.
<ch12 toc ch14>