iainiiin«<i>;';f«nm.ii'.ii''B'ii(iHrgamnjaaiyffiy'r''i
?:>a^f^u
c,SKCH»^^X,
*I.I.T. LIBRARJES - DF'iVEY
MJ
@
IMPLEMENTING RADICAL CHANGE:
GRADUAL VERSUS RAPID PACE
Michael J. Gallivan
J. Debra Hofman
Wanda J. OrlikowskI
August 1994
CISR WP No. 271
Sloan WP No. 3709
Dewey
©1994 M.J. Gallivan, J.D. Hofman, W.J. OrlikowskI
Center for Information Systems Research
Sloan School of Management
Massachusetts Institute of Technology
(iASSACHUSETTS INSTITUTC
OF TECHNOLOGY
NOV 2 9 1994
LIBRARIES
Implementing Radical Change:
Gradual Versus Rapid Pace
ABSTRACT
This paper explores the question of how radical changes are implemented in
organizations. The literature either does not directly address this issue or implies that
radical change can only be implemented rapidly. In fact, to speak oi the gradual implemen-
tation of radical change may at first glance appear paradoxical: how can radical change be
implemented slowly? We examine the assumptions underlying various notions of radical
change, and suggest that it may be useful for both conceptual and managerial reasons to
distinguish, at least analytically, between the nature or degree of organizational change
(radical or incremental) and the pace or speed of its implementation (rapid or gradual).
Drawing on the findings of a field study that investigated the implementation of radical
change in systems development, we show that the gradual implementation of radical change
may not only be feasible, but also effective in some situations. Specifically, we identify
characteristics of the organizational context and the technological innovation that can
indicate the conditions under which gradual implementation of radical changes may be
appropriate.
Acknowledgments
Thanks are due to the men and women of MidCo who participated in this research study.
Tlie support of MIT's Center for Information Systems Research is also gratefully
acknowledged.
Implementing Radical Change: Gradual Versus Rapid Pace
There is considerable attention being paid today — both in the research and practitioner
literatures — to the importance of organizational change around the introduction of new
technology. Calls to reinvent the corporation, reengineer business processes, and redesign
work flows have become the fashionable response to 'he so-called information technology
paradox. Hammer's (1990) by now well-known dictum, "Don't Automate — Obliterate,"
accurately captures the general sentiment — to gain real benefits from investment in
information technology, managers must accomplish radical change in their organizations.
Implementing radical change in organizations is no mean feat, as several studies
comparing radical and incremental change have demonstrated (Dewar and Dutton, 1986;
Ettlie, Bridges and O'Keefe, 1984; Orlikowski, 1993; Tushman and Romanelli, 1985). In
contrast to incremental change, where established structures, processes, and knowledge are
extended and augmented, radical change replaces the status quo with a new order of things
and as a result may create serious disruptions in structures, processes, operations,
knowledge, and morale. Jobs are altered and eliminated, skills are gained and lost,
information flow is redefined and rerouted, processes are transformed and created,
responsibilities are transferred, and power bases are undermined. Managing such disruptions
becomes critical to the experiences and outcomes associated with radical organizational
change.
This paper explores the question of how radical changes are implemented in
organizations. The literature either does not directly address this issue or implies that
radical change can only be implemented rapidly. In fact, to speak of the gradual implemen-
tation of radical change may at first glance appear paradoxical: how can radical change be
implemented slowly? We became intrigued by this question during a research study of the
implementation of CASE (Coniputer-Aided Software Engineering) tools in systems
development. Orlikowski (1993) and Fichman and Kemerer (1993) have shown that a
1
number of software development innovations such as CASE tools, development methodolo-
gies, and programming languages can represent radical change in the work, knowledge, and
organization of systems development. The organization we were studying was clearly
implementing a radical change in software development, represented by the adoption of the
IE methodology and lEF CASE tools. Yet, the implementation of these radical changes
appeared to be proceeding somewhat gradually. This apparent paradox prompted us to
examine the relationship between the nature or degree of change and the pace or speed of
its implementation, and in particular to confront the oft-taken-for-granted notion that
radical change can only be implemented quickly. In contrast to the expectation that the slow
implementation of radical change necessarily means reducing it to a series of incremental
changes, our research findings suggest that under certain conditions the gradual implemen-
tation of radical change may be not only feasible, but also effective.
Before considering the research study which generated these implications, we believe
it is instructive to examine some of the assumptions that underlie our understandings and
notions of radical change. In particular, an examination of both business and academic
writings on the topic suggests that there are multiple and different meanings as well as uses
of the term. Our research findings have made us realize that it is useful ior both conceptual
and managerial reasons to distinguish, at least analytically, between the nature or degree of
change (radical or incremental) and the pace or speed of its implementation (rapid or
gradual). That is, it is possible to characterize an organizational change in terms of two
dimensions, as represented by the two questions: how big is the change? [nature] and how
quickly is the change accomplished? [pace]. In this we follow Gersick's (1991) recommenda-
tion to differentiate between the processes of change (e.g., pace of change) and their
outcomes (e.g., nature of change). As our brief review of the literature will indicate, such
a distinction is not always made. We believe that disentangling these two dimensions of
change can be particularly valuable in helping us think about and deal with the implementa-
tion of radical change.
Literature Focusing on the Nature of Change Only
TTie technological innovation literature makes a strong distinction between incremental
and radical types of technological innovation (Dewar and Dutton, 1986; Ettlie, Bridges and
O'Keefe, 1984; Pennings, 1988; Tushman and Romanelli, 1985), so as to indicate "the
degree of change they create in the existing practice of the adopting organization"
(Damanpour, 1988:5-9). Incremental change amounts to an extension of the status quo, that
is, adjustments or refinements in current products, processes, relationships, knowledge, and
norms. Such changes represent "minor improvements or simple adjustments in current
technology" (Dewar and Dutton, 1986:1423). Radical change replaces the status quo,
requiring a shift to fundamentally different products, processes, relationships, knowledge,
and norms. In using the notions of radical and incremental change, these mnovation
researchers do not refer to and appear to make no assumptions about the pace with which
the change is accomplished.
Literature Focusing on the Pace of Change Only
While some researchers focus specifically on the nature of change, others focus only on
the pace of change, without making r.ny reference to the degree of change being
implemented. For example, in his research on organizational innovations. Van de Ven
(1993:286) advocates rapid implementation because the trial period of an innovation is brief:
"After the honeymoon period, innovations terminate at disproportionately higher rates, in
proportion to the time required for their implementation." Similarly, Kanter (1983) argues
that because slow implementation of change may allow resistance among workers to
accumulate, decisive and expeditious action on the part of management is required. In the
same vein but taking an opposing stance, other researchers argue that a more gradual pace
of implementing change may be more effective in general. For example, Hage and Aiken
(1970:106) suggest that the longer the implementation period, the longer the period of trial
and error, thus "the greater the chances of the new program achieving its intended
objectives." Likewise, Rogers (1983:364) notes that "too-rapid implementation of the
innovation... can lead to disastrous results" because when the introduction process is rushed,
problems that later interfere with effective use of the technology may be ignored. While
these researchers differ on whether they advocate a slow or fast pace of implementation,
they are similar to the extent that none of them specify the type or nature of change to
which their recommendations apply.
Literature Combining tlie Nature of Change and the Pace of Change
In contrast to those researchers who only focus on one or the other of the two
dimensions of change (nature or pace), a number of commentators in both the research and
business communities see these dimensions as either inseparable or as interdependent. On
the former side are researchers in organizational strategy who assume that the dimensions
of nature and pace of change are not independent. That is, they make assumptions about
both the nature of change and the speed with which change is accomplished when they use
terms such as incremental (or evolutionary), radical (or revolutionary), and quantum change
(Miller, 1982; Miller and Friesen, 1980; 1982). For example, Quinn (1980, 1982) describes
"logical incremeiitalism" as a way of constructing business strategy that combines a "step
by step" process [pace] with an "incremental" effect [nature].
While not going so far as to consider nature and pace of change as inseparable, many
writers treat these dimensions as highly interdependent. That is, they assume that only
particular combinations of these two dimensions are feasible. For example, Hammer (1990;
Hammer and Champy, 1993) has argued that a rapid implementation is the only feasible
way of accomplishing radical chanjie. He notes that "Reengineering cannot be planned
meticulously and accomplished in small and cautious steps. It's an all-or-nothing proposition
with an uncertain result" (1990:104-105). Tushman, Newman and Romanelli (1986:39)
observe that resistance to "fundamental change is natural. If frame-breaking [radical] change
is implemented slowly, then individuals have a greater opportunity to undermine the
4
changes and organizational inertia works to further stifle fundamental change." Likewise,
in the area of expert systems, Sviokla (1992:30) notes that transformation technologies (his
term for radical changes) "need swift, concentrated action to make change. The benefits of
speed have been documented copiously."
With respect to incremental changes, some researchers have suggested that a gradual
pace of implementation is warranted. For example. Tyre and Orlikowski (1993, 1994) have
shown that the introduction of new production technologies may be more effectively
accomplished if executed through a series of phases. In their research they found that the
implementation and adaptation of technologies in organizations were not accomplished in
a single concentrated implementation period. Rather, these occurred episodically over a
long period of time. Comparing these research findings to practices in Japanese firms, Tyre
and Orhkowski (1993) conclude that some incremental changes to technologies and work
practices may be implemented more effectively if managed in a phased or episodic manner.
Implications for Managing Change
Despite these various discussions of implementing change, there remains little guidance
to help change managers choose an appropriate pace for the radical change they wish to
accomplish. As we saw above, many of the discussions oi pace of implementation in the
literature do not explicitly discuss the nature of change. For those authors advocating rapid
or gradual implementation, it is often unclear whether their recommendations apply to
radical or incremental innovations — or both. Those who are specific about the nature of
change when advising a particular implementation pace imply a strict coupling of rapid
implementation with radical change (Hammer, 1990; Sviokla, 1992; Tushman, Newman and
Romanelli, 1986), and phased implementation with incremental change (Tyre and
Orlikowski, 1993, 1994). Yet, there is some empirical evidence that the implementation of
radical change does not have to be done rapidly. Based on a study of 41 firms implementing
flexible manufacturing systems, Ettlie (1986) found that a gradual pace of change was
5
among the most frequently cited factors contributing to the successful implementation of
radical technological changes. He argues that: "It is wise to take a strategic approach to
phased adoption and implementation for these major [radical]... changes in systems"
(1986:80). In a similar vein, Greiner (1992), has suggested that a gradual approach toward
organizational restructuring is associated with more favorable change outcomes.
The implicrtion of these various discussions and recommendations is thus ambiguous,
and the question — which pace of implementation is more effective in the context of radical
change — has not been systematically addressed. Tlie conditions that indicate a rapid versus
a gradual pace of implementing radical change remain unspecified. That is the issue we
explore in this paper.
Below we examine the details of one organization's experience in implementing a radical
change, paying close attention to the nature of the changes being realized and the timing
with which various changes were accomplished. We then interpret the findings in the context
of the rapid versus gradual pace debate, and attempt to outline some of the organizational
and technological conditions that appear to facilitate either rapid or gradual implementa-
tions of radical change. While our study examines the radical change that was associated
with the introduction of new technology (CASE tools) in systems development, we believe
that the issue of implementation pace applies more generally to other organizational
changes as well. The broader question of whether radical change associated with new
information technologies is better implemented swiftly or more cautiously is one that
transcends the particular details of the change being attempted.
RESEARCH METHODOLOGY
Our field study investigated the implementation of a set of integrated CASE tools in a
large chemical products company located in the midwest — hereafter called MidCo. We were
interested in understanding the systems development changes associated with these CASE
tools. Data were collected through on-site interviews executed during two separate visits
four months apart, follow-up telephone interviews, and a review of available documentation.
The on-site interviews followed a semi-structured interview protocol, and lasted about an
hour in length. Thirty-five respondents participated in our study, representing several
different divisions at MidCo (both business and IS) and several different organization levels
(staff, department managers, and division managers). Table 1 shows the distribution of
respondents across vertical and function:-! lines. The documentation we examined included
general information about the organization, as well as specific materials related to the
evaluation and implementation of CASE tools.
Table 1: List of Interview Respondents by Position and Function
Level in Organization
IS
Business
Total
Sr. Executive (e.g., Vice President, Division Manager)
1
3
4
Middle Manager (e.g., Department Head)
6
3
9
Staff (e.g., Project Manager, Analyst)
16
6
22
Total
23
12
35
Data analysis employed qualitative techniques (Glaser and Strauss, 1967; Miles and
Huberman, 1994). We searched our interview transcripts and available documentation for
themes, using a technique of open coding that allowed us to detect patterns in the data
which were consistent across respondents, or which showed divergence across different types
of respondents. In the case of inconsistency or incompleteness, we probed for clarification
and confirmation during our second site visit and through telephone interviews.
MidCo is a multi-national chemical products company with revenues of $1.4 billion and
over 5,000 employees worldwide in 1991. MidCo competes in several different market niches
and is the market share leader in its various product segments. MidCo's profitability is
driven by its relative superiority in chemical technology, and this is understood to be
critically dependent on R«&.D effort and excellence. This understanding is reflected in the
prominence afforded R&D within the company. Nearly all executives occupying the CEO
and COO offices have come from positions in R&D, and investment in research is heavily
supported (5.1% of revenues in 1991). One executive highlighted the critical position of
R&D by noting that "Research drives the vision here — everything else is in the dust." TTie
managerial philosophy expressed by senior managers suggests a will'ngness to make current
investments in order to reap future gains. Respondents frequently mentioned MidCo as a
"[chemical] technology leader" and the firm had adopted a firm-wide quality management
program in 1987. This quality management program, based on the approach of Deming
(1962), was initiated to strengthen and sustain the company's strong performance, rather
than to resolve any particular problem areas. The Deming approach was selected because
it was seen to be consistent with MidCo's scientific and engineering culture. A long-term
goal stated by one of the executives was to achieve "a flatter, empowered organization,"
with teamwork and ready access to information across departmental lines.
RESEARCH RESULTS
Context for the Clianges in Systems Development —
MidCo's corporate IS division was centralized with approximately ninety full-time
employees, organized into six departments each headed by a department manager. Three
of the departments were application development groups which developed information
systems for specific business divisions, and three were technical support groups. The
application development groups were organized around the major divisions of the
corporation: R&D, Logistics, and an "umbrella group" of traditional business functions.'
The IS managers and staff referred to the user departments they supported as
"customers" rather than as user?. The mission of IS was described by the IS director as
follows:
To be a value-added business partner, to help our customers do their jobs — but as a partnership, not
a service to them.
Although the IS division did not directly charge the business divisions for its services, there
was nonetheless a sense of ownership by each business division for the systems requested
by them. The business divisions also assumed an informal claim over the IS staff within the
specific application development group that supported them.
IS was both similar to and different from the business. Employee turnover in IS was
very low, as in the rest of the company. The commitment to quality, innovation, and
empowerment, so prevalent in the rest of the company, also pervaded IS. For example,
there was a shared belief that the role of IS was to "empower users to do their jobs with
available information" as one senior IS inanager put it. TTie IS division differed from the
other business divisions in that it had a larger proportion of younger members and women
employees. About half of the IS employees were women, including five of six IS department
managers. An IS manager observed:
We are risk takers. We are pushy. We are very young age-wise. We have as many female as male
employees. Everyone gets an equal chance in the IS organization.
Background to the Changes in Systems Development
Prior to implementing CASE tools, MidCo was using the Method/ 1 systems development
methodology purchased froin Arthur Andersen. The Method/1 methodology provides
software development guidelines based on a set of structured, process-oriented design
principles (cf. Yourdon and Constantine, 1978). In 1987, the IS division created a Data
Administration group, which began using James Martin's (1982, 1990) data-centered
Information Engineering (IE) approach to guide their systems planning efforts. At this time,
there were no automated tools available to support the IE methodology, and manual
methods were used to perform the various IE analyses. This period coincided with the
adoption by senior MidCo management of Deming's quality management program, and the
acquisition of the IE methodology was seen as compatible with this broader quality
initiative. The deployment of IE however, did not extend beyond the Data Administration
Group, and the rest of the IS division continued to follow the Method/1 systems
development methodology.
In 1988, the IS division began experimenting with two early CASE tools. These were not
integrated CASE tools, but stand alone tools that each supported a single step of the system
development life cycle. One was an upper-CASE tool, called Information Engineering
Workbench (lEW), which was based on the IE methodology, while the other was a lower-
CASE tool, Telon, which allowed IS analysts to generate application code. Both of these
stand-alone tools received limited use within the IS division, their lack of integration with
the rest of the development life-cycle proving to be a significant drawback.
Table 2: MidCo's Selection Criteria for Choosing a CASE Tool
. (Source: MidCo Corporation, lEF Evaluation Project, December 1989, page 2.3)
• The need for complete life cycle support.
• The support of a data-driven methodology.
• The need for a fully integrated set of tools to support the life cycle.
Rekeying of data is to be minimized.
• The availability of the toolset on the PC, in particular the analysis, design,
and at least some testing.
• The enforcement of a particular methodology, eliminating the potential of
varying from a given approach.
• The support of multiple platforms.
In 1988, the Data Administration group decided to evaluate software tools to structure
their data management activities. They first reviewed and rejected a group of data dictionary
tools, and then shifted attention to a class of integrated-CASE software tools which were
10
being introduced to the market at that time. At this point the Data Administration group
realized the potential of integrated tools for supporting all of IS development, and derived
a set of product evaluation criteria that reflected their new understanding of the value of
integrated CASE tools to MidCo (see Table 2). An Evaluation Committee consisting of IS
managers and senior analysts was formed in 1989 to conduct a detailed review of three
major integrated CASE tools." Based on the evaluation criteria, the committee members
selected lEF' {Information Engineering Facility from Texas Instruments) and a hand-picked
project team was assembled to perform a pilot project. After a short but intensive pilot
study, the Evaluation Committee recommended that MidCo purchase lEF and proceed with
full-scale implementation of both IE and lEF across all IS division activities. In a formal
report in December 1989, the Evaluation Committee outlined the IS division's goals for full
implementation of IE and lEF, and issued a set of detailed implementation recommenda-
tions. In their report, the committee emphasized how IE reflected and reinforced the quality
principles practiced at MidCo:
IE and quality management have many things in common and are, in fact, mutually supportive of
one another. Both are founded on teamwork and a scientific approach based on da-
ta....Implementing the IE approach. ..would reinforce the quality management effort and further
strengthen the quality of systems development at MidCo.
- w*.
During 1990, each of the IS division's three application development groups initiated
projects using IE and lEF. Several consultants from Texas Instruments were on-site during
this first year to provide expertise, advice, and support with the implementation. Training
on lEF was conducted in small groups, with separate courses for each of the seven steps of
the lEF methodology (see Table 3). MidCo tried to have its employees trained as close as
possible to when they needed a specific skill, an approach the respondents referred to as
"just-in-time training. "■*
At the time of our second site visit (in late 1991), lEF was being used on eight
concurrent projects by the three application development groups. While use of lEF was not
mandatory, it was "highly encouraged" by senior IS managers. These managers allowed the
11
different application development groups to use IE and lEF in various and customized ways,
permitting them to deviate from the guidelines recommended by both the IE methodology
and the lEF tool. For example, in contrast to the recommended use of lEF which calls for
the derivation of a top-down enterprise-wide information model or Information Strategy
Plan (ISP), senior IS managers had decided not to require a top-down ISP for the
corporation at the outset. Similarly, most IS project managers did not insist that individual
business divisions create their own ISP before they embarked on the design and develop-
ment of a specific business system. Instead, each business division was permitted leeway to
conduct the ISP or to proceed directly to the next IE phase — Business Area Analysis
(BAA). TTie expectation was that divisions would return to complete an ISP after having
gained experience with using IE and lEF on single applications.
Table 3: Description of the Stages of Information Engineering
(Source: Texas Instruments, 1^90, Introduction to Information Engineering, pp. 3-4)
Information Strategy Planning (ISP) - Planners gain a broad view of the information needs of the
business. From this information, they create a blueprint for the future and subdivide the blueprint into
smaller segments^, , _^
Business Area Analysis (BAA) - Analysts examme a particular segment of the business called a
business area. They develop a detailed, conceptual model of this business area, based on its informa-
tion needs.
Business System Design (BSD) - Designers detail a business system within a particular business area.
They consider how the user will interact wilh the business system, without concerning themselves with
the target computing environment.
Technical Design (TD) - Designers tailor the result of BSD to a target computing environment. They
consider the hardware environment, operating system, teleprocessing monitor and database manage-
ment system.
Construction - Developers generate all the executable components of a system. These include
programs, databases, job control statements, screen formats, and transaction definitions. These pieces
enable an application system to run in the selected target environment.
Transition - Developers install a newly constaicted application system in a production environment.
This phased installation may involve replacing existing systems or portions of systems.
Production - The business realizes the full benefit of the application system. Its execution satisfies
specific business needs identified during the ISP.
12
The Nature of the Changes in Systems Development
MidCo's primary goal for investing in CASE tools was to adopt and implement the
principles of data-centered design, which IE embodied and lEF enabled. This shift from a
structured, process-centered systems development approach to a data-centered one can be
characterized as a radical change in systems development (Fichman and Kemerer, 1992;
Orhkowski, 1993). As might be expected, this radical innovation involved a number of
significant changes to the work of systems development. One IS manager commented on this
innovation by contrasting it to others she had experienced:
The change resulting from IE is the methodology, not just the automation... People didn't see a large
change with code generators, but with integrated-C'ASE — it changes the way you work.
Another IS manager noted that,
... when you talk about bringing about a major change such as CASE tools, you are really changing
the way people work.
We found evidence for three specific types of changes that were associated with the radical
innovation implemented by MidCo — changes in IS analysts' skills, changes in the role of
users on project teams, and changes in coordination across multiple project teams.
Many respondents commented that use of the CASE tools had changed their role from
application programmers to business analysts. Because the new IE-based systems
development process was more oriented toward business issues, a greater proportion of the
tasks performed during systems development focused on business analysis compared to more
traditional methodologies, including the previously-used Method/1. In addition, respondents
noted that the skills and knowledge they needed to develop systems with lEF no longer
covered areas such as programming, hardware details, and operating system specifics. For
example, respondents no longer needed their detailed knowledge of traditional programming
languages (e.g., COBOL) and database design techniques to be productive. Tlieir use of lEF
facilitated a greater focus on the business and more conceptual aspects of systems,
decreasing their prior preoccupation with technical matters.
13
( 'Ui\i\frr.% III jolc, iiiid skill'. ;tl'.() extended lo iIh- h .< i ;'|()ii|)'., because use of Ilv and IliF
li.irl iiK leased llic level ol ir.ei involveiiient on all ;.y:.teiii developiiieni leani.s. A new IS
poliry had hfcii iiii[)l'iiifii(cd as [lait ol (lir- d'-ploynicnl of II, aiirl IIJ- in llic IS flivisif)n;
It ■.ti[)iilal(d llial a iiiiiiiIm i ol iMr.jiii-,', iimt. ji.id to he si;Miilieantly involved dnrinj'; llie
analysis phases ol a pio)i( t, and thai tli<y h;id to lair ii-.pon silulity loi piojcc t deliverahles.
This cx|)anded and iiion- pai ti( ijjaloiy loli- alloidid tlir iiscis was deserilxd l)y one IS
mialyst as;
Now lliry |inr-t'i| are an iiilccral (uiil ol the (Icvcloinnctil cllort. '[Ii<-ir in[)iil into llir (l(V(|n[)tricnl
Mill';! he (iiii'.laiil and oiipniiij'. llicy inu'.t hi; dcdic al('(l full Imik'.
Sim h iiKieasi-d alliiilioii to liSdS ie|jre sciilcd a sipiiif'if aiil d(|)aifuie from prif)r systems
(levelopiiKiil ' IIdiI , ,uid < oim< idid with and I'lln iid ijic increased enipliasr •xjrM' placed
on enipowcini'iil and Icaimng in llie lesl ol (he oij;ani/alioii.
Pcspoiidcnts also iiolrd (hat pMijerl', ii siii)' II'. and IF.F bej'.an (o have a pailieularly
iiiti I diseiplinaiy and < in . . Iiiik tional ihai.iitii llnic was a I'lealei eiii|)hasis on
iiil(-)'ialin;' and ( odidiiiatin;' pio|(-(l planniii)' a( loss seveial business divisions diiiiii;', the
early stap.es of I'AA I Insc intcjM.ilmj' cHoits lypi( ally o((niicd in loint Applualion
I )(V(|(ipimiit ( I Al )) scs sion s, ,i in<( li.uii sni H( (iiiinicnded by tlic II iiiclhodoloj'y, where
biisiiMss M(|miiiiMrits arc idintificd by IS .ind nsci stall Anolhci new (ooidinatinj',
inechanisni was the ( k alion ol the infi iininlitin unliilri i lole, filled full tinie by an analyst
lioin l>ata Adiiiinistiation who assnnied le sponsibility loi ( (Kndinatin;' the data models of
all piojec (s, ensniiii)' ((insisleney aeioss liieni, niiniiiii/iii)' data lediiiidaney, and assnrin/»,
data ipiality
The l'a(c of Inipleiiieiiliiiji ( 'liaii^^ies in Systems Development
I he (iveiall I haiij'e III Midf d's sysfcms deve|(i|iiiieMt pi(p( (• ss (the sliilt fnmi a proCCSS-
(II Killed In ,1 data (ii Milled systems de ,i)"ii .ipjii i i.n h ) invnlved a series of changes, lieginning
with till' iiiiiMJ iiMpleiiieiii.iiKiii <i| || on ,i jnnited basis witliin Data Administration, and
then Its (III In .Kill aldii;-. with lid to the lesI ol the IS (li\ i sioii As is evident lioiii I able 4,
14
'I'iililf 4: liii|)k-iiu-ii(a(i()ii ol Kadiial I'rixc.s.s <.'liaii);i'.s in MidCo
back(;k()iini>
DAII-,
litiplcincnUUion ;iihI Use o\' Mfdiod/I structural .sys
tcins (Icvclopmcril tuctluuloloKy
i<m
Adoption of Quality M;uiageincnt I'l'ograui
\')H7
PROCESS CIIANCIC
DA'I'IC
Formation of Data Administration fiionp
1987
Adoption and im|)lcmcntatioii ol //'.' in Data Adminis
tration Group
I'M/
Adoption and limited ii'.c ol //.W in I);iia Adminisli;i
lion (jroup
l'»HH
Adoption and limited use of Tchm in IS Divimou
\')'M
Pilot Miidy ol II. I'
l<)K<>
Adoption of //^' and //:'/'' by whole IS iJiviMon
I'/ A)
Use of //•-•and //■;/'• in "llinl.tclhi" Divi'.ioir
lirst use of il.i' on ;i piojixl
1 I'irst use ol ISl'
\')'H)
Use of //i and HCl' in HM) Division;
f'irst use of II.I' on a project
lirst u;..: of ISI'
(none Nchrdulcd)
Use ol //■; ;in(l //■,/■ in I.oi'J'itics Division:
First um: ol III on a project
First use of ISF
\')'f7 (V lirdiilrd)
(',li;i(lc.(l (cll-, ii|iM';i-fi( ti;i( k)',i'iiiiiil cvciil;; to the [ifx cf,-, i |i;ifi)M •;;
thin shilt took ■,c7(i;)l y<;i/, ;ui(l 7/,r. not .\\i\< ,t\ii<\ ,il| ,ii mii'i- I Im- I', <Iiii < Iui .t.ilf d .md
MKiny oilier n-spondrnl'. < oii' nii'd tli,it tlif iiMivt- to f AM . v/.r. .ui rvoliili<ui, i.iIIh i ili.m
a revolution." Anotli<-[ r, ni;in;iv',cr siniilaily noted
Ilii') jlhc ciiari;/<; to II. ;iiul II. i| iei{Uifr'; tteKiriidoii'. .iiii'<iint% al |i;ili<'ti(e. llV, ;i loiij/ tilow
procc«n.,.l knew irom (l;iy one lli.it il w;if> ypiny, to l>c ri^lit ll juil tiikco ;i Utuif, llinv
MidC^o's ;/r;i(lii;d p;iec i,i implemi ntin;' f;idi( ;il ' li;in;'e mi'iiiIi' -uitly iiiIIim o^ cfj the ;'e||./,i|
15
experience of the change by the organization and its employees. For some respondents,
particularly those employees who had already been using IE for up to two years before lEF
was adopted, the implementation of the lEF tool was seen as a continuation of a change
already begun and therefore they were willing and able to embrace it relatively easily.
For the other IS employees, who had not been previously exposed to IE, the
implementation experience was moderated by the control they perceived over when and how
they would assimilate the IE methodology and lEF tool. Not required to assimilate both
changes immediately and in full, these employees were able to more gradually accommodate
the changes. Because IS managers had provided an opportunity for employees to adapt the
implementation of IE and lEF to their own schedules, the changes were not perceived as
overwhelming or threatening — a common response to radical changes in the workplace.
The general experience of the radical changes within MidCo appeared to be surprisingly
uneventful. A striking finding was the apparent absence of resistance by both IS employees
and users. While our interviews probed for evidence of resistance, disruption, frustration,
and unanticipated problems associated with the changes, we found no such data. In fact, the
reactions of our respondents was generally very positive. One IS manager who described the
CASE implementation as "far more successful than we expected," noted that most of the
project teams were eager to try out the IE methodology and lEF tool. As she put it, "people
are clamoring for it — people want it."
The one concern we detected from a few respondents was some skepticism. However,
even this was accompanied by a willingness to stay open-minded, and to wait and see if IE
and lEF delivered the promised benefits. One senior business manager commented that "we
are taking the benefits on a leap of faith right now," but indicated that he expected to
observe benefits in the near future. He noted that other managers in his division had
adopted a "wait-and-see attitude" toward the changes. This reaction reflects the gradual
implementation strategy adopted by MidCo in that it had permitted each business division
to implement the changes at their own pace rather than forcing them all to accept and
16
implement the changes immediately. The decision not to conduct an enterprise-wide or top-
down ISP for the whole business allowed each business division to control its own
implementation of IE and lEF, deciding when and whether to conduct an ISP and when to
focus on specific application areas so as to produce tangible system products. This decision
appears to have been appropriate for the MidCo organizational context, as a senior
executive explained that business managers would not be willing to wait for the completion
of a top-down ISP data model before requesting specific application systems.
Based on their first full year of experience using IE and lEF in the three application
development groups, respondents described their enthusiasm for continuing to develop
systems using the new approach. In addition, due to the greater emphasis on business
planning and analysis — which IE and lEF enable — some IS managers indicated that further
organizational changes were now possible. For example, several managers described that
some functions currently residing in the central IS group would be "dispersed to the
business divisions over the next five years." This general decentralization of IS to the
business divisions, enabled by the systems development changes of IE and lEF, had already
begun at the time of our second site visit. One IS application group — that supporting the
prominent and powerful R&D division — had been reorganized so that it was physically
located within the R&D division and reported to R&D management. IS managers
describing this transfer noted that IE and lEF had facilitated this change, because they
allowed a tighter alignment of IS and business interests, and promoted a closer working
relationship between IS and the R&D division.
DISCUSSION
Based on MidCo's experiences with implementing CASE tools, it appears that they had
implemented a radical change in their system development process, and that they hrd done
so gradually. Tlie pace of implementation we observed more closely resembled the episodic
pattern identified by Tyre and Orlikowski (1994) in that the change was implemented in
17
phases, rather than the rapid and revolutionary pattern advocated by Hammer (1990) and
others. But in contrast to Tyre and Orhkowski's phases which involved only incremental
changes, each of MidCo's phases represented a radical change in systems development when
compared to the existing practice of developing systems. Further, it appears that MidCo's
radical change had proceeded relatively smoothly, without the turbulence typically associated
with radical organizational changes. In particular, the implementation of 15 and lEF did not
generate active opposition from employees in either the IS or the business divisions. On the
contrary, these changes were enthusiastically received and appeared to be causing minimal
disruption in operations and morale.
TTie MidCo study suggests — in contrast to recommendations advocating rapid
implementation of radical change — that there may be conditions where a gradual or episodic
pace of implementing radical change may be effective. Our findings emphasize the
importance of not only distinguishing the pace of implementing change from the nature of
the change, but of understanding how they relate. Where the nature of a change refers to
what magnitude of change is intended or realized (radical versus incremental), the pace of
implementing change refers to how the change is being implemented, that is, the speed with
which it is introduced (rapid versus gradual). From this perspective, tlit nature and pace of
change are seen as conceptually distinct dimensions of change, that become related in the
implementation of any particular change. How these are to be related in any particular
change project is thus a choice that should be made by the change agents involved.
The distinction between the nature of change and pace of implementing change
essentially decouples the two dimensions, allowing us to imagine the possibility of
implementing radical (and incremental) changes rapidly or gradually. Table 5 shows the
separate dimensions of nature and pace of change, and uses this as a structure for mapping
this and other research which investigates the implementation of organizational and
technological change along these dimensions. In this table, we can see that both radical and
18
Table 5
The Nature and the Pace of Change:
Two Dimensions of Research on Organizational Change
Nature of Change
Radical
Incremental
PACE OF CHANGE
Gradual Rapid
Ettlie, 1986
Gallivan, Hofman &
Orlikowski, 1994
Liker, 1987
Orlikowski, 1993
Seeger, Lorsch &. Gibson,
1974
Mackay, 1990
Orlikowski, 1993
Tyre & Orlikowski,
1994
Kraut, Dumais & Koch,
1989
Orlikowski, 1992
incremental changes may be implemented gradually or rapidly. This begs the question: if
a rapid or gradual pace may be used to implement radical change, what are the conditions
under which a certain pace is suggested? Based on our study of MidCo and an examination
of the literature, we suggest that there are two key elements that may facilitate or inhibit
a gradual pace of implementation: characteristics of the organizational context and
characteristics of the technological innovation. We examine each in turn.
Characteristics of the Organizational Context
With respect to the organizational context, MidCo had certain structural and cultural
characteristics that appeared to contribute to the effectiveness of implementing radical
19
changes gradually. First, the company had a tradition of valuing investments in technology
that might not have immediate payoffs. Expectations in this research-oriented firm thus
reflected a willingness to invest time and resources to achieve long-term benefits. Second,
the corporate philosophy reflected a commitment to quality, empowerment, and learning.
As an executive observed, "we are in the learning business." The cultural norms and work
practices within IS similarly reflected Uiese sentiments, as is evident in the focus on
teamwork, user involvement, and empowering the business. Third, there was no immediate
crisis in systems development to compel MidCo to rush the implementation of IE and lEF.
The motivation to adopt radical changes in the absence of serious problems parallels the
motivation behind the company's adoption of Deming's quality management program — a
sense that things could be better. Fourth, the company was doing well financially and so had
sufficient slack resources to implement change slowly. It could thus afford to adopt a more
measured pace and to spend time on training, consulting, experimentation, and feedback.
Clearly these characteristics will not be present in the organizational context surrounding
all new technology adoptions, and hence the experiences at MidCo do not represent a
universal strategy for achieving radical change; however they do point to some possible ones.
In this light, it is instructive to compare MidCo's experience with that of another firm
implementing IE and lEF, as described by Orlikowski (1993) in her examination of a firm
called PCC. In particular, the experiences and outcomes around the radical change
experienced by MidCo differ substantially from those experienced by PCC. Differences in
the organizational conditions around PCC's change are worth recounting as they serve as
a useful contrast to those we detected at MidCo.
Like MidCo, PCC introduced IE and lEF into its systems development activities, and
like MidCo, this represented a radical change in PCC's process of systems development.
However, the pace of implementPtion adopted by PCC managers was rapid, unlike that at
MidCo. At PCC, both IE and lEF were introduced simultaneously, thus IS and business
personnel had to learn and assimilate the data modeling concepts of the new methodology
20
at the same time as they were learning to use lEF. PCC also initiated IE and lEF by
enforcing the execution of a top-down ISP for the entire business. This represented an
enormous effort for both IS and the business, because the ISP relied on design principles
that were unfamiliar to most of the participants, particularly the business users. Finally, the
IS division instituted a new policy of only developing systems in the sequence recommended
by the resulting top-down ISP. Thus, PCC's IS division changed the rules by which it
delivered service to the business divisions and it did so abruptly. Not surprisingly, these
changes precipitated strong resistance from business managers and users, which threatened
to undermine the entire change initiative. At MidCo, in contrast, the new rules for
delivering systems services to business divisions were implemented gradually, with much less
disruption.
This contrast between MidCo and PCC suggests that a significant benefit associated with
a gradual implementation of radical change may be that it is often experienced as more
palatable. Tliis may significantly reduce the level of user resistance to the change. When
combined with other aspects of the organizational context such as a nurturing and self-
developing culture, a resource munificence, and an orientation to innovation and
experimentation, these may add up to an effective set of conditions for implementing radical
changes over a longer period of time.
Characteristics of the Technological Innovation
Prior research on the management of technological innovation suggests that characteris-
tics of the innovation itself may also influence the pace of implementation, not just the
context into which it is being introduced. One such characteristic is the extent to which a
particular technological innovation can be subdivided into smaller components — a concept
that has been variously labeled divisibility (Rogers, 1962; Leonard-Barton, 1988), trialability
(Rogers, 1971), and reversibility (Walton, 1975). Leonard-Barton (1988) differentiates the
concept of divisibility into two subconstructs — modularization and individualization. Tlie
21
former allows for segmenting the innovation or the change program into discrete chunks,
while the latter allows the innovation to be implemented into parts of the organization in
sequence.
Examining the gradual implementation process at MidCo in terms of these concepts,
we see that it was both modularized and individualized. Table 4 shows that different
components of IE and lEF were implemented over time and the various divisions and
project teams chose to use these as appropriate. Within each application development
group, the adoption of IE and lEF represented radical innovations to software development,
because when compared to the previous systems development approaches in use, they were
"clear departures from existing practice" (Dewar and Dutton, 1986: 1423). Each implementa-
tion phase was thus still a radical change, not an incremental one. The fact that one group
preceded another in adopting the lEF tool for performing strategic systems planning did not
render the change an incremental one, since it did not reduce the scope of the required
change to a "minor improvement or simple adjustment in current technology" (Dewar and
Dutton, 1986:1423). Hence, contrary to the possible interpretation that MidCo had simply
achieved an overall radical change through a series of incremental changes, we believe that
MidCo was adopting a series of radical changes through gradually implv.menting them into
distinct work groups. Tlie radicalness (Damanpour, 1988) of changes in developers' work
processes, knowledge, and coordination efforts was not diminished by MidCo's phased
implementation tactics which were facilitated by the innovation's divisibility. The strategy
of decomposing a radical innovation into discrete phases for separate work groups
(individualization) or into separate components (modularization) does not necessarily
transform a radical change into a series of incremental ones.
Research suggests that the divisibility of an innovation increases the likelihood of more
effective implementation for three reasons. First, as Rousseau (1989:43) notes, introducing
changes "one by one.. .increases employee confidence in their abilities to learn and use new
systems." Hence, the users are more willing to participate in the change since the stakes are
22
reduced and the costs to them are decreased.
Second, divisibihty provides opportunities for experimenting with the innovation and
making changes to it. As Leonard-Barton (1988:613) notes, "Divisibility is an important
implementation characteristic because it allows trial of a new technology for the purposes
of feedback and learning." For example, Tyre and Orlikowski (1993, 1994) show how
discrete episodes of change — which they label "windows of opportunity — allowed users to
accumulate particular problems or desired enhancements to their technology or work
procedures until they were ready to make changes. Without this pacing of issues, users felt
too overwhelmed and too busy to take the time to fix all their problems at once. Likewise,
Leonard-Barton's (1988a) notion of cycles of mutual adaptation recognizes that when a
technology is first introduced, misalignments always exist between the technology and the
organization. Such misalignments cannot all be resolved up front, and it is only over time,
through iterative cycles of change that the technology and the organization can be aligned
with each other.
Third, users will be better able to assimilate the innovation, because they can implement
it in a piecemeal fashion and hence can control the pace of the changes they experience.
Leonard-Barton recommends that, where ."^.n innovation is modularizable, thrtt sponsors and
champions "allow user managers some control over the pace of change, by presenting the
potential for implementation in phases, rather than all at once" (1988:626).
These notions of windows of opportunity, cycles of mutual adaptation, and controlled
change suggest that significant benefits in learning, participation, and flexibility may be
afforded by a gradual pace, whereas such benefits may be forfeited in the rush to implement
rapidly. This clearly happened at MidCo, where the use of IE and lEF was encouraged but
not enforced from the top, and where divisions were allowed to adopt this software
development innovation at their own pace over a period of time rather than all at once.
With regard to the generality of the gradual approach to implementing radical change,
we recognize that not all innovations may be divisible to the degree observed at MidCo. In
23
evaluating the various strategies involved in divisibility, however, it is useful to consider
separately an innovation's modularization and its individualization. While not all radical
innovations may be modularizable, since, in some cases, the new processes, knowledge, and
structures are so interdependent that they must be implemented as a whole (e.g., the
paradigm shift associated with a radically new scientific theory), many more innovations can
be individualizable, that is, phased in into discrete work units or sites in sequence. Many
authors have, in fact, advocated such an implementation strategy to allow an organization
to learn from the implementation experiences of the early adopters of the radical change.
For example, Opper and Fersko- Weiss (1992) recommend a staged implementation of new
technology, using distinct phases of experimental and expanded pilot studies, where each
pilot draws on the previous one's experiences. Other researchers have described the benefits
of vicarious learning (Leonard-Barton, 1990:186) through which potential users of a new
technology can acquire the know-how and know-why of earlier adopters — either within the
same organization or externally (through product user groups).
Managerial Intentions
In this paper we have been considering the question of how to implement radical
organizational change. Implicit in this question is the assumption that there is an intention
by the stakeholders — usually managers — to accomplish radical change. Thus our focus is
specifically on the question of how to implement intended radical change. While there are
many instances where a series of small incremental changes can, when aggregated over an
extended period of time, result in a radical change (e.g., species differentiation [Gould,
1989] and meteorology [Gleick, 1987]), these are examples of unintended changes. We
certainly believe that unintended changes are inevitable whenever shifts occur in physical,
biological, or social systems. And sometimes the accumulation of quantitative shifts may at
some point transform an entity into a qualitatively different one (Oilman, 1971). However,
in the context of trying to understand how to manage organizational change, we are
24
concerned with change that can be planned, guided, and controlled— that is, intended
change. As a result, we have not, and cannot within the scope of this paper, consider the
question — how to implement unintended radical change.
In the case of MidCo, managers of the IS division clearly had intentions for the nature
of the change — wanting to radically change the way of developing systems and delivering
service to their clients. TTieir intentions for the pace of implementation reflected an
understanding of their organizational context. In particular, they realized that requiring
radical changes to be implemented all at once would run against the grain of MidCo's long-
standing participatory and learning-oriented culture. Hence, they encouraged the
involvement of the divisions in realizing the intended radical changes by allowing them to
design and control their own process for implementing and adopting the radical changes
represented by the IE methodology and IE CASE tools.
While MidCo's managers utilized their company's favorable conditions for gradually
implementing radical change, there certainly are conditions where pursuing such a gradual
pace would be counterindicated. In particular, where a company or department is facing a
crisis, whether an external competitive threat or an internal crisis of legitimation or
production, managers' intentions are focused on survival, and hence they are likely to
initiate a rapid implementation of radical change. Likewise, where a company or department
has a track record of not being able to sustain a change process over an extended period
of time, or where there is limited organizational capacity for change (Pettigrew, Ferlie and
McKee, 1992), managers may believe it is prudent to implement as much change as is
possible as quickly as possible. Under these conditions, managers' intentions for rapid
implementation would seem appropriate given that the opportunity to change anything later
may be lost as enthusiasm wanes, skepticism grows, resistance accumulates, resources are
reallocated, and champions are reassigned.
25
CONCLUSION
The research we reported in this paper drew on a field study to analyze one
implementation of a radical organizational change. We suggested that the pace of
implementing change (rapid versus gradual) should be distinguished, at least conceptually,
from the nature of change intended (radical versus incremental), and the two considered
as separate choices facing change agents. Recognizing this distinction is particularly valuable
as it affords researchers and practitioners a broader perspective from which to evaluate or
manage change processes. It allows researchers to explain, for example, why two apparently
similar technology implementations — the radical changes implemented in PCC and
MidCo — resulted in two quite different experiences and outcomes. It allows practitioners
to treat these two concepts as separate choices to consider when embarking on a change
program. An examination of the particular organizational and technological conditions offers
some guidance for deciding how a radical change would be more effectively implemented.
While our articulation of the concept of implementation pace extends understanding of
organizational change, there are limits to the current research. It is based on a single field
study, conducted at only two points in time, around a particular change, and the
implementation process was acknowledged by our respondents as still in progress.
Nevertheless, we believe that the findings of this research have some interesting implications
for researchers and offer new ways of thinking for practitioners.
Despite the common wisdom that radical change can only be implemented rapidly, we
suggest, on the contrary, that under certain conditions it may be implemented episodically.
Based on an analysis of the implementation of CASE tools in one organization, we found
that a gradual implementation pace was a useful strategy for achieving radical change in the
software development process. While more research is clearly needed to examine this
finding in other settings and with other technologies, we believe that this finding is insightful
as it suggests that there is more than one way to accomplish radical change. We outlined
a number of conditions: characteristics of the organizational context (such as a culture that
26
values continuous improvement, a strategy that invests over the long-term, an absence of
crises, and sufficient slack resources), and characteristics of the technological innovation
(such as divisibility) that may represent important indicators of the feasibility of a gradual
implementation pace. While these organizational and technological conditions require
further empirical exploration, they nevertheless can begin to guide change agents in
fashioning an appropriate implementation strategy lo accomplish intended radical change.
We believe that the findings and argument presented above represent a useful starting
framework for helping researchers and practitioners think about and evaluate the
implementation of intended radical change around new technology in organizations.
27
ENDNOTES
1. The business functions included in the umbrella group r.re Finance, Sales, Marketing,
and Human Resources. MidCo's three other IS departments handle technical IS
functions — data administration, technical support and operations.
2. The three integrated CASE tools reviewed were Arthur Andersen's Foundation,
Knowledgeware's lEW and Texas Instruments' lEF. The version of lEW available at
that time was a new release with more functionality than the version MidCo had
experimented with previously. Unlike its predecessor, the new release claimed to be
integrated and capable of supporting the entire system development life cycle.
3. The lEF CASE tools from Texas Instruments consist of a set of integrated software
routines for identifying business needs, designing, developing and maintaining computer
information systems. lEF also includes a central repository of standard data definitions
(or data dictionaiy). It is an integrated CASE technology, because it supports all the
phases of IS development, and the work generated in one phase is used in later phases.
lEF is strongly influenced by the IE methodology developed by James Martin (1990).
4. There was also an lEF overview course taught to MidCo's IS managers and many of the
business division managers, in order to familiarize them with the new systems
development process that would be used in the firm. In addition, some business users
were also trained when they were designated to participate on a specific IS project.
5. The Joint Application Design (JAD) process involves assembling a broad range of
representatives from user and IS groups, and collectively generating ideas, defining
requirements, and negotiating the specifications for system design (Davidson, 1993).
28
REFERENCES
Damanpour, F. "Innovation Type, Radicalness, and the Adoption Process," Communications
Research, 15, 1988, 545-567.
Davidson, E.J. "An Exploratory Study of Joint Application Design in Information Systems
Delivery," Proceedings of the 14ih International Conference on Information Systems, J.I.
DeGross, R.P. Bostrom, and D. Robey (Eds.), Orlando FL, 1993, 271-285.
Deming, W.E. Out of the Crisis. New York: Pantheon Books, 1962.
Dewar, R.D., and Dutton, J.E. "The Adoption of Radical and Incremental Innovations: An
Empirical Analysis," Management Science, 32, 1986, 1422-1433.
Ettlie, J.E. "Implementing Manufacturing Technology: Lessons from Experience," in D.
Davis (Ed.), Managing Technological Innovation, San Francisco: Jossey-Bass, 1986, 72-103.
Ettlie, J.E., Bridges, W., and O'Keefe, R. "Organization Strategy and Structural Differences
for Radical Versus Incremental Innovation," Management Science, 25, 1984, 682-695.
Fichman, R.G., and Kemerer, C.F. "Adoption of Software Engineering Process Innovations:
The Case of Object Orientation," Sloan Management Review, Winter 1993, 34(2), 7-23.
Fichman, R.G., and Kemerer, C.F. "Object-Oriented and Conventional Analysis and Design
Methodologies," IEEE Computer, October 1992, 22-39.
Gersick, C.J. "Revolutionary Change Theories: A Multilevel Exploration of the Punctuated
Equilibrium Paradigm," Academy of Management Review, 1991, 16, 10-36.
Glaser, B., and Strauss, A. The Discovery of Groimded Theory. Chicago: Aldine, 1967.
Gleick, J. Chaos: Making a New Science. New York, Penguin Books, 1987.
Gould, S.J. "Punctuated Equilibrium in Fact and Theory," Journal of Social Biological
Structure, 12, 1989, 117-136.
Greiner, L. "Resistance to Change During Restructuring," 7ot(r«a/ of Management Inqidry,
1992, 1, 61-65.
Hage, J., and Aiken, M. Social Change in Complex Organizations. New York: Random
House, 1970.
Hammer, M. "Reengineering Work: Don't Automate, Obliterate," Haivard Busines:' Review,
July-August, 1990, 68(4), 104-114.
Hammer, M., and Champy, J. Reengineering the Corporation: A Manifesto for Business
29
Revolution. New York: Harper Business Press, 1993.
Kanter, R.M. The Change Masters: Innovation and Entrepreneiirship in the American
Corporation. New York: Simon and Schuster, 1983.
Kraut, R.M., Dumais, S. and Koch, S. "Computerization, Productivity and QuaHty of Work-
Life," Communications of the ACM, 32, 1989, 220-238.
Leonard-Barton, D. "Implementing New Production Technologies: Exercises in Corporate
Learning," in M.A. von Glinow and S.A. Mohrman (Eds.), Managing Complexity in High
Technology Organizations, New York, Oxford University Press, Chapter 9, 169-187.
Leonard-Barton, D. "Implementation Characteristics of Organizational Innovations: Limits
and Opportunities for Management Strategies," Communications Research, 15, 1988, 603-
631.
Leonard-Barton, D. "Implementation as Mutual Adaptation of Technology and Oxg?in'\z?i-
tion," Research Policy, 17, 1988a, 251-267.
Liker, J.K., Roitman, D.B., and Roskies, E. "Changing Everything All at Once: Work Life
and Technological Change," Sloan Management Review, 28(4), 1987, 29-47.
Mackay, W. "Users and Customizable Software: A Co-Adaptive Phenomenon," Ph.D.
Thesis, MIT Sloan School of Management, Cambridge, MA., 1990.
Martin, J. Strategic Data Planning Methodologies. Englewood Cliffs, NJ: Prentice Hall,
1982.
Martin, J. Information Engineering. Englewood Cliffs, NJ: Prentice Hall, 1990.
Miles, M.B., and Huberman, A.M. Qualitative Data Analysis: An Expanded Sourcebook.
Thousand Oaks, CA.: Sage Publications, 1994.
Miller, D. "Evolution and Revolution: A Quantum View of Structural Change in
Oxg?in\s^i\ox\%," Journal of Management Studies, 19(2), 1982, 131-151.
Miller, D. and Friesen, P. "Structural Change and Performance: Quantum vs. Piecemeal-
incremental Approaches," /4fa^ewv f^/A/^AZ^^'cmen/ /f.'a/na/, 25, 1982, 867-892.
Miller, D. and Friesen, P. "Momentum and Revolution in Organisational Adaptation,"
Academy of Management Journal, 23, 1980,591-614.
Oilman, ^.Alienation. Cambridge, UK: Cambridge University Press, 1971.
Opper, S. and Fersko- Weiss, H. Technology for Teams: Enhancing Productivity in
Networked Organizations. New York: Van Nostrand Reinhold, 1992.
30
3 1060 OOfiMbEQl 1
Orlikowski, W.J. "CASE Tools as Organizational Change: Investing Incremental and
Radical Change in Systems Development," MIS Quarterly, 17, 1993, 309-340.
Orlikowski, W.J. "Learning from Notes: Organizational Issues in Groupware Implemen-
tation," Proceedings of the Conference on Computer Supported Cooperative Work, Toronto,
Canada, 1992, 362-369.
Pennings, J. "Information Technology in Production Organizations," International Studies
of Management and Organization, 17(4), 1988, 68-89.
Pettigrew, A., Ferlie, E., and McKee, L. Shaping Strategic Change. Newbury Park, CA.:
Sage Publications, 1992.
Quinn, J.B. "Managing Strategies Incrementally," Omega, 10, 1982, 613-627.
Quinn, J.B. Strategies for Change: Logical Incrementalism. Homewood, IL: Irwin, 1980.
Rogers, E.M. Diffusion of Innovations (2nd. ed.). New York: Free Press, 1983.
Rogers, E.M. Diffusion of Innovations. New York: Free Press, 1962.
Rogers, E.M. Communication of Innovations: A Cross-Cidlural Approach. New York:
Free Press, 1971.
Rousseau, D.M. "Managing the Change to an Automated Office: Lessons from Five
Case Studies," Office: Technology and People, 4, 1989: 31-52.
Seeger, J. A., Lorsch, J.W. and Gibson, C.F. First National City Bank Operating Group,
Cambridge, MA: Harvard Publishing, 19*7 i.
Sviokla, J.J. "Managing a Transformation Technology: A Field Study of the Introduction
of Profiling," Harvard Business School, Boston, MA, June, 1992.
Tushman, M.L., Newman, W.H., and Romanelli, E. "Convergence and Upheaval:
Managing the Unsteady Pace of Organizational Evolution," California Management
Review, 29(1), 1986, 29- 44.
Tushman, M.L., and Romanelli, E. 'Organizational Evolution: A Metamorphosis Model
of Convergence and Reorientation," in L.L. Cummings and B.M. Staw (Eds.), Research
in Organizational Behavior (7), Greenwich, CT: JAI Press, 1985, 171-222.
Tyre, M.J., and Orlikowski, W.J. "Windows of Opportunity: Temporal Patterns of
Technological Adaptation," Organization Science, 5, 1994, 98-118.
Tyre, M.J., and Orlikowski, W.J. "Exploiting Opportunities for Technological Improve-
ment in Organizations," Sloan Management Review, 35(1), Fall 1993, 13-26.
31
Van de Ven, A.H. "Managing the Process of Organizational Innovation," in G.P. Huber
and W.H. Click (Eds.) Changing and Redesigning Organizations, New York: Oxford
University Press, 1993, 269-294.
Walton, R.E. "Diffusion of New Work Structure: Explaining Why Success Didn't Take,"
Organizational Dynamics, 3(3), 1975, 3-22.
Yourdon, E., and Constantine, L.L. Structured Design. New York: Yourdon Press, 1978.
2!76 -■>
O i
32
Date Due
Lib-26-67