Rituals in Information System Design

Author(s): Daniel Robey and M. Lynne Markus

Source: MIS Quarterly, Vol. 8, No. 1 (Mar., 1984), pp. 5-15
Published by: Management Information Systems Research Center, University of Minnesota
Stable URL: https://www.jstor.org/stable/249240
Accessed: 01-04-2019 19:13 UTC

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 200.89.68.196 on Mon, 01 Apr 2019 19:13:08 UTC
All use subject to https://about.jstor.org/terms
 Rituals in Information Systems

Rituals In Information Introduction

System Design It is commonly acknowledged that information

systems (IS) impose both technical and social
changes upon organizations. Understanding
these changes requires an awareness of the
values and assumptions built into systems during
the design process. This awareness, however, is
By: Daniel Robey limited by the common assumption that IS
Florida International University development is a rational process, directed
Tamiami Trail toward the improvement of decision making and
Miami, Florida 33199 organizational effectiveness. This assumption
ignores the possibility that IS design is a political
By: M. Lynne Markus
process in which various actors stand to gain or
Arthur D. Little, Inc.
4 Embarcadero Center
lose power as a result of design decisions. In this
article we examine several elements of system
San Francisco, California 94111
design from two perspectives, the rational and
the political. From the first perspective, these
design elements are viewed as logical features of
a rational process. The political perspective treats
these elements as rituals - symbolic behaviors
that reinforce the prevailing belief system in an
organization.

Recent literature on organizations demonstrates

the usefulness of multiple perspectives or
paradigms for analyzing organizational behavior
[7]. In particular, organization theorists have
Abstract become aware of a need to provide political inter-
pretations of organizational events to supplement
Developing computer-based information systems is or replace rational interpretations. Recent books
usually conceived as a rational process, intended to
[31, 37] show a developing synthesis of material
achieve identifiable and agreed upon goals. From this
on power that balances more traditional
perspective, certain elements in the system develop-
ment process are believed to enhance its effec-
treatments of the management process.
tiveness. For example, handoffs between one project Research which applies a political perspective
phase and another, feasibility studies conducted priorreveals many new insights into the management
to development work, and the use of project teamsarea. and For example, a case study by Borum [5]
steering committees are recommended in most texts indicates
as far more support for a political inter-
activities instrumental to effective system design. pretation of events in planned intervention than
Recently, the political view of organizations has the more rational and humanistic assumptions
assumed greater stature in organization theory. This normally made by organization development
perspective interprets organizational events not only practitioners. In a similar fashion, Lund [22] con-
from the rational standpoint, but also in terms of
ducted a political analysis of the impact of worker
negotiation and conflicting goals. From the political
participation on worker power. In both of these
perspective, elements of the system design process
can be interpreted as rituals which enable actors to studies, the researchers gained insight by
remain overtly rational while negotiating to achieve examining the political motives of actors and
private interests. This paper seeks to understand those subgroups.
rituals and to reveal their function in the systems design
process.
IS scholars have drawn sparingly from these
developments in organization and management
Keywords: Organizational impacts, project manage-
theory. Common frameworks for IS research do
ment
not include political variables to any significant
ACM Categories: K.4.3, K.6.1 extent [11, 20, 33]. However, some writers have

MIS Quarterly/March 1984 5

This content downloaded from 200.89.68.196 on Mon, 01 Apr 2019 19:13:08 UTC
All use subject to https://about.jstor.org/terms
Rituals in Information Systems
recognized the value of political models for
analyzing IS development. For example, Argyris
[1] provided early insight into the area, and
Mason and Mitroff [27, p. 484] mentioned the
relationship between information and power in
their seminal article on IS research. The most
thorough study of an IS-related decision process,
Pettigrew's [36] analysis of a computer purchase
decision, not only demonstrates the value of
political analysis, but also shows how to do it well.
More recently, a number of authors have offered
both conceptual frameworks and empirical
studies which substantiate the value of a political
perspective [2, 3, 14, 16, 23, 25, 43, 44].
These works are consistent with the focus of this
paper.
The Rationality of
System Development
Characterizing a process as rational implies two
things: first, that the process has an identifiable
and agreed upon set of goals and, second, that it
has been prescribed to achieve that goal. The
systems development process is rational to the
extent that two primary goals can be identified:
* to produce systems that enhance task
performance and organizational effec-
tiveness, and
* to produce systems that are accepted
and used appropriately.
Two common features of the IS development pro-
cess, the development life cycle and techniques
for user involvement, are often prescribed to
achieve these goals. In this section, we describe
these activities and show how they support the
view of systems development as a rational pro-
cess. In the following section, we show how the
same activities are consistent with a political view
of systems development.
System development life cycle
Virtually everyone in the systems field is familiar
with the concept of the system life cycle. The life
cycle describes the stages through which a pro-
ject develops as it becomes part of an organiza-
tion's normal activities. These steps include
6 MIS Quarterly/March 1984
This content downloaded from 200.89.68.196 on Mon, 01 Apr 2019 19:13:08 UTC
All use subject to https://about.jstor.org/terms
project inception, a study of its feasibility,
systems analysis, design, preparing specifica-
tions, programming, testing, training users,
installing, and finally, operating the system. These
activities are outlined in Table 1.
The life cycle is intended to ensure the translation
of system objectives into operational systems
within constraints of schedule and budget. It
disciplines practitioners to respect technical
prerequisites, for example, by delaying program-
ming until file design and input/output
requirements have been specified. Likewise,
estimates of project costs should be made prior
to investing many resources in systems analysis
and design. In addition to these technical
requirements, the life cycle shows concern for
human users and their needs. Thus, training is
conducted prior to conversion and installation in
order to reduce resistance that might accompany
abrupt changes in the work environment.
The life cycle also delineates the responsibilities
of various actors over the entire process.
Systems development entails considerable skill
specialization. Fundamental differences between
analysts, programmers, hardware technicians,
and computer operators necessitate a rather
extensive division of responsibilities during the life
cycle. By logically defining the steps involved, the
life cycle shows where each group of specialists
contributes. Significantly, the transition from one
step to the next requires "handoffs" or a formal
"signoff" from one group of specialists to the next
when work on one step is completed.
Techniques for user involvement
Technically-sound systems completed on
schedule and within budget are not always
accepted, as many studies have shown [17, 18,
41 ]. Frequently, these failures are attributed to a
lack of user involvement throughout the life cycle.
Consequently, Lucas [1 9] and many others have
strongly advocated techniques for user involve-
ment intended to achieve acceptance and
appropriate use of systems.
In theory, user participation in systems design
affords all parties the opportunity to confront
important issues and resolve differences of
opinion [1 2]. Various techniques have been used
to involve users in systems design. Below, we
 Rituals in Information Systems

Table 1. The Systems Life Cycle

Inception
Preliminary survey

Feasibility study
Existing procedures
Alternative systems
Cost estimates

Systems analysis
Details of present procedures
Collection of data on volumes, input/output files

Design
Ideal system unconstrained
Revisions to make ideal acceptable

Specifications
Processing logic
File design
Input/output
Programming requirements
Manual procedures

Programming

Testing
Unit tests
Combined module tests
Acceptance tests

Training

Conversion and installation

Operations
Maintenance
Enhancements

Source: H.C. Lucas, Jr. Information Systems Concepts for Management, 2nd
edition, McGraw-Hill
Publishers, New York, New York, 1982, p. 292. Reprinted by permission.

review
review briefly
brieflythe
theuse
use
of of
steering
steering
committees,
committees,steering committee.
committee. The
The purpose
purpose of
of such
suchaacom-
com-
information
informationrequirements
requirements analysis
analysis
techniques,
techniques,
mittee is to review proposed systems and to
prototyping,
prototyping,and and
other
other
behavioral
behavioralapproaches.
approaches.administer information system policy. Of 127
This
This is
is by
byno
nomeans
meansanan
exhaustive
exhaustive
list,list,
but but
rather
rather
a a
firms in a recent survey, 85% had corporate
sampling
samplingof ofmethods
methods intended
intendedto improve
to improve the theexecutive steering committees [35, p. 72].
utility
utility ofofcomputer
computer systems
systemsforfor
thosethose
whowho
use useSpecific functions of these committees included
them.
setting direction, rationing resources, designing
appropriate organization structures, staffing, and
Steering Committees auditing performance. Conceptually, and
empirically, considerable justification can be
One way to achieve the involvement of top found for involving top managers on steering
management in system activities is to form a committees [38, 46]. Lack of support from upper

MIS Quarterly/March 1984 7

This content downloaded from 200.89.68.196 on Mon, 01 Apr 2019 19:13:08 UTC
All use subject to https://about.jstor.org/terms
Rituals in Information Systems

management
management is often
is often
citedcited
as theas
reason
the reason
systems systems brought together and communicate more
projects
projectsfail.
fail.
TheThe
steering
steering
committee
committee
ideally sup-
ideally sup-accurately by referring to the physical prototype.
ports
portsworthwhile
worthwhile projects
projects
while while
disbanding
disbanding
less less
worthy
worthyprojects
projectsbefore
before
they they
go toogofar.too
In this
far. In this
way, information resources are conserved and Behavioral Approaches
directed only toward projects that meet the
established strategic plan of the organization The three techniques of user involvement
[15]. discussed above incorporate few explicit
behavioral techniques for improving communica-
tion between users and developers. Mason and
Carey do refer to the role of systems architect
Information Requirements Analysis
intended to bridge the communication gap
Of the specific types of user involvement con- between the user and developer, but say little
sidered here, none has received more attention about specific activities for this role. Several other
than Information Requirements Analysis (IRA) authors report success in using specific
behavioral exercises to create a climate of mutual
methods for determining what information
managers need for effective decision making. In a respect and appreciation. Ward [47] describes
review of 22 IRA techniques, Taggart and Tharp the use of group training techniques to improve
[45] found a heavy reliance on rational problem- the likelihood of implementing quantitative
solving approaches, as evidenced by the sequen- models. Green [10] has used the nominal group
tial structure of most methods. These methods technique, developed by Delbecq et al. [8], to
typically lead users through several steps where aid design projects. Kaiser and Bostrom [13]
have explored personality differences between
management objectives are specified, existing
jobs analyzed, improvements planned, and new users and developers within project teams and
information needs determined. This involves more used that knowledge to improve project success.
Also, Bostrom and Thomas [6] have used the
than simply asking managers what they want.
PRECISION communication techniques [28] in a
Rather, the techniques require either "bottom-up
similar context to improve the accuracy of infor-
data analysis" or "top-down decision analysis" to
mation requirements analysis. These behavioral
determine what information is needed in making
approaches complement the more structured
decisions [32].
user involvement methods. They aim explicitly at
the social and emotional factors inherent in human
behavior and focus on the dynamics of planned
Prototyping
change.

Another approach to user involvement is the With this emphasis on human issues, the
development of systems prototypes which users behavioral techniques exhibit a logic of their own.
can operate experimentally before suggesting The main idea is to take a situation where there is
changes. Use of prototypes has been shown to potential for conflict and use it constructively.
improve significantly the likelihood of developing Advocates of constructive conflict see
systems that users require and to shorten the interdepartmental differences as necessary for
overall life cycle [26]. Prototype methods, like thesuccessful performance of subtasks, but ideally
life cycle itself, use iterations to determine these differences are successfully integrated so
specifications. One methodology begins with that overall goals are also achieved [25, 39]. To
"scenarios" constructed from sequences of some extent, the various behavioral approaches
display screens and proceeds through several mentioned above strive for this integration by
iterations until the user agrees to an adequate using third-party consultants or integrators,
first-level representation of the application [26]. improving communication between parties,
Following this, issues such as screen-flow increasing the influence that each party
sequences, screen content, and layout are perceives, and encouraging a consensus solu-
clarified with the user through further interactionstion. Partial empirical support for this model of
with the prototype. Prototypes offer the user the constructive conflict was reported by Robey and
advantages of hands-on trial and error in systems Farrow [40] and is implicit in much other research
design. Ideally, the user and developer are [39].

8 MIS Quarterly/March 1984

This content downloaded from 200.89.68.196 on Mon, 01 Apr 2019 19:13:08 UTC
All use subject to https://about.jstor.org/terms

Evaluation
The systems life cycle concept and the tech-
niques for user involvement discussed in this sec-
tion can be defended as rational attempts to make
systems better and to improve the effectiveness
of the organization through more effective
decision support. Systematic procedures assure
proper sequences of development activities, pro-
ducing higher quality systems. This structuring of
the design process and interactions between
users and developers eliminates redundancy and
honors both technical and social requirements.
The behavioral approaches assume that conflict
resolution results from maximum information
exchange, awareness of superordinate goals,
and shared power.
At the same time, these same activities can be
described as elements of a political process. A
political interpretation, as presented in the next
section, does not imply that the above techniques
are unnecessary or ineffective. Rather, systems
development activities may well serve purposes
beyond the rational goals of system quality and
user acceptance.
System Development as
a Political Process
Political processes
For a process to be described as political there
are two minimum requirements which may loosely
be termed motive and opportunity. Motive refers
to the presence of two or more actors, either
individuals or groups, having differing objectives
and interests. Opportunity refers to a situation
involving the actors in which some may achieve
their objectives to the absolute or relative dis-
advantage of the others. The systems develop-
ment process satisfies both of these
requirements because it almost always entails
multiple actors with differing objectives, and
brings them together in various forums. (Users of
interactive or personal computing sometimes
build systems for their own exclusive use, but this
situation will not be considered in this paper.)
This content downloaded from 200.89.68.196 on Mon, 01 Apr 2019 19:13:08 UTC
All use subject to https://about.jstor.org/terms
Rituals in Information Systems
For
For the
the sake
sake of
of simplicity,
simplicity,we
weshall
shallconsider
consider
only
only
two types of actors: systems developers and
users. While the specific motivations of
developers and users vary among individuals,
organizations, and situations, it is clear that
developers and users rarely have identical or
similar interests. Unlike users, developers are
usually computer professionals who may even be
employed by an external software house, con-
sulting firm, or service bureau. Consequently,
developers may differ from users in one or more
of the following characteristics:
* cognitive style and personality dif-
ferences which either influence an
individual to select an occupation or
which are reinforced by specialized
occupational training,
* job characteristics which mold the
evaluation criteria and reward
mechanisms applied to the actors,
* location in the organizational structu
and
* organizational affiliations which shape
loyalties and perspectives.
Together, these differences in background and
circumstance may produce different motives dur-
ing systems design. For example, a user may
prefer to keep computing costs low by purchas-
ing software packages, using outside services, or
using existing in-house computer hardware. A
system-developer, on the other hand, may be
motivated by the professional challenge of
building a sophisticated system or by a personal
concern to avoid career obsolescence. This
interest could motivate the developer to sug
building the system in-house and running it
state-of-the-art computers and systems softw
In many cases of systems development, the p
ture is further complicated by the presence
multiple users and designers. This plurality
interests threatens one of the key assumption
rationality, that is, a well-defined and accepted
goal. In cases of conflicting interests, appeals to a
superordinate goal may be ignored by parties
seeking to achieve their own ends. Unlike the
rational perspective, the political perspective
makes no claim that actors will work toward the
integration of their differences with other groups.
As Keen [1 4] has observed, "While we all may try
MIS Quarterly/March 1984 9
Rituals in Information Systems

to
to act
act in
inthe
the'corporate'
'corporate'interest,
interest,
we we
often
often
havehave the system,
system, much
much ofof their
their protest
protest came
cametoo
toolate
lateto
to
very
very different
differentdefinitions
definitions of of
exactly
exactly
whatwhat
it is"
it is" prevent the
the shift
shift of
of power
power to
to corporate
corporatepersonnel.
personnel.
(p.
(p. 28).
28). Two
Twoexamples
examplesillustrate
illustratethethe
shortcomings
shortcomings
in
in the
the rational
rationalview
viewofof
systems
systems development.
development. A second
second example
example demonstrates
demonstrates that
thatdifferent
different
motives may
may exist
exist within
within the
the functional
functionalspecialties
specialties
of "applications
"applications development"
development" (business
(businessanalyst,
analyst,
Illustrations system analyst,
analyst, programmer,
programmer, maintenance
maintenancepro-pro-
grammer).
grammer). In In one
one company
company systems
systemsanalysts
analysts
Markus [23] describes a financial information were located
located in
in two
two different
different organizational
organizationalunits
units
system developed for two different accounting [24]. Those
Those reporting
reporting directly
directly to
to the
theuser
userdepart-
depart-
units in a manufacturing firm. Divisional ment were responsible for meeting user
accountants reported to divisional general requirements; those reporting to the IS depart-
managers, who, in turn, were responsible for the ment were responsible for the technical aspects
profits and losses in their organizational units. of systems design. Analysts in the user area,
Corporate accountants reported to the vice however, had been trained in IS and feared losing
president of finance, who was concerned with the their technical skills. To remain technically cur-
timely production of external financial statements rent, they tried to perform the design activities of
to comply with SEC reporting requirements. Cor- the technical group, but this tended to shortcut
porate accountants felt disadvantaged in their their requirements analysis duties. The technical
dealings with the divisional accountants by the systems analysts were determined to avoid such
lack of an information source other than divisional
encroachment and responded by redoing the
reports. work performed by the user analysts. This
conflict produced several systems which did not
Consequently, when faced with the opportunity meet the users' needs and ultimately had to be
to develop a new accounting system, the two reprogrammed or scrapped.
groups had very different objectives. The
divisional accountants desired a system that These examples illustrate both characteristics of
would ease the burden of data entry and provide a political process: two or more actors with dif-
them with timely reports for managerial decision ferent interests and motivations, and an arena in
making. The corporate accountants desired a which actors achieve objectives at the expense of
system that would produce consolidated financial others. Interestingly, these political activities
statements, tax analyses, and independent audits occur within those processes previously
of divisional performance. The objectives of these described as rational elements of system design -
two user groups not only differed but were in the development life cycle and user involvement.
direct conflict on the issue of who would control This presents a potential paradox because
the creation of information about performance. political actions seem to be at odds with the
rational objectives of systems development. To
Rational analysis suggests that the differences help understand this dilemma, we must reanalyze
between the corporate and divisional accountants the rational elements from the viewpoint of the
could be resolved through user involvement and political perspective.
perhaps one or more structured techniques.
Markus reports, however, that the corporate
accountants systematically excluded the divi-
sional accountants from the design process. The
design team was composed entirely of people
Design Process Elements
from corporate accounting and data processing. from the Political Perspective
Two full years after the team's formation, divi-
sional accountants were given their only role, to
provide input data for the system, long after its System life cycle
main features had been determined. Divisional
accountants were effectively forced to use a From a political perspective, the life cycle of
system which reduced their power by making systems development creates the opportunity for
division performance more transparent to cor- parties with diverse interests to exert influence
porate analysts. While divisional users resisted over one another. For example, in performing the

10 MIS Quarterly/March 1984

This content downloaded from 200.89.68.196 on Mon, 01 Apr 2019 19:13:08 UTC
All use subject to https://about.jstor.org/terms
 Rituals in Information Systems

feasibility
feasibilitystudy
study
(see(see
Table
Table
1), systems profes-profes- user and data processing becoming jointly
1), systems
sionals
sionalsmay
maystrategically
strategically
statestate
"truths"
"truths" about pro- accountable for systems design and data quality.
about pro-
ject costs and requirements. Their expert However, a political perspective on computing
knowledge and position in the cycle allows them growth would examine possible self-interests that
to represent data about user needs, implementa- underlie the voiced concern for user control. In
tion alternatives, and cost-benefit analyses in this regard, Lucas and Sutton [21] present
ways that may be advantageous for themselves evidence that growth in data processing budgets
and disadvantageous for users. The prescribed was best predicted by the prior year's budget.
precedence of the feasibility study over later Since budget size is a useful measure of organiza-
activities creates an inherent power advantage for tional power, we can surmise that data proces-
those conducting it. sing power, rather than user control, motivates
growth. Similar findings on budget growth have
While the hand-offs, sign-offs, and approvals are
been reported in universities and explained with
designed to formalize and rationalize the reference to political motives [42]. Lucas and
interdependence between users and developers,
Sutton noted that budget growth may occur in
they also encourage political behavior.
data processing departments that are not respon-
"Upstream" errors may require major corrections sive to user needs, but instead concentrate on
at later stages, leading "downstream" parties to
developing sophisticated hardware and software
limit their liability for error correction by requiring a
for its own sake [21].
formal sign-off on obligations and responsibilities.
Users, for instance, may sign off on specifications With respect to information requirements
delivered to developers, promising, in effect, to
analysis, most IRA methods have an inherent bias
accept the system if it meets those specifica- to preserve the status quo, a beneficial outcome
tions. But users may also insist on the right of final for those who already possess power. Boland [4]
approval, arguing that little would be gained by argues that such a strategy is acceptable "only if
implementing a system that does not meet cur- the world is the best of all possible ones"
rent needs. As a result, each of the hand-offs and
(p. 266). He calls for more action-based
subsequent approvals become opportunities for approaches to IRA which would challenge the
covering one's position, blaming others, and status quo by "opening issues, making asser-
escaping responsibility for poor performance. In
tions, posing questions, holding forums,
short, the life cycle provides the opportunity to
developing agendas, and conducting debates"
achieve one's own objectives at the expense of
(p. 263). Taggart and Tharp [45] have also sug-
others.
gested extending IRA techniques to include
"nonrational" methods for determining managers'
information needs. Clearly, these radical changes
Techniques for user involvement would make IRA a more open, political process.
The fact that few, if any, IRA methods come close
Each of the methods for user involvement con-
to this challenge reveals the conservatism in the
tains potential for political behavior as well. For
IRA process.
example, major issues in forming steering commit-
tees are their composition and leadership. As the
committee members perform their function of pro-
Finally, efforts to improve communications
ject review, different coalitions may seek to head through the use of systems architects and
off or minimize each others' efforts to support behavioral techniques offer further opportunities
private objectives. Clearly, steering committees to influence systems outcomes. Departmental
may perpetuate disagreements about subgoals affiliation of the facilitator or change agent is a
rather than directing computing resources toward crucial issue. For example, Mason and Carey [26,
superordinate goals. p. 349] recommend that systems architects be
drawn from the systems development area
Nolan, one of the strongest advocates of steering because it ". . . is the one equipped to manage,
committees, notes that their importance increases train, and support the specialized professional skills
as organizations progress through various growth embodied in this role." Clearly, their point is
"stages" to maturity [34]. Later stages imply thearguable. Whoever fills the facilitator role
highest level of user involvement, with the end assumes power to guide the outcome of the

MIS Quarterly/March 1984 11

This content downloaded from 200.89.68.196 on Mon, 01 Apr 2019 19:13:08 UTC
All use subject to https://about.jstor.org/terms
Rituals in Information Systems

systems development efforts. Despite the administrative

administrativedata
data
bases
bases
in real
in real
time"
time"
and having
and having
humanistic language used in most behavioral the potential to "revolutionize health care
approaches, these methods also remain delivery" [30, p. 54]. In this case, computing
vulnerable to political influences. assumed a symbolic value beyond its utility as a
tool for administrative decision making. It signaled
to employees, clients, and the outside world that
Discussion and Conclusions the organization stood for progressive and effi-
cient management.
We have argued that IS design can fruitfully be
Feldman and March [9] have further explored the
explained as both a rational and a political process
symbolic use of information processing in
and have shown evidence to support this conten-
organizations. They cite many instances where
tion. The phases and handoffs of the systems
organizations collect (at great cost) information
development life cycle and the techniques of user
which is not used, but ignore relevant information
participation that are the hallmarks of the rational
that is available (at low or no cost). While such
perspective in IS design can also be viewed as
behavior does not seem rational, the information
rituals from the political perspective. From this
may have a symbolic value beyond its instrumen-
viewpoint of rationality, systems design elements
tal value. Thus, a computer-generated report may
are instrumental to the achievement of organiza-
have little instrumental value for making a
tional goals. As rituals, these same elements fulfill
decision, especially if the total cost of producing
different, although equally important fuctions.
the report is considered. However, a fat report
Rituals in systems development function to main- resting on a manager's desk may be useful
evidence that a decision was based on "hard
tain the appearance of rationality in systems
information" rather than "soft intuition." In a
development and in organizational decision mak-
ing. Regardless of whether it actually produces society committed to intelligent choice, managers
who want to look effective will demonstrate overt
rational outcomes or not, systems development
must symbolize rationality and signify that the rationality by gathering and displaying such
information.
actions taken are not arbitrary, but rather
acceptable within the organization's ideology. As
Clearly, this need for rationality extends into the
such, rituals help provide meaning to the actions
systems development process. The rituals of
taken within an organization.
systems development perpetuate the prevailing
By performing this function, systems design ideology of rationality and provide an acceptable
rituals uphold the myth, central to Western cover for unexpressible political motives in the
society, that organizations are rational entities dealings between users and designers. Overt
serving social interests by pursuing their own conflict and manipulation are thereby controlled,
goals. Myths are not necessarily false; their lending stability and order to systems develop-
essential characteristic is that they are widely ment. In effect, the rituals of systems develop-
believed. Since a lore of rationality surrounds ment enable participants to act in their self
both computing and organizational decision mak- interests without discrediting the organization's
ing, it is completely understandable that the rational ideology.
systems development process be regarded as
Of course, the political perspective is also well-
rational also. The rituals help to ensure this
equipped to explain overt conflict where it does
perception.
occur. Often systems fail to be developed to any
Recent studies contribute to our awareness of party's satisfaction, or projects may be terminated
myths, rituals, and ideologies in organizations. in spite of apparent rational justification. Cases like
Meyer's [29, 30] studies of hospitals show thatthese are more obvious evidence of political
computing can play a key role as a symbol of anbehavior. Our concern in this paper has been to
organization's rationality. For example, in one make the less obvious point, i.e., that systems
hospital, information technology signified a "cor-which appear to be rationally justified also serve
porate cybernetic" ideology. The language used political aims. Behind participants' skillful honoring
reveals the significant role of the computer, of the appropriate rituals may lie self-interest and
capable of "interfacing our clinical and considerable negotiating power.

12 MIS Quarterly/March 1984

This content downloaded from 200.89.68.196 on Mon, 01 Apr 2019 19:13:08 UTC
All use subject to https://about.jstor.org/terms
 Rituals in Information Systems

Some
Somecontend
contend
thatthat
a political
a political
perspective
perspective
of IS of IS Choice
Choiceand
andComputers,
Computers, 2, North-Holland,
2, North-Holland,
development
development should
should
be applied
be applied
only under
onlycertain
under certain Amsterdam, 1980, pp. 97-109.
conditions.
conditions. Kling
Kling
[16], [16],
for example,
for example,
argues that [3]
argues that Bjorn-Andersen, N. and Pedersen, P.H.
political
political analysis
analysis
is more
is more
appropriate
appropriate
as the set-as the set- "Computer Facilitated Changes in the
tings
tingsforforsystems
systemsdesigndesign
becomebecome
more pluralistic
more pluralistic Management Power Structure," Account-
and
anddynamic.
dynamic. Stable
Stable
settings
settings
characterized
characterized
by by ing Organizations and Society, Volume 5,
widely-shared
widely-shared values
values
and consensus
and consensus
are likelyare
to likely to Number 2, 1980, pp. 203-216.
be more receptive to rational interventions. [4] Boland, R.J., Jr. "Control, Causality and
Rapidly changing environments with many actors, Information System Requirements,"
however, tend to produce conflict more readily Accounting, Organizations and Society,
than consensus. Thus, political behavior may not Volume 4, Number 4, 1979, pp. 259-272.
exist in some situations, and researchers may be [5] Borum, F. "A Power-Strategy Alternative to
unable to apply political analysis effectively [24]. Organization Development," Organization
By the same token, however, researchers and Studies, Volume 1, Number 2, 1980,
managers should not assume that politics is irrele- pp. 123-146.
vant simply because rational processes are used. [6] Bostrom, R.P. and Thomas, B.D. "Getting
the Requirements Right: A Communication
An alternative view suggests that rational and Perspective," Unpublished paper, 1982
political views can both be applied to any situa-
[7] Burrell, G. and Morgan, G. Sociological
tion. These perspectives simply provide different
Paradigms and Organizational Analysis,
interpretations of the events which occur during Heinemann, London, England, 1 979.
systems development. The events themselves [8] Delbecq, A.L., Van de Ven, A.H., and
may be described objectively, but their interpreta- Gustafson, D.J. Group Techniques for Pro-
tions may vary considerably depending on which gram Planning, Scott-Foresman, Glenview,
perspective is used. In other words, rational and Illinois, 1 975.
political perspectives are not mutually exclusive [9] Feldman, M.S. and March, J.G. "Informa-
[39]. Each merely provides a different interpreta- tion in Organizations as Signal and
tion of the same events.
Symbol," Administrative Science Quarterly,
Volume 26, Number 2, June 1981,
In conclusion, it seems important for systems
designers, managers, and researchers to be pp. 171-186.
aware of rituals in systems development and the [10] Green, T.B. "Improving Modeller-User
important functions they perform. Because IS Interaction," Operational Research
development can be both rational and political, it Quarterly, Volume 28, Number 3,
is essential for those engaged in the process to September 1977, pp. 527-537.
be aware of what is really going on. There is [11] Ives, B., Hamilton, S., and Davis, B. "A
nothing inherently wrong with organizational Framework for Research in Computer-
politics. However, the naive actor who remains Based Management Information Systems,"
unaware of the differences between symbol and Management Science, Volume 26,
substance, or between ritual and reality, will be a Number 9, September 1980,
less effective participant in the process. pp. 910-934.
[1 2] Ives, B. and Olson, M.H. "User Involve-
ment and MIS Success: A Review of

References Research," Management Science, in

press.

[1] Argyris, C. "Management Information [13] Kaiser, K.M. and Bostrom, R.P. "Personali-
Systems: The Challenge to Rationality and ty Characteristics of MIS Project Teams: An
Emotionality," Management Science, Empirical Study and Action-Research
Volume 17, Number 6, February 1971, Design," MIS Quarterly, Volume 6,
pp. B275-B292. Number 4, December 1982, pp. 43-60.
[2] Bjorn-Andersen, N. and Eason, K.D. [14] Keen, P.G.W. "Information Systems and
"Myths and Realities of Information Organizational Change," Communications
Systems Contributing to Organizational of the ACM, Volume 24, Number 1,
Rationality," in A. Mowshowitz, ed., Human January 1981, pp. 24-33.

MIS Quarterly/March 1984 13

This content downloaded from 200.89.68.196 on Mon, 01 Apr 2019 19:13:08 UTC
All use subject to https://about.jstor.org/terms
Rituals in Information Systems
[15]
[15]King,
King,
W.R.W.R.
"Strategic
"Strategic
Planning for
Planning
Manage- for Manage- Volume 19, Number 5, January 1973,
ment
ment Information
Information
Systems,"
Systems,"
MIS Quarterly,
MIS Quarterly, pp. 475-487.
Volume 1, Number 2, June 1977,
pp. 55-67.
[16] Kling, R. "Social Analyses of Computing:
Theoretical Perspectives in Recent
Empirical Research," Computing Surveys,
Volume 12, Number 1, March 1980,
pp. 61-110.
[17] Lucas, H.C., Jr. Why Information Systems
Fail, Columbia University Press, New York,
New York, 1975.
[18] Lucas, H.C., Jr. "Unsuccessful Implemen-
tation: The Case of a Computer-Based
Order Entry System," Decision Sciences,
Volume 9, Number 1, January 1978,
pp. 68-79.
[19] Lucas, H.C., Jr. Information Systems Con-
cepts for Management, 2nd edition,
McGraw-Hill, New York, New York, 1982.
[20] Lucas, H.C., Jr., Clowes, K.W., and Volume 1, Number 2, June 1977,
Kaplan, R.B. "Frameworks for Information pp. 55-67.
Systems, INFOR, Volume 12, Number[33]
October 1974, pp. 245-260.
[21] Lucas, H.C., Jr. and Sutton, J.A. "The
Stage Hypothesis and the S-Curve: Some
Contradictory Evidence," Communications
of the ACM, Volume 20, Number 4,
April 1977, pp. 254-259.
[22] Lund, R. "Indirect Participation, Influence,
and Power: Some Danish Experiences,"
Organization Studies, Volume 1, Number 2,
1980, pp. 147-160.
[23] Markus, M.L. "Power, Politics and MIS
Implementation," Communications of the
ACM, Volume 26, Number 7, June 1983,
pp. 430-444.
[24] Markus, M.L. An Organizational Angle on
Systems: Their Bugs and Features, Pitman,
Marshfield, Massachusetts, 1984.
[25] Markus, M.L. and Robey, D. "The
Organizational Validity of Management
Information Systems," Human Relations,
Volume 36, Number 3, March 1983,
pp. 203-225.
[26] Mason, R.E.A. and Carey, T.T. "Proto-
typing Interactive Information Systems,"
Communications of the ACM, Volume 26,
Number 5, May 1983, pp. 347-354.
[27] Mason, R.O. and Mitroff, I.I. "A Program for
Research on Management Information
Systems," Management Science,
14 MIS Quarterly/March 1984
This content downloaded from 200.89.68.196 on Mon, 01 Apr 2019 19:13:08 UTC
All use subject to https://about.jstor.org/terms
[28] McMaster, M. and Grinder, J. PRECISION:
A New Approach to Communication, Preci-
sion Models, Beverly Hills, California 1 980.
[29] Meyer, A.D. "Adapting to Environmental
Jolts," Administrative Science Quarterly,
Volume 27, Number 2, December 1982,
pp. 515-537.
[30] Meyer, A.D. "How Ideologies Supplant For-
mal Structures and Shape Responses to
Environments," Journal of Management
Studies, Volume 19, Number 1,
January 1982, pp. 45-61.
[31] Mintzberg, H. Power In and Around
Organizations, Prentice-Hall, Englewood
Cliffs, New Jersey, 1983.
[32] Munro, M.C. and Davis, G.B. "Determining
Management Information Needs: A Com-
parison of Methods," MIS Quarterly,
2, Nolan, R.L. and Wetherbe, J.C. "Toward a
Comprehensive Framework for MIS
Research," MIS Quarterly, Volume 4,
Number 2, June 1978, pp. 1-19.
[34] Nolan, R.L. "Managing the Crises in Data
Processing," Harvard Business Review,
Volume 57, Number 2, March-April 1979,
pp. 115-126.
[35] Nolan, R.L. "Managing Information
Systems by Committee," Harvard Business
Review, Volume 60, Number 4, July-
August 1982, pp. 72-79.
[36] Pettigrew, A.M. The Politics of Organiza-
tional Decision Making, Tavistock, London,
England, 1973.
[37] Pfeffer, J. Power in Organizations, Pitman,
Marshfield, Massachusetts, 1981.
[38] Radnor, M. and Bean, A.S. "Top Manage-
ment Support for Management Science,"
Omega, Volume 2, Number 1, 1974,
pp. 63-75.
[39] Robey, D. "Conflict Models for Implemen-
tation Research," R.L. Schultz, ed.,
Applications of Management Science, JAI
Press, 1984.
[40] Robey, D. and Farrow, D.L. "User Involve-
ment in Information System Development:
A Conflict Model and Empirical Test,"
Management Science, Volume 28,
Number 1, January 1982, pp. 73-85.
 Rituals in Information Systems

[41] Robey, D. and Zeller, R.L. "Factors About the Authors

Affecting the Success and Failure of an
Information System for Product Quality," Daniel Robey, D.B.A., is Professor of Manage-
Interfaces, Volume 8, Number 2, ment at Florida International University. He is the
February 1978, pp. 70-75. author of Designing Organizations: A Macro
[42] Salancik, G.R. and Pfeffer, J. "The Bases Perspective and numerous articles in Manage-
and Use of Power in Organizational Deci- ment Science, Academy of Management Journal,
sion Making: The Case of a University," Academy of Management Review, Human Rela-
Administrative Science Quarterly, tions, Decision Sciences, Communications of the
Volume 19, Number 4, December 1974, ACM, and other leading journals. Professor
pp. 453-473. Robey received his doctorate from Kent State
[43] Saunders, C.S. "Management Information University and has held faculty positions at the
Systems, Communications, and Depart- University of Pittsburgh and Marquette University.
mental Power: An Integrative Model," His current research interests include the impact
Academy of Management Review, of information systems on organization and
Volume 6, Number 3, July 1981, management, related implementation problems,
pp. 431-442. and managerial decision styles.
[44] Shrivastava, P. "Decision Support Systems
for Strategic Ill-Structured Problems," M. M. Lynne Markus, Ph.d., is a consultant in the
Ginzberg and C.A. Ross, eds., Pro- Strategy Management and Systems practice at
ceedings of the Third International Con- Arthur D. Little, Inc. She is also a research
ference on Information Systems, 1982, associate of MIT's Center for Information
pp. 75-91. Systems Research. Prior to joining Arthur D.
[45] Taggart, W.M., Jr. and Tharp, M.O. "A Little, Dr. Markus was an Assistant Professor of
Survey of Information Requirements Management at the Alfred P. Sloan School of
Analysis Techniques," Computing Surveys, Management at the Massachusetts Institute of
Voi ime 9, Number 4, December 1977, Technology.
pp. 76-88.
She holds a doctorate in organizational behavior
[46] Vanlommel, E. and DeBrabander, B. "The from Case Western Reserve University and a BS
Organization of Electronic Data Processing degree in industrial engineering from the Univer-
(EDP) Activities and Computer Use," Jour- sity of Pittsburgh.
nal of Business, Volume 48, Number 3,
1975, pp. 391-410. Dr. Markus is the author of An Organizational
Angle on Systems: Their Bugs and Features and
[47] Ward, R.A. "More Implementation Through
articles in Human Relations, Communications of
an OR/Behavioral Science Partnership and
the ACM, Organizational Dynamics, and Account-
Management Training," Operational
ing Organizations and Society. She is a member
Research Quarterly, Volume 25,
Number 2, June 1974, pp. 209-218. of the editorial board of Office: Technology and
People.

MIS Quarterly/March 1984 15

This content downloaded from 200.89.68.196 on Mon, 01 Apr 2019 19:13:08 UTC
All use subject to https://about.jstor.org/terms