Chapter 9 • Methodologies for Custom Software Development 375The Prototyping Project Team
Managing an evolutionary development process is clearly
a joint IS and user management responsibility. Whether the
project manager role is played by IS alone, business per-
sonnel alone, or both IS and business personnel, both
groups need to jointly determine when to continue to
request revisions to a prototype and when to end the itera-
tive tryout-and-revise steps. The business manager needs
to determine whether a satisfactory solution has been
developed, and the IS manager needs to determine whether
all relevant technology capabilities have been explored.
Because only basic requirements are being defined,
the systems analyst and prototype builder (which might be
one and the same) need to have some different skill sets
than required for the SDLC process. Techniques to elicit
abstract requirements and an emphasis on detailed docu-
mentation under the SDLC process are replaced by a heavy
reliance on skills to build systems quickly using advanced
tools. The initial prototypes are assessed more in terms of
their look and feel from a user perspective and less in terms
of technical quality from a systems performance perspec-
tive. Interactions between IS specialists and users center
around creative development solutions and personal reac-
tions to user-system interfaces and outputs.
A prototyping methodology also requires a dedicated
business user role. Because there is continual user involve-
ment with the various versions of the system, the designated
business user needs to be able to be freed from other respon-
sibilities to work with the application and to suggest changes
over the life of the project. Sometimes more than one person
plays this critical end-user role, which will require a struc-
ture and process for reaching agreement when suggested
changes from different users are in conflict. The business
user also needs to be patient and to understand that each iter-
ation results in a system that may be “not quite right.”
Managing a Prototyping Project
Managing new development projects with a methodology
based on an iterative or evolutionary process requires a dif-
ferent mind-set than managing projects using an SDLC
methodology based on a highly structured development
approach. IS project managers and system builders need to
approach the project differently: The objective is to respond
quickly to user requests with a “good-enough” prototype
multiple times rather than to produce a tightly engineered
actual system at the outset of the project. This might require
some cultural changes within the IS organization. IS pro-
fessionals who have built their careers on skills and atti-
tudes required by an SDLC approach might need to acquire
new skills for prototyping approaches.
IS managers also find managing prototyping projects
more problematic because it is difficult to plan how long it
will take, how many iterations will be required, or exactly
when the system builders will be working on the system.
Project managers need to have sufficient IS resources
available for system building in order to quickly respond to
user requests for system changes within an agreed-upon
timetable. Users who will be trying out each prototype ver-
sion must be committed to the process and must be willing
and able to devote the time and effort required to test each
prototype version in a timely fashion. IS managers might
rightfully feel that they have less control over the project’s
scope. One of the potential hazards of prototyping is that
the iterative steps will go on and on and that the project
costs will keep accumulating. Good working relationships
between IS personnel and users responsible for the project
are required to move to the prototype evaluation step (Step
5) at the optimal time. Joint IS-user accountability would
appear to be a key to success for these types of projects.
Depending on the software tools used to build the
prototype, the operational efficiency of a prototype that is
evaluated in Step 5 might be significantly inferior to sys-
tems developed using the traditional SDLC methodology.
Technical standards established by the organization also
might not be rigorously followed, and the documentation
might be inadequate. A substantial investment in comput-
er-aided software engineering (CASE) tools (see the final
section of this chapter entitled “Newer Approaches”),
database management tools, and IS specialist training
might be required before an IS organization can success-
fully implement the end prototype as the final system.Prototyping Advantages and Disadvantages
The advantages of the evolutionary development methodol-
ogy address the disadvantages inherent in the SDLC
methodology. First, only basicsystem requirements are
needed at the front end of the project. This means that sys-
tems can be built using an evolutionary approach that
would be impossible to develop via an SDLC methodology.
Furthermore, prototyping can be used to build systems that
radically change how work is done, such as when work
processes are being redesigned or a totally new type of
managerial support tool has been envisioned but never seen.
It is virtually impossible to define requirements for these
kinds of systems at the beginning of a systems development
process. Prototyping also allows firms to explore the use of
newer technologies, because the expectations under an evo-
lutionary methodology are that the builders will get it right
over multiple iterations, rather than the first time.
Second, an initial working system is available for
user testing much more quickly. In some cases, business