Chapter 9 • Methodologies for Custom Software Development 385to be used to develop the system and the degree to which
the application is to be interconnected with other applica-
tions (or databases). For example, spreadsheet functions
are relatively simple to design and spreadsheet applications
are relatively simple to implement, whereas data mining
tools based on neural network technologies are much more
complex and require more sophisticated tool training.
Applications can also vary greatly on the extent to
which they rely on other applications for data inputs. If an
application requires sophisticated tools and access to data
distributed via a network, then an IS-developed solution
may be the only appropriate approach. However, it is not
uncommon for users to first develop a stand-alone applica-
tion to address a business problem and then later for this
application to be used as a prototype for a more integrated
application developed by IS specialists.
DEVELOPER CHARACTERISTICS The application devel-
oper skills and experience and the availability of the user
developer resources in relation to the time period allotted
for the development of the new application should be con-
sidered. As discussed earlier, the lack of dependence on
scarce IS department resources is a frequent catalyst for
UAD if the user developers have, or can be trained to have,
the tool skills and application development expertise
required. One management challenge here is that the busi-
ness manager who wants the application might not have the
knowledge to adequately assess the user developer’s skills
and expertise prior to the project getting underway.
Consultation with IS experts inside or outside the organiza-
tion may therefore be needed to adequately assess this
potential risk factor.
Guidelines for User Developers
When systems are developed by IS professionals, they use a
methodology (described earlier in this chapter) appropriate
for the specific application. For user-developed systems, the
user developer (or the accountable business manager) typi-
cally chooses the development methods to be used. Panko
(1988) suggests that the most appropriate methodology for a
user-developed application depends on three of the applica-
tion characteristics: scope (personal or departmental use),
size (small to large), and the nature of the business problem
being supported by the application (simple to complex).
In Panko’s framework, small applications for simple
problems that will be used by the person developing the
application (personal scope) could be developed with a
simplified (“collapsed”) life-cycle approach. However,
when the application for personal use is of larger size and
requires more complex logic, a more disciplined approach
needs to be taken to ensure a quality application.
If the application is for other users (a workgroup or
department), then one or more of the other intended users
should be involved in the application’s development, even if
a formal project team for the application is not established.
If a large, complex application is being developed for multi-
ple users, it should be developed using an SDLC methodol-
ogy (with formalized user and developer roles). In fact, the
Definition phase should include a reassessment of whether
the project should be user developed or IS developed, using
factors such as those summarized earlier (see Figure 9.15).
Prototyping and other iterative methods are especially
well suited for user-developed applications: The screen de-
signs can be tried out with multiple users, and today’s UAD
tools have graphical interfaces that support prototyping well.
However, as described earlier in this chapter, a basic set of
requirements for the application should first be defined to
guide the development of the prototype; selected users then
try out the prototype and suggest changes; and the prototype
is then modified by the developer until there is agreement
that the application meets the business users’ needs.
Figure 9.16 lists a number of important questions that
can serve as a guide for user developers during the
Definition and Construction phases. These questions are
similar to those that arise during an SDLC or prototyping
development process run by IS professionals. It is common
for user developers to underestimate what it takes to define
a system’s requirements, especially if other users will also
be using the application. A key learning point for most first-
time user developers is not to move to the Construction
phase, or the building of the prototype, too soon.
Two common UAD pitfalls are not doing enough
testing of the application and not providing sufficient
documentation. The lack of adequate testing for decision
support applications can lead to serious consequences for a
business. Errors in spreadsheet applications, for example,
are known to have resulted in business losses ranging from
hundreds of thousands to millions of dollars (Galletta et
al., 1996), and inadequate debugging practices can be a
major cause (Panko, 1996; Panko and Halverson, 1996).
Studies have found that many spreadsheet developers
apparently do not attempt to reduce their spreadsheet
errors systematically and do not have other workers check
their programs. Since research on the work practices of IS
professionals has found that spotting errors by inspection
is difficult for the original programmer, user developers
should regularly involve others in debugging their applica-
tions rather than relying wholly on self-testing.
The documentation that is necessary for a user-
developed application depends on the application’s charac-
teristics. If the application is to be used by someone other
than the user developer, including a possible successor in a
specific organizational role, formal documentation should