Chapter 9 • Methodologies for Custom Software Development 383First, a major downside can be the potential loss of
quality controls. By virtue of their training and work meth-
ods, IS professionals design robust controls into a new infor-
mation system: controls for data access and inputs, controls
for calculations and other outputs, and application controls
for backup and reliability. As in any profession, products
developed by those with less training and experience will, on
the average, be of lower quality. Depending on the type and
size of the application, there is also an organizational cost
associated with having an untrained, or partially trained,
employee spend considerable amounts of time on what could
be much more efficiently achieved by an IT professional.
(Similarly, time spent by business managers on application
development can be time spent from their core jobs and com-
petencies.) Undetected bugs in processing logic, the lack of
audit trails, inadequate backup and security procedures, and
undocumented systems are much more common in user-
developed systems than in those developed by a trained IS
professional (Schultheis and Sumner, 1991). Errors in
spreadsheet programs are particularly common, and business
decisions based on faulty data can imperil the survival of the
business (see the sidebar entitled “Errors in Spreadsheets”).
Second, when systems are developed outside of an IS
organization, there is also a greater likelihood that
Errors In Spreadsheets
End users produce countless spreadsheet models each year, often to guide mission-critical decisions.
Some consultants have claimed that something like a third of all operational spreadsheet models
contain errors. One Price Waterhouse consultant reported auditing four large spreadsheet models for a
client and finding 128 errors.
Different types of errors contained in spreadsheets that have been identified include the following:- Mechanical errors—Typing errors, pointing errors, and other simple slips. Mechanical errors can
be frequent, but they have a high chance of being caught by the person making the error. - Logic errors—Incorrect formulas due to choosing the wrong algorithm or creating the wrong
formulas to implement the algorithm. Pure logic errors result from a lapse in logic, whereas domain
logic errors occur because the developer lacks the required business area knowledge. Some logic
errors are also easier to identify than others: Easy-to-proof errors have been called Eureka errors,
and difficult-to-proof errors have been called Cassandra errors. - Omission errors—Things left out of the model that should be there. They often result from a
misinterpretation of the situation. Human factors research has shown that omission errors have low
detection rates. - Qualitative errors—Flaws that do not produce immediate quantitative errors, but can lead to
quantitative errors during later “what-if” analyses or when updates are made to a spreadsheet
model, or errors that cause users to misinterpret the model’s results or make maintenance difficult,
leading to increased development costs and the potential for new errors.
To reduce error rates requires aggressive techniques—similar to the discipline followed by developers of
more complex applications.
[Based on Panko, 1996, and Panko and Halverson, 1996]
opportunities for data integration are missed. Employee time
is spent “reinventing” an application (and data) with function-
ality that is similar to an application already in use by another
workgroup, or missing the opportunity for even greater orga-
nizational value by including features other users would find
appealing. When business units throughout an organization
independently develop applications using software and data
definitions of their own choosing, the result is dozens, or even
hundreds, of what has been referred to as isolated silos or
“islands” of automation. The risks include not only
unsharable data but also conflicting reports of key business
indicators, especially if different data sources, business rules,
or time periods are utilized by the different applications.
Finally, user-developed applications that are utilized
on an ongoing basis can pose operational risks. Corporate
systems run on servers in a data center are monitored and
maintained by computer specialists. However, the responsi-
bilities for the ongoing operation and maintenance of a user-
developed application typically belong to the business unit
that created and owns the application—and might in fact be
managed by a single employee who originally developed it.
If the original developer of a database application or a
spreadsheet application (especially one with complex logic)
moves on to a different work unit, or even a different