364 Part III • Acquiring Information Systems
and emerging technological solutions, the IT expertise of in-
house personnel, and the anticipated infrastructure needed
to both develop and support the proposed system. The busi-
ness manager is primarily responsible for assessing the pro-
posed system’s economic and operational feasibility. In
some organizations, business analysts who are knowledge-
able about IT, but are not IT professionals, play a lead role in
this process. Operational feasibility entails assessing the
degree to which a proposed system addresses the business
issues or opportunities that gave rise to the idea for a new or
changed information system. The motivation may be discre-
tionary (e.g., “I think we can improve sales with an X sys-
tem”) or imposed (e.g., a new EPA or FTC regulation or new
language in a labor contract).
Both business managers and IS analysts work
together to prepare a cost-benefit analysis of the proposed
system to determine the economic feasibility. Typical ben-
efits include costs to be avoided, such as cost savings from
personnel, space, and inventory reductions (which might
be due to reducing errors); new revenues to be created
(which might come from increased speed of decision mak-
ing, improving planning and control, or opening new sales
opportunities); and other ways the system could contribute
business value overall. However, for many applications
today, some or all of the major benefits might be intangible
benefits; they are hard to measure in dollars. Examples of
intangible benefits include better customer service, more
accurate or more comprehensive information for decision
making, quicker processing, or better employee morale.
(For a further discussion of system justification, see the
section later in this chapter entitled “Managing an SDLC
Project.”)
The IS analyst takes primary responsibility for estab-
lishing the development costs for the project. This requires
the development of a project plan that includes an estimat-
ed schedule in workweeks or months for each step in the
development process and an overall budget estimate
through the installation of the project. Estimating these
project costs and schedules is especially difficult when
new technologies and large system modules are involved.
(Note that these costs usually do not include user depart-
ment costs, which might be substantial during both the
Definition and Implementation phases.)
Any project, not just systems development, has risks,
and these risks need to be considered. Not every project needs
to be low risk. Often an organization will undertake a port-
folio of systems development projects that range from low to
high risk and low to high net value. Risks can arise from bar-
riers to achieving the benefits (e.g., overcoming resistance
from some key players—often called political feasibility—or
differences of opinion about system requirements), uncertain-
ties of economic estimates, inexperience of development staff
with the application area or technologies to be used, and the
sheer size of the project (large projects tend to be more risky
than small projects). Projects with high risks and low rewards
may not be approved.
The deliverable of the Feasibility Analysis step is a
document of typically 10 to 20 pages that includes a short
executive overview and summary of recommendations, a
description of what the system would do and how it would
operate, an analysis of the costs, benefits, risks of the pro-
posed project and system, and a plan for the development
of the system. Sometimes referred to as a systems propos-
al document or a business case, this document is typically
first discussed and agreed to by both the executive sponsor
and the IS project manager and then reviewed by a man-
agement committee that has authority for system approvals
and prioritization.
Before additional steps are undertaken, both IS and
business managers need to carefully consider whether to
commit the resources required to develop the proposed
system, given the funding available for what might be
many proposed systems. The project costs up to this point
have typically been modest in relation to the total project
costs, so the project can be abandoned at this stage without
the organization having spent much money or expended
much effort. As described earlier, the approval of a large
system request might not actually occur until after the
completion of a formal feasibility analysis and may be
reassessed after each step in the SDLC. For large projects,
the executive sponsor of the application is typically
responsible for the presentation of a business case for the
system before the approving body.REQUIREMENTS DEFINITION If the document produced
from the feasibility analysis receives the necessary organi-
zational approvals, the Requirements Definition step is
begun. Both the development of the “right system” and
developing the “system right” are highly dependent on
how well the organization conducts this step in the SDLC
process. This requires heavy participation from user man-
agement. If this step is not done well, the wrong system
might be designed or even built, leading to both disruptive
and costly changes later in the process.
Although in the past new systems often automated
what had been done manually, most of today’s systems are
developed to do new things, to do old things in entirely
new ways, or both. Although the executive sponsor plays a
key role in envisioning how IT can be used to enable
change in what the sponsor’s people do and how they do it,
the sponsor is often not the manager who helps to define
the new system’s requirements and will not be a primary
user of the system. Rather, the sponsoring manager must
make sure that those who will use the system and those