Understanding the Information Content in MIS Management Tools

Author(s): Christine T. Kydd

Source: MIS Quarterly , Sep., 1989, Vol. 13, No. 3 (Sep., 1989), pp. 277-290
Published by: Management Information Systems Research Center, University of
Minnesota

Stable URL: https://www.jstor.org/stable/249002

JSTOR is a not-for-profit service that helps scholars, researchers, and students discover, use, and build upon a wide
range of content in a trusted digital archive. We use information technology and tools to increase productivity and
facilitate new forms of scholarship. For more information about JSTOR, please contact support@jstor.org.

Your use of the JSTOR archive indicates your acceptance of the Terms & Conditions of Use, available at
https://about.jstor.org/terms

Management Information Systems Research Center, University of Minnesota is collaborating

with JSTOR to digitize, preserve and extend access to MIS Quarterly

This content downloaded from

102.115.189.225 on Tue, 15 Sep 2020 17:55:38 UTC
All use subject to https://about.jstor.org/terms

Understanding
Understandingthe
the
Information Content
in MIS Management
Tools1
By: Christine T. Kydd
Department of Business
Administration
University of Delaware
Newark, Delaware 19716
Abstract
This article suggests that failure to address the
uncertainty and equivocality that exist during the
development and implementation of a new man-
agement information system is a major reason
why projects fail. Uncertainty and equivocality
occur naturally at different intensities in the vari-
ous stages of the systems development life
cycle. They can also be introduced into the situ-
ation based on the level of technology of the
new system. Specific management tools that
can be effective for reducing uncertainty, re-
solving equivocality, or both, are presented and
evaluated according to the capability of each
for eliminating such conditions. General guide-
lines concerning application of the framework
are provided for managers.
Keywords: MIS failures, information processing,
communication, uncertainty, equivo-
cality, communication tools
ACM Categories: K.6.1, C.5.m
Support for this research was provided by the Center
for Information Systems Management, Education and
Research, College of Business and Economics, Uni-
versity of Delaware, Newark, Delaware.
This content downloaded from
102.115.189.225 on Tue, 15 Sep 2020 17:55:38 UTC
All use subject to https://about.jstor.org/terms
MIS Management Tools
Introduction
At a time when many of us thought that comput-
ers had become more user-friendly and individu-
als more computer-oriented than ever before, sta-
tistics still indicate that between one-third and
one-half of all information systems projects never
reach the implementation stage (Turner, 1982).
Numerous other reports of incomplete or unsuc-
cessful implementation efforts continue to appear
in the academic literature and business press.
Bank of America recently announced the can-
cellation of a new automated trust accounting
system. The announcement stated that the bank
had set aside $80,000,000 to cover the loss in-
curred up to the point that the project was
cancelled (for additional examples see Jones
and Kydd, 1988; Lucas, 1975; Markus, 1984;
Schmitt and Kozar, 1978). Clearly, such failures
are still a major problem faced by systems spe-
cialists, managers, and organizations today.
Problems associated with the development and
implementation of new management information
systems have been attributed to technical issues,
social issues, and various interactions between
the technology and the individuals intended to
use the technology (Lucas, 1975; Markus, 1983;
1984). On the technical side, there can be re-
curring problems or setbacks based on the
chosen technology. It is easy to understand how
such problems lead to frustrated systems people
and disillusioned users regarding the new
system, particularly as due dates pass by with
work still incomplete. Such problems may be at-
tributed to either hardware or software. They
may depend, for example, on the way in which
a new system was designed to link with previ-
ous organizational computer facilities or on the
way the programs were designed and written.
The difficulty stems primarily from the technol-
ogy rather than from the user.
Many studies suggest that there are also seri-
ous barriers to success associated with the
social or behavioral side of information systems
development and implementation (Alter, 1976;
Edstrom, 1977; Ginzberg, 1981a; Lucas, 1976;
Nichols, 1981; Schmitt, 1978; Zmud and Cox,
1979). This attention to behavioral and organ-
izational issues has been incorporated into
recent implementation theories (Kling, 1980;
Markus, 1983; 1984; McFarlan, 1983). Several
specific reasons for failure of information sys-
tems at the implementation stage, as suggested
by these theories, include lack of an appropriate
MIS Quarterly/September 1989 277
MIS Management Tools

systems
systems champion,
champion,change
change agent
agent
or or
integrator
integrator agement's commitment
commitment playsplays in
in determining
determining the the
(Ackoff,
(Ackoff, 1960;
1960;Argyris,
Argyris,1970;
1970;
1971;
1971;
Curley,
Curley,
1983;
1983; extent to which
which aa new
new system
system is is accepted
accepted (Jones
(Jones
Kolb
Kolb and
and Frohman,
Frohman,1970;
1970;Lewin,
Lewin,1947;
1947;
Nichols,
Nichols, and Kydd, 1987;
1987; 1988;
1988; Markus,
Markus, 1984).
1984). If
If the
the com-
com-
1981;
1981; Schein,
Schein,1961;
1961;Turner,
Turner,1982),
1982),
poor
poor
user
user mitment level
level is
is perceived
perceived to
to be
be low,
low, users
users often
often
attitudes/perceptions/commitment
attitudes/perceptions/commitment levels
levels "pretend" to
to use
use aa new
new system,
system, while
while still
still rely-
rely-
(Ginzberg,
(Ginzberg,1981a;
1981a;1981b;
1981b;Lucas,
Lucas,
1978;
1978;
1979),
1979), ing primarily
primarily onon old
old methods
methods to to carry
carry out
out tasks.
tasks.
lack
lack of
of management
managementsupport
support
(Bean,
(Bean,
et et
al.,al.,
1975;
1975;
Although problem
problem areas
areas have
have been
been identified
identified
Ginzberg,
Ginzberg, 1981a;
1981a;Lucas,
Lucas,1978;
1978;
Schmitt,
Schmitt,
1978),
1978),
low
low user
user initiation
initiationand/or
and/orparticipation
participation (Alter,
(Alter,
and suggestions
suggestions made
made on
on how
how to
to increase
increase the
the
1978;
1978; Boland,
Boland,1978;
1978;Schmitt,
Schmitt, 1978;
1978;Zmud
Zmud andand likelihood of
of MIS
MIS project
project success,
success, these
these sugges-
sugges-
tions vary by
by specificity
specificity and
and applicability
applicability to
to par-
par-
Cox,
Cox, 1979),
1979),and
andlow
lowinvolvement
involvement in in
project
project
defi-
defi-
ticular organizational
organizational situations.
situations. Nichols
Nichols (1981),
(1981),
nition
nition and
andplanning
planningby byusers
usersand
andmanagement
management
for example,
example, conducted
conducted aa behavioral
behavioral analysis
analysis
(Ginzberg,
(Ginzberg,1981a).
1981a).
and suggested
suggested aa plan
plan of
of action
action whereby
whereby the
the sys-
sys-
There
There are
are also
alsobroader,
broader,organizational
organizationalsituations
situations tems analyst
analyst steps
steps into
into the
the user's
user's shoes
shoes to
to gain
gain
that
that contribute
contributetotodevelopment
development and
and
implementa-
implementa- a true understanding
understanding of of the
the job
job and
and effects
effects of
of
tion
tion problems.
problems.Information
Information systems
systems have
have
been
been the new system
system on
on that
that job.
job. Others
Others suggest
suggest
strongly
strongly linked
linkedtotoananorganization's
organization'spower
powerstruc-
struc- more general
general ideas
ideas such
such as
as the
the assignment
assignment of of
ture
ture (Kling,
(Kling,1980;
1980;Markus,
Markus,1984).
1984).
Gaining
Gaining
or or project responsibility
responsibility to
to the
the user,
user, intensive
intensive user
user
losing
losing access
accessto
toinformation
informationbased
based
onon
thethe
wayway education programs,
programs, toptop management
management involve-
involve-
a new
new system
systemdistributes
distributesinformation
information
often
often ment, and use
use of
of the
the systems
systems analyst
analyst as
as aa tech-
tech-
means
means gaining
gainingor orlosing
losingpower
power as as
well.
well.
There-
There- nical expert and
and catalyst
catalyst for
for user
user involvement
involvement
fore,
fore, since
sinceimplementation
implementation ofofananMISMIScancan
sig-sig- (see Zmud and
and Cox,
Cox, 1979,
1979, for
for example).
example). These
These
nificantly
nificantlychange
changea acompany's
company's power
power structure,
structure, and several other researchers have hinted at the
those
those on
on the
thelosing
losingside
sidemay
maynot
notwant
want to to
accept
accept need for good communication on both technical
the
the system.
system.Other
Otherorganizational
organizational structures
structures suchsuch and organizational issues among the relevant
as standard
standardcommunication
communication patterns,
patterns, perform-
perform- parties, including systems analysts, users, man-
ance
ance evaluation
evaluationmethods,
methods,workwork flow
flowcoordina-
coordina- agers of systems and user personnel, and top
tion,
tion, and
and organizational
organizationalculture
culturemaymayalsoalso
be be
af- af- management. Ein-Dor and Segev (1977) sug-
fected
fected by
by the
theintroduction
introductionofof
a new
a new
system
system gest that top management should create an en-
(Markus,
(Markus, 1984).
1984). vironment that fosters interaction among partici-
pants; Zmud and Cox (1979), Dickson and
Although
Although technical
technicalfeatures
featuresororindividual
individual
or or
or-or- Powers (1973), Turner (1982), and Boland
ganizational
ganizationalcharacteristics
characteristicsalone
alone
maymaycontrib-
contrib- (1978) all endorse a problem-solving team ap-
ute
ute to
to development
developmentandandimplementation
implementation prob-
prob- proach where a sense of mutual trust and com-
lems
lems regarding
regardinga anew
newsystem,
system,
many
many
studies
studies mitment among the participants exists to encour-
ascribe the difficulties encountered to an inter-
age a free exchange of beliefs and opinions; and
action between the technical and the social as-
Boland (1978), Nichols (1981), and Zmud and
pects (Curley, 1983; Keen, 1981; Kling, 1980;Cox (1979) emphasize the importance of good
Lucas, 1975; Markus, 1984; Nichols, 1981). A interpersonal skills on the part of the systems
number of important issues in this discussion in- analyst for the resulting quality of the interaction
clude (1) the fit between the technology and the between the analyst and user.
individuals who will use it (e.g., have the indi-
viduals been prepared technically? Are they Communication, therefore, is a critical key to the
ready emotionally and socially for the change?); successful development and implementation of
(2) the fit between the features of the new an MIS project. The purpose of this article is
system and various organizational features (will to discuss specifically what mechanisms facili-
the system support the current organizational tate communication at various stages in the sys-
structure and patterns, or will it change them tems development life cycle and in various in-
radically?); (3) perceptions of how jobs will be formation systems situations. Situations are
changed by the introduction of the new system; defined in terms of the levels of uncertainty and
and (4) perceptions of the level of commitment equivocality that are present based on the level
on the part of upper management concerning of technology used. This characterization uses
actual use of the system. This last issue is par- the information processing framework that sug-
ticularly important, as evidenced by several stud- gests that organizations process information to
ies that underline the critical role that upper man- reduce uncertainty and resolve equivocality (Daft

278 MIS Quarterly/September 1989

This content downloaded from

102.115.189.225 on Tue, 15 Sep 2020 17:55:38 UTC
All use subject to https://about.jstor.org/terms
 MIS Management Tools

and
and Lengel,
Lengel,1986;
1986;Weick,
Weick,1969;
1969;1979).
1979).
TheThe
frame-
frame- unclear
unclear about
about their
their needs.
needs.Open
Opendiscussions
discussions
work
work is
is aauseful
usefulone
onefor
for
organizing
organizing manymanyof the
of the with the
the systems
systems analyst
analysthelps
helpsa auser
usertotoclarify
clarify
reasons
reasons (reviewed
(reviewedabove)
above)
for
forfailure
failure
of of
develop-
develop- what the
the requirements
requirements of
ofaanew
newsystem
systemshould
should
ment
ment and
andimplementation
implementation efforts.
efforts.It also
It also
leads
leads be in order
order to
to be
be of
of maximum
maximumbenefit
benefittotothe
theuser.
user.
to
to suggestions
suggestionsfor
forthe
thetypes
types
of of
management
management
tools
tools appropriate
appropriatefor
forvarious
various
types
types
of of
projects
projects Preliminary
Preliminary written
written specifications
specifications(a(asystems
systems
at
at various
variousdevelopment
development stages.
stages. requirements
requirements document)
document)provide
provideusers
userswith
witha a
great deal
deal of
of objective
objective information
informationabout
aboutthe
the
In
In the
the next
nextsection,
section,management
management tools
tools
thatthat
are are system's
system's capabilities.
capabilities. Such
Suchaadocument
documentinforms
informs
typically
typicallyused
usedduring
duringthe
the
systems
systems development
development potential
potential users
users about
about the
thesystem's
system'smajor
majorfunc-
func-
life
life cycle
cycleare
arediscussed.
discussed.
Then
Then each
each
tooltool
is evalu-
is evalu- tions before the user has committed to the final
ated
ated for
for its
itsusefulness
usefulnessinin
reducing
reducing uncertainty,
uncertainty, system and before the system has been built.
resolving
resolvingequivocality,
equivocality,oror
both.
both.This
This
evaluation
evaluation Often preliminary specifications serve to provide
is done
done with
withrespect
respecttoto
both
bothstage
stage
in the
in the
lifelife
cycle
cycle a written summary of the discussion between
and
and level
levelof
oftechnology
technology used
usedin in
thethe
development
development the analyst and the users concerning require-
environment.
environment.Guidelines
Guidelines for
for
appropriate
appropriate manage-
manage- ments of the system (Gane and Sarson, 1979).
ment
ment tools
toolsto
touse
useinineach
each
stage
stage
andand
forfor
eacheach
situation are offered. A structured walk-through of design specifi-
cations is a useful management tool among ana-
lysts, managers and users. This type of walk-
through allows the analyst to help the users ex-
MIS Management Tools perience the way a system will work when com-
There are a number of management tools that pleted by taking them through the system one
are typically used during the planning, develop- step at a time. It is a detailed description of how
ment, and implementation of a new information the system uses data and what the relevant
system. Several of these tools are described inputs and outputs are at each stage. A walk-
below. through can be useful in clarifying what the
system will and will not do and what the final
Systems standards documents generally pro- use of the system will be. At this point in devel-
vide instructions on how information systems opment, the user and analyst can still discuss
should be designed and implemented. Such docu- viewpoints that differ and resolve ambiguous
ments often include a systems development issues that arise from the user's lack of under-
methodology and associated deliverable stan- standing of the system to date. The advantage
dards. They provide a great amount of objective is that the user has something concrete to focus
information regarding how system work is to be on and can determine what still remains ambigu-
done within a given organization and how stan- ous or unclear about the system.
dard problems should be dealt with.

A systems integrator, or champion, is a A structured walk-through of code is similar

person who acts as a liaison among the various
stakeholders of a new information system. This
person is able to move such a group of ana-
lysts, users, and managers, toward a collective
decision regarding the planning, design, and im-
plementation of the system. Such a person pro-
vides the strong and unfailing support often
needed to complete a systems implementation
effort. If he or she is at a high enough manage-
ment level, an integrator acts to coordinate top
management involvement with lower levels of
managers (Curley, 1983).
Systems analyst/user meetings for require-
ments specification are planning meetings.
The purpose of such meetings is to determine
what user needs are and what the new system
will do to meet those needs. Users are often
to the above but is conducted for the purpose
of detecting errors in code during the develop-
ment process. This tool is very useful to ana-
lysts and programmers in determining where the
code is incomplete or inconsistent. It also points
out the outputs of the system, which can then
be compared to specifications.
Prototyping goes one step beyond a structured
walk-through. It allows the integration and syn-
thesis of different perceptions of what a system
will look like when completed. A prototype is a
model of the finished system, which the user can
utilize on a limited basis. It is more than just a
description; it is an actual working system (Alavi,
1984). Thus, the user can readily identify as-
pects of the system that are unclear or that the
user would like to change. If several different

MIS Quarterly/September 1989 279

This content downloaded from

102.115.189.225 on Tue, 15 Sep 2020 17:55:38 UTC
All use subject to https://about.jstor.org/terms
MIS Management Tools

potential
potentialusers
usersofof
thethe
same
same
system
system
havehave vastlyto resolve
vastly resolve equivocality
equivocality (Daft
(Daftand
andLengel,
Lengel,1986;
1986;
divergent
divergentviews
viewsabout
aboutthethe
system's
system's
design and and Perrow,
design Perrow, 1967;
1967; Weick,
Weick, 1969;
1969;1979).
1979).Uncertainty
Uncertainty
capability,
capability,the
theavailability
availability
of aofprototype allowsallowsis defined as the absence of information
a prototype
each user to see where his or her view differs (Downey and Slocum, 1975; Tushman and
from the actual system. Through several itera- Nadler, 1978). Therefore, in order to reduce un
tions, a consensus can be reached on the final certainty, questions must be asked and addi-
specifications of the system. tional information gained, usually through the col
lection of objective data, to learn the answers
User training sessions can serve a variety of The questions in this case are known; it is just
needs. They may be used to quickly transmit a matter of obtaining the information necessar
large amounts of objective data about the use to answer those questions. This information ma
of a system, or they may focus primarily on be in the form of raw data or may be the output
users' concerns with implementing the system of a sophisticated modeling and analysis effort
in their respective positions. In the first case,
such a session may be used primarily to edu- Equivocality, on the other hand, is defined as
cate users on the system's use. In the latter ambiguity and the existence of multiple, conflict
case, the participants may discuss various view- ing interpretations about a given organizationa
points and perceptions, working to integrate situation (Daft and Macintosh, 1981; Weick,
them into one cohesive and unified view of the
1969; 1979). It is assumed that there is confu-
new system. Through such discussions, users sion and a lack of understanding about what ap
and analysts can resolve ambiguous issues. propriate questions need to be asked. One o
the most difficult aspects of equivocality is tha
Formal system documentation includes com-
it is not feasible to ask a "yes or no" question
prehensive information about a particular infor-
In an equivocal situation, the questions them-
mation system, including how it works, what the
selves must be defined or created; they are not
relevant input and output files are, whether any
already known. To resolve ambiguity, there mus
databases are involved, and who has responsi-
be an exchange of existing views in order t
bility for running, updating, and maintaining the
define what the relevant problems are. There
system. For a given system, this documentation
is a need for social interaction so that intuition
should help to answer virtually any question re-
judgment, and beliefs can contribute to the en
garding the workings of the system. Since the
actment of a shared interpretation.
documentation is specific to a particular system,
it may or may not include general systems stan-
Figure 1 shows the framework that emerge
dards. In some cases, the systems analyst may
when combinations of the uncertainty and equivo
include in the documentation notes on recurring
cality factors are formed. The horizontal axis rep
and unexpected bugs in the system or on
resents organizational uncertainty. The vertica
changes in responsibility assignment over time.
axis represents equivocality. Each cell describe
The planning, development, and implementation a general situation for various levels of uncer
of a new information system can be the cause tainty and equivocality. Examples of events fall
of great uncertainty and ambiguity in an organi- ing into each cell are provided in the next sec
zation. Each of the tools described above has tion (from Daft and Lengel, 1986).
a certain capacity for reducing this uncertainty
and/or ambiguity if used in the proper stage Whenof both uncertainty and equivocality are low
the development life cycle and under appropri- (cell 1), little additional information is necessary,
and since a common interpretation already
ate conditions. Following a discussion of the un-
certainty/equivocality framework, the tools are exists, there is little need for social interaction
An example is the use of a routine, familiar tech-
evaluated for their potential contribution to each
stage and condition. nology in a stable and predictable environment
When uncertainty is high but equivocality is low
(cell 2), there is a need for additional objective
data to provide answers to predefined questions
The Uncertainty/ Equivocality Examples include a situation of sudden high turn
over or an unanticipated customer reaction to
Framework a new product feature. In both situations, the
It has been proposed that organizations proc- problems or questions are clear, but large
ess information both to reduce uncertainty andamounts of information need to be collected and

280 MIS Quarterly/September 1989

This content downloaded from

102.115.189.225 on Tue, 15 Sep 2020 17:55:38 UTC
All use subject to https://about.jstor.org/terms
 MIS Management Tools

High 3.
3.High
HighEquivocality,
Equivocality,
Low Uncertainty
Low4.Uncertainty
High Equivocality, 4.
High
High
Uncertainty
Equivocality, High
Occasional ambiguous, unclear Many ambiguous, unclear events,
events, managers define managers define questions, also
questions, develop common seek answers, gather objective
grammar, gather opinions. data and exchange opinions.
Equivocality

1. Low Equivocality, Low Uncertainty 2. Low Equivocality, High Uncertainty

Clear, well-defined situation, need Many, well-defined problems,
few answers, gather routine managers ask many questions,
objective data. seek explicit answers, gather new
quantitative data.
Low

Low High
Uncertainty

Figure 1. Framework of Information Requirements

Based on Uncertainty and Equivocality

Source: Daft, R.L. and Lengel, R.H. "Organizational Information Requirements, Media Richness, and
Structural Design," Management Science (32:5), May 1986. Reprinted with permission by The
Institute of Management Sciences.

analyzed
analyzed to to
determine
determine
the solutions.
the solutions.
Surveys Surveys
or or reduction
reduction requires
requires the
theacquisition
acquisitionofofnew,
new,objec-
objec-
interviews
interviews areare
twotwo
options
options
for useful
for ways
usefulin ways in tive information.
information. Equivocality
Equivocalityresolution
resolutionrequires
requires
which
whichtotocollect
collect
the the
required
required
data in data
these in
cases.
these cases. the sharing
sharing of of opinions
opinionsandandviewpoints
viewpointsininorder
order
to lead
lead to
to aa common
commoninterpretation
interpretationthat
thatcan
candirect
direct
In
In situations
situationswhere
where
therethere
is low is
uncertainty
low uncertainty
and and future
future activities.
activities. ToTosupport
supportthese
thesedifferent
differentbe-be-
high
highequivocality
equivocality(cell (cell
3), obtaining
3), obtaining
additional
additional
in- in- havioral
havioral responses,
responses, different
differenttypes
typesofoforganiza-
organiza-
formation
formation is not
is not
as important
as important as defining
as defining
the ap- the ap- tional
tional communication
communicationmechanisms
mechanismsshould
shouldbebeput
put
propriate
propriate questions.
questions.
Managers
Managers
in suchin
a situ-
such a situ- into place
place to
to support
supportthethereduction
reductionofofuncertainty
uncertainty
ation need to exchange views to enact a or the
the resolution
resolution of ofequivocality,
equivocality,asasneeded.
needed.
common perception of the situation. Examples
include determining the feasibility of acquiring
Following
Following DaftDaft and
andLengel's
Lengel's(1986)
(1986)framework,
framework,
the particular
particular organizational
organizationalmechanism
mechanismrequired
required
another company or determining the appropri-
to reduce
reduce uncertainty
uncertaintyor ortotoresolve
resolveequivocality
equivocality
ate set of goals for a new company. In both
cases, an exchange of perceptions and opin- depends
depends largely
largely on on the
theamount
amountand andrichness
richnessofof
ions rather than the collection of additional data the information
information neededneededforfora agiven
givensituation.
situation.
Amount
Amount of of information
informationrefers
referstotothethequantity
quantityofof
is warranted. If both uncertainty and equivocality
data that
that will
will bebe sufficient
sufficienttotoanswer
answerthe theques-
ques-
are high (cell 4), additional objective data as well
tions
tions that
that arise
arise from
fromthethesituation
situationatathand.
hand.Rich-
Rich-
as the enactment of a shared perception are re-
ness of
of information,
information,on onthe
theother
otherhand,
hand,refers
refers
quired. An example occurs during a period of
to how
how well
well aa particular
particularcommunication
communicationtransac-transac-
very rapid technological advancement, where
tion is
is able
able to
to overcome
overcomediffering
differingpoints
pointsofofview
view
sudden unanticipated events occur and the new
or clarify
clarify ambiguous
ambiguousissues
issuesinina atimely
timelymanner.
manner.
technology is relatively difficult to analyze. Since
Rich
Rich information
information generally
generallyenables
enablesdebate
debateandand
there is a high level of ambiguity to deal with,
managers must define the relevant questions
discussion
discussion to
to take
take place
placeso
sothat
thata aconsensus
consensus
can be reached. Communication media that are
and then gather large amounts of objective in-
best at providing rich information are those that
formation to try to answer these questions.
allow "face-to-face" meetings, or at least voice
In each case, different responses are required contact. In order from best to worst, examples
to deal effectively with each situation. Uncertainty of media that transmit rich information are face-

MIS Quarterly/September 1989 281

This content downloaded from

102.115.189.225 on Tue, 15 Sep 2020 17:55:38 UTC
All use subject to https://about.jstor.org/terms
MIS Management Tools

to-face
to-face meetings,
meetings,telephone
telephonecontact,
contact,
personal
personal Equivocality
Equivocalityhashas
already
already
been
been
resolved
resolved
before
before
letter
letter or
or memo,
memo,impersonal
impersonalletter
letter
oror
memo
memo
(writ-
(writ- the
the rules
rulesand
andregulations
regulations
cancan
be determined.
be determined.
ten),
ten), and
and numeric
numericdocuments
documents(Daft
(Daft
andand
Lengel,
Lengel,
1986;
1986; Daft
Daft and
andWiginton,
Wiginton,1979;
1979;Galbraith,
Galbraith,1973;
1973; Planning
Planningisisananongoing
ongoingprocess
process
thatthat
is directed
is directed
1977;
1977; Lengel
Lengel and
andDaft,
Daft,1984).
1984). at
at reducing
reducingboth
both equivocality
equivocality
and and
uncertainty.
uncertainty.
Equivocality
Equivocalityusually
usuallyneeds
needs
to be
to resolved
be resolved
first.first.
Figure
Figure 22 shows
showsaacontinuum
continuumofofselected
selectedorgan-
organ- For
For example,
example,underlying
underlying goals
goals
or targets
or targets
mustmust
izational
izational mechanisms
mechanismswithwithrespect
respect
tototheir
theirrela-
rela- be
be agreed
agreedupon
uponbefore
beforeanyany
further
further
activity
activity
can can
tive
tive capacity
capacityfor
forreducing
reducinguncertainty
uncertainty or or
forfor
re-re- be
be carried
carriedout.
out.Rich
Richinformation
informationprocessing
processing
solving
solving equivocality
equivocality(Daft
(Daftand
andLengel,
Lengel,
1986).
1986).
TheThe mechanisms
mechanismssuch such
as as
face-to-face
face-to-face
meetings,
meetings,
figure
figure shows
showsthat
thatthose
thosestructures
structuresthat
that
provide
provide group
groupnegotiations,
negotiations, andand
exchanges
exchanges
of opinions
of opinions
richer
richer information
informationare
arethose
thosethat
that
tend
tend
to to
be be
better
better help
help resolve
resolveequivocality.
equivocality.
Once
Once
initial
initial
goalsgoals
are are
at solving
solving the
theequivocality
equivocalityproblem,
problem,while
whilethose
those set,
set, then
thenplanning
planningalso
also
encompasses
encompassesuncertainty
uncertainty
that
that communicate
communicatelargelargequantities
quantitiesofof
information
information reduction
reductionby bygathering
gatheringobjective
objective
datadata
through
through
quickly
quickly are
are best
bestsuited
suitedfor
forreducing
reducing uncertainty.
uncertainty. less
less rich
richmedia
mediasuch
such
as as
written
written
reports
reports
and and
As examples,
examples,selected
selectedmechanisms
mechanismsareare
ex-ex- documents.
plained next.
Group meetings include all types of face-to-
A firm's formal rules and regulations are es- face contact such as reams, task forces, and
tablished to document the appropriate response committees. They can be used simply to trans-
to a recurring problem that is well understood. mit information and thereby address uncertainty
This is the least rich type of mechanism, and reduction. However, they are a very effective
it focuses primarily on uncertainty reduction. means of resolving equivocality through allow-

Formal
Formal
Information Group
Rules and Systems Planning Integrator Meetings
Regulations Special Direct
Reports Contact

_ vVI V 1VvV v
V

^--^^^ ^^~~~Equivocality Reduction

Uncertainty Reduction

- Structure facilitates - Structure facilitates rich,

less rich, impersonal personal media
media for communication

- Focus on clarity,
- Focus on amount of information determination of questions

Figure 2. Structural Mechanisms for Reducing

Source: Daft, R.L. and Lengel, R.H. "Organizational Information Requirements, Me

Structural Design," Management Science (32:5), May 1986. Reprinted with pe
Institute of Management Sciences.

282 MIS Quarterly/September 1989

This content downloaded from

102.115.189.225 on Tue, 15 Sep 2020 17:55:38 UTC
All use subject to https://about.jstor.org/terms
 MIS Management Tools

ing
ing group
groupmembers
memberstotoreach
reach
a collective
a collective
deci-
deci- It
It should
shouldbebe noted
notedthatthat
uncertainty
uncertainty
and equivo-
and equivo-
sion
sion or
or judgment.
judgment.Participants
Participantsin in
a group
a group
meet-
meet- cality
calityare
arenot notmutually
mutually exclusive
exclusive
conditions
conditions
and and
ing
ing can
can exchange
exchangeperceptions
perceptionsand,
and,
through
through
a a often
oftenexist
exist together.
together.In fact,
In fact,
one may
oneargue
may thatargue that
subjective
subjectiveprocess,
process,reach
reacha common
a common frame
frame
of of if
if equivocality
equivocality exists,
exists,
thenthen
therethere
must bemust
somebe some
reference.
reference.The
Theface-to-face
face-to-faceinteraction
interaction
in aingroup
a group uncertainty
uncertainty as as
well.
well.
An argument
An argumentsupporting
supporting
this this
meeting
meeting allows
allowsthe
theparticipants
participantsto to
resolve
resolve
am-am- view
viewis:is:IfIf
thethequestions
questionshave have
not yetnotbeen
yetde- been de-
biguous
biguous issues
issuesthrough
throughthe
the
exchange
exchange
of of
richrich fined,
fined,how
how cancanthethe
involved
involved
parties
parties
alreadyalready
know know
information. the
the answers?
answers?OnOn
thethe
other
other
hand,hand,
one might
one might
argue
arguethat
that equivocality
equivocality can be
canhigh
be while
high uncer-
while uncer-
In the next section, the MIS management tools
tainty
taintyisislow:
low:i.e.,i.e.,
the the
questions
questions
have not
haveyetnot
beenyet been
are evaluated in terms of how each contributes
defined;
defined;but butonceonce theythey
are determined,
are determined,the an-the an-
to the reduction of uncertainty, the resolution of
swers
swersarearereadily
readily forthcoming.
forthcoming.This article
This article
sup- sup-
equivocality, or both, during various stages of
ports
portsthetheview
view that that
uncertainty
uncertainty
and equivocality
and equivocality
the systems development life cycle.
can
can exist
existtogether
together simultaneously
simultaneously
in a given
in a situ-
given situ-
ation
ationininanyanycombination
combination (for (for
example,
example,
high un- high un-
certainty
certaintyand andlowlow equivocality,
equivocality,
low uncertainty
low uncertainty
and
andhigh
highequivocality,
equivocality,
highhigh
both,both,
low both).
low both).
Evaluation of MIS Figure
Figure3 3shows
shows these
these
combinations
combinations
in twoindi-two di-
Management Tools mensions
mensionsonly onlyto to
suggest
suggest
wherewhere
the strengths
the strengths
of
of each
eachtool
toollies.
lies.
ThisThis
frame
frame
is expanded
is expanded
in the in the
The information systems management tools de-next section.
scribed earlier vary in their capacity to process
rich information. Thus, they also vary in their ca-Tools that are best suited for uncertainty reduc-
pability for reducing uncertainty and/or equivo- tion include formal systems documentation, sys-
cality. Figure 3 suggests how the tools might be tems standards documents, and systems require-
placed along a continuum with respect to this ments documents. Each of these tools is a
capacity. written document and therefore has limited ca-

Formal Preliminary Written User Training Structured Prototype

Systems Specifications Sessions Walk-Through Systems
Documentation (Systems Requirements of Design Specifications
Documents)
Systems Structured Systems Analyst Systems
SSteamndards
Standards Structured as Integrator Analyst/User
Walk-Through Meetings
Documents of Code

V v v V V v v V
Equivocal
I

Uncertainty Reduction

- Structure facilities - Structure facilitates rich,

less rich, impersonal personal media
media for communication

- Focus on clarity,
- Focus on amount of information determination of questions

Figure 3. MIS Management Tools for Reducing

Uncertainty/Equivocality

MIS Quarterly/September 1989 283

This content downloaded from

102.115.189.225 on Tue, 15 Sep 2020 17:55:38 UTC
All use subject to https://about.jstor.org/terms
MIS Management Tools

pacity
pacityfor
forprocessing
processingrich
rich
information.
information.
However,
However, Planning
each
each conveys
conveysa alarge
large
amount
amountof objective
of objective
data data
The initial planning stage of an information
and
and provides
providesanswers
answersto to
questions
questions
about
about
a given
a given
system generally represents a situation of high
system
systemor orthe
themethod
methodto to
be used
be used
in the
in devel-
the devel-
uncertainty and high equivocality. Neither user
opment
opmentofofthe
thesystem.
system.
Thus,
Thus,
the the
primary
primary
but not
but not
exclusive use of such tools is to reduce uncer- nor analyst has a clear understanding from the
start about requirements and desired capabili-
tainty. A systems development methodology
ties of the new system. Therefore, a variety of
(often part of systems standards) could be con-
communications tools should be employed
sidered useful in resolving equivocality also be-
during the planning stage.
cause it provides guidelines for the process to
be used in systems development. Also, a sys-
tems requirements document could serve as a Since equivocality needs to be addressed first,
catalyst for further clarification of system deliv-tools such as a development methodology (part
erables, if the document does not meet prior ex-of systems standards), analyst/ user meetings for
pectations of user or analyst. In this way, it con- requirements specifications, and use of an inte-
tributes to equivocality resolution. grator are most appropriate at the early stages
of planning. A development methodology clari-
A structured walk-through of code, user training fies for the analyst what the development proc-
sessions, and use of a systems integrator con- ess should be. It also provides information re-
tribute to the reduction of both uncertainty andgarding expected milestones and associated
equivocality. These tools have the capability to delivery dates to the user. Thus, it helps both
convey objective information, thus reducing un-analyst and user to focus on what the relevant
certainty. They also can help to process rich in-questions are. A user/analyst meeting for require-
formation through their social interaction com-ments specification is another critical tool through
ponent, enabling participants to resolve which users and analysts together determine
equivocality. what the system will do. Through a face-to-face
meeting, the analyst and user can discuss,
Tools that are better at resolving equivocality
debate, and eventually come to an agreement
than uncertainty include a structured walk- on the system specifications. Such a meeting
through of design specifications, analyst/user
allows for rich information processing, which is
meetings for requirements specification and pro-
necessary to resolve existing equivocality con-
totyping. In each case, the tool primarily en-
cerning the new system. Use of a system cham-
hances open discussion and the processing of
pion or integrator also contributes to reducing
rich information through multiple cues and chan-
ambiguity at the planning stage. An integrator
nels. Thus, each allows divergent views to be can serve as a liaison between various user
expressed and discussed, and enables the de-
groups and the systems department, or betwee
velopment of a common interpretation. These
divergent groups of users of the same system
tools may provide objective information as well,
Through summarization and integration of th
thereby aiding uncertainty reduction; but they are
various viewpoints, an integrator helps to defin
seen as contributing primarily to equivocality a common frame of reference.
resolution.

Later in the planning phase, such tools as a struc-

Tools for Stages of the
Systems Development Life
Cycle
Based on the continuum just described, it is
useful to think about what conditions generally
exist during the various stages of a systems de-
velopment life cycle and what tools would be
most useful in reducing either uncertainty or
equivocality or both during each stage. The four
stages considered including planning, analysis
and design, implementation, and operation
(McLeod, 1986).
tured walk-through of design specifications, a writ-
ten systems requirements document, or a pro-
totype model of the system are useful in
reducing ambiguity. The structured walk-through
allows both the user and analyst to see how the
system is designed to work to date. A written
requirements document, although a less rich com-
munications tool, can make a user aware of mis-
specified or unspecified issues regarding the
system. Both tools can be followed up with dis-
cussion of potential additions, deletions, or modi-
fications. A prototype model is an excellent tool
for reducing equivocality because the user can
see exactly how the system works and what it

284 MIS Quarterly/September 1989

This content downloaded from

102.115.189.225 on Tue, 15 Sep 2020 17:55:38 UTC
All use subject to https://about.jstor.org/terms

does and does not do. However, a prototype
would be appropriate at later stages of planning
only because at the very least, some user/
analyst discussions would have to precede the
building of a prototype system.
Analysis and design
If the equivocality at the planning stage has been
dealt with successfully, then all that should
remain at the analysis and design stage of an
information system is uncertainty. Thus, this
stage is characterized as a high uncertainty, low
equivocality situation. Most of the questions re-
garding the new system have already been de-
termined; however, the answers to those ques-
tions are not yet known.
At this stage, tools that should be employed to
reduce uncertainty include systems standards
documents, preliminary written specifications,
and structured walk-throughs of code. Each of
these tools helps the analyst primarily to deter-
mine how the system should be built. The stan-
dards document, possibly including a develop-
ment methodology, provides very concrete and
specific details as to the development process.
Preliminary written specifications force the ana-
lyst to put down in writing exactly what the
system will do and how it will work. Such speci-
fications can be passed along to the user at this
stage as well to get early feedback on the valid-
ity of the specifications. Written specifications
also provide objective information to the user con-
cerning how far the analyst's thinking has come
to date regarding the system's development. A
structured walk-through of code allows the ana-
lyst and programmer to determine whether the
code is complete and consistent. All of these
tools can be used in the analysis and design
stage to reduce uncertainty, i.e., providing ob-
jective information that helps the individual
answer predefined questions.
During the analysis and design stage of any in-
formation system, the analyst can learn that cer-
tain desired features agreed upon during the plan-
ning phase are infeasible. If this occurs, then
both analyst and user need to rethink the design
specifications. This, in effect, means that they
must return to the planning stage and use the
tools indicated there to reduce both uncertainty
and equivocality.
This content downloaded from
102.115.189.225 on Tue, 15 Sep 2020 17:55:38 UTC
All use subject to https://about.jstor.org/terms
MIS Management Tools
Implementation
The implementation stage of the development
life cycle should ideally be one of low uncer-
tainty and low equivocality. However, that is
rarely the case. More often, when a system is
finally implemented, numerous unforeseen prob-
lems occur, both along technical as well as
social interaction lines. Thus, this stage is char-
acterized as one of moderate uncertainty and
moderate equivocality.
It is appropriate in this stage to utilize tools
across the entire spectrum shown in Figure 3.
If technical problems arise, they most likely rep-
resent uncertainty; i.e., why was some other
system affected when the new system was im-
plemented? Or why didn't the new system work
the way in which the analyst intended it to work?
To answer this sort of question, the analyst
needs to collect additional objective data using
such tools as systems documentation, standards
documents, written specifications or a walk-
through of code. If problems linked to the social
network of the company arise, such as an un-
anticipated shift in perceived power or an in-
tended user group refusing to take responsibil-
ity for the system, they are generally problems
of equivocality. Thus, such tools as group meet-
ings, use of an integrator, and possibly user edu-
cation sessions are appropriate.
Operation
The operation stage of an information system
should be one of low uncertainty and low equivo-
cality. By the time the system is in full operation,
most of the bugs, both technical and other, have
been worked out. This is not always the case,
of course. Consider the situation where one firm
had a long-standing forecasting system in place,
but whose users and analysts went to great
lengths to manually force the system to give the
desired output. In most situations, however,
there is little uncertainty or equivocality associ-
ated with a fully implemented, operable system.
Events that might create new uncertainty or am-
biguity concerning a working system are the
effect of a new system on a working system (for
example, a bug suddenly develops in a working
system that has been accurate for years), or a
change in the personnel who control the use of
the working system (for example, the system is
no longer being used, or is being used incor-
rectly). Tools that are good at addressing un-
MIS Quarterly/September 1989 285
MIS Management Tools

certainty
certaintyin
inthe
thefirst
firstcase
case
and
and
equivocality
equivocality
in the
in the The level of technology of a new system com-
second case should be utilized to correct these pared to that of the organization or relevant
conditions. subset of individuals has been cited as being
related to the level of risk associated with imple-
Changes in the environment could also occur menting the new system (McFarlan, 1981). If the
that would require a complete reassessment of
level of technology used in a new system is
a working system. For example, industry deregu-
higher (i.e., more sophisticated) than that which
lation could nullify most of the underlying as-
the analysts and users are familiar with, then
sumptions of a given system, in which case the risk associated with the project is high. Pre-
users and analysts might be faced once again vious experience with the technology, however,
with conditions of high uncertainty and high reduces the project's risk of failure.
equivocality. Thus, tools appropriate for the plan-
ning stage would again be appropriate here.
In terms of the uncertainty/equivocality frame-
work, technology can be broken down into two
factors - variety and analyzability - as shown
Tools for Different Levels of in Figure 4 (Daft and Lengel, 1986; Perrow,
Technology 1967; Van de Ven, 1980). Uncertainty is repre-
sented by the amount of variety inherent in the
In this day and age computer technology is
set of tasks that the technology performs. When
moving too fast for any given individual to be
there is little task variety, then the level of un-
able to keep up with it. It is important, therefore,
certainty is low, because little information is nec-
to consider the nature of the interaction between
essary to describe the few types of tasks that
potential user groups and the level of the tech-
the system carries out. Similarly, when task va-
nology they are being asked to embrace. Over
riety is high, then uncertainty is also high, since
and above the individual stages of the systems
much more information is required to inform
development life cycle, this interaction can be
users about all of the different types of tasks
a source of uncertainty and equivocality through-
the system is able to perform.
out the stages of development. In this section,
technology is defined in terms of the uncertainty/ Equivocality is represented by task analyzabil-
equivocality framework. Examples of systems ity; that is, how easily each task the system per-
that fit into each combination of uncertainty and forms can be analyzed or understood by the
equivocality are provided along with suggested user. When several of the tasks are very difficult
tools for reducing each. to understand (unanalyzable), then equivocality

High
Unanalyzable 3. Expert System 4. Al-based System
Structure: Structure:
- Rich media - Rich media
- Small amount - Large amount
of information of information
Task
Analyzability
Equivocality
1. Accounting system 2. Production Planning
Structure: Structure:
- Media of low richness - Media of low richness
- Small amount of- Large amounts of
information information
Analyzable
Low
Little variety Task variety Great variety
Low Uncertainty High

Figure 4. Level of Technology as a Source of Uncertainty and Equivocality

286 MIS Quarterly/September 1989

This content downloaded from

102.115.189.225 on Tue, 15 Sep 2020 17:55:38 UTC
All use subject to https://about.jstor.org/terms

is high. Users faced with using such a system
may have problems based on their shallow com-
prehension of the system. When most of the
tasks are easy to understand, then equivocality
is low. In such a case, even though the users
may still have numerous questions regarding the
system, at least they know enough about the
various tasks to be able to ask relevant ques-
tions. System comprehension is related to situ-
ational and personal factors that have been
found to be strongly related to successful imple-
mentations (Lucas, 1978). This suggests that
users are more likely to support systems devel-
opment and implementation when they under-
stand what the system does. This high compre-
hension can exist only if equivocality is low.
In Figure 4, each cell represents a combination
of task variety (uncertainty) and task analyzabil-
ity (equivocality). For each category, an exam-
ple of an information system type is given, along
with the general types of communication mecha-
nisms appropriate for addressing uncertainty and/
or equivocality.
Cell 1: A well-focused, routine system is repre-
sentative of this cell, where there is little variety
regarding the system technology, and all tasks
performed are easily analyzed. An example is
an accounting system where tasks are standard
and repetitive. In such a case, there is low un-
certainty and low equivocality. For most poten-
tial users, implementing such a system would
create few problems from a technical standpoint
since they would understand what the system
does. Therefore, they would require little objec-
tive information concerning how to implement
and subsequently use the system.
Since uncertainty and equivocality are both low,
a small amount of information is required, and
communication media of low richness are suffi-
cient. Therefore, written specifications, systems
documentation from the analyst, and possibly a
few training sessions should be satisfactory to
the users regarding such a system.
Cell 2: In this cell, there is great variety in the
tasks the new system performs, but each of
those tasks is easily understood. Therefore, the
result is moderate to high uncertainty and rela-
tively low equivocality. An example of this type
of system is a production planning system. From
a technical standpoint, what the potential user
needs in this case is a large amount of informa-
tion concerning what the system does and how
it is used correctly. Questions concerning the
This content downloaded from
102.115.189.225 on Tue, 15 Sep 2020 17:55:38 UTC
All use subject to https://about.jstor.org/terms
MIS Management Tools
system
system areare
well
well
known
known
and easily
and answered
easily answered
with with
additional
additional data.
data.
In general,
In general,
there are
there
no ambigu-
are no ambigu-
ous
ousissues
issuesconcerning
concerning
understanding
understanding
of the of the
system.
The appropriate management tools include such
media as formal systems documentation (writ-
ten), user manuals, and user training sessions
where the emphasis is on communicating a quan-
tity of information in a short period of time. Tools
that foster discussion and debate (provide rich
information) are not required in this case, since
equivocality is low.
Cell 3: There is little task variety for these sys-
tems, although the tasks that are performed are
difficult to understand, and therefore, the system
falls into the unanalyzable category. This corre-
sponds to low uncertainty and high equivocality.
An example could be an expert system. A naive
user who is faced with using a new expert
system would not necessarily need large
amounts of information to learn how to use the
system, but may need extensive training to un-
derstand what an expert system is all about.
Since expert systems are generally based on
one individual expert's intuitive decision process,
a user may see this process as highly ambigu-
ous. From the user's viewpoint, formulating ques-
tions may not be possible. This may hamper will-
ingness to try to use such a system.
To alleviate the equivocality in such a case
means making the tasks seem more analyzable,
or understandable, to the user. This can best
be accomplished through the use of rich com-
munication media such as face-to-face user/
expert and user/analyst meetings, a structured
walk-through of design specifications, and use
of a prototype system. It is easier and less stress-
ful to try to get clarity on a subject through per-
sonal, face-to-face attention than through writ-
ten memos such as formal documentation. In
this example, a meeting and/or walk-through be-
tween the user and original expert, or a proto-
type may help the user to better understand the
decision process being modelled in the system.
Cell 4: In this ceil, there is great task variety,
and the tasks are primarily unanalyzable (high
uncertainty and high equivocality). An example
of a system falling into this category is one of
the leading-edge, artificial intelligence or robot-
ics systems. Particularly for the naive Al user,
these systems would certainly appear to be very
sophisticated and complex. For such systems,
there is not only a large amount of information
MIS Quarterly/September 1989 287
MIS Management Tools

that
thatneeds
needsto be
totransmitted
be transmitted
to the potential potential applied
to theuser, applied
user, based
based
on each
on each
tool'stool's
capacity
capacity
for elimi-
for elimi-
but
butthere
thereare are
also many
also many
ambiguous issues that issues nating
ambiguous nating
that uncertainty
uncertainty
and/or
and/or
equivocality.
equivocality.
need to be resolved.
In
In order
orderto to
apply
apply
this this
framework
framework
to a specific
to a specifi
situation,
situation,
For systems falling into this cell, rich information thethe
following
following
general
general
guidelines
guidelines
are pro- are pro
mechanisms are necessary as well as mecha- vided
videdforfor
MIS
MIS
designers,
designers,
developers,
developers,
implemen-
implemen-
tors,
tors,and
nisms that are able to communicate a great quan- andmanagers.
managers.
tity of data. For reducing uncertainty, appropri-
ate mechanisms include formal systems docu-1. Systems people and managers of MIS
mentation, systems requirements documents, groups need to be more aware of the fact
and group user training sessions, all mecha- that uncertainty and equivocality exist at vari-
nisms where large amounts of information can ous stages in the systems development life
be provided in a clear and unambiguous cycle and can lead to problems in complet-
manner. Where ambiguous issues exist, differ- ing the system successfully if not adequately
ing perceptions regarding the system can be addressed. MIS personnel also need to ex-
aired and consolidated through discussion and amine the level of technology of each new
debate in analyst/user meetings or during a struc- system for potential sources of uncertainty
tured walk-through of design specifications. An and/or equivocality.
integrator is also useful in this situation as a
2. Systems people and MIS managers need to
person who can talk to both the technical per-
better understand and act to implement the
sonnel involved and the non-technical user, and
appropriate communication mechanisms that
help to resolve unclear issues between the par-
can reduce the particular existing levels of
ties, thus reducing equivocality. An early proto-
uncertainty and equivocality. This refers to the
type of the system would further help to resolve
determination of whether some type of social
ambiguity for the user.
interaction is required (e.g., use of prototyp-
ing, walk-throughs, or meetings) or whether
more formal and impersonal management
Conclusions mechanisms (e.g., systems documentation,
preliminary specifications, or written reports
The framework presented in this article and and its documents) are sufficient to resolve the
application to the information system develop-
problems created by the uncertainty and
ment and implementation setting is important be-
equivocality.
cause it provides an integrative framework con-
cerning the failure of information systems. These
Many guidelines should not be particularly diffi-
of the factors associated with information system
cult nor time consuming to implement since all
failures in the literature, such as lack of man-
the tools are already in widespread use. The
agement support, lack of a systems champion, key issue, however, is recognition of the uncer-
and low user involvement in project definition
tainty and equivocality that may exist at various
and planning, result in conditions of uncertainty
stages of a systems project and appropriate ap-
and/or equivocality and are therefore subsumed
plication of the correct tools to resolve resulting
under the uncertainty/equivocality framework.problems.
Based on this framework, the article suggests
Future research should address methods or pro-
that many systems fail because the uncertainty
cedures
and equivocality that exist at the start of any IS that would help managers to be better
project are not adequately addressed. Uncer- at recognizing when uncertainty or equivocality
exists. It could also focus on the evaluation of
tainty and equivocality occur naturally (at vary-
the electronic communication tools that are cur-
ing intensities and combinations) in the different
stages of the system's life cycle. They also rently
can on the market. Such tools as video con-
be created based on the level of technology
ferencing or group decision support systems
have been designed to replace or enhance more
used in a given system. Thus, it is imperative
traditional
that analysts, managers, and users work to- communication methods such as a
gether through all phases of planning, anal'sis
face-to-face group meeting. Whether these elec-
and design, implementation, and operation tronic
to tools can address equivocal situations as
reduce existing uncertainty and to resolveeffectively
am- remains to be seen, however. Similar
issues exist regarding uncertainty. This should
biguous issues. To accomplish this, the appro-
be and
priate communication tools must be selected a fruitful area for further research.

288 MIS Quarterly/September 1989

This content downloaded from

102.115.189.225 on Tue, 15 Sep 2020 17:55:38 UTC
All use subject to https://about.jstor.org/terms
 MIS Management Tools

References ation," Academy of Management Journal

(18:3), September 1975, pp. 562-577.
Edstrom, A. "User Influence and the Success
Ackoff, R.L. "Unsuccessful Case Studies and of MIS Projects: A Contingency Approach,"
Why," Operations Research (8:4), March/ Human Relations (30:7), July 1977, pp. 589-
April 1960, pp. 259-263. 607.
Alavi, M. "An Assessment of the Prototyping Ap- Ein-Dor, P. and Segev, E. "Information-System
proach to Information Systems Development," Responsibility," MSU Business Topics (25:4),
Communications of the ACM (27:6), June Autumn 1977, pp. 33-40.
1984, pp. 556-563. Galbraith, J. Designing Complex Organizations,
Alter, S.L. "How Effective Managers Use Infor- Addison-Wesley, Reading, MA, 1973.
mation Systems," Harvard Business Review Galbraith, J. Organizational Design, Addison-
(54:6), November-December 1976, pp. 97- Wesley, Reading, MA, 1977.
104. Gane, C. and Sarson, T. Structured Systems
Alter, S.L. "Development Patterns for Decision Analysis: Tools and Techniques, Prentice-
Support Systems," MIS Quarterly (2:3), Sep- Hall, Inc., Englewood Cliffs, NJ, 1979.
tember 1978, pp. 33-42. Ginzberg, M.J. "Key Recurrent Issues in the MIS
Argyris, C. "Resistance to Rational Management Implementation Process," MIS Quarterly (5:2),
Systems," Innovation, No. 10, November June 1981a, pp. 47-59.
1970, pp. 28-34. Ginzberg, M.J. "Early Diagnosis of MIS Implemen-
Argyris, C. "Management Information Systems: tation," Management Science (27:4), 1981b,
The Challenge to Rationality and Emotional- pp. 459-478.
ity," Management Science (17:6), February Jones, L.H. and Kydd, C.T. "An Information Proc-
1971, pp. B275-292. essing Framework for Understanding Manage-
Bean, A.S., Neal, R.D., Radnor, M. and Tansik, ment of the MIS Development Process," De-
D.A. "Structural and Behavioral Correlates of cision Science Institute Proceedings, Boston,
Implementation in U.S. Business Organiza- MA, 1987.
tions," in Implementing Operations Research/ Jones, L.H. and Kydd, C.T. "An Information Proc-
Management Science, R.L. Schultz and D.P. essing Framework for Understanding Success
Slevin (eds.), American Elsevier, New York, and Failure of MIS Development Methodolo-
NY, 1975. gies," Information and Management (15),
Boland, R.J., Jr. "The Process and the Product 1988, pp. 263-271.
of System Design," Management Science Keen, P.G.W. "Information Systems and Organ-
(24:9), May 1978, pp. 887-898. izational Change," Communications of the
Curley, K.F. and Gremillion, L.L. "The Role of ACM (24:1), January 1981, pp. 24-32.
the Champion in DSS Implementation," Infor- Kling, R. "Social Analyses of Computing: Theo-
mation and Management (6:4), August 1983, retical Perspectives in Recent Empirical Re-
pp. 203-209. search," Computing Surveys (12:1), March
Daft, R.L. and Lengel, R.H. "Organizational In- 1980, pp. 61-110.
formation Requirements, Media Richness and Kolb, D.A. and Frohman, A.L. "An Organizational
Structural Design," Management Science Development Approach to Consulting," Sloan
(32:5), May 1986, pp. 554-571. Management Review (12), 1970, pp. 51-65.
Daft, R.L. and Macintosh, N.B. "A Tentative Ex- Lengel, R.H. and Daft, R.L. "An Exploratory Analy-
ploration into the Amount and Equivocality of sis of the Relationship Between Media Rich-
Information Processing in Organizational Work ness and Managerial Information Processing,"
Units," Administrative Science Quarterly working paper, Texas A & M University, 1984.
(26:2), June 1981, pp. 207-224. Lewin, K. "Frontiers in Group Dynamics,"
Daft, R.L. and Wiginton, J. "Language and Or- Human Relations (1:1), February 1947, pp. 5-
ganization," Academy of Management 41.
Review (4:2), April 1979, pp. 179-191. Lucas, H.C., Jr. Why Information Systems Fail,
Dickson, G.W. and Powers, R.F. "MIS Project Columbia University Press, New York, NY,
Management: Myths, Opinions and Reality," 1975.
California Management Review (15:3), Spring Lucas, H.C., Jr. The Implementation of Com-
1973, pp. 147-156. puter-Based Models, National Association of
Downey, H.K. and Slocum, J.W. "Uncertainty: Accountants, New York, NY, 1976.
Measures, Research and Sources of Vari- Lucas, H.C., Jr. "Empirical Evidence for a De-

MIS Quarterly/September 1989 289

This content downloaded from

102.115.189.225 on Tue, 15 Sep 2020 17:55:38 UTC
All use subject to https://about.jstor.org/terms
MIS Management Tools

scriptive
scriptive Model
Modelof ofImplementation,"
Implementation," MISMIS
Quar-
Quar- Turner, J.A. "Observations on the Use of Be-
terly
terly (2:2),
(2:2), June
June1978,
1978,pp.
pp.27-41.
27-41. havioral Models in Information Systems Re-
Lucas,
Lucas, H.C.,
H.C.,Jr.
Jr."The
"TheImplementation
Implementation of of
an an
Op-Op- search and Practice," Information and Man-
erations
erations Research
ResearchModel
Modelininthe
the
Brokerage
Brokerage In-In- agement (5:4,5), September-November 1982,
dustry,"
dustry," TIMS
TIMSStudies
Studiesininthe
theManagement
Management Sci-Sci- pp. 207-213.
ences,
ences, North-Holland
North-HollandPublishing
PublishingCompany,
Company, Tushman, M.L. and Nadler, D.A. "Information
Amsterdam, 1979, 13, pp. 139-154. Processing as an Integrating Concept in Or-
Markus, M.L. "Power, Politics and MIS Implemen- ganization Design," Academy of Management
tation," Communications of the ACM (26:6), Review (3:3), July 1978, pp. 613-624.
June 1983, pp. 430-444. Van de Ven, A.H. and Ferry, D.L. Measuring
Markus, M.L. Systems in Organizations: Bugs and Assessing Organizations, John Wiley and
and Features, Chapters 1,2,3, Pitman Pub- Sons, New York, NY, 1980.
lishing Co., Boston, MA, 1984. Weick, K.E. The Social Psychology of Organiz-
McFarlan, F.W. "Portfolio Approach to Informa- ing, Addison-Wesley, Reading, MA, 1969.
tion Systems," Harvard Business Review, Sep- Weick, K.E. The Social Psychology of Organiz-
tember-October 1981, pp. 142-150. ing, Addison-Wesley, Reading, MA, 1979.
McFarlan, F.W. and McKenney, J.L. Corporate Zmud, R.W. and Cox, J.F. "The Implementation
Information Systems Management: The Process: A Change Approach," MIS Quarterly
Issues Facing Senior Executives, Chapter 7, (3:2), June 1979, pp. 35-43.
Irwin, Homewood, IL, 1983.
McLeod, R., Jr. Management Information Sys-
tems, 3rd edition, Scientific Research Associ-
ates, Palo Alto, CA, 1986.
Nichols, M.L. "A Behavioral Analysis for Plan-
About the Author
ning MIS Implementation," MIS Quarterly
(5:1), March 1981, pp. 57-66. Christine T. Kydd is an assistant professor in
Perrow, C. "A Framework for the Comparative the Department of Business Administration at the
Analysis of Organizations," American Socio- University of Delaware in Newark, Delaware. Her
logical Review (32:2), April 1967, pp. 194- research activities have examined topics in indi-
208. vidual and organizational information process-
Schein, E.H. "Management Development as a ing, cognitive biases in decision making and im-
Process of Influence," Industrial Management plementation problems in MIS. She has pub-
Review (2:2), Spring 1961, pp. 59-77. lished in OMEGA: The International Journal of
Schmitt, J.W. and Kozar, K.A. "Management's Management Science and Information and Man-
Role in IS Development Failures: A Case agement. She is a member of The Institute of
Study," MIS Quarterly (2:2), June 1978, pp. Management Science, the Decision Sciences In
7-16. stitute and the Academy of Management.

290 MIS Quarterly/September 1989

This content downloaded from

102.115.189.225 on Tue, 15 Sep 2020 17:55:38 UTC
All use subject to https://about.jstor.org/terms