Jomo Kenyatta University of agriculture and technology

FEASIBITY STUDIES
A feasibility study is part of the initial design stage of any project/plan. It is
conducted in order to objectively uncover the strengths and weaknesses of a
proposed project or an existing business. It can help to identify and assess the
opportunities and threats present in the natural environment, the resources
required for the project, and the prospects for success. It is conducted in order
to find answers to the following questions:

1. Does the company possess the required resources and technology?

2. Will the company receive a sufficiently high return on its investment?

The Feasibility Studies

1- What is a feasibility study?
2- What to study and conclude?
3- Types of feasibility
Technical
Economic
Schedule
Operational
4- Quantifying benefits and cost
5- Comparing alternatives
6- Feasibility report

Why feasibility study?

Things to be studied in the feasibility study:

1- The present organizational system

2- Stakeholders, users, policies, functions, objectives,...

3- Problems with the present system

4- Inconsistencies, inadequacies in functionality, performance,…

5- Goals and other requirements for the new system

6- Which problem(s) need to be solved?

7- What would the stakeholders like to achieve?

Constraints

1- including nonfunctional requirements on the system (preliminary pass)

2- Possible alternatives
 3- “Sticking with the current system” is always an alternative

4- Different business processes for solving the problems

5- Different levels/types of computerization for the solutions

6- Advantages and disadvantages of the alternatives

Things to conclude:

1- Feasibility of the project

2- The preferred alternative.

3- Exploring Feasibility

Four Types of feasibility

Levels of Feasibility Assessment

A feasibility study of an idea is conducted at three levels

1- Operational/ personnel Feasibility

Is the expertise of the systems development section sufficiently advanced to

tackle (and successfully achieve) the production of the system? Such a
question must also be asked of an outside agency if it is to produce the
system. If the answer is "No", can the expertise be obtained by hiring new
staff or training existing staff? Is the cost of this justifiable? Many modern
systems are run by users themselves who may, or may not, have the support
of an IT department. With a small business system, it may be necessary to go
back to the supplier if support is required. In both cases, it is necessary to
consider the personnel within the user departments when deciding on the
feasibility of a particular approach. The question “Will it work?” should be
answered.

2. Technical Feasibility

Is the current state of hardware and software technology capable of

supporting the idea of the system? “Can it be built?” 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 for this team?

Is relevant technology mature enough to be easily applied to our problem?

What kinds of technology will we need?

Some organizations like to use state-of-the-art technology…but most prefer to
use mature and proven technology. A mature technology has a larger
customer base for obtaining advice concerning problems and improvements.

Is the required technology available “in house”?

If the technology is available: …does it have the capacity to handle the

solution?

If the technology is not available: …can it be acquired?

3. Economic Feasibility

“Will it make economic sense if it works and is built?”

“Will it generate PROFITS?”

We conduct economic feasibility studies in the very early stages in the project
to reach a judgment of whether solving the problem is worthwhile or the
proposed project is worth execution. Once specific requirements and
solutions have been identified, the costs and benefits of each alternative can
be calculated.

Determining the Main Requirements of the System

The assignment brief will have specified in general terms the requirements of
the proposed system. However, even at this preliminary stage, detailed
requirements must be determined, otherwise the analyst will be unable to
envisage the total scope of the problem and thereby suggest possible
solutions. Initially, therefore, the team will conduct a survey of all interested
parties to find out exactly what will be required of the system.

(a) Main Characteristics

These will be defined in terms of the output information required. At this
preliminary stage, the detailed layouts and methods of presentation will not
be needed, but the team will need to find out:

Volumes of output required. Frequencies of the output.

Geographical location of the receivers of the information.
Response times to requests for information if on-demand output is required.
When the outputs have been determined, the team will be able to ascertain –
again in general terms – the volume, frequency, etc. of input data and the
volume of stored data necessary to produce the output.

(b) Main Constraints

Not only must the requirements of the system be known, but also any
constraints on its operation. We have indicated one of these above – that of
geographical location.
Others might include: Limitations caused by associated existing systems.
Financial and staffing considerations. Statutory constraints. Auditing
requirements. IT policies governing the inclusion of ultra-new technology
(many firms will only use tried and tested technologies – many "fingers have
been burnt" by pioneering organisations).
Current computer equipment. Environmental constraints. Time, especially
when information must be available at a particular time (as in a payroll
system).
Performance in terms of throughput, response times with a given number of
users, etc. Accuracy of output information. Control and security procedures.

(c) Input Data

This section will describe all the input data. It will indicate the type of data, its
quantity and frequency. If relevant, it will define the structure and layout of
the data when the design of input data documents is outside the control of the
systems designer. The medium for input may be a specific requirement.

(d) Output Information

All the output to be produced by the system will be specified in this section.
Unless there is a specific requirement, it may be left to the systems designer to
prepare the actual layouts and presentation of the information. However, this
section will specify the elements of information required for each output, the
frequency and volume of output, together with the medium on which the
output is to be presented.

(e) Validation Requirements

The data input to any automatic data processing system must be correct. It is
important that the validation procedures to be adopted in the new system are
specified fully so that the designer can incorporate them in the design. This
section will specify both the validation procedures to be adopted, and the
ranges of values and other associated information for every data element used
by the system. For example, a name must be given a maximum length, a code
number, its check digit mechanism and the range of values it can adopt.
In addition, if the system is to be on-line with direct data entry from
keyboards, then the methods of indicating errors and the action to be taken by
the system should be specified, especially if the user is to be allowed to make
immediate corrections to any data erroneously input.

(f) File Requirements

Unless the system uses files created by other systems, it is usual to leave the
file requirements to the system designer. If the system does use existing files,
then their details will be included in this section. This is a fundamentally
important point with existing files increasingly being used to promote
integration throughout systems methodology.
(g) Enhancements
It is quite usual for a system to be specified with the intention of enhancing its
facilities at a later date, or for there to be a future system envisaged which will
use the output or files of the specified system. The system designer, in
studying this section of the requirement specification, will be able to allow for
such enhancements and facilitate their inclusion in the future.

Considering Alternatives
When all the relevant facts have been collected, differing approaches to
solving the problem can be considered. The team should investigate solutions
which have been found for systems with similar requirements both within
and outside the organization.
Cost/Benefit Analysis
This is the most important aspect of the feasibility study as its results will be
the main information from which future decisions concerning the viability of
the project will be determined. Cost/benefit analysis is frequently used in
management accountancy in order to compare solutions to a given problem
and, by using value judgements, to assess savings and losses made by various
parts of the system. Essentially, such an analysis attempts to place a monetary
value on all aspects of a system. Some
aspects will create a cost (e.g. the purchase of computer equipment) and
others will create income or reduce cost (e.g. an increase in the number of
transactions handled or the scrapping of existing computing machinery). The
method is not as straightforward as it at first appears since some items –
usually benefits – are greatly influenced by subjective evaluation. For
example, what is the benefit of providing a better service to customers? How
much will sales increase if the sales director has more information on which
to base marketing decisions?
When each aspect of each alternative has been given a monetary value, then
their costs and benefits can be compared. We can therefore identify three
main parts to such an analysis:

(a) Determine the costs

These may be divided into four parts:
Computing costs – which start with the salaries and associated overheads for
the systems analysts as they perform the feasibility study and investigate the
requirements of the new system and then go on to develop and implement
the system. This work may be carried out by people from an outside
company, in which case the costs will be easier to itemise. Also under this
heading comes the cost of any new computer hardware and any "bought-in"
software. These can be regarded as capital costs of the new system.

User department costs incurred during the investigation and implementation

stages, which include wasted productive time as a result of the investigation
disturbing the normal flow of business, education and training costs and
"phasing in" costs when, for example, parallel running may make some
overtime necessary. These again can be regarded as capital costs.
Operational costs, which include salaries and overheads of the people
running the system (who may be IT or user staff or both), consumable
materials such as special stationery and disks, communication costs (for
example, telephone, if the system has some remote users) and hardware and
software maintenance.
Other costs – all systems must be monitored throughout their life to ensure
that they continue to fulfil the original requirements, or to check that the
requirements still apply. The system may thus require modification if it is
found not to be achieving the best results. This evaluation and modification is
often termed "system maintenance" and can involve major expense, especially
if the design is poor and ease of maintenance was not allowed for in the
system.
(b) Determine the benefits
These may be assessed under three headings:
Direct savings, which can be defined as a definite reduction in cost as a result
of changing from an old to a new system. These are fairly easy to identify and
attach a monetary value to, and because of this they are sometimes used as
the sole measure of benefit. However, this is incorrect, as the other two
groups of benefits often give rise to much greater returns on the investment in
the new system.
Measurable benefits, which can be defined as "a monetary or financial return
which accrues to the organisation as a result of the operation of the new
system". These are by far the most important benefits to be balanced against
the costs of the new system. They are often difficult to assess, yet effort should
be expended to assess their monetary value. One example is a purchase
ordering system which may produce great benefits by ensuring that the best
possible terms for bulk purchase discounts and early payment discounts are
obtained.
Intangible benefits, which are those to which no monetary value can be
attached. A new system will usually provide improved information. For
example, an on-line order processing system will expedite the despatch of
goods to customers. The organisation will thus provide a better service than
its competitors, and this should mean higher sales, but the level will be
difficult to assess.

(c) Perform a comparison to determine the "best" approach

The most important comparison is between the measured costs and benefits
of the alternative systems. One might assume that this is a simple task of
adding all the costs, subtracting this from the total of the benefits, and the
system showing the largest net benefit is the one to choose. However, factors
such as return on investment, inflation and risk have to be taken into account.

Cost-benefit analysis

Purpose - answer questions such as:

 Is the project justified (I.e. will benefits outweigh costs)?

 What is the minimal cost to attain a certain system?

  How soon will the benefits accrue?

 Which alternative offers the best return on investment

The Report

We can now list the contents of a typical feasibility report produced by the
team of systems analysts on completion of their investigation. These are as
follows:
Restatement of the terms of reference.
Summary of the investigation (often the detailed findings are attached as an
appendix to the report).

 Identification of the requirements and constraints.

 Descriptions of the solutions.
 Detailed costings and benefits of each solution.
 Summary comparisons

NOTE: ASSIGNMENT: Discuss the contents of the feasibility report