Chapter 9 • Methodologies for Custom Software Development 371of the business activities involved in the application. The
role of the systems analyst needs to be played well in order
formultipleuser perspectives to be taken into account.
Sometimes the systems analyst also provides the important
function of providing checks and balances for IS special-
ists eager to work with new, but unproven, technologies by
ensuring that the business risks associated with new tech-
nologies are accounted for in project decisions.
Other key roles, including key business roles (e.g.,
sponsors, champions), are discussed in the chapter on IT
project management (see Chapter 11).
Managing an SDLC Project
All systems projects are typically measured by three primary
success criteria: (1) on-time delivery of an IS that (2) is of
high quality and meets business requirements and (3) is with-
in project budget. Additional project management techniques
for achieving these goals will be considered in Chapter 11.
Particularly critical for the success of custom devel-
opment projects using an SDLC methodology are three
characteristics: manageable project size, accurate require-
ments definition, and executive sponsorship.
MANAGEABLE PROJECT SIZE Experience has convinc-
ingly shown that very large custom IT projects are very
difficult to deliver within budget, which is one reason these
types of projects are considered riskier when developing
the business case. On the other hand, projects that take
fewer technical people a year or less to complete are more
likely to meet the success criteria for the project. This sug-
gests that large systems should be broken down into rela-
tively independent modules and built as a sequence of
small, manageable projects, rather than as a single monster
project.
ACCURATE REQUIREMENTS DEFINITION The SDLC
waterfall process is based on the premise that requirements
for a new system can and should be defined in detail at the
beginning of the process. The downside is that if the require-
ments are not well defined, or significantly change during
the project, there could be large cost overruns and the sys-
tem could be unsatisfactory. Early studies have shown that
about half of the total number of requirements errors (or
omissions) is typically detected in the Requirements
Definition step. Further, an error detected in the
Implementation phase costs about 150 times as much to fix
as an error detected in the Definition phase (Boehm, 1976).
Every effort must therefore be put into obtaining as accurate
a requirements definition document as possible. This
requires systems analysts skilled in eliciting requirements as
well as in process and data representation techniques. It also
requiresaccess to business usersknowledgeable about both
current business operations and the envisioned system.EXECUTIVE SPONSORSHIP Although all large systems
projects require business sponsorship, the intensity and
length of time involved with the typical SDLC project
means that executive-level sponsorship is critical to suc-
cess. Key business managers need to understand the poten-
tial benefits of the proposed system and be dedicated to
contributing resources to the systems project team, as well
as to the sustained usage of the new custom application.
Because some business managers and end users will also
be assigned to the project team, business sponsors need to
be willing to dedicate these resources to the project team,
sometimes on a full-time basis for the life of the project.
Although not every project team has end users as
formal team members, end users frequently participate by
providing information about current work processes or
procedures and evaluating screen designs from an end-user
perspective. This, too, takes time away from normal busi-
ness activities. User involvement in a systems project has
in fact been associated with user acceptance and usage of
the new system (Hartwick and Barki, 1994). However,
business managers must be willing to dedicate these busi-
ness resources throughout the project as needed, not just at
the time of implementation.Beath and Orlikowski (1994) have pointed out that
systems development methodologies can differ in their as-
sumptions about IS and user roles over the life of the project.
For example, two methodologies that have been practiced
more commonly outside of the United States (the ETHICS
method and the Soft Systems Methodology) are specifically
designed to facilitate more user involvement.
System implementation also requires managing organi-
zational changes. Unless there is strong business sponsorship,
there will not be a strong initiative to make changes to the
business as part of the systems project effort. (See Chapter 11
for some guidelines for managing business change.)SDLC Advantages and Disadvantages
The SDLC process is a highly structured approach best
suited to the development of large, complex applications
for one or more business units. A summary of the advan-
tages and disadvantages of the SDLC approach is provided
in Figure 9.7 and is discussed in the following paragraphs.
The disadvantages serve as cautions about the best conduct
of the SDLC and suggest circumstances when the SDLC is
likely not the best custom systems development approach.
In a subsequent section, we will review some alternative
approaches that address these concerns about the SDLC.