Database Reference
In-Depth Information
Feasibility Study: The First Step
It never pays to just jump into developing a system. Usually, it's a good
idea to do a feasibility study first. The easiest part of the feasibility study is
determining whether the system is technically feasible. Sometimes, how-
ever, it might not be feasible because the company doesn't have the techni-
cal expertise to do the job. A good system analyst will go one step further
and see if it's feasible to outsource the project to people that can do the job.
Sometimes, you'll find that the technology is just not robust enough. For
example, many years ago I wanted to deliver voice-recognition devices to
the floor of the New York Stock Exchange. The technology at that time was
just too primitive, so the entire project was deemed not feasible.
Adding a layer of complexity to the problem is when you discover that
the project is feasible from a technical perspective but would require vast
organizational changes (e.g., creation of new end-user departments). This,
then, would make the project organizationally not feasible.
Finally, the project just might cost too much money. To figure this out,
you will need to do a cost/benefit analysis. This will require you to figure
out an estimated cost for everything you wish to do, including cost of hard-
ware, cost of software, cost of new personnel, cost of training, etc. Then
you need to calculate the financial savings for creating the new system,
e.g., reduce staff by one-third, save five hours a day, etc. However, some-
times the benefits are intangible, e.g., compete with our major competitor.
Once it has been determined that the project is feasible, a project plan is
created that plots out the course for the entire systems development effort,
e.g., budget, resources, schedule, etc. The next step, then, is to start the
actual analytical part of systems development. For that, we need to collect
some information.
Information-Gathering Channels
One of the first things you will do when starting a new project is gather
information. Your job is to understand everything about the department
and proposed system you are automating. If you are merely modifying an
existing system, you are halfway there. In this case, you will review all of
the system documentation, the system itself, and the end users to ferret
out the changed requirements.
How can you make sense out of a department and its processes when
you don't know anything about it? One of the things you do is act like
Search WWH ::
Custom Search