Information Technology Information Model

THE INFORMATION TECHNOLOGY INTERACTION MODEL:
A CORE MODEL FOR THE MBA CORE COURSE
Mark S. S i l v e r
Stern School of Business
New York University
M. Lynne Markus
Information Science
Claremont Graduate School
Cynthia Mathis Beath

Cox School of Business
Southern Methodist University
Workinq Paper Series

STERN IS-94-5
Center for Digital Economy Research

Working Paper IS-94-05
THE INFORMATION TECHNOLOGY INTERACTION MODEL:
Mark S. Silver
New York University
M. Lynne Markus
Information Science
Clarernont Graduate School
Cynthia Mathis Beath

Cox School of Business
Southern Methodist University

THE );lTFORMATION TECHNOLOGY INTERACTION MODEL:
Abstract
This paper presents a teaching model we have used successfully in the MBA core course in
Information Systems at several universities. The model is referred to as the "Information
Technology Interaction Model" because it maintains that the consequences of information
systems in organizations follow largely from the interaction of the technology with the
organization and its environment. The model serves a number of pedagogical purposes: to
integrate the various course components, to provide a formal foundation for the course
content, to foster practical analytical skills, and to provide a framework for case discussions
and student projects. Moreover, the model is intended to acquaint students with the
. dynamics of information systems in organizations and to help them recognize the benefits,
dangers, and limitations of these systems. The paper includes a discussion and examples of
how the model can be used for proactive and reactive analyses, and it concludes with an
assessment of the model's effectiveness in the core course.
Acknowledgment
The authors are indebted to Burt Swanson for his contributions to the design of the MBA
core course that produced the model presented in this paper.

THE INFORMATJON TECHNOLOGY INTERACTION MODEL:
"The course was not sufficiently analytical." "The course lacked theory." "I didn't
learn anything I can use at work." "I understand the pieces but I don't see how they fit
together." These concerns are typical of those voiced by MBA students reaching the end of
their core course in Information Systems (IS). Indeed, as compared with other core courses
they take conc~rrently(for example, accounting, economics, and marketing), it may be
difficult for students to discern the fundamental principles of the IS course that integrate the
material, that provide a theoretical foundation, and that foster useful business skills. Toward
remedying this deficiency, we propose in this paper a model of information systems in
organizations that we have used successfully in teaching the core course in information
systems at several universities.
We refer to the model as the "Information Technology (IT) Interaction Model"
because it rests on the premise that the consequences of information systems in organizations
follow from the interaction of the technology with the organization and its environment.
Understanding the nature of this interaction, therefore, is central to leveraging the benefits
and avoiding the hazards that information technology presents for organizations. And
learning how to leverage the benefits and avoid the hazards is at the core of the core
information systems course.
The model addresses the interaction of an information system's design features with
five elements of the organization: (1) its external environment, (2) its strategy, (3) its
business processes, (4) its structure and culture, and (5) its IT infrastructure. The model

considers the consequences of this interaction for system use, for organizational performance,
for the organization's personnel, and for the firm's future flexibility. Moreover, the model
relates various aspects of the interaction process to the phases of the development and
implementation lifecycles.
By combining these various components, the model integrates the many aspects of the
course, inclucihg such topics as technology basics, what businesses accomplish with
information technology, how IT can change firm and industry structure, how organizations
acquire new applications, how firms manage IT standards, and so forth. At the same time,
the model serves as a formal foundation for the course. And the model builds practical
skills, as well, since it can be used proactively in designing and implementing systems or
reactively to evaluate what transpired after the fact. In particular, the model lends itself to
use in case discussions and in student projects.
While the model is based upon and consistent with our understanding of the
Information Systems research literature, we must emphasize that the model we are presenting
in this paper is a teaching model, not a research model. Our aims in this paper are to
describe a model that we have found useful for pedagogical purposes in the hope that others
will similarly find it worthwhile and to contribute to the current dialogue about teaching
innovation and curricular reform. Of necessity, this model, intended for MBA students,
reflects a simplification of the full set of relationships that would interest researchers and
specialists in the field. We believe, however, that it is flexible enough to serve as a starting
point for discussing many specific theories not explicitly modeled in it, while not being so

vague and abstract as to be meaningless.
We begin the paper by stating a premise concerning the core MBA course in
Information Systems, after which we present the model. Next we discuss how the model can
be used for proactive and reactive analyses, and we then offer an example of each in the
context of the core course. After discussing more generally the role of the model in the
course, we turn
- to a number of specific pedagogical issues. We conclude by assessing the
model's effectiveness in the course.
THE PREMISE
Core courses in information systems differ both because of programmatic constraints
imposed by the institution (for instance, the number of contact hours and the sequencing of
the course in the MBA curriculum) and because of content decisions made by the course
designers. Among the content choices that vary from school to school and are currently in
dispute in the IS community are such issues as which topics to cover, how much hands-on
instruction to provide, and if and how to use business cases (Stohr et al., 1990). Although
we have strong feelings about a number of these content choices, our aim is not to debate
here the objectives or content of the core course but to proceed from a minimalist set of
objectives and topics we take as givens. We believe that these givens apply to a large share
of core course offerings today and are likely to apply to even more as the decade progresses.
We take as a starting point that as a core course--the only course in information
systems many MBA students will take--the course addresses "what every MBA needs to

know about information systems in organizations." While opinions differ as to what
constitutes this core of required knowledge, at a minimum the course must acquaint students
with the dynamics of information systems in organizations so that they will be able to
function and manage effectively in the now IT-laden corporate and industrial worlds. And to
function effectively, they must recognize that the consequences of information technology are
nondeterministic and not necessarily positive. That is, despite all the excitement surrounding
the potential Gilue of IT for business, the benefits of a given system for a given firm may be
nonexistent and the effects may even be negative. Indeed, the road to information system
success is strewn with information system failures. To succeed, students must understand the
range of potential effects, the set of factors that contribute to these outcomes, and the
connections between them. Put differently, an objective of the core course is the following:
to increase students' knowledge of the potential benefits, dangers, and limitations of
information technology and to equip them to leverage the benefits, avoid the dangers, and
surmount the limitations. We use the IT Interaction Model to accomplish this objective.
THE MODEL
The IT interaction model is best thought of as a stylized view of the dynamics of
information systems in organizations. Based on a large body of research findings (for
example, Kling and Scacchi, 1982; Markus, 1984; Markus and Robey, 1988; Orlikowski and
Robey, 1991; DeSanctis and Poole, 1994), the model asserts that the effects of an
information system for an organization emerge over time as the result of the interaction of
the system with the organization. This view leads to a model with four interrelated elements:

( I ) the implementation process, ( 2 ) the organization and its environment, (3) the information
system, and (4) the system's effects.
We present the model to the students in diagrammatic form as shown in Figure 1.
The schematic, which captures the main elements of the model and depicts the principal
relationships, serves several purposes. It highlights the key components and helps the
students see the relationships among them. It also helps the students remember those
--
components and relationships. The figure allows us to focus easily on one portion of the
model, without losing sight of how that component fits into the big picture. And it helps the
students appreciate the model's dynamics. Figure 2 accompanies the schematic, outlining
and exemplifying the model's salient features.
In presenting the model here, we use the terminology that we have found most
effective in the classroom. We recognize, however, that in the jargon-rich and rapidly
changing field of information systems, some terms have a variety of connotations and,
conversely, some concepts go by a variety of names. A given instructor, therefore, might
wish to substitute alternative vocabulary for ours to reflect consistency with his or her
preferred terminology or with that of the adopted textbook, What matters in the following
discussion, therefore, is not the terminology, but the underlying concepts. We shall
endeavor to make clear how we use the terms we employ.
What follows is an overview of the essentials of the model. As the term unfolds, we
cover a large body of more detailed material that fleshes out the components and
relationships more fully.

The Implementation Process
Implementation is one of those terms that has multiple meanings in the context of IS.
For example, used narrowly, the term sometimes refers to the coding phase of development
and other times to specific tactics and strategies used to introduce a system into an
. organization. -Recause we see implementation as an ongoing process throughout the life of an
information system, we use the phrase implementation process in its broadest sense to refer
to all the management policies and interventions associated with the development,
introduction, and use of an information system, from its inception to its retirement (Leonard-
Barton, 1988; Markus, 1990).
The model's treatment of the implementation process neither adopts nor depends upon
any particular view of the systems development process. It is intended to be compatible with
the various versions of the traditional Systems Development Lifecycle (SDLC) as well as
with such alternative lifecycles as those associated with prototyping or outsourcing,
Consequently, we identify four generic stages in the implementation process: (1) initiation,
(2) acquisition (buildlbuy), (3) introduction, and (4) adaptation. In Figure 1, time proceeds
from left to right, but the process is deliberately left "open-ended" to reflect that adaptation
of both the organization and the information system is ongoing.

The Organization and Its Environment
The organization and its environment provide the context for an information systems
intervention. At the most basic level, it is organizational needs that motivate the design of
the system. Nonetheless, organizations are dynamic entities, and once a systems
development project is initiated, the process begins to engender changes in the organization
in anticipation of the new system. This influence is reflected by the arrow in Figure 1
pointing from "Initiation" to "The Organization."
For the purposes of understanding the dynamics of information systems interventions,
we find it useful to distinguish between the organization's external and internal environments
and, within the internal environment, to differentiate four components: the firm's strategy,
its structure and culture, its business processes, and its IT infr-cstructure.
The External Environment
Understanding the external business environment is important because the external
environment provides the context within which the firm operates. For example, such aspects
of the externaI environment as the competitive position of the firm within the structure of its
industry and the firm's relationships with its customers and suppliers will influence its
corporate strategy and its use of information technology. Among the relevant dimensions
for studying the external environment are the competitive structure of the industry, the
relative power of buyers and sellers, the basis of competition, whether the industry is
growing, shrinking, or stable, the state of regulation, and the state of technological

deployment (Porter, 1980; McFarlan, 1984).
Firm Strategy
Many information systems projects in organizations today are closely linked to
corporate strategy. In some cases, the information system is a key element of implementing
a strategy; in other cases, it is at the very essence of the strategy. For many systems,
. therefore, firm,strategy is a critical factor. Among the business strategies that are receiving
much attention for their IT implications, for example, are differentiation, low-cost
production, a focus on quality and service, globalization, right-sizing, and just-in-time
inventory and manufacturing (McFarlan, 1984; Ives and Learmonth, 1984; Porter and Millar,
1985; Boynton, Victor, and Pine, 1993; Treacy and Wiersema, 1993; Lucas, 1994).
Organizational Structure and Culture
A firm's internal design elements--its structure and its culture--may influence system
design as well as system success. For example, systems that share data across departmental
boundaries raise special design and implementation concerns and are especially vulnerable to
user resistance due to loss of flexibility (Goodhue, Wybo, and Kirsch, 1992).
By organizational structure we mean formal aspects of organizational functioning,
such as the division of labor, hierarchical authority, and job descriptions. Structure typically
includes whether the firm is centralized or decentralized; whether it uses a divisional,
functional, or matrix organization; and its reporting relationships. By culture we mean the
shared values, basic assumptions, and behaviors of organizational members. Elements of

culture include whether the organization values individuality or teamwork, whether bigger is
better, and whether risk taking, such as that commonly associated with IT innovations, is
rewarded or reproached.
Business Processes
Information technology, and the procedures associated with it, often represent a major
part of a firm's business processes, such as order fulfillment, materials acquisition, and new
product development. In the past, many information systems were designed to automate
existing business processes. More recently, firms have begun to focus on using IT to
reengineer those processes. Although business processes typically cut across the major
functional divisions of organizational structure, information systems have often been designed
while ignoring that structure. The reengineering movement has helped us realize that, when
designing systems, we must consider both business processes and organizational structure
simultaneously.
IT Infrastructure
IT infrastructure is another term that appears frequently in the IS literature, but whose
meaning varies from source to source. For the purposes of the course, we adopt a broad
definition of infrastructure, referring to it as "the capacity of the organization to generate
new IT applications" (Weill and Olson, 1989; Markus and Soh, 1993; Weill, 1994). Thus
defined, it encompasses a large set of organizational IT resources, including computing
hardware, software development tools and programming libraries, databases,

telecommunications networks, training materials and facilities, and the capabilities of IT
personnel. And thus defined it also clearly has significant implications for the design and
success of an information system.
The Information System
The infc>rmationsystem itself is for most students the most familiar element of the
model. But our definition of information system, while corresponding with the approach
taken in many of the popular IS textbooks, differs from what many of the students entering
the course expect. We emphasize that the system is not just the software or even the
software and the hardware; the system comprises hardware, software, data, people, and
procedures. To portray diagrammatically that the information system is placed into the
organizational environment, an arrow points from the "Build/BuyWactivity to "The
Information System," which is embedded within the organizational rec-tangle. Examples of
information systems for the purposes of the course and the model include such diverse
applications as SABRE, ASAP, OTISLINE, Excel, and Lotus Notes.
System Effects
When an information system is introduced into an organization, the system's features
will fit well or poorly with the various elements of the organizational environment. I f is ibis
inrerucrion of rhe sysrem wirh rl~eorgunizurion r11ur we see US rhe prinrury cll.rern?inunr of the
eflecrs of rlie syreil7 on rhl~orguni:urion. A system that depends on data sharing, for

example, introduced into an organization that inhibits it, may encounter resistance or provoke
turf-battles. We also believe rl7ar implemenrurion is a key derenninanr of sysrem eflecrs. For
instance, how a system is introduced may affect if and how that system is used {Orlikowski,
1992; DeLuca, 1993). In particular, the implemenrurion process can mediate the eflecrs of
the organizarion-sysrem inreracrion. That is, in cases where the new system is in conflict
with the existing organization, the way the implementation process is handled may facilitate
organizational change and system acceptance or, alternatively, may provoke greater
resistance. These effects of implementation are portrayed diagrammatically by the m o w
from "Introduction" to "Use."
Although not always thought of as an effect, one of the most fundamental results of
introducing an information system into an organization is that the system either is used or is
not. This first-order effect must not be neglected, because it is quite common for systems
not to be used and such nonuse is a major reason for systems' not achieving their design
objectives (Markus and Keil, 1994). And, if the system is used, the question of how the
system is used--when, by whom, for what purpose, and so forth--remains a significant issue.
Systems are often used in ways other than intended, sometimes with positive consequences,
as when a decision support system also serves as a tool for improving customer relations
(Keen and Scott Morton, 1978), and sometimes with negative consequences, as when an
executive information system is used to intimidate subordinates, stifling creativity. So,
understanding if and how a system is used is an essential first step in evaluating system
effects.

The second stage of evaluating effects is to assess the consequences of the system for
the organization. The model focuses on three classes of outcomes: (1) performance effects,
(2) consequences for people (the organization's personnel), and (3) future flexibility.
Performance, indicated by a "$" in the figure, includes such bottom-line results as profit,
gross revenue, and market share. Consequences for people include such outcomes as shifts
in power and influence, job enrichment, and deskilling. Future flexibility (the infinity sign
in !he figure) rcfers to the ways that the system may enable or constrain future information
systems and strategic initiatives by the organization (Keen, 1991). For example, companies
that have invested heavily in mainframe computer architectures and mainframe-related skills
are predicted to incur great difficulty and expense converting to object-oriented and client-
server architectures (Fichman and Kemerer, 1993).
The consequences of an IS are not necessarily uniform. Some may be desirable while
others may not. Performance effects may be at odds with people effects; for example, a
system might improve profits at the expense of the quality of worklife for company
personnel. Various aspects of performance may clash; increasing long-run market share may
conflict with increasing short-run profit. And the consequences for people may differ from
one person to another; a system that enriches one person's job may deskill or eliminate
another's.
A third-order effect of implementing an information system is that as a result of how
the system is used and of its perceived consequences for performance, people, and future
flexibility, adaptations will be made over time to the system, the organization, or both. At

Frito-Lay, for example, changes due to the hand-held computer project and the improved IT
infrastructure enabled the organization to shift from a one-year planning cycle to a
three-times-a-year planning cycle, dramatically improving the rate of organizational learning
("Frito-Lay, Inc. : A Strategic Transition (C), " 1992). Similarly, it has been suggested that,
as with any new technology, a period of learning, adjustment, and restructuring may be
necessary before the full return on an IT investment is reaped (Brynjolfsson, 1993). The
figure depicts these adaptive effects in the form of a feedback loop at the bottom of the
diagram.
USING THE IT INTERACTION MODEL:

mTTHE FIELD AND IN THE CLASSROOM
Before discussing the specific role that the model plays in the core course, we
consider more generically how the model can be employed in the field of Information
Systems, To do this, we must first consider the "interaction" between system and
organization in more depth.
The key concept in understanding the interaction of the system with the organizational
environment is the notion of "fit." Intuitively, one might expect that if a system "fits" the
organization well, then its effects will be favorable, and that if the system fits the
organization poorly, the effects will be unfavorable. But the relationship is not SO simple.
Since systems have multiple effects, some may be favorable while others are not. Even
more importantly, a good "fit" between the new system and the existing organization is not
necessarily desirable. Understanding what is desirable requires considering the design

objectives.
Broadly speaking, one can distinguish two design objectives for an information
system. These are, in Hammer's (1990) words, "automation" and "obliteration." Put
differently, the objective of an information systems project might be to create incremental
change, largely by mechanizing or automating the current business processes. Alternatively,
the design objective might be radical change, fundamentally reengineering or transforming a
firm's processes. For the first case, where changes are incremental, success generally
depends on a reasonably good fit with the existing organization, because too great a
mismatch between firm and system may engender resistance and other damaging responses.
In contrast, where the system is an agent for radical change, success depends on a deliberate
clash with the existing organization carefully designed to transform the organization in the
desired manner (Markus and Keil, 1994).
So we can understand a system's effects in terms of the interaction between the
system and the organization as follows: A good fit is consonant with successful
mechanization, while a mismatch offers the potential for transformation. With this
observation as a foundation, the IT interaction model can be used in two fundamentally
different ways:
proactively, to analyze the issues involved in designing and implementing an

information system and to make appropriate recommendations for action, or
reactively, to analyze what transpired after the fact in an IS project and to make
recommendations for improvement.

When designing an information system, the model can be used proactively in the early
stages of development to anticipate consequences and design system features accordingly.
One way to do this is by first studying the elements of the existing organizational
environment and then contemplating the consequences of the planned system, taking into
account both intended effects to be targeted as well as undesirable side-effects to be avoided.
Following these analyses, the major design choice between incremental improvement and
radical change (transformation) is made. And then throughout the implementation process
attention must be given to the various model elements. In the case of incremental
improvement, this means ensuring an adequate fit between the existing environment and the
system. l n the case of transformation, it entails fitting some elements of the environment
while deliberately clashing with others (Markus and Keil, 1994; Gersick, 1991; Tushman and
Romanelli, 1985). Moreover, in all cases, one must ensure that the implementation process
itself is appropriate and effective. In particular, when the information system is
transformative, implementation must support and facilitate the organizational transformation.
The interaction model can also be used reactively to analyze the outcome of an
information systems project. Such analysis might be useful either for academic purposes or
as part of the adaptive process of revising the system. When using the model reactively, a
good starting point is to ask whether the design objective was to improve or transform. If
the objective was improvement, then the results might best be understood by looking for
places where there may be a lack of fit between the system and the organization. If the
objective was transforination, the results might depend on understanding where there were
fits and where there were clashes. Figure 3 presents a checklist of questions to consider

when performing such an analysis. Note that not every question--every possible interaction--
will be important for every situation. The challenge is to determine which are the salient
issues for a given project.
These two real-world uses of the model correspond with two uses in the classroom.
The reactive approach--ex post analysis of a systems project--lends itself to retrospective
analysis of business cases. Students are encouraged to recognize whether the objective was
-
improvement or transformation, to consider whether this objective had merit, to contemplate
the full set of consequences (not just the obvious ones of profit or market share), to identify
the salient elements of the model that contributed to these outcomes, and to make
recommendations concerning what could have been done differently. This approach can also
be used for comparative case analyses, to help students examine how different mixes of
organizational factors and system features contributed to different outcomes. The model can
be used either for written case analyses or as the basis for class discussions.
The proactive approach also has multiple uses in the core MBA course. Many such
courses include small systems analysis and design projects, and others include term-long
development projects. In some instances these are "textbook cases, " where students design
systems based on predefined scenarios, while in others they are "living cases," which allow
the students to study the environment and interview the people directly. Either way, the
interaction model can be used proactively to guide systems analysis and design. The
proactive approach may also be appropriate for "action" business cases where students are
presented with a business situation and asked what the organization should do next.

EXAMPLES OF PROACTIVE A h a REACTIVE ANALYSES
To make the IT Interaction Model and its uses more concrete, we describe two
examples of how we use the model in the core course. The first example illustrates the role
of proactive analysis in student projects, and the second shows reactive analysis using the
OTJSLlNE business case.
A Living Case: A Proactive Illustration
We have used the model as a foundation for a variety of student projects including
systems analysis and design assignments (based on predefined case descriptions) and field-
based analysis projects (where the teams found their own sites). One approach we found
especially worthwhile for the students was to engage the class in a term-long living case
where the teams all served as IT consultants to the same client. For each section of the core
course, we selected a different unit in the business school that had expressed a need for IT
support. These units included the planning office, placement center, and admissions office.
Ekrly in the term we devoted one class session to introducing the interaction model and
another to a presentation by the client. The formal charge to the students was to "advise the
client about IT-related problems and opportunities," but the client briefings typically focused
on a particular issue where the client felt IT could be brought to bear. The students were
strongly encouraged to apply the model in making their recommendations. During the term
students scheduled follow-up interviews with members of the client organizations and others
whose input was desired. Class time was allocated as needed to address issues of importance

to more than one team. At the end of the term, each team submitted a written report and
presented an oral summary to the class and the client.
Examining the differences across teams highlights how the students used the model.
Some groups took a very technical approach to the task, devoting a good deal of their effort
to designing and building prototypes. While their demos were generally slick, other teams
that took a broader and more behavioral approach generally made greater use of the model
"$
and produced richer analyses. The teams varied in their assessments of whether it was best
to automate or obliterate. Some teams made low-tech recommendations, arguing that little
new technology was needed but that changes to the unit's processes and procedures were
essential. Others argued for incremental improvement, automating existing approaches. Still
others argued for more radical reengineering or transformation.
The teams identified an assortment of factors within the organizational environment
that constrained the system design or had the potential to affect outcomes. For example, a
number of t&ms expressed concerns about the ability of the existing IT infrastructure to
support what they saw as the ideal solution to the problem. Concerns about hardware
resources, software compatibility, data availability, and computer skills led some groups to
recommend enhancements to the infrastructure and other groups to scale back their proposed
solutions. Similarly, internal structure and culture were often seen as additional constraints.
Difficulties in sharing data across units, a low-tech atmosphere, and competition among units
for central computer resources were all seen as factors requiring attention. Most groups
pointed to areas where business processes could be improved, if not transformed. And

although these were units of a nonprofit organization, the external environment also played a
role. Units such as the placement center and admissions office were sensitive to the behavior
of their counterparts at competitor institutions, and this influenced the project goals and
parameters. In their analyses, students were also able to identify sources of potential
resistance.
Based on the written reports, oral presentations, follow-up discussions with students,
-- -
-.
and feedback from clients, we believe that the model helped the students to appreciate the
dynamics of information systems in the client organizations and to recognize the
opportunities, dangers, and limitations that the client environment posed for the application
of information technology. Of course, since the students' term-long participation reflected
only the initiation stage of the implementation process, they were not able to experience first-
hand the interactions and consequences that would ensue as the projects progressed. For this
reason, we recommend coupling the proactive analysis of the project with reactive analyses
of a number of business cases.
OTISLINE: A Reactive Illustration
The OTISLINE (1988) case is a popular business case that illustrates how Otis used
information technology to enhance its competitive position in the elevator industry. The case
is rich with respect to many aspects of the IT Interaction Model.
In brief, the case describes how Otis centralized its dispatching and monitoring of
service calls, thereby improving the quality of service and achieving a variety of related

competitive benefits. Our objective in the discussion is to recognize what transpired and to
analyze why. The way we open the discussion is usually to ask if OTISLINE was
successful.
Students generally conclude that the system was a success by noting that Otis
strengthened its number one share of the service market (performance). And they point to a
number of second-order competitive benefits that also followed from the system, such as the
-
edges in manufacturing and selling elevators that OTISLINE produced indirectly. Further
analysis also reveals that OTISLINE served as the springboard for additional technological
innovations that Otis planned down the road. We press the students on this issue of future
flexibility versus current performance, asking questions such as the following: How
dependent is Otis on OTISLINE? How can Otis insulate itself from the risks of dependence?
Is Otis blinding itself to other, better approaches that might be invented in the future?
Next we ask what made OTISLINE a success. It is usually agreed that OTISLINE
met the firm's strategic business need and was responsive to the competitive problems Otis
faced in the elevator service industry. But we probe further. While the system may have
been a good strategic fit, consonant with the demands of the external environment,
OTlSLINE represented a transformation within the organization. Otis moved from a highly
decentralized handling of elevator service, controlled by the field office managers, to a
highly centralized approach. Many of the immediate and future benefits of OTISLINE
follow from this radical change, which was not just a redesign of the business process of
dispatching, but a transformation of managerial control within the firm.

We probe still further. The case notes that Otis was only able to implement
OTISLINE so rapidly because a critical database was already in place. So OTISLINE's
success was attributable, in part, to having necessary infrastructure already in position to
support the new system. We also encourage the students to consider the implementation
process; they generally note a number of implementation factors that further contributed to
OTJSLINE's success.
- -.
At this point, the discussion may seem complete to many students, but we have not
yet considered the effects on people. These effects varied by position. Centralized
dispatching meant replacing local dispatchers with new ones at the central site. For
mechanics, the improved dispatching made their lives better in some ways, but it also
subjected their performance to greater monitoring. And field office managers found
themselves bypassed as service data flowed directly to corporate headquarters, which began
to intercede in local service operations. So, the consequences for people in the organization
were very mixed. In this, OTlSLlNE is similar to many systems, we believe, which is why
we find it so effective to use this case in conjunction with our model.
We use the IT Interaction Model to present our conclusions. Among the conclusions
we reach is that OTISLINE was a good fit with strategic need, but that it was not the
technology or the fit alone that produced the successful outcomes. Having an appropriate
infrastructure and employing a good implementation process also contributed. And {he key
ingredient was transforming the organization through centralization. While this
transformation had a positive effect on performance, it had a variety of negative effects on

many people's jobs. This conclusion can support a discussion of alternative system design
features or alternative implementation strategies that might have produced different results.
THE ROLE OF THE MODEL IIV THE COURSE
We can summarize the role of the model in the course as follows. The IT Interaction
Model is both a foundation for, and an integration of, virtually all the material we cover
during the term. Like many IS core courses, we structure the course around the following
main topics:
the basics of information technology (hardware, software, databases, and

telecommunications),
IS development (the traditional systems development lifecycle, prototyping,

outsourcing, and end-user development), and
IT applications (transaction processing systems, interorganizational systems, decision

support systems, groupware, expert systems, and more).
Each of these topics is reflected prominently in the model, yet interwoven with the others as
it is in the business world. Consider some examples:
The busies of rechnology come into play in at least three ways in the model.
Technology concepts matter for assessing the IT infrastructure, for describing system
features, and for examining the relationship between the capabilities of the existing
infrastructure and the demands of the proposed system. Indeed, the model helps those
students who might otherwise be resistant to the technological component of the course
appreciate why they need to learn this material. For example, OTISLINE provides an

excellent illustration of the importance of voice technology (automatic call distribution)
complementing computing technology (databases).
The sysrems development portion of the course is reflected by the implementation
process time-line that runs across the top of the model. The model portrays an abstracted
process comprising four generic phases, but systems development and implementation receive
proper and complete attention during the course. In particular, our treatment of these topics
7 A
pays special attention to the systems analysis and design phases and to implementation tactics
and strategies. We point out the importance of process, noting that the implementation
process, too, affects system use, consequences, adaptation, and success. The implementation
process structures the model visually just as, in the real world, it is the process that carries
us from the existing organization to the new system to the effects of their interaction.
Our objective in the IT applicurions section of the course is twofold. One goal is to
acquaint students with the range of application types they are likely to encounter in the
workplace. The other aim is to familiarize them with the dynamics of these various
applications in organizations. We rely on the model heavily to realize this second aim. In
the paragraphs that follow we use expert systems, group decision support systems, executive
information systems, and interorganizational systems to illustrate briefly this use of the
model.
In addition to explaining the routine characteristics of expert systems (Leonard-Barton
and SvioMa, 1988)--what rule-based expert systems are, how they work, what tasks they are
suited for, and what benefits they offer the organization--we use the interaction model to

provide a more penetrating analysis. What are the consequences of an expert system for
people in the organization? Is such a system job enriching or deskilling? Are the
consequences the same for the expert and for the novices? How might this system constrain
the organization's future flexibility? For instance, might the system lead to deskilling, which
in the long r u n could lead to a loss of knowledge and expertise for the firm?
Similarly, we use the model to probe the features of group decision support systems
(GDSS). One GDSS feature that has received much attention is the possibility of sharing
ideas anonymously (DeSanctis and Gallupe, 1985; Nunamaker, Applegate, and Konsynski,
1987; Jessup, Connolly. and Galegher, 1990: Valacich, Dennis, and Nunamaker, 1991).
Such anonymous communication offers potential advantages as well as potential
disadvantages. For example, while anonymity might promote greater participation and more
effective brainstorming by reducing inhibitions, it might also suppress participation since
individuals are not rewarded for their contributions. Whether anonymity produces good or
bad results, therefore, may depend upon whether the organizational culture encourages or
stifles open communication and upon whether the organizational reward structure favors
individual or group performance. An organization might set anonymity on or off in
consonance with its existing structure and culture, or it might do the opposite, using the
system, together with a careful implementation process, to transform the structure and
culture.
Executive Information Systems (EIS) are rapidly turning into "Everybody Information
Systems," proliferating throughout the firm as a means of sharing valuable corporate data

("Trickle-Down Systems," 1990). In some firms, efforts toward corporate-wide information
systems may be stymied by inadequate technological infrastructures. In others, the
infrastructures may now be robust enough to support such data sharing, but structural and
cultural barriers may still block it. A system intended to promote a more informed, data-rich
business environment may instead evoke resistance accompanied by the withholding and
falsifying of data. Here, again, success may depend upon a well managed transformation of
.-?2
the organization.
Interorganizational Systems (10s) that electronically link one firm with another
(Malone, Yates, and Benjamin, 1989; Cash and Konsynski, 1985) are also growing rapidly in
popularity. Whether a given firm will benefit from hooking up with its suppliers and
customers electronically, however, and what the most appropriate type of connection will be
(for example, an electronic market versus an electronic hierarchy, a proprietary versus a
standard ED1 protocol, and so forth) depend upon such elements of the external environment
as the concentration of sellers in the industry, the relative power of buyers and sellers, and
the basis of competition. The Reynolds Aluminum Supply Company case ("RASCO: The
ED1 Initiative," 1990) illustrates a number of these issues nicely.
In addition to these main topics--technology, development, and applications--two
themes that run throughout the course are (1) the strategic use of information technology and
(2) business process reengineering. As we have seen, the model captures these themes as
well. Strategic use of technology is reflected in the external view of the organizational
environment. And reengineering is at the center of both the proactive and reactive uses of

the model,
Given the model as an integrative framework for the course, the students emerge with
a better understanding of how the pieces fit together and why each is important for a sound
understanding of information systems in business. And by presenting the students with a
formal, causal model of information systems in organizations--albeit in the form of a
schematic and not a set of equations or propositions--we convey the message that the course
and the subject are not a collection of loosely related topics but an integrated whole resting
on a well-defined theoretical foundation. It is reassuring to the students to be able to point to
the model as the core of the course. If the students grasp the model, they can feel
comfortable with their understanding of the theory that underlies IS. And our use of the
model also makes the students aware of what we expect them to take from the class.
The way we employ the model in the course fosters a number of important business
proficiencies that should serve the students well in the workplace. As "the line takes the
leadership" (Rockart, 1988) and the partnership between IT professionals and line managers
grows, MBA's are likely to participate in information systems development projects in a
number of significant ways: as project sponsors, as members of the design team, as
managers of development, as end-user developers, and as project funders. At a minimum,
managers should expect to be interviewed during systems analysis and design. Experience
with proactive use of the IT interaction model will enable them to serve more competently in
these capacities, increasing the likelihood of positive consequences and decreasing the
chances of negative ones. Systems will always have unanticipated effects, but the more

people understand about the dynamics of information systems, the better they will be able to
minimize these unanticipated effects, to recognize them when they occur, and to cope with
them. As citizens of wired organizations, MBAs should expect to encounter first-hand the
consequences of their firms' IT undertahngs. Experience with reactive use of the model will
enable them to comprehend how a given system is affecting them and their organizations and
to recommend any necessary corrective actions. This combination of proactive and reactive
analytic ability should prepare the students well for the demands of the workplace.
OTHER PEDAGOGICAL ISSUES
In this section, we briefly discuss several additional pedagogical issues that have not
already been addressed: at what point in the course the model should be introduced, the
independence of the model from the particular sequence of topics, and the relationship
between the model and other MBA core courses.
First, we advocate introducing the model early in the core course. Some instructors
may wish to present the model at the outset of the term to lay a foundation for what is to
come. We find that it is often useful to defer introducing the model until the students have
encountered some basic course material and have analyzed at least one business case. This
approach serves to motivate the need for a model and to provide a context for appreciating
the issues the model raises. OTlSLINE is a good choice for such a case. The case can be
discussed in class prior to introducing the model, and it can then be used as an illustration
while presenting the model.

Second, the IT interaction model does not depend on a particular sequence of topics.
Many core courses begin with technology basics, then discuss the development process, and
conclude with specific types of applications. Others follow different orders, and still others
integrate the topics (for example, by spreading basic technology concepts throughout the
discussion of applications or by teaching development approaches in the context of particular
classes of applications). Over the years, we have varied the order of presentation, but were
still able to employ the model successfully. The model represents an additional level of
course structure and can therefore be applied no matter what sequencing of material is used.
Third, although our model uses concepts found in other core MBA courses, such as
strategy, structure, and culture, it is not our intention in the core IS course to teach such
subjects. Depending on whether these courses are taken by the students previously,
concurrently, or in subsequent terms, the level of detail that we employ in presenting the
components of the organizational environment vary. For example, in some instances we may
make a formal distinction between structure and culture while in others we may not. For
those MBA programs focusing on cross-functional integration of the curriculum, the model
provides an excellent opportunity for collaborative teaching with the management core
course.
ASSESSING THE EFFECTlVENESS OF THE hlODEL
Based on our experiences at several universities, we believe that the IT Interaction
Model is a useful mechanism for addressing a number of practical teaching concerns as well

as for achievtng our matn course objecttves. With respect to the pedagogical Issues. the
model unifies what IS often percel~~ed

as a "topics" course. the model offers a formzl
foundation for what students somettmes consider a "soft" or "nonrigorous" subject. the
mode1 provides a consistent framework for case analyses, dtscussions, and group projects,
and the model fosters critlcal bustness competencies. Slnce introducing the model several
vears ago, the feedback we have received has shown a marked reduction in student concern
about these matters.
With respect to the course objectives. recall that the course goals are to acquaint
students with the dynamics of information systems in organlzattons and, in particular. to
increase students' knowledge of the potential benefits. dangers, and limitations of information
technology. equipping them to leverage the benefits, avoid the dangers, and surmount the
I~mltations. Based on the way students progress through the term, as evidenced in case
discussions, written case analyses. and student projects. we believe that the model
accomplishes these objectives. While students tend to enter the course as "technological
determinists' (Markus and Robey. 1988), the model shows them that information technology
is just one of many inlportant contributors to information systems outcomes and that an
assortment of factors interact to produce results. At the beginning of the term, students often
focus on technological issues and positive outcomes. h4idu.a~through the course, the focus
tends to shift in the other direction. such that they are inclined to see only the limitations and
the organizational dangers. By the end of the term a balance is achieved.
One concern we have is that some students may be memorizing the model rather than

learning to apply jt effectively. Just as jn other courses students may memorize equations
and invoke them by rote. we have noticed that some students absorb the IT Interaction hlodel
onlv superficiall!.. These students include all the buzzwords in their written analyses and
class participation, but they do not demonstrate an understanding of the concepts. For
example. the better analyses and comments focus on the subset of model elements that are
salient for the case at hand. The weaker ones. however, list all the components without
conveying significant insight. We combat this tendency in a number of ways: through oral
and writren feedback, by providing a series of written assignments and case discussions so
students can develop their analytic skills. and through group projects so the more
perspicacious students can share their insights with their peers.
The model is most successful when used for both business cases and student projects
W e believe that the model is effective for analyzing most IS cases. but because there is a
dearth of IS business cases, and because the existing ones were written independently of the
model, finding a complementary set of cases that are rich with respect to the model is
difficult. Writing IS cases while keeping the model in mind would therefore be helpful. For
example, if the students were provided with rich and thorough description, they could be
challenged to identify which model features are the salient factors in the case.
\4Je have found the IT lnreraction hlodel to be a valuable roo1 for teaching the MBA
core course in information systems in a number of academic settings. Our hope is that as a

teaching model that encompasses the full range of applicable topics. highlights the critical
issues. and focuses on the essent~alrelat~onships.while remaining independent of particular
content cholces. the interaction model xllll prove useful to others as well. We believe the
model can also s e n e as a vehicle for ad~ancingthe ongoing dialogue concerning the design
of the IS core course.

Bovnton, A.C.. Victor. B.. and P ~ n e .B.J., 11. "New Competitive Strateg~es: Challenges to
Orpanizat~onsand Informat~onTechnology," IBM Sjsretns Journal, (32: 1). 1993, pp. 40-64.
Brynjolfsson. E. "The Productiv~tvParadox of Informatton Technology." Cor77t?iunrcar1onsof

rhe ACM. (36: 12), December 199i, pp. 66-77.
Cash. J.I., Jr., and Konsynsh. B.R.. "IS Redraws Competitive Boundaries." Hanlord
BIIS~~~ESS
Review, (53:2). hlarch-April 1985, pp. 134-14,.
DeLuca. J.R. Overcon~in~

Resisrunce lo Chunge. Evergreen Business Group. New York.
NY. 1993.
DeSanctis. G. and Gallupe. R.G. "A Foundation for the Study of Group Decision Support
S~~stems."Munagen7enr Sc~ence.(33:5). May 1987, pp. 589-609.
DeSanctis. G . and Poole. M.S. "Capturing the Complex~tvin Advanced Technology Use:
Adaptive Structuration Theory." Orguniioiion Scicncc. ( 5 : 2 ) , May 1994, pp. 121-117.
Fichman. R. and Kemerer, C. "Adoption of Softmdare Engtneering Process Innovations: The

Case of Object Orientat~on." Slour~Munugetneni Revrelv. (34:2). Winter 1993, pp. 7-22.
"Frito-Lay, Inc.: A Strategic Transition (C)," Haward Business School, 9- 190-071, revised,
March 1992.
Gersick, C.J.G. "Revolutionary Change Theories: A Multilevel Exploration of the

Punctuated E,quilibrium Paradigm." Acudemny of Manugetnenr Review, ( 1 6: I), 1991.
pp. 10-36.
Goodhue, D.L., Wybo. M.D.. and Kirsch, L.J. "The Impact of Data Integration on the
Costs and Benefits of Information Systems," MIS Quarrerly, (16:3), September 1992.
pp. 293-3 1 1.
Hammer, M. "Reengineering Work: Don't Automate. Obliterate." Hulvurd Business

Review, (68:4), July-August 1990, pp. 104-1 12.
Ives, B. and Learmonth. G.P., "The Information Svstems as a Competitive \4Ieapon."

Cotwnunicorions of riie ACM. (27:
12). December 1984. pp. I 193- 1201.
Jessup. L.M., Connolly. T.. and Galegher G. "The Effects of Anonymity on GDSS Group
Process With an Idea-Generating Task." MIS Quuric~riy.( 14:3), September 1990.
pp. 313-321.

Keen. P.G.W. Shaping rhe Furure: Business Design T1'7rough lnfonnarion Technolog).
Hanrard Business School Press. Bosron, MA, 1991.
Keen. P. G .M'. and Scott Monon, hl. S. Decision Supporr S ~ S I P ~ An

I S :Orgonizarional
Perspecnve, Addison-Wesley. Readlng, M A , 1978.
Kling. R . and Scacchi. \V. "The Web of Computing: Computer Technology as Social
Organization." in Advances in Con~purers,(21), Academic Press. New York, N Y , 1981
Leonard-Barton, D. "lmplementat~onas Mutual Adaptat~onof Technology and

Organizat~on."Research Polrq, (17). 1988, pp. 251-267.
Leonard-Rarto;~,D. and Sviokla. J.J.. "Putting Expert Sysrems to Work," Hamard Business
Re\.rew. (66:2), March-April 1988, pp. 91-98.
Lucas. H.C., Jr. lnfoni?ur~ot?

SJ.S~CIITS
C ~ n c e p r s f o rMunupc.menr, Mitchell McGraw-Hill. San
Francisco, CA, fifth edit~on,1994.
Malone, T.W., Yates, J.. and Ben-lamin, R.I. "The Logic of Electronic Markets," Nanard
Business Review, (67:3). May-June 1989, pp. 166- 1 69.
Markus, M. L. Systems in Orgunizarions: Bugs and Features. Pitman Publishing, hlarshfield,

MA. 1984.
Markus, M.L. "Toward A 'Crit~calMass' Theory of lnteract~veMedia," in Organizations

and Con?n~unicarionTechnoiog~.J . Fulk and C.W. Steinfield (eds.), Sage Publications,
Newbury Park, CA, 1990, pp. 194-218.
h4arkus. M.L. and Keil. hl."If We Build It They \xiill Come: Designing Information
Sjlstems That Users Want To Use." Sloan Managenwnr Review, (35:4), Summer 1994 (in
press).
Markus. M.L. and Robey, D. lnformat~onTechnology and Organizational Change: Causal

Srructure in Theory and Research. Mui~ugen~enr
Science. (34:5), May 1988, pp. 583-598.
hlarkus, h4.L. and Soh. C. "Ranking on Information Technology: Converting IT Spending

Into Firm Performance," in Pcrspec~~ves on [he Srraregic and Econon~icValue of lnfonnurion
Technology Invesrmpnr. R . D . Banker, R.J. Kauffman. and h4.A. Mahmood (eds.). Idea
Group Publishing, Middletown. PA, 1993, pp. 364-392.
McFarlan, W.F. "Information Technology Changes the Way You Compete," Hurvurd
Business Review, (62:3). May-June 1984, pp. 98-103.
Nunamaker, J.F., Jr.. Applegate. L.M., and Konsynski, B.R. "Facilitating Group Creativity:
Experience with a Group Dec~slonSupport System," Jol~rnulof Munu,qen~enrInfit-n~urron
Sysren~s,(3:4), Spring 1987. pp. 5-19.
Orlikowsh. W.J. "Learning from Notes: Orpan~zationalIssues in Groupware
Implementat~on." Proceedings of rhe Conference on Cornpurer Supporied Cooperative Work.
1992, pp. 362-269.
Orlikowskj, W.J. and Robey. D. "lnformat~onTechnology and the Srructuring of

Organizations." I~jo~niurion
Sysren~sResearch. (2:2), June 1991 , pp. 143- 169.
Porter, M.E. Col?~,~eritive

Srruregy. The Free Press, New York. NY, 1980.
Porter, M.E. and hllllar, V.E. "How Information Gives You Compet~tlveAdvantage."
Hurvard Business Rei9rerv, (63:4). July-August 1985, pp. 149- 160.
"OTISLINE." Han,ard Business School. 9-186-304, revised, January 198s.
"RASCO: The ED1 Inlt~atlve,"Darden Graduate School of Buslness Admlnlstration.

Univers~tyof V l r g ~ n ~ UVA-IT-001.
a. revlsed. J u l y 1990.
Rockart. J.F. "The Line Takes the Leadership." Sloan Monagen~enrR P I ~ I P I(29:4),
I * , Summer
1988, pp. 57-64.
Stohr, E.A., Jelass~.T.. Madnick. S.E., hlcKenney, J.L., Senn. J.A.. and Silver, M.S.
"Panel 3: Approaches to the MBA Core Course in Information Svstems." in Proceedings of
rhe Elelrnih Iniernurional Conference on lnfonliunon Sysrenls, 1.1: DeGross. M . Alavi, and
H. Oppelland (eds.). December 16-19. 1990. Copenhagen, Denmark, pp. 308-309.
Treacy, hl. and 1Viersema. F. "Customer Intimacy and Other Value Disciplines," Harvard
Business Rcr,ie\zl. (7 1 : I), January-February 1993, pp. 84-93.
"Trickle-Down Systems." Infomurion Week. May 7, 1990.
Tushman, hl. and Romanelli, E. "Organizational Evolution: A Metamorphosis Model of

Convergence and Reorientation," in Researcli in Organizarionul Beiiawor, L.L. Cummings
and B.M. Staw (eds.), (7), 1985, pp. 171-222.
Valacich. J.S.. Denn~s.A.R., and Nunamaker, J.F., Jr. "Group Slze and Anonymity Effects
on Computer-h4edtated Idea Generation." 7n Academy of Monupe17lenr Proceedings, Miami
Beach, FL. August 11-14, 1991, p. 447 (abstract).
Weill. P., Broadbent. hl., and St. Clair. D. "I/T Value and the Role of I/T Infrastructure
Investments." Srru~ogrcAl1gn117eni.Oxford University Press. Oxford. UK. 1994 (in press)
Weill, P. and Olson. h4.H. "Managing Investment in Informat~onTechnology: Mini Case

Examples and lmpl~cations.MIS Qrrurierlj., (13: I), March 1989, pp. 3-17.

1N3 VU N0 I/\ N3 1V NkJ 3 1:
& t e Z i Digiia.l Economy Re3errcl
FIGURE 2
COMPONEIUTS OF THE IT 1NTERACTION MODE1
ELEMENTS OF THE EXTERNAL ENVIRONMENT
* Competitive Structure of the Industry

Relative Power of 6uyers and Sellers
Basis o f Competition
GrowingiShrinkingiStabk
Regulation
Technological Deployment
EXAMPLES OF FIRM STRATEGIES:
Differentiation
Low-Cost P r o d u c t ~ o n
OualityIService
- 3 o i n g Global
Right-Sizing
Just-In-Time InventoryiManufacturing
SOME ELEMENTS OF ORGANIZATIONAL STRUCTURE
Centralization vs. Decentralization

Functional, Divisional, or Matrix Organization
Reporting Relationships
EXAMPLES OF ORGANIZATIONAL CULTURE:
Individuality (or Teamwork)

Bigger is Better (or n o t )
Risk Aversion (or Risk Taking)
EXAMPLES OF BUSINESS PROCESSES:
Order Fulfillment
Materials Acquisition
N e w Product Development
IT INFRASTRUCTURE
Computing Hardware
Software Development Tools and Program Libraries
Databases
Telecommunications N e t w o r k s
Training Materials and Facilities
Capabilities of IT Personnel
THE INFORMATION SYSTEM
Hardware
Software
Data
People
Procedures

FIGURE 3
REACTIVE ANALYSIS OF A N INFORILIATIOIL' SYSTEM
* Was the sysiem's design objective t o IMPROVE the organization incrementally

or t o TRANSFORM i t ?
* What are the sysiem's FEATURES? What does it d o ?
H o w does the svsrem FIT the firm's external BUSINESS ENVIRONMENT?
H o w does the sysrem FIT the firm's STRATEGY,
* H o w does the sysiem FIT the firm's BUSINESS PROCESSES?
H o w does the sysrem FIT the organ~zationalSTRUCTURE and CULTURE?
Can the organization's IT INFRASTRUCTURE support i h e system?
a H o w and h o w effectively was t h e system IMPLEMENTED?
. W h o USES t h e sysrem and h o w d o they USE it? A s intended'
* What are the CONSEOUENCES of the system for PERFORMANCE, PEOPLE, and
FUTURE FLEXIBILITY' Did t h e system accomplish its objectives?


Information Technology Information Model

Uploaded by

Copyright:

Available Formats

Information Technology Information Model

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Information Technology Information Model

Uploaded by

Copyright:

Available Formats

THE INFORMATION TECHNOLOGY INTERACTION MODEL:

A CORE MODEL FOR THE MBA CORE COURSE

Cynthia Mathis Beath

Workinq Paper Series

Center for Digital Economy Research

Cynthia Mathis Beath

Center for Digital Economy Research

Information Systems at several universities. The model is referred to as the "Information

Technology Interaction Model" because it maintains that the consequences of information

assessment of the model's effectiveness in the core course.

core course that produced the model presented in this paper.

Center for Digital Economy Research

they take conc~rrently(for example, accounting, economics, and marketing), it may be

remedying this deficiency, we propose in this paper a model of information systems in

systems at several universities.

We refer to the model as the "Information Technology (IT) Interaction Model"

information systems course.

Center for Digital Economy Research

use in case discussions and in student projects.

Center for Digital Economy Research

model's effectiveness in the course.

Core courses in information systems differ both because of programmatic constraints

We take as a starting point that as a core course--the only course in information

Center for Digital Economy Research

to increase students' knowledge of the potential benefits, dangers, and limitations of

The IT interaction model is best thought of as a stylized view of the dynamics of

information systems in organizations. Based on a large body of research findings (for

Center for Digital Economy Research

system, and (4) the system's effects.

We present the model to the students in diagrammatic form as shown in Figure 1.

and exemplifying the model's salient features.

conversely, some concepts go by a variety of names. A given instructor, therefore, might

endeavor to make clear how we use the terms we employ.

relationships more fully.

Center for Digital Economy Research

. organization. -Recause we see implementation as an ongoing process throughout the life of an

Barton, 1988; Markus, 1990).

with such alternative lifecycles as those associated with prototyping or outsourcing,

of both the organization and the information system is ongoing.

Center for Digital Economy Research

pointing from "Initiation" to "The Organization."

For the purposes of understanding the dynamics of information systems interventions,

The External Environment

Understanding the external business environment is important because the external

Center for Digital Economy Research

Many information systems projects in organizations today are closely linked to

production, a focus on quality and service, globalization, right-sizing, and just-in-time

Organizational Structure and Culture

By organizational structure we mean formal aspects of organizational functioning,

includes whether the firm is centralized or decentralized; whether it uses a divisional,

shared values, basic assumptions, and behaviors of organizational members. Elements of

Center for Digital Economy Research

definition of infrastructure, referring to it as "the capacity of the organization to generate

defined, it encompasses a large set of organizational IT resources, including computing

hardware, software development tools and programming libraries, databases,

Center for Digital Economy Research

success of an information system.

The Information System

organizational environment, an arrow points from the "Build/BuyWactivity to "The