Once the number of projects has been narrowed according to the criteria discussed previously, it is still necessary to determine if the selected projects are feasible. Our definition of feasibility goes much deeper than common usage of the term, because systems projects feasibility is assessed in three principal ways: operationally, technically, and economically. The feasibility study is not a full-blown systems study. Rather, the feasibility study is used to gather broad data for the members of management that in turn enables them to make a decision on whether to proceed with a systems study.
Data for the feasibility study can be gathered through interviews, which are covered in detail in Chapter “Information Gathering: Interactive Methods“. The kind of interview required is directly related to the problem or opportunity being suggested. The systems analyst typically interviews those requesting help and those directly concerned with the decision-making process, typically management. Although it is important to address the correct problem, the systems analyst should not spend too much time doing feasibility studies, because many projects will be requested and only a few can or should be executed. The feasibility study must be highly time compressed, encompassing several activities in a short span of time.
After an analyst determines reasonable objectives for a project, the analyst needs to determine if it is possible for the organization and its members to see the project through to completion. Generally, the process of feasibility assessment is effective in screening out projects that are inconsistent with the business’s objectives, technically impossible, or economically without merit.
Although it is painstaking, studying feasibility is worthwhile because it saves businesses and systems analysts time and money. In order for an analyst to recommend further development, a project must show that it is feasible in all three of the following ways: technically, economically, and operationally, as shown in the illustration below.
| The Three Key Elements of Feasibility |
|---|
Technical Feasibility
|
Economic Feasibility
|
Operational Feasibility
|
Technical Feasibility
The analyst must find out whether it is possible to develop the new system given the current technical resources. If not, can the system be upgraded or added to in a manner that fulfills the request under consideration? If existing systems cannot be added onto or upgraded, the next question becomes whether there is technology in existence that meets the specifications.
At the same time, the analyst can ask whether the organization has the staff who are technically proficient enough to accomplish the objectives. If not, the question becomes whether they can hire additional programmers, testers, experts, or others who may have different programming skills from theirs, or maybe outsource the project completely. Still another question is whether there are software packages available that can accomplish their objectives, or does the software need to be customized for the organization?
Economic Feasibility
Economic feasibility is the second part of resource determination. The basic resources to consider are your time and that of the systems analysis team, the cost of doing a full systems study (including the time of employees you will be working with), the cost of the business employee time, the estimated cost of hardware, and the estimated cost of software or software development.
The concerned business must be able to see the value of the investment it is pondering before committing to an entire systems study. If short-term costs are not overshadowed by long-term gains or produce no immediate reduction in operating costs, the system is not economically feasible and the project should not proceed any further.
Operational Feasibility
Suppose for a moment that technical and economic resources are both judged adequate. The systems analyst must still consider the operational feasibility of the requested project. Operational feasibility is dependent on the human resources available for the project and involves projecting whether the system will operate and be used once it is installed. If users are virtually wed to the present system, see no problems with it, and generally are not involved in requesting a new system, resistance to implementing the new system will be strong. Chances for it ever becoming operational are low.
Alternatively, if users themselves have expressed a need for a system that is operational more of the time, in a more efficient and accessible manner, chances are better that the requested system will eventually be used. Much of the art of determining operational feasibility rests with the user interfaces that are chosen, as we see in Chapter “Human–Computer Interaction“.
Contents
- Project Initiation
- Defining the Problem in Project Initiation
- Selection of Projects
- Feasibility Study – Determining Whether the Project is Feasible
- Technical Feasibility – Ascertaining Hardware and Software Needs
- Acquisition of Computer Equipment – Technical Feasibility
- Software Evaluation in Technical Feasibility
- Economic Feasibility – Identifying & Forecasting Costs & Benefits
- Comparing Costs and Benefits – Economic Feasibilty
- Activity Planning and Control – Project Management
- Using PERT Diagrams in Project Planning
- Managing the Project
- Managing Analysis and Design Activities
- Creating the Project Charter & Avoiding Project Failures
- Organizing the Systems Proposal
- Using Figures for Effective Communication in System Proposal
