Sei sulla pagina 1di 10

Page 1

Chapter 5
Chapter 5

Feasibility Analysis and The System Proposal


Feasibility Analysis A Creeping Commitment Approach
Feasibility is the measure of how beneficial or practical the development of
information system will be to an organization. Feasibility analysis is the process by
which feasibility measured.
Feasibility is measured throughout the life cycle because a project that is feasible at
one point may become infeasible later. Feasibility analysis is appropriate to the
systems analysis phases but particularly to the decision analysis phase. To measure the
feasibility throughout the life cycle, we use creeping commitment approach. Using
this approach, multiple feasibility checkpoints are built into any system development
methodology and at each checkpoint, feasibility is reassessed. These checkpoints are
shown in the figure below:

System Analysis and Design

Page 2

Chapter 5

System Analysis Scope Definition Checkpoint


The first feasibility analysis is conducted during the scope definition phase. At this
phase, realistic feasibility cant be accurately measured because problems and
requirements are not better understood. At this checkpoint, we identify if the problem
warrant the cost of a detailed study and analysis of the current system.
After estimating benefits of solving the problem, analysts estimate costs of developing
the expected system. The analyst increases this cost by 50 to 100 percent.

System Analysis Problem Analysis Checkpoint


The next checkpoint occurs after a more detailed study and problem analysis of the
system. The analyst can make better estimates development costs and the benefits to
be obtained from the new system because the problems are better understood.
Development costs at this point are still just guesstimates because user requirements
and design solutions are not defined yet.

Systems Design Decision Analysis Checkpoint


The major checkpoint for feasibility study is the decision analysis checkpoint. During
decision analysis 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. The alternative solutions that can be
defined by the analyst are:
Do nothing
Reengineer the (manual) business process
Enhance existing computer processes
Purchase a packaged application
Design and construct a new computer-based system
After defining these options, each is analyzed for operational, technical, schedule, and
economic feasibility. One alternate is recommended to system owners for approval.

Four Tests for Feasibility


To analyze different alternative solutions, most analysts use four categories of
feasibility tests: operational, technical, schedule and economic feasibility.

Operational Feasibility
It is a measure of how well the solution will work in an organization. It is also a
measure of how people feel about the system/project. So, this feasibility is people
oriented. Operational feasibility addresses two major issues:
Is the problem worth solving, or will the solution to the problem work?
How do end users and management feel about the problem (solution)?

System Analysis and Design

Page 3

Chapter 5

When determining operational feasibility, usability analysis is often performed with a


working prototype of the proposed system. Usability analysis is a test of systems
user interfaces and is measured in how easy they are to learn and to use and how they
support the desired productivity levels of the users. Usability is measured in terms of
ease of learning, ease of use, and satisfaction.

Technical Feasibility
It is a measure of practically of a specific technical solution and availability of
technical resources and expertise. Technical feasibility is computer oriented. This
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?

Schedule Feasibility
It is a measure of how reasonable the project timetable is. Schedule feasibility is the
determination of whether the time allocated for a project seems accurate. Projects are
initiated with specific deadlines. It is necessary to determine whether the deadlines are
mandatory or desirable. If the deadlines are desirable rather than mandatory, the
analyst can propose alternative schedules.

Economic Feasibility
It is the measure of the cost-effectiveness of a project or solution. This feasibility
deals with costs and benefits of the information system. 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. However, as soon as specific requirements and
alternative solutions have been identified, the analyst can determine the costs and
benefits of each alternative.

Cost-Benefit Analysis Techniques


Economic feasibility has been defined as a cost-benefit analysis. Most schools offer
courses like financial management, financial decision analysis, and engineering
economics and analysis for cost benefit analysis. The cost benefit analysis techniques
include:
How much will the system costs?
What benefits will the system provide?
Is the proposed system cost-effective?

How much will the system costs?


Costs fall into two categories: costs associated with developing the system and costs
associated with operating the system. The former costs can be estimated from the
outset of the project and should be refined at the end of each phase of the project. The
later can be estimated only after specific computer-based solution has been defined.
System Analysis and Design

Page 4

Chapter 5

System development costs are usually onetime costs that will not recur after the
project has been completed. Many organizations have standard cost categories that
must be evaluated. In the absence of such categories, we use the following list:
Personnel cost The salaries of systems analysts, programmers, consultants, data
entry personnel, computer operators, secretaries, and the like who work on the
project.
Computer usage The cost in the use of computer resources.
Training Expenses for the training of computer personnel or end-users.
Supply, duplication, and equipment costs.
Cost of any new computer equipment and software.
The operating costs tend to recur throughout the lifetime of the system. The costs in
this case can be classified as fixed or variable.
Fixed costs Fixed costs occur at regular intervals but at relatively fixed rates.
Some examples include: lease payments and software license payments, salaries
of IS operators and support personnel etc.
Variable costs Variable costs occur in proportion to some usage factor. Some
examples include: costs of computer usage (e.g., CPU time used, storage used),
supplies (e.g., printer paper, floppy disks), overhead costs (e.g., utilities,
maintenance, telephone service) etc.

What benefits will the system provide?


Benefits normally increase profits or decrease costs. Benefits can be classified into
two categories: tangible and intangible.
Tangible benefits Tangible benefits are those that can be easily quantified.
These benefits are usually measured in terms of monthly or annual savings or of
profit to the firm. Alternatively, these benefits might be measured in terms of unit
cost savings or profit. Some examples of tangible benefits are: fewer processing
errors, increased throughput, decreased response time, elimination of job steps,
increased sales, reduced credit losses, and reduce expenses.
Intangible benefits Intangible benefits are believed to be difficult or impossible
to quantify. Unless these benefits are at least identified, it is entirely possible that
many projects would not be feasible. Some examples of intangible benefits are:
improved customer goodwill, improved employee morale, better service to
community, and better decision making.
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.

Is the proposed system cost-effective?


There are three popular techniques to assess economic feasibility, also called costeffectiveness: payback analysis, return to investment, and net present value.
One concept that is shared by all three techniques is the time value of money a
dollar today is worth more than a dollar one-year form now.

System Analysis and Design

Page 5

Chapter 5

Some of the costs of the system will be accrued in after implementation. Before costbenefit analysis, these costs should be brought back to the current dollars. Present
value is the current value of a dollar at any time in the future. It is calculated using the
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.
Payback analysis It is a technique for determining if and when an investment
will pay for itself. Because system development costs are incurred long before
benefits begin to occur, it will take some time for the benefits to overtake the
costs. After implementation, there will be 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 payback period, that is the period of time that will lapse before accrued
benefits overtake accrued costs.
Return-on-investment analysis This technique compares the lifetime
profitability of the solution. It is a percentage rate that measures the relationship
between the amounts the business gets back from an investment and the amount
invested. It is calculated as follows:
Lifetime ROI = (Estimated lifetime benefits Estimated lifetime costs)/Estimated
lifetime costs

Net present value It is an analysis technique that compares costs and benefits
for each year of the systems lifetime. Many managers consider it the preferred
cost-benefit analysis technique.

Feasibility Analysis of Candidate Systems


During decision analysis phase, the system analyst identifies candidate system
solutions and analyzes those solutions for feasibility. To compare and contrast the
candidate system solutions, we use two documentation techniques: candidate
systems matrix and feasibility analysis matrix. Both use a matrix format.

Candidate systems matrix


This technique allows us to document similarities and differences between candidate
system solutions on the basis of several characteristics. However, it offers no analysis.
In this technique, the columns of the matrix represent candidate solutions. The rows
of the matrix represent characteristics that differentiate the candidates. The major
characteristics are:
Interfaces Identify how the system will interact with people and other systems.
Data Identify how data stores will be implemented, how inputs will be captured,
how outputs will be generated.
Processes Identify how (manual) business processes will be modified, how
computer processes will be implemented.
Geography Identify how processes and data will be distributed.
Other characteristics include:

System Analysis and Design

Page 6

Chapter 5

Portion of the system computerized


Benefits
Servers and workstations
Software tools needed
Application software

There are several approaches for identifying candidate solutions, including:


Recognizing users ideas and options Throughout a system development
project, users may suggest manual or technology-related solutions.
Consulting methodology and architecture standards It may dictate how
technology solutions are to be selected and what technology (ies) may be
represented.
Brainstorming possible solutions It is a technique for identifying possible
solutions
Seeking references The analyst should solicit ideas and options from other
persons and organizations that have implemented similar systems.
Browsing appropriate journals and periodicals It includes advertisements and
articles concerning automation strategies, success; failures and technology.
A combination of the above approaches could be used independently by the
development team members to derive a number of possible alternative solutions.

Feasibility analysis matrix


This technique complements the candidate systems matrix with an analysis and
ranking of the candidate system solutions.
In this technique, columns of the matrix correspond to the candidate solutions. Some
rows correspond to the feasibility criteria. Rows are added to describe the general
solution and ranking of the candidates. A column is also added for the weight of each
type of feasibility study.

The System Proposal


The system proposal is a written report or formal presentation of a recommended
solution among the candidate solutions intended for system owners and users.
Therefore, the system analyst should be able to write a formal business report and
make a business presentation.

Written Report

Length of The Written Report: - The general guidelines to restrict the size of the
report are:
To execute-level managers one or two pages.
To middle-level managers three to five pages.
To supervisory-level managers less than 10 pages.
To clerk-level personnel less than 50 pages.
System Analysis and Design

Page 7

Chapter 5

It is also possible to organize a larger report to include summarized sub-reports for


managers who are at different levels. These sub-reports are usually included as
early sections in the report, focusing on the bottom line.
Organization of The Written Report: - Every report consists of both primary
and secondary elements. Primary elements present the actual information that
the report is intended to convey. Secondary elements package the report so that
the reader can easily identify the report and its primary elements.
The primary elements can be organized in one of the two formats: factual and
administrative. Factual format is traditional and best suited to readers who are
interested in facts and details as well as conclusions. This format is used to specify
detailed requirements and design specifications to system users.
In contrast, administrative format is a modern, result-oriented format preferred
by many managers and executives. This format is designed for readers who are
interested in results, not facts. It includes conclusions and recommendations first.
Factual Format

Administrative Format

I. Introduction

I. Introduction

II. Methods and procedures


III. Facts and details

II. Conclusions and recommendations


III. Summary and discussion of facts
and details

IV. Discussion and analysis of facts


and details

IV. Methods and procedures

V. Recommendations
VI. Conclusion

V. Final conclusion
VI. Appendixes with facts and details

Both formats include some common elements. Introduction should include:


purpose of the report, statement of the problem, scope of the project, and a
narrative explanation of the contents of the report. The methods and procedures
section should briefly explain how the information contained in the report was
developed. The facts section should describe the type of factual data presented
(e.g., existing system description, analysis of alternate solutions, or design
specifications. The conclusion should briefly summarize the report, verifying the
problem statement, findings, and recommendations.
The secondary or packaging elements of the report are self-explanatory. The
elements are given below.
Letter of transmittal
Title page
Table of contents
List of figures, illustrations, and tables
Abstract or executive summary
(The primary elements--the body of the report, in either the factual or administrative
format--are presented in this portion of the report.)

System Analysis and Design

Page 8

Chapter 5

Appendices
No report should be distributed without a letter of transmittal to the
recipient. This letter should be clearly visible, not inside the cover of the
report. It states what type of action is needed on the report. It can also call
attention to any features of the project or report that deserve special attention.
The abstract or executive summary is a one- or two-page summary of the
entire report. It helps readers decide if the report contains information they
needed to know.
Writing the Report: -

Fig: Steps in Writing a Report


We can follow the following guidelines to write a good report:
Paragraphs should convey a single idea
Sentences should not be too complex
Write in the active voice
Eliminate jargon, big-words, and dead-words

Formal Presentation
Formal presentations are special meetings used to sell new ideas and gain approval for
new systems. They may also be used for any of these purposes: sell a new system, sell
new ideas, sell change, verify conclusions, clarify facts, report progress etc. In many
cases, a formal presentation may set up or supplement a more detailed written report.
System Analysis and Design

Page 9

Chapter 5

Effective and successful presentations require significant preparation. The time


allotted to presentation is frequently brief; therefore, organization and format are
critical issues. A typical outline and time allocation for an presentation is given below:
I. Introduction (one-sixth of total time available)
A. Problem statement
B. Work completed to date
II. Part of the presentation (two-thirds of total time available)
A. Summary of existing problems and limitations
B. Summary description of the proposed system
C. Feasibility analysis
D. Proposed schedule to complete project
III. Questions and concerns from the audience (time here is not to be included
in the time allotted for presentation and conclusion; it is determined by those
asking the questions and voicing their concerns)
IV. Conclusion (one-sixth of total time available)
A. Summary of proposal
B. Call to action (request for whatever authority you require to
continue systems development)
The advantage of presentation is the immediate feedback and spontaneous
responses. The disadvantage is that the material presented is easily forgotten.
Therefore, presentations are often followed by a written report.
Preparing for The Formal Presentation: - While making presentation, it is
important to know your audience. This is especially true when presentation is
trying to sell new ideas and a new system. Furthermore, a successful analyst must
be an effective salesperson. It is entirely appropriate and strongly recommended
for an analyst to formally study salesmanship. Some guidelines for the preparation
of the formal preparation are given below:
Define your expectations of the presentation.
The presentation should be carefully organized around the allotted time
(usually 30 to 60 minutes).
Use visual aids Predawn flipchart, overhead slides, PowerPoint slides, and
the like.
Practice the presentation.
Conducting The Formal Presentation: - Some guidelines that improve the
actual presentation are:
Dress professionally.
Avoid using the word I when making the presentation. Use you and we.
Maintain eye contact with a group and keep an air of confidence.
Be aware of your own mannerisms. Some of the most common mannerisms
include using too many hand gestures, pacing, and repeatedly saying, you
know or ok.

System Analysis and Design

Page 10

Chapter 5

Sometimes while you are making a presentation, some members of the audience
may not be listening. The following suggestions may prove useful for keeping
people listening:
Stop talking.
Ask a question and let someone on the audience answer it.
Try a little humor.
Use props.
Change your voice level.
Do something unexpected.
Usually a formal presentation will include time for questions from the audience.
The guidelines for answering questions are:
Always answer a question seriously, even if you think it is a silly question.
Answer both the individual who asked the question and the entire audience.
Summarize your answer.
Limit the amount of time you spend answering any one question.
Be honest.
Following Up The Formal Presentation: - It is extremely important to follow up
a formal presentation because the spoken words and impressive visual aids used in
a presentation often do not leave a lasting impression. So, most presentations are
followed be written reports that provide the audience with a more permanent copy
of the information that was communicated.

System Analysis and Design

Potrebbero piacerti anche