123-
jJUL 26
ASSIMILATING CASE TOOLS
IN ORGANIZATIONS:
AN EMPIRICAL STUDY OF THE
PROCESS AND CONTEXT OF
CASE TOOLS
Michael
Wanda
J.
Friesen
Orlikowski
E.
October 1989
CISR
Sloan
WP
WP
No. 199
No. 3123-90-CISR
Center for Information Systems Research
Massachusetts
Institute of
Technology
Sloan School of Management
77 Massachusetts Avenue
Cambridge, Massachusetts, 02139
1990
ASSIMILATING CASE TOOLS
IN ORGANIZATIONS:
AN EMPIRICAL STUDY OF THE
PROCESS AND CONTEXT OF
CASE TOOLS
Michael
Wanda
J.
E.
Friesen
Orlikowski
October 1989
CISR
Sloan
WP
WP
No. 199
No. 3123-90-CISR
©1989 Massachusetts
Institute of
Technology
Center for Information Systems Research
Sloan School of Management
Massachusetts Institute of Technology
&
ASSIMILATING CASE TOOLS IN ORGANIZATIONS:
An Empirical Study of the Process and Context of CASE Tools
ABSTRACT
This paper describes a study into
how CASE [Computer Aided
Software Engineering] tools are
deployed by information systems units within organizations. The study explored the process by
which
CASE
tools are assimilated
by organizations, and
how
this
process
is
influenced by various
organizational and technological factors. Case studies of eleven companies
single
CASE tool
were conducted, and
the findings
from
this investigation
who have adopted
were analyzed
in
a
terms
of the conceptual frameworks of innovation research. The data reveal that nominal amounts of time
and effort are spent on evaluating the
CASE
tools prior to their adoption,
and that as
organizational consequences of these tools are poorly apprehended. Further, a
factors facilitating and inhibiting the process of
CASE
tools assimilation
were
a result,
number of key
identified.
The
implications of these findings for research and practice are discussed, and specific
recommendations for managing the implementation of CASE
tools are
provided
1.
INTRODUCTION
The aim of the study reported
was
in this paper
(Computer Aided Software Engineering)
organizations.
tools in Information
While much has been written about
CASE
CASE
examine the deployment of
to systematically
tools, there
Systems
(IS) divisions of
appears to be
little
empirical
evidence to support the extravagant claims being made for these systems development aids. The
few studies
that
have been undertaken of the use of
focused on the features of the
utilization.
While these are
vacuum, but rather
CASE
tools, or
interesting issues,
in a social context.
And
CASE
on the performance outcomes accruing from
we need
to
remember
CASE
tools being
implemented and used
The purpose of our study was
implement and assimilate
number of different
of stages by which
in organizations?
IS organizations
to increase
CASE
tools.
CASE tools
and
are
accommodate
that questions about the
example,
to
CASE
tools
how
CASE
are
this
and manage these changes?
We examined the CASE tools implementation processes of
we
(i)
identified the sequence
implemented and assimilated into organizations,
inhibit this
(ii)
implementation and assimilation process, and
CASE
tools'
articulated
(iii)
gained
deployment. This paper
describes the study, and the implications for research and practice that stem from
is
in a
understanding of the process by which organizations
insight into the organizational consequences of
This paper
used
what changes are being occasioned by
organizations, and on the basis of the field data
the factors that facilitate
some
we propose
tools need to take account of organizational dimensions, for
new technology? and how should
a
that tools are not
their
the interaction of a technology with its organizational
context plays a significant role in shaping outcomes. Hence
use of
tools in organizations have typically
it.
organized as follows. Section 2 provides the groundwork for the study by discussing
and the prior research
research activities
we
that has
been undertaken on them. Section 3 explains the
pursued to investigate the process of
CASE tools implementation
in
eleven
organizations. Section 4 describes the data analysis and results, and section 5 provides
implications and recommendations.
The
article is
concluded
in section
some
6 with suggestions for
future research.
SETTING THE SCENE
2.1 CASE Tools
CASE tools mean many things
2.
commentators agree
that they
to
many
encompass
people. There
all
or
some
is
no well-accepted
definition, but
subset of the following features: for the front-
end conceptual stages of systems development, such as analysis assistance, data modeling
data dictionaries, text and diagram editors (known colloquially as upper
CASE); and
tools,
for the back-
end implementation stages of systems development, such as screen/report design
1
most
aids,
code
(known colloquially
generators, testing and debugging tools
Some CASE
Cooprider 1988; Rochester 1989].
explicit integration)
and sold as
CASE
as lower
CASE) [Henderson &
tools are bundled together (with or without
packages or
There
toolsets.
is
currendy a wide range of
CASE
tool products being offered in the
many
vendors), varying from stand-alone first-generation tools (e.g., code generators, or
market (over 100 products have been estimated from as
aids) to integrated, second-generation toolsets (e.g., tool environments with
diagramming
centralized data dictionaries).
Research
2.2 Prior
Little research
has been conducted into the use of
CASE
tools in organizations,
and none into the
process of deploying and assimilating the tools. Most of the general literature involves a discussion
of the potential of
CASE
and augment the quality of systems
tools to eliminate software backlogs
and the productivity of systems developers [Case 1985; Freedman 1986; Russell 1989; Stamps
1987]. While
some of
these benefits
detailed analyses of any actual
which
CASE
CASE
that result
is little
be realizable, most of the discussions do not provide
technology implementations. The mechanisms through
tools are to be successfully
not identified. There
changes
may
deployed so as to accomplish the promised benefits are
empirical data on the various organizational and systems development
from using automated means
to
develop information systems. The few available
discussions of this topic raise more questions than they answer [Loh
1989].
The paucity of research on
options,
what are the problems, and what are
next section
we
recommendations
3.
these issues
means
that little is
Nelson 1989; Rochester
understood about what are the
the implications, of deploying
describe a study that provides
some
CASE
and suggests
tools. In the
a
series of
in capabilities, size, scope, price, functionality,
computer
insight
for practitioners using, or contemplating investment in,
CASE tools.
RESEARCH STUDY
Given
the
tremendous diversity
requirements and education demands of
seems
futile.
A
CASE
tool products, a
standard survey across tools would
confounding effects to provide useful knowledge about
to restrict
our attention to a single
case studies that would examine
CASE
the
&
tool.
how
To maximize exposure
more advanced products,
CASE
comparison across different tools
embody
CASE
toolset product,
and
different organizations
to different facets of
too
much
variation, noise, and
tools in general.
to
Hence we decided
perform a series of comparative
implemented and assimilated
CASE tools, we
the
same
chose to focus on one of
a second-generation toolset that is integrated across multiple stages of
the systems
development
life-cycle: Information
produced by KnowledgeWare
is
3.1
Background on the
Inc.,
IEW
and was
EEW
Engineering Workbench (IEW). The
first
developed
in 1984.
toolset
1
toolset
The Information Engineering Workbench has two primary organizing
tools (whether for planning, analysis, design, or
"encyclopedia" (storing data descriptions); and
(ii)
principles:
(i)
programming) are linked
that the tools are
that all the
to a central
based on the concepts and
precepts of a systems development methodology, Information Engineering (IE) which was
developed by Martin and his colleagues [Martin
methodology
data,
hence
it
is
that information
&
has been termed a "data oriented" methodology as distinct from more traditional
provide automated support for
aspects of the systems
all
life
cycle,
IEW
from
set
of tools attempts to
strategic planning
code generation and maintenance [Desmond 1988]. The platforms on which
include microcomputer as well as mainframe computers.
units of the
CASE
3.2
We
EEW
tools base,
second behind Excelerator with
29%
EEW
KnowledgeWare has
product worldwide [Desmond 1988], and currently has
16%
down
can operate
sold over
8000
of the installed
market share [Gane 1988].
Sample
obtained a
list
of
EEW
to three years
who met
the following criteria:
company, a
diversity of industries,
customers from KnowledgeWare
substantial financial investment in
two
this
systems should revolve around the design of an organization's
systems development methodologies that are "process oriented." The
to
The premise of
Finkelstein 1982].
EEW, medium
to large sized
experience with EEW, and extensive use of the toolset across the system
cycle. All eleven of the
companies by industry,
companies we contacted agreed
size,
and extent of use with
EEW
to participate.
The
life
distribution of
are indicated in Tables
through
1
4.
Semi-structured interviews were conducted with IS directors or senior IS managers designated as
responsible for
EEW. Subsequent
conducted during which
comments and
we
clarification.
prior respondents
to these initial interviews, a
second round of data collection was
circulated transcripts of interviews to participants and requested their
During
this
second round the participants gave us feedback on
and updated us on other issues
that they thought relevant.
We
their
further
interviewed a number of key users from the participating companies in order to obtain an
alternative perspective
1
on
the implementation of
CASE tools in the companies.
While currently having the second largest share of the CASE tools market [Gane 1988], the future viability of
EEW seems certain given the recenUy announced marketing partnership between KnowledgeWare and IBM, the
purchase by IBM of a minority equity interest in KnowledgeWare, and the intention of KnowledgeWare to
interface with IBM's new CASE tool offering (a Repository product).
Table
1:
Distribution of
INDUSTRY TYPE
Companies by Industry
Table
3:
Length of time
MONTHS
IEW
used by Organizations
3.3
Research Questions
No existing model
or hypotheses of
an exploratory one.
of
CASE tools
specifically,
CASE
tools assimilation
and use are available, so our study
is
We wanted to probe a series of topics and issues regarding the implementation
with the participants. These topics and issues reflect prior research into
and the
literature
CASE tools
on systems development and implementation more generally. Our
research interests guided our discussion of topics with participants, ensuring our attention to issues
of implementation, consequences and the factors that seemed to promote or constrain the
successful deployment of
CASE
tools.
The interviews
thus addressed the following broad areas:
implementation process, organizational changes (including structural, performance, and
personnel), and technical issues. While an agenda informed our interviews, the data collection
process was sufficiently open-ended to allow for the discussion of other topics and issues. Given
the exploratory nature of our study,
we emphasize
that the results obtained
and discussed below
are impressionistic, and are to be understood as suggestive rather than as rigorous or definitive.
Follow-up research to refine the ideas presented here
4.
clearly
needed
in the future.
DATA ANALYSIS
4.1 Stage
I:
Searching for Patterns
We initially examined
the
is
the data
on content alone,
implementation process, and factors
articulated
some themes
to identify general
themes
that
seemed
related to
that facilitated or constrained this process.
across the companies,
we attempted
to
make some
data that had emerged. In this analysis and interpretation process
Having
sense of the patterns of
we found
the conceptual
apparatus of innovation research to be particularly useful. Adopting Rogers' [1983:22] notion of
"innovativeness"
we found
that the
companies we had investigated could be differentiated by
extent to which they had adopted and diffused the
While the innovation framework was
CASE
organizational innovativeness
we
tools within their units or organizations.
companies on
their "degree of
also had to be careful
which studies of
useful, simply ranking
innovativeness" was not particularly informative.
relied on, as
We
the
many have been
criticized for oversimplifying the
process of diffusion of innovations within organizations, and for inappropriately transferring
models and methods of innovativeness from
the individual to the organizational level [Rogers
1983:355).
Given our primary
interest in the process of
CASE
tools implementation,
we found
those
innovation studies that focused on the process of innovation to be most valuable, as these were
most compatible with our focus on how
We
were interested
in the
different organizations
process an organization engages in
implement the same
when
assimilating a
CASE
new
toolset.
innovation.
and on the attributes of organizations and innovations
that influence this assimilation.
concerned with identifying variables that discriminate between more and
organizations.
Thus we adopted
a process, as
opposed
Meyer
& Goes
&
1988; Rogers 1983; Rousseau 1989; Schein 1969],
were
less
less innovative
We examined
to a variance orientation.
number of innovation process frameworks [Ginzberg 1979; Kolb
We
a
Frohman 1970; Lucas 1981;
all
of which appear to extend
and elaborate Simon's [1960] three stage model of the decision-making process (intelligence
design
-
choice) to the level of organizational innovation.
specifically they detail the innovation process,
The frameworks
differ primarily in
whether they deal with innovation
human
action or
allow for non-rational (political and symbolic) action. The framework that seemed to best
data and predilections about organizational processes
which
was Meyer
&
how
or with
in general
technological innovation in particular, and whether they focus only on rational
-
our
fit
Goes' [1988] framework,
highly articulated, deals exclusively with technological innovation, and recognizes not
is
only economic and strategic aspects of innovation, but also social, cultural and political aspects.
Meyer
&
Goes [1988] framework of
articulated
the process of innovation assimilation
by Rogers [1983:361-366], but goes beyond
it
is that
based on that
by focusing not only on the innovation
process, but also on the factors that influence assimilation.
Goes' framework
is
The underlying premise of Meyer
&
innovations in general are seen to trigger a predictable sequence of
cognitive, social, and organizational events.
The framework
is
depicted in Table
5. It
should be
noted that the stages are presented as ideal types, hence the sequence and outcomes of innovation
adoption and assimilation can and typically do depart from
however, does provide a useful structure within which
Meyer
&
Goes [1988:901] elaborate
that three types
skill
(i)
model of technological innovation, suggesting
framework of the stages
attributes of innovations,
and training
is
needed
articulated in
in organizations,
Table
which include how risky the technology
to use the technology;
The framework,
begin to interpret empirical data.
of factors influence the process of innovation assimilation
that these factors operate within the
types are:
their general
to
this representation.
(ii)
5.
is,
The
and
three factor
or what level of
attributes of organizational contexts,
which
include the size of the organization, the complexity of the product/service delivered, and
characteristics of employees;
and
(iii)
attributes arising
from
the interaction of innovations
and
organizational contexts, which include the compatibility of the technology with the characteristics
of the employees, and the extent of managerial support for the technological innovation.
Table
5:
General Stages
[from Meyer
in the
& Goes
Assimilation of Technological Innovations
1988: 903]
KNOWLEDGE-AWARENESS STAGE
1
.
Apprehension: Individuals
2
.
Consideration: Individuals consider the innovation's
3
.
Discussion: Individuals engage
learn of an innovation's existence.
in
suitability.
conversations concerning adoption.
EVALUATION-CHOICE STAGE
4
.
Acquisition Proposal: Adoption of technology
5
.
Rational Evaluation: The proposed investment
proposed formally.
is
is
evaluated according to
functional and financial criteria.
6. Political-Strategic Evaluation: The proposed investment
according to political and strategic criteria.
is
evaluated
ADOPTION-IMPLEMENTATION STAGE
The technology
acquired but remains under
7
.
Trial:
8
.
Acceptance: The technology becomes well accepted and frequently used.
9
.
Expansion: The technology
is
second-generation model.
is
trial
evaluation.
expanded, upgraded, or replaced with a
4.2 Stage II: Searching for
Meaning
Using the framework of Meyer
&
Goes
[1988],
we
returned to the data, and analyzed and
categorized the interview transcripts searching specifically for the following references:
stage in the assimilation process followed;
-
factor influencing innovation assimilation, namely, attribute of the
toolset
All of the companies
we
and the organization.
CASE
studied, by virtue of having acquired
U.S. firms have not yet done so, 2 could be seen to be innovative.
was
in their assimilation processes.
assimilation which
we took
We
had ber n completed with the
IEW
CASE
we examined
this
IEW
toolset.
the
number of production systems
risks.
Of the remaining
more cautious
tools
eight companies, six
in their assimilation of
systems (one to four) with a few others
and reap
fall into
CASE
CASE
we
will call
examine
to assimilate
the patterns that
CASE
having five or more
them early assimilators,
their benefits, without taking
unnecessary
The
final
two companies are
IEW
yet,
part of the late
and being skeptical
tools into their operations. In the following sections
emerged from our data
as
only having completed a few production
assimilators group, 3 having completed no production systems with
and more reluctant
tools,
eleven companies
the deliberators group, as they are slower and
tools,
in progress.
Of the
years.
that
Adapting Rogers' [1983:248-251] innovation
adopter categories to the case of innovation assimilation,
CASE
they differed, however,
tools penetration in their systems
studied, three clearly stood out in their implementation of
they are eager to implement the
Where
two or three
toolset over the past
production systems completed with the
tools while the majority of
thus distinguished the companies on their degree of
to be the extent of
development operations. As a gauge of
we
toolset,
of the organizational context, and attribute of the interaction between the
attribute
CASE
CASE
in terms
we
of these categories of assimilators, with
respect to the stages of the assimilation process, and the factors that influenced this process.
Stages in the Assimilation Process of
Of
the eleven
CASE
innovations
companies we examined none followed exactly the nine substage process of
technological innovation assimilation, outlined in Table
later stages,
and seemed
CASE tools in
2
3
to be influenced
5.
Most of the differences occurred
in the
by managers' perceptions of the role to be played by
their organizations.
estimated that only some 2 percent of organizations in the U.S. have purchased
percent of the purchasers are continuing users of this innovation [Vitalari 1988].
It is
We decided not to employ Rogers [1983]
CASE
tools,
and
label "laggards" for this final group, to prevent confusion
that only
between
40
this
categorization of assimilation and his categorization of innovativeness, and also to avoid the unintended pejorative
connotation of the "laggards" label.
Knowledge-Awareness Stage:
In
most of the cases, the knowledge-awareness stage was followed as outlined, with one or two
senior information systems managers considering and discussing the viability of adopting
tools in their
company. Most of
the
managers appeared
and their contact with contemporaries
in other
to learn
of
CASE
tools
from the
CASE
trade press
companies. In one of the deliberators, a new
information systems manager was hired in from outside, and he brought with him knowledge of
and
interest in the
FEW
This boosted the assimilation process as the chief advocate of the
toolset.
innovation had prior experience with
it,
and could speak with authority about
its
likely effects
and
consequences.
Evaluation- Choice Stage:
The next
stage
was
typically not followed as outlined.
benchmarks comparing
CASE
tools with their current
None of
development
the
companies undertook
practices. In only
two of
the
companies, one from the early assimilators and one from the deliberators group, was a financial
evaluation completed, with costs and benefits formally analyzed.
Some
respondents cited difficulty
reason for not pursuing formal feasibility studies. That these
in assessing benefits as the
respondents did not also find costs difficult to assess reveals a lack of appreciation for the potential
impacts of
CASE
tools, an issue
the general finding that IS
we
return to in section 5. This underestimation
managers do not perceive deployment of
CASE
is
an indicator of
tools as a significant
technological innovation, certainly not significant enough to warrant a formal feasibility analysis,
the
mechanics of benefits assessment
aside.
One company
in the late assimilator
group had
attempted a costs-benefits analysis primarily for symbolic reasons to appease senior decisionmakers. The respondent from
this
company noted
companies
why
so
CASE
and particularly the benefits are so
was "a waste of time." The overwhelming motivation
difficult to calculate that the exercise
implementing
that the costs
for
tools appears to be the quality of systems development, with nine of the
citing this concern.
many companies
felt
Given
it
the difficulty of quantifying the notion of quality,
it
unnecessary to perform a financial evaluation of their
is
clear
CASE
innovations.
Functional and political-strategic considerations did, however, play a role in promoting investment
in
CASE
tools,
although these served more as rationalizations than as documentary evidence for
the need to innovate.
Managers
cited, as their reasons for
and length of the systems development
maintenance personnel, and the desire
None of
effort, the productivity
to enforce data
these rationales for adopting
adopting IEW, concern with the quality
CASE
10
of systems development and
modeling and improve data management.
tools however,
were formally documented or
quantified, and
seemed
depend
to
on rational evaluation than on dissatisfaction with the
less
existing state of affairs in systems development or concern about the future.
CASE tools
seemed
to be
functionally necessary
-
based on one or more of three types of perceptions of CASE
to reduce the
"...
amount of redundant data
shared data environment that met the needs of the corporation";
survival of the information systems unit
success factor; that
we need
-
"IS
management
company provides information
do
it
services to
and do
right
believes that
it
fast, if
its
we
company
customers]
can't
do
-
...
"... all
If
we
to invest in
tools:
(i)
our company to a
[CASE
it
tools] is a critical
lot
company"; or
we have
we
of ways
(iii)
as
information [the
is
can't change these systems with
with speed and quality, someone else
it
as
as politically important for the
for the business of our clients within the
strategically important for the success of the
is
(ii)
to bring
...
automate ourselves to stay competitive. There are a
to
compete with outside vendors
quality, that
The choice
is
going to."
Adopt on-Implementation
Stage:
i
Breakdowns and
were observed
short-cuts
in the third
and
the companies, an early assimilator, has fully accepted the
upgrade
their version of the
IEW
toolset with an
companies, the process of assimilation seems
Adopting units or organizations appear
have tended to implement
IEW
in
to
CASE
organization that there
is
In
most of
an extended phase of
be equivocal about widespread use of
only a few projects, or only one division.
three years after acquiring the innovation. Choice of pilot project
some companies choosing
innovation, and has started to
expanded version.
to be stuck in
only one of
final stage as well. First,
a critical system to pilot, reasoning
emerged
"The
trial
evaluation.
CASE
And
the other
tools,
this is
and
two
to
as a key decision, with
pilot project
has to prove to the
a great quality improvement, not necessarily just improved productivity in
a pilot project", while others preferred the less risky but, also potentially, less informative strategy
of piloting small and simple systems. The decision to pilot a
critical
system does not
reflect the
degree of assimilation of the company (two are from the early assimilator group, two from the
deliberators and one
from the
late assimilators groups), but
preferences, or their views of the importance of
who
CASE
may
reflect
managers' individual
tools. In the latter case, those
risk
managers
believe in the strategic importance of tools are anxious to test them on major projects, while
those deploying
CASE tools for more conventional reasons adopt them incrementally,
starting with
limited, routine systems.
An
important phase in this stage that emerged from the data, and that
Meyer
& Goes'
[1988] assimilation model (except
that of implementation.
By
this
we mean
in the
name of the
the decisions, strategies,
order to put the innovation into routine use in the organization.
11
As
is
not explicitly covered by
third stage; see Table 5), is
and
activities
engaged
in in
research on information systems
implementation has shown [Ginzberg 1979; Lucas 1981; Markus 1983; Rousseau 1989]
introducing
new information technology
into an organization
alternative strategies, involving multiple constituencies,
Rogers [1983:364-365]
in his original
implementation, suggesting
is
it
model of
is
a nontrivial endeavor, permitting
and generating conflicting perspectives.
the assimilation process does, however, include
constituted by the three phases of: restructuring, clarifying, and
routinizing. Restructuring involves the modification of the innovation to
change
the reciprocal
clarification, the
organization structure to
in the
meaning of
organizational practices stabilize around
routinized,
last
and
it
becomes
becomes
the innovation
as
it
it
&
clearer to the organization
will reveal
is
is
all
these three phases, and the most significant
final substages
of the third assimilation
and expansion, have not yet been experienced by any company. One company
moved
However
members, and
achieves wider use. Finally the innovation
implementation phase appeared to be restructuring. The
projects.
During
the innovation.
Goes' [1988] substage of acceptance. The eleven
companies we studied had not moved through
appears to have
the organization, and
fully integrated into the organization, losing its distinct identity. This
phase of routinization resembles Meyer
stage, acceptance
accommodate
fit
it is
into a
form of acceptance phase by mandating the use of
not clear
how much
whether the innovation
EEW on
all
new
acceptance the innovation has in reality, and only time
persists,
becoming routinized and commonplace, or whether
it
discontinued through not having sufficient support from organizational members.
Most of the eleven companies have embarked on some
of their
own
restructuring, both of the
were no "off-the-shelf IE methodologies
systems development and maintenance
IEW
that
life
toolset. In the
opinion of the respondents, there
provided adequate depth and coverage for the entire
cycle.
As
a result
most of the companies had developed
their
own
One
organization, in the late assimilators group, had adapted
of standards, procedures, and plans, that accompanied their use of
based on Yourdon
methodology
-
play this role.
The respondents
&
interacting with the
CASE
The primary
tools,
and
CASE
deliberators,
units, with
restructuring in the near future.
projects.
prior systems development
-
to
also reported that reciprocal, structural and procedural changes had
companies (one early assimilator, three
systems development
its
IEW on
Constantine's [1979] structured systems development
been initiated to accommodate the deployment of
their
tools and
organizations. All of the companies reported customizing the methodology,
information engineering (IE), that guides the
set
CASE
tools in their companies. Five of the
and one
late assimilator)
have reorganized
two companies (both deliberators) contemplating
reorganization involves the concentration of personnel
their distinction
12
from other systems personnel by
the
formation of a
developers
on
EW
We
to
found
new
structural unit. 4
who use EEW
form a
it
For example, some companies have grouped the applications
together, while others have grouped the personnel
who
support and train
staff unit.
interesting that of the seven
CASE
changes to accommodate
companies reporting current or proposed organizational
tools, early assimilators
were under-represented. 5 Early
assimilator companies have progressed the quickest through the assimilation process yet they
furthest behind in
intent
accommodating
to
CASE
on implementing the innovation and
contemplating organizational change.
innovation
needed
more slowly and
It is
tools.
possible that these early assimilators are so
It is
getting widespread acceptance that they spend less time
feasible that a
company or
deliberately, has the luxury to reflect
to integrate the innovation.
From
seem
unit that
is
assimilating an
on the organizational adjustments
discussions with the respondents
deliberate action of information systems managers, in structuring the
appears that the
it
deployment of
CASE
tools,
plays an important role in enacting their assimilation and shaping people's expectations.
The above has examined an
idealized
model of the innovation assimilation process
eleven companies attempting to implement the same innovation, the
appears to be useful
CASE
of
in identifying disjunctures
innovations
more time and
attention
and differences, and
is
IEW CASE
we
in the
see that in the assimilation
focused on the implementation stage, while less
this
process
is
5.
Factors influencing the Assimilation of
The innovation
The model
tools.
energy and resources are expended on formal evaluation. The appropriateness of
addressed in section
context of
literature has identified a
CASE
Innovations
number of organizational and technological
influence the process of innovation assimilation. In this section
we examine
factors that
those factors that
emerged from
the data obtained in our study. In discussing the factors that are associated with
implementing
CASE
[1988].
tools,
we
Hence we examine
will
employ
the
model of
factors proposed
by Meyer
&
Goes
the factors in terms of: attributes of innovations, attributes of
organizational contexts, and attributes of the interaction between innovations and contexts.
Attributes of
Meyer
CASE Innovations:
& Goes first identified the risk associated with use of the innovation as a negative influence
on the assimilation process. None of the companies we studied considered
4 In
5
this factor as significant
some organizations such groups have been labeled "Development Centers."
of two late assimilators, five out of six deliberate assimilators, and only one of the
One
had insututed or were about to iniuate organizational changes
13
in
response to
CASE
three early assimilators
tools.
adoption behavior, although one
in their
services]
was concerned with
the risk of decreasing the
company
not adopting
and provider of information
[an early assimilator
CASE
tools for fear of losing customers. Interestingly
morale of systems developers as a consequence of
CASE
considered a significant attribute of the innovation, despite the dissatisfaction of
systems personnel to
CASE
tools (see the discussion of IS personnel below).
managers we interviewed,
for the
that dissatisfaction
tools
many
It
was
not
information
appears, at least
by the systems development workforce
is
considered a personnel problem, and hence an attribute of the organizational context, rather than
something associated with or engendered by the technology.
The second
by Meyer
attribute articulated
as a relevant attribute of
CASE
& Goes
[1988], skill,
tools, in particular the nature
was invoked by many managers
and amount of training
developers and users need before they can interact usefully with IEW.
found
that those innovations that required relatively little skill
assimilated than other innovations. In our study
training
by outside vendors. Those companies
&
Meyer
that
systems
Goes [1988]
and training were more readily
we found concern
that established their
with the lack of available
own
internal training
appear to to be more satisfied with the rate and manner of transferring
IEW
programs
skills to their
personnel. Providing in-house training allows companies to retain control over the content, timing,
and frequency of courses.
It
them
also allows
methodologies, and to particular project teams.
An
customized IE
to tailor training to their
interesting result that
emerged was
that the best
education results were obtained from training entire project teams together. Such group training
apparently allows educators to target project-specific issues, and permits participants to learn about
CASE
tools in a relevant context, in contrast to being
reference to
The
exposed
to the innovation abstractly or with
&
[1988], observability, played an
some minor problem.
final innovation attribute identified
important role in the companies
the impact of
CASE tools on
we
by Meyer
studied.
We
Goes
interpreted observability in this context to
the performance and quality of systems
most systems development improvement
efforts.
development
None of the companies had
the targets of
Nine of the companies reported improvements
quality of systems development, particularly user satisfaction, while only
in performance.
-
mean
instituted
in
two noted improvements
measures of quality or user
satisfaction,
and
only one was tracking systems development productivity (via function point measures), so most of
the impact assessments
were based on perceptions. However
it
is
often the subjective impressions
rather than the objective results of an innovation that influence action. This
be operating in the companies
we
following early experiences with
CASE tools,
high across
all
phenomenon seems
studied, for despite the lack of measurable
improvements
the motivation to continue using this innovation
assimilator groups.
14
to
was
Attributes of the Organizational Context:
Some of Meyer
hospitals,
in
&
and hence
our sample was
may
Goes [1988] organizational context
One of the
will not be considered here.
size,
we could
so
not consider
its
be an interesting variable for future research.
were specific
factors
to their study
of
criteria for selecting the organizations
role in the assimilation process, although this
Some
other factors indicated by
Meyer
& Goes'
[1988] research such as market strategy, complexity of product/service, and personnel education
and tenure
may
also be appropriate.
unavailable in our study,
why and how
we had
these attribtues
The following discussion
are implemented.
We
to
may
Because information on these
attributes or their surrogates
exclude them from consideration. However,
be significant in section
the data to determine the significance of a
attributes that characterize the context
speculate on
6.
refers to the particular organizational context within
examined
we
was
CASE
which
tools
number of possible
around systems development, such as IS department
organization (centralized, decentralized, or mixed), size of IS department, type of information
processing (transactions, control, decision support,
to be significant influences of the process of
emerge
as
CASE
key organizational influences. The
but none of these appeared in our dataset
etc.),
tools assimilation.
first
to their
work and
their careers. Personnel
however, did
we term orientation of information
systems personnel. Prior research [Orlikowski 1988] has shown
personnel respond differentially to the deployment of
Two attributes
that
systems development
CASE tools depending on
their orientations
having a process orientation to systems development
work, tend to be more technically inclined and tend to have data processing career aspirations.
They
are
status,
much more
resistant to
CASE
innovations, perceiving these as threats to their
skills,
job security and work autonomy. Results oriented systems developers tend to have more
functional interests and career aspirations that are not localized in the data processing occupation.
They have
a closer affinity to users
and are
less threatened
status potentially displaced are not highly valued.
expectations.
More
traditional (usually
The
by
CASE innovations as the
more
and
findings from this study support these
implying older or more tenured) systems development
personnel or more technical personnel were reported to be reluctant to utilize
those personnel being
skills
analysis oriented were eager to try
them
CASE
tools, while
out. Further, all systems
developers were found to be somewhat resentful of the increased role played by users in projects.
As we
discuss below, the particular
CASE
tool
we examined, IEW,
facilitates greater user
participation in and responsibility for the front-end of projects. This shift in control
problematic for the systems developers to adjust
15
to.
is
typically
A
surprising result
adopting
CASE
was
the degTee of reluctance of
many systems development managers
we term
This led to the second organizational context factor, which
tools.
territorialism of the information systems department.
which systems developers and managers
By
this
we mean
to
the extent to
are protective of their traditional areas of control. Prior
research [Orlikowski 1988] had found project managers to be sufficiently concerned with
and "getting the system out the door"
efficiency, productivity
CASE
tools.
However some of
the
companies we examined were experiencing resistance
innovation from management ranks.
management has
been the group
really
a lot of older people
Just like our users,
One respondent
who have developed systems
we
resist
change."
explained, "The
that has not reacted to
It is
for years,
it
in
DP
[Data Processing]
we
and
think
we know how
between
this finding
companies examined, with the
latter
on software consulting projects, where project managers may be expected
traditional skills
managers
is
players
may
and familiar ways of doing things. Resistance
when
it
comes
and
it.
that
focusing only
innovation by IS
key operational
well thwart the entire innovation assimilation effort.
Both of Meyer
believe
CASE
do
and executing projects. Non-cooperation from these
to initiating
Attributes of the Interaction between
we
to the
to
to be less tied to
likely to restrict the assimilation process, for they are typically the
decision-makers
to the
[TEW] with open arms. You've got
likely that the discrepancy
of the prior research rests on the difference
of
to be enthusiastic supporters
& Goes'
two others
which they mean
examined how
Methodology
Inno vations and Organizational Context:
[1988] factors in this category proved relevant in our study. In addition,
are also significant. First, the
the
Meyer
congruence of the technology
We interpreted
specialization.
CASE
this to refer to the role
the methodology-in-use in the IS unit
is critical
to the use of the
CASE
& Goes'
by
attribute of compatibility,
to the existing pattern of
work and
of systems development methodology, and
is
compatible with that of the
innovation for
it
CASE
tools.
mediates between the division of
labor in the systems development process and the automated tools that facilitate task execution.
Thus we examined
the extent to
which companies had adapted
development work, as represented by
CASE
all
tools, in the case of
IEW,
their existing pattern of
their methodology-in-use, to
the IE methodology.
conform
systems
to that informing the
We found that all the early assimilators
and
but one of the deliberators had specifically adopted the IE methodology either before or at the
same time
as the acquisition of
IEW. For
methodology-in-use and that inherent
advantages of consistency
in
and developers. Both of the
these eight
in the
CASE
companies a compatibility between
tools
the
had been accomplished. This provided
terminology, standards, concepts, learning and familiarity of users
late assimilators
and one deliberator had deliberately chosen not
adopt the IE methodology, preferring to retain their
own
traditional (process-oriented)
methodologies. Maintaining two different methodologies (even though one
16
to
is
more
implicit, being
embodied
in the
CASE
tools) adds a conceptual
and
logistic
burden on systems development.
Inconsistencies in approaches, timing, milestones, deliverables, standards, terminology, and
assumptions need to be resolved, translated and communicated. This takes time, energy, and
coordination.
Meyer
&
senior
management
Goes' [1988] second interaction
facilitator
of the
advocacy. 6
CASE tools
management we mean both
we
follow
Meyer
&
factor,
CEO
advocacy,
is
similar to what
This factor appeared consistently in the data as an important
assimilation process in
all
of the companies
we examined. By
senior functional or user managers and the IS director.
Goes [1988:910]
personally support the acquisition of
in referring to (i) the extent to
CASE
tools
and
(ii)
CASE
CASE
tools (all three early assimilators, and
By advocacy,
which senior managers exert
the extent to
who made
companies reporting greater success
tools, those
senior
which senior managers
influence and expend resources during the assimilation process. Regardless of
decision to acquire the
we termed
the initial
in diffusing the
one deliberator) reported exceptionally high degrees
of senior management involvement and commitment to the innovation.
Two other
CASE
factors
emerged
innovation.
One
as relevant in the interaction
of these
involvement, while the other
emerged
as the
assimilation.
is
is
implementation strategy. In
this result,
it
is
assimilation process has warranted
companies
highly predicted by the implementation literature, user
most consistent finding across
Given
between organizational context and the
all the
companies, whatever
their state
of
CASE
interesting to note that the role of the user or client in the
little
attention
from the general innovation
in this study reported a significant increase in the extent of user
development following the use of
user involvement
this study,
CASE
tools.
More
interesting
is
literature. All
involvement
in
systems
the finding that this user
CASE tools, because users begin to pressure the IS
departments for greater use of the IEW CASE tools. Indeed, in some companies senior users have
started to be project managers on those projects employing CASE tools.
involvement augments the assimilation of
Users appear to be highly appreciative of the
CASE
known
IE parlance. This phase
as Business
Area Analysis (BAA)
in
tools'
requirements determination phase,
is
a conceptual, highly
functional analysis of the business requirements of a particular system, in terms that are easily
understood by the users. Users reported that the
of requirements definition, and
6
We
it
BAA
process had taken
much of the mystery
out
allowed an integrated view of the entire system before
&
Goes' [1988] term "advocacy" rather than the more common one of
it captures more of the championing activity required of senior
managers, than does the more passive endorsement implied by "commitment"
have deliberately adopted Meyer
"commitment" used
in the IS literature, as
17
development began. Further users reported increased completeness of requirements, decreased
ambiguity, more comprehensive documentation, and greater enthusiasm.
A
user noted that the
process involves the users in the front end and forces them to address the business problems,
A critical
while keeping the systems developers in focus about what the business needs are.
of greater user involvement
provides users with a level of control over systems
is that it
development they have typically not experienced before. One user commented about
the
first
my
time in
experience
at
[name of company], and
of data processing, that the users had the
However
benefit
first
say so as to
that's
how
BAA:
been twenty-six years
"It
was
and out
in
they wanted the system designed."
has not always been well received by the system developers or their
this shift in control
managers. One company, an early assimilator, was experiencing negative reactions from IS
managers about
the fast pace of
development fueled by the
such manager explained the resentment:
they need.
liked
As
it
We
when
don't like
there
was a
users appreciate
CASE
lot
BAA
systems development
the
all this
"We
think
user involvement.
CASE
we know
We
tools
and the user demand. One
better than the users
like to protect
our
do
territory.
what
as to
We
kind of
of mystery."
more, they become more insistent about the use of
efforts,
CASE
tools
on
their
hence pressuring the IS department to speed up their assimilation of
innovation. However, this influence
is
not only one-directional, for often the IS
directors play an important role in ensuring user involvement, hence facilitating user participation
and understanding of the innovation. One IS manager, responsible for integrating the
in
tools in his
company
explained: "If they [the users] are not involved, there
don't have time to put a good person on the project, the project
don't
know how many
projects, but
clients don't take interest or don't
As
it
is
is
cancelled.
not unreasonable to see that a project
is
no
CASE
project. If they
We have cancelled
I
cancelled because
is
have the time."
indicated above, the implementation stage
or Rogers [1983], and neither
is
is
not treated in any depth by
the particular strategy that
Meyer
& Goes [1988]
companies follow during
implementation. This attribute of the implementation stage however, proved to be a dominant
aspect of the process followed by companies in assimilating
CASE
innovations. In particular, the
presence of an explicit and phased implementation strategy appears to
CASE
had no
tools through systems
development operations. One of the companies, a
explicit implementation strategy,
strategies.
the ten companies.
One we
all
of the
late assimilator,
which may account for some of the delay
production system completed. The rest of the companies
implementation
facilitate the diffusion
in getting a
appeared to have explicit
Three different implementation strategies were identified among
refer to as the vertically
premised on implementing the
CASE
phased implementation
strategy,
tools incrementally via individual projects.
18
Another
which
is
strategy,
which we refer
the
to as the horizontally phased implementation strategy, is
CASE tools
incrementally stage by stage, across the development
final strategy
we
diffusing the
CASE
phased implementation
label the combination
tools in
phased strategy), and
strategies appear to
two
have merit
by
life
cycle of
all projects.
strategy, and this
by project
directions: incrementally project
laterally, stage
premised on implementing
stage, (as in the horizontally
in that they structure the diffusion
is
The
premised on
(as in the vertically
phased strategy). All these
of the innovation, generating a
decomposition logic and time-based plan to organize the implementation
activities.
We suggest that
the strategies need not be followed to the letter, as their value lies in their symbolic
and organizing
function rather than in their detailed prescriptions.
The
vertically
phased strategy was by
companies. For each project
companies adopting
the
CASE approach,
CASE
initiated, the
this strategy started
most prevalent, detected among eight of the
far the
tools are used during the entire life cycle.
with one or two pilot projects to demonstrate viability of
then followed this with the vertically phased strategy whereby an increasing
proportion of the systems development projects use
systems development projects (see Figure
point where 100 percent of
assimilator
is at
the
The
its
until
One company, an
1).
new development
70 percent mark. The
CASE
rest
projects use
of the companies
it
becomes
the standard for
early assimilator,
CASE
we
is
all
already at the
tools, while another early
studied displayed
much lower
rates of diffusion.
An
advantage of the vertically phased implementation strategy
learning curve,
making adjustments
to their
the first projects can be used
is,
horizontally
CASE
CASE
tools projects.
Another advantage
system developers gaining expertise with the
on subsequent
experience they gained on prior development
The
companies can exploit the
methodology and development standards and
procedures as a result of lessons learnt on prior
development of critical mass. That
is that
projects. This allows project
CASE
is
tools
the
on
teams to leverage the
efforts.
phased strategy was evident
in only
one company, a
tools are introduced functionally, first the analysis
design workbench across projects, and so on (see Figure
late assimilator.
workbench across
1).
CASE
Here the
projects, then the
tools are thus not being
introduced in an integrated fashion, rather particular tools are being brought in one by one to be
used in combination with existing manual methods. Eventually
implemented and the advantages of an integrated
adopted
this strategy is
system has yet been
one of the
built with
19
the phase tools will have been
toolset can be derived.
late assimilators.
CASE tools.
all
The company which has
Progress has been slow, and no production
Figure
1:
Implementation Strategies
Systems
Development
Life Cycle
System Development Projects
2
3
4
Requirements
Definition
System
Design
Construction
Installation
Maintenance
v///)/////////A^^^^
5
6
N
The advantages of
the horizontally phased strategy is that
it
allows the implementation of the
innovation in conceptual chunks. Rather than inundating system developers with a whole
approach to the entire development
familiarity with
cycle, this approach allows developers to gain expertise
one piece of the innovation
experienced with a
it
life
tool, is the
diffuses the innovation to
system developers
who
developers
at the
same
time.
gain exclusive experience with
and experience of a few developers,
encourage resentment and resistance from the
maintenance work, and
activities.
The
who
rest
It
CASE
automated development projects. The "crack team" approach
that the expertise
all
is
does not create an
tools
and
system developers are
The other advantage of this approach
next one implemented.
all
Only when
at a time.
new
group of
elite
and then tend
to
is that
dominate
to innovation diffusion is efficient, in
highly leveraged.
of the developers
who
It
may however
get left with the
perceive themselves as no longer in the mainstream of development
horizontally phased strategy can help to avoid this potential
human
resource
problem.
The combination phased strategy was observed
strategy the requirements definition stage of the EE
CASE
projects incrementally adopting the
CASE innovation,
the
The combination phased
methodology (BAA)
BAA,
BAA
users get so excited by the
years, while
Summary
one aspect
phase
most
the
is
still
visible
CASE tools, for as
BAA process that they
making
the
greatly increases user enthusiasm and
It
and most relevant to the
company using
the
users.
It
increases
this strategy reported, the
spreading positive information about the
start
company has completed approximately 70 BAA's
same
in the
relative progress as other early assimilators in the
implementation of CASE tools in the entire development
4.3
projects,
for the up-front requirements determination activities.
innovation throughout the company. The
two
all
strategy thus gains the advantages of the vertically phased strategy, as
pressure from users to diffuse the
past
used for
tools over time, but all projects are adopting
well as that of the horizontally phased strategy.
involvement, for the
is
this
EW tools during development or not. Thus not only are individual
whether these will use the
of the
one company, an early assimilator. In
at
life
cycle.
of Results
Based on the detailed findings discussed above,
the process of assimilation of
CASE
innovations
can be seen to mirror that of other innovations, except with different emphases. Assimilation of
CASE tools appears to involve more
While
this is
time in the implementation stage, with less formal evaluation.
what companies are doing
procedure. In the following section
potential impact of their
CASE
we
not clear that this necessarily
it is
will argue that
innovation, and that
21
is
the appropriate
companies may be underestimating the
more
careful evaluation and weighing of
consequences
may
be in order. Table 6 summarizes the factors that emerged from our case studies
as important attributes influencing the assimilation process of
that this is a preliminary
Table
6:
innovations.
We emphasize
model, whose elaboration and verification awaits future research.
Factors influencing the Assimilation of
[adapted from
CASE
Meyer
& Goes
CASE
Innovations
1988:908]
ATTRIBUTES OF CASE INNOVATIONS
Skill/Training: Extent of
( - )
(
+
or specialized training required.
skill
Observability: Extent of perceived impact on systems development quality
)
and performance.
ATTRIBUTES OF ORGANIZATIONAL CONTEXT
Orientation of IS Personnel: Extent to which systems developers are
(-)
process-oriented and
commined
to data processing careers.
Territorialism of IS Department: Extent to which systems developers and
(-)
managers
are protective of their traditional areas of control.
CASE INNOVATION-CONTEXT ATTRIBUTES
(
+
Senior
)
Management Advocacy:
personal support, and
(
+
that inherent in the
(
(
to
)
.
the methodology-in-use
to
consistent with
which users are involved and directing
systems development projects utilizing
CASE tools.
Implementation Strategy: Extent
which an
is
to
explicit
and phased
employed.
IMPLICATIONS OF FINDINGS AND RECOMMENDATIONS
In this section
we
attempt to translate some of the specific findings into more general terms, and
propose some of the implications of our study for practice.
tentative
in
is
CASE tools.
implementation strategy
5
which
User Involvement: Extent
+)
+
commitment of resources.
Methodology: Extent
)
Extent of senior managers influence,
two
We caution that these interpretations are
and based on our exploratory analysis of data from a limited sample. The implications
are
and are more general, while
the
parts, the first set refer to the assimilation process itself
second refer to the factors
that
may
influence the success of the process and are
particular organizational contexts.
22
more
specific to
5.1
CASE
Recommendations on the
In the discussion of results
we
Tools Assimilation Process
noted that in distinction to other innovation processes, the process
followed by companies assimilating
CASE
tools
seems
to
be focused on implementation with
attention being paid to the evaluation phase. Just as the systems
less
development community
is
beginning to accept the need to spend more time and energy on the front-end aspects of systems,
so
we recommend
tools,
that potential adopters of
CASE
tools
spend more time up-front evaluating the
determining their compatibility with existing methodological, structural and cultural
characteristics of the organization.
tools can
and do interact with
a major information system
all
As
a
major innovation, and as
these dimensions.
Thus we suggest
whose successful implementation
that
will
CASE
shown,
this study has
CASE tools
need careful
be treated as
justification,
planning, user involvement and training.
We
suggest that the real intended and unintended consequences of integrated
sufficiently substantial that treating
most cases.
CASE
intention
to substantially alter
is
tools are premised
Nunamaker 1988; Orlikowski
Little attention
them
seems
on
as significant organizational interventions
the automation of systems
development
many
warranted
in
activities; their
&
1988]. Ignoring their innovative aspects ignores their very essence.
to be paid to the costs
and benefits of CASE
disadvantages within the particular organizational context.
the
is
tools are
systems development and maintenance processes [Norman
tools. Difficulty in quantifying
them should not preclude considering them and carefully weighing
unaware of
CASE
their
advantages and
Many of the companies
intangible costs that are often associated with
CASE
tools.
studied
The
seemed
costs are not
only those of purchasing the software, developing training programs, and educating
all
the
systems developers. There are also organizational costs such as restructuring the IS organization:
possible declining morale of systems developers
tools;
who may
feel threatened
and alienated by
CASE
changing career paths and evaluation mechanisms to accommodate changed jobs and
expectations of systems developers; and introducing a
new methodology and new
ensure compatibility with the underlying philosophy of the
recommendation
is that
contemplating investing
organizations that
may
CASE
the activities of evaluation be taken
in
CASE tools
facilitate
more
toolset.
standards to
Our general process
seriously,
and
that
managers
spend time carefully evaluating the particular factors
or constrain the
CASE implementation process
in their
(see below).
We also recommend that companies consider organizational restructuring to accomodate the CASE
tools.
The accommodation of organizations
of reasons.
It
to an innovation has significant benefits for a
expedites the introduction and use of the
CASE
tools
by structurally concentrating
expertise, committing resources, and facilitating assistance and training. Further,
23
number
it
allows the
organization to establish appropriate policies, standards, and practices, hence smoothing the
assimilation of the innovation into the organization. This procedural accommodation, while
instrumental,
is
also useful motivationally, forcing deliberation
employed, and focusing energy and attention on
possibly most significantly,
organizational
members
organization to utilize
a relationship
it.
it
is
its
on how the innovation
potential use and consequences. Finally, and
useful symbolically, for
it
sends a powerful message to
that this innovation is sufficiently significant that
The innovation
is
between organizational accommodation
is
"success" of
this. It is,
5.2
CASE
We suspect that there is
and "success" of the
understood to be more than merely quick
alterations. In this exploratory study
tools assimilation,
warrants modifying the
to the innovation
and ambiguity
assimilation, for speedy innovation can bring disruption, insecurity,
tempered by structural
it
given credibility and legitimacy.
assimilation process. Success in this regard
it
was not possible
if
these are not
to determine the
and the role of organizational restructuring
in facilitating
however, an important topic for future research.
Recommendations on Factors
we
In section 4.2
identified
that Influence the Assimilation Process
and discussed eight factors (presented
in
Table 6) that were found
our study to influence, either positively or negatively, the process of assimilating
organizations.
manipulated
We now
re-examine these factors more practically,
to obtain a desired assimilation result. In
is critical
within a particular
company
in
our discussion
factors identified above, six are critical to the assimilation process.
these
will be
terms of
we
CASE
how
in
tools in
they can be
argue that of the eight
The extent
to
which each of
varies, of course, as different factors will be
more or
less critical in different organizational contexts.
Thus, before an organization can perform an effective evaluation of
CASE
tools, a careful
CASE tools are in order. Managers need to
which CASE tools will be deployed, and the
assessment of the organizational context and potential
have a good sense of the conditions under
circumstances within which they will operate, to be able to assess the potential success or impact
of CASE tools in their organization. Having understood the organizational conditions, practitioners
should assess which of the factors
critical in their
environment for the assimilation of CASE
Each of the
CASE
context can be engineered to create a conducive
tools.
factors can be understood to either promote, constrain or be neutral to the success of a
tools assimilation process.
development methodology and
For example, we argue
that of the tools
can
incompatibility appears to be neutral as far as success
to operate in
opposing ways,
that
is,
either
is
that compatibility
between the systems
facilitate the assimilation process,
while
concerned. Other factors however, appear
promoting the assimilation process or constraining
24
it.
For example, the presence of senior managers' advocacy may be
while
the
its
absence could be a significant inhibitor.
workings of these factors
critical to facilitating assimilation,
We believe that practitioners need to understand
in the assimilation
process generally, and in their particular
organizational contexts specifically. Such understanding should allow
the influence of those factors that faciliate successful assimilation of
them
to realize or
augment
CASE tools, while minimizing
or eliminating the effect of those factors that constrain successful assimilation of
CASE
tools.
Table 7 presents a summary of these factors, and the direction of their influence.
Table
7:
Factors affecting the Successful Assimilation of
FACTOR
Facilitating Successful
CASE Assimilation
IS Personnel
System developers are process
oriented and seek technical
data processing careers
is not protective of its
sharing responsibility with
IS unit
turf;
and relinquishing control
Management
Advocacy
IS unit is protective of its turf;
retaining responsibility and
control vis-a-vis users
to users
Senior Managers champion CASE
tools, expending personal effort,
influence, and resources
Senior
tools
Constraining Successful
CASE Assimilation
System developers are result
oriented and seek functional
or analysis careers
IS Culture
CASE
Senior Managers do not support
CASE tools, nor commit time
and resources
to
them
Methodology
Methodology-in-use and that of
CASE tools are compatible
Indifferent
User Involvement
Users are actively involved and
even directing systems projects
Indifferent
Implementation Strategy
Implementation
and incremental
Indifferent
The following
are our
recommendations
is explicit,
for assessing
phased
and dealing with these
factors.
IS Personnel Orientation
CASE tools potentially disrupt the way
in
which system developers work, changing
task requirements, and threatening their job security.
particularly those
who have
an investment
Many system
in their technical
25
their skill
and
developers react defensively,
knowledge and experience, and who
derive satisfaction from the technical activity of building systems. Resistance from system
developers can be handled in a number of ways.
option to
move
into
expectation here
more
is that
and interact with
is to
give system developers the
technical work, such as tools support or database maintenance.
self-selection will guarantee that process-oriented types will
applications development, while those
tools
One approach
users.
more functionally oriented
Another approach
is
to
will
move
remain to use the
The
out of
CASE
change the career paths and expectations
within the systems development unit. Developers will then realize that to have successful careers in
become
the firm, they will have to
technical wizardry.
Those who
analysis-oriented, be users of tools, and forego images of
change
are not comfortable with this
in orientation
can seek careers
elsewhere, but at least they are informed that their prior expectations and experiences are no longer
appropriate guidelines for success in this fiim Their choice
"adapt or leave."
is theirs:
CASE
This approach needs to be coupled with strong IS management support for the
these are perceived to be an uncertain strategy, developers are unlikely to
change.
One
IS
manager commented: "They
rookies again, because they
them.
When
[the IS personnel] are willing to
know management
really
wants
it,
and
the professional sees that the boss understands that
going to take some pain, then they will do
it."
commit
will stick
it is
...
tools, for if
to an orientation
almost become
by them and reward
going to take a year, that
it
is
This approach clearly depends on the availability of
education and training courses, and on management allowing for the training time, the learning
curve, and the readjustment problems that inevitably ensue.
One company
normal training courses, instituted an information campaign whereby
has, in addition to
CASE
tools
implications are explained at a general level to system developers and users. This tactic
dispel
some of the rumors and misinformation
that typically
accompany a controversial
and
may
their
help to
innovation.
Culture of Systems Development
This factor concerns the extent to which the systems developers and managers are willing to
relinquish or at least share control and responsibility for systems with users.
Many companies
reported a deeply rooted territorialism within the IS culture, which serves as a critical barrier to
allowing users to take responsibility for systems. For those
comprehensive and accurate requirements definitions
code generation), the lack of user involvement
the organization.
efforts, not all
While we believe
CASE
tools
and not
(to drive
CASE
depend on
subsequent screen/report design and
will inhibit their successful use
that users should be involved in all
all
tools that
and assimilation
in
systems development
organizations operate under this premise. However, for
those organizations that want to encourage shared responsibility, and where turf lines have been
carefully delineated in the past, cultural change can be encouraged through education, joint task
forces at multiple levels, and
management advocacy of the changed work norms.
26
Methodology
We believe that the relationship between a well-articulated systems development methodology and
a set of
CASE
tools should be a mutually reinforcing one. That
is,
the
methodology should inform
the assumptions and conceptual structure of the tools, so that they operate consistently, in an
integrated fashion, and in concert according to
some common
should enforce the logic and assumptions of the methodology
to standards),
logic.
On
through ensuring compliance
(e.g.,
and provide automated means to support the labor intensive
methodology. Given
this
methodology-in-use
in
symbiotic relationship,
it
is
the other hand, the tools
activities required
by the
clear that there are advantages to having the
an organization's systems development practices be compatible with the
methodology underlying
a set of
CASE
tools. Interactions
between these methodologies
will be
transparent, and there will be less training requirements and less need to enforce different
standards. These advantages can decrease the development times, as there
is
no need
to translate
between different world views. One systems developer commented about the ease of
among
the
development
stages:
"The programming was
translation process of the design deliverables
We recommend that,
like falling off a log.
attain consistency
the methodology-in-use in their IS organizations. This will
conform
reflect the
methodology of the
to the existing methodolgy-in-use, or
CASE
tools adopted.
action and needs to be carefully justified.
methodology
(for
example,
if
It
really
was a mirror
..."
where possible, companies
tools that
It
transition
may
a data-oriented
The
mean
between
their
CASE
tools
either acquiring a set of
and
CASE
changing the methodology-in-use
latter
approach
is
clearly the
more
to
radical
be an opportunity to adopt a more appropriate
methodology
is
database architecture of the organization), on the other hand
it
seen as more suitable to the
may
new
be disruptive and expensive
(provoking resistance and lowering morale).
Senior
Management Advocacy
With regards
to senior
management advocacy our contention
organizational innovation, managerial
condition for successful implementation.
commitment
It is
is a
is that
as with any major
necessary (although not sufficient)
clearly an important facilitator of success, in that
it
can expedite the assimilation of a new endeavor through motivational as well as financial and
institutional resources.
We believe that its presence is critical, and where it is unavailable the CASE
assimilation process will be problematic and outcomes will be uncertain. Thus, if senior managers
do not advocate an innovation,
this
can serve as a significant constraint on successful assimilation.
27
User Involvement
The
role of users in the use of
CASE
assimilation in
IEW CASE
of the
all
tools
we
The
of this interaction
investigated, as they encourage and
it
we
depend on
is
a consequence
significant
amounts of
suspect that user pressure on the IS unit can be an important
set
of
CASE
on
phase can be used without
less as all the
BAA
and direction of the
their participation
the capabilities of the
system characteristics
finally put control of the
finally able to exert influence
much
we examined. Some
as well as a facilitator of
tools are deployed in an
CASE
users in our study felt that one of the most important implications of the
innovation was that
BAA
was an important outcome
manner and speed with which any
influence on the
Through
tools
of the companies
user participation. However,
organization.
CASE
DEW.
how
their
hands of the users.
phase of the IE methodology, users were
systems turned out. While the IE methodology with
CASE tools, we
In those
in the
found that the
BAA's were
greatly facilitated by
companies using IE before IEW, enthusiasm with
information being generated had to be recorded manually.
BAA
systems. While
have greatly facilitated
we
believe
it
is
this activity
drawing on user participation, we do recommend
active
engagement by users
in
and given users a meaningful voice
possible to implement
CASE
that IS
was
The tediousness and
error-prone nature of this endeavor served to discourage extensive emphasis on this phase.
IEW CASE tools
its
The
in their
tools in organizations without
managers encourage and expedite the
systems development as
much
as possible.
Not only
will
responsibility for systems be shared and the quality of systems should improve, but the use and
assimilation of
CASE tools
should be promoted.
Implementation Strategy
In the section
above we described three kinds of implementation strategy
companies displayed.
We
that our
sample of
suggest that which implementation strategy (vertically phased,
horizontally phased, or combination phased)
is
adopted
is
less important than that
some
explicit
strategy be followed. Carefully articulating the manner, timing, and phases of diffusing the
tools structures the
tools.
It
way
in
which people, both systems developers and
users, perceive
also serves to organize training activities and creates the impression that the
systematic about
its
CASE
and use the
company
is
adoption of the innovation. Along with articulating, choosing and following an
implementation strategy, organizations will need to customize the methodology and the use of
CASE tools to reflect their specific
be drawn up to specify changes
contexts. Standards, procedures, controls,
in deliverables,
and policies have
time-frames, and expectations, as well as to clearly
delineate the role to be played by the automated aids, the system developers, and the users.
tools
change the ground on which systems are
communicated
to
to realize their benefits.
28
built,
CASE
and these changes must be formalized and
6.
CONCLUSION
There have been few previous studies of the deployment of
CASE
tools,
and even fewer of the
processes by which these tools are assimilated into organizations. In the study reported here,
CASE
found a process of assimilating the
other innovations.
We
substantially, the process of assimilation.
that
found with
factors that appear to influence,
sometimes
tools that differed in
number of
also identified a
emphasis from
we
We believe that the articulation of these factors, and an
understanding of their role in facilitating and constraining successful assimilation, are useful to
practitioners
The study
who
are, or are
also has
considering implementing,
some implications
CASE tools in
for future research. First, the factors identified in Table 7,
and their expected influence on the process of
CASE
assimilation
extensive verification and application in other settings. Further
there
was
their organizations.
may
insufficient information in this study
many
exploratory and needs
is
potential factors for
which
well be relevant influences on the assimilation
process. These need to be investigated. For example, one of the criteria for selecting the
organizations in our sample
This
may be
was
size,
so
we
could not consider
its
role in the assimilation process.
an interesting variable for future research, as might
CEO
(and even CIO) tenure,
education, and attitude towards innovation. Market strategy of the organization
relevant as the concern in this study
was
the assimilation of
CASE tools by
was not considered
IS departments to build
systems for users, rather than with assimilating a technology to service outside customers.
However
it is
feasible that
where an organization's business
services to outside clients, market strategy
Further, if a different
view
is
why and how CASE
CASE
factors
we
toolset,
well affect the process of assimilating
some measure of departmental
Finally, future research should
particular
to provide information products
and
CASE tools.
taken of the IS department, as a unit servicing clients (even though
these are internal clients), then
influence on
may
is
may
be a significant
tools are assimilated
examine other
IEW. While we
identified are relevant across
CASE
tools, as this study
only investigated one
believe that the assimilation process and
CASE
toolset types, our findings
applied to
CASE tools in
many, and
attributes of the technological innovation, the
general.
service strategy
As we noted
earlier, the varieties
many
of the
can only cautiously be
and flavors of CASE tools are
CASE tools, can be expected to influence
the assimilation process. Careful, comparative studies across this range are needed.
In this paper
explored
we
how
articulated a process
this
process
is
by which
CASE tools are assimilated into organizations,
and
influenced by various organizational and technological factors.
29
Findings from an empirical investigation revealed that nominal amounts of time and effort are spent
CASE
on evaluating the
tools prior to their adoption,
and
that as a result, organizational
consequences of these tools were poorly understood and dealt with.
number of key
factors that
we
assimilation in organizations.
practice,
We identified and discussed a
believe facilitate and constrain the process of
We
CASE
tools
discussed the implications of these findings for research and
and proposed some recommendations for managing the implementation of CASE
tools.
REFERENCES
Bouldin, Barbara
Englewood
A gents of Change:
M.
Cliffs NJ,
Yourdon
Managing
the Introduction of
Automated Tools
Press, 1989.
Case, Albert F. "Computer-Aided Software Engineering: Technology for Improving Software
Development Productivity," DataBase,
Desmond, John "A Visionary and
Fall 1985: 35-43.
a Motivator deliver the
CASE message," Software
Magazine, September 1988.
Freedman, David H. "Programming without Tears," High Technology, April 1986: 38-45.
Gane, Chris "Computer-Aided Software Engineering: The Methodologies, The Products, The
Future," Technical Report, Rapid System Development Inc.,
Ginzberg, Michael
J.
"A Study
New
of the Implementation Process,"
York, 1988.
TIMS
Sudies
in the
Management
Sciences, 13: 1979; 85-102.
Kolb, D.A.
& Frohman, A.L. "An Organizational Development Approach to Consulting," Sloan
Management Review,
Loh, Marcus
12:1; 1970: 51-65.
& Nelson, R. Ryan "Reaping CASE Harvest," Datamation, July
Lucas, Henry C.
Jr.
Implementation: The
Columbia University
1989: 31-34.
New York:
Key
to Successful Information
MIS
Implementation," Communications of the
Systems
Press, 1981.
Markus, M. Lynne "Power,
Politics,
and
ACM,
26: 1983; 430-444.
Martin, James
& Finkelstein, Martin Principles of Information Engineering Englewood Cliffs:
Prentice-Hall, 1982.
30
Meyer, Alan D.
& Goes, James B. "Organizational Assimilation of Innovations: A Multilevel
Contextual Analysis,"
Norman, Ronald
J.
Academy of Management Journal,
31:4, 1988: 897-923.
& Nunamaker, Jay F. Jr. "An Empirical Study of Information Systems
CASE Technology," Procs. of the Ninth
Minneapolis MN, December 1988: 111-118.
Professionals' Productivity Perceptions of
Conference on Information Systems,
Orlikowski,
"CASE Tools and the IS Workplace: Some Findings from Empirical
of the ACM SIGCPR Conference, College Park MD, April 1988.
Wanda
Research," Procs.
International
J.
Rockart, John F. "Chief Executives define their
own
data needs,"
Harvard Business Review,
March-April 1979: 81-93.
Rochester, Jack R. (ed.) "Building
Rogers, Everett
More
Flexible Systems," I/S Analyzer, 27:10; 1989: 1-12.
M. Diffusion of Innovations New York: The Free
Press, 1983.
Rousseau, Denise M. "Managing the Change to an Automated Office: Lessons from Five Case
Studies, Office:
Russell, Fred
Technology and People,
"The case
for
4: 1989: 31-52.
CASE," ICL Technical Journal, May
Schein, Edgar Process Consultation:
Its
Role
in
1989: 479-495.
Organizational Development Reading
MA,
Addison-Wesley, 1969.
Simon, Herbert A. The
New
Science of Management Decision
Stamps, David "Cranking out Productivity," Datamation, July
31
New York:
1,
Harper
1987: 55-58.
& Bros,
1960.
/
b 3
Date Due
FEB 23
MY
1991
1 1 1991
SEP.
3
19ft
Lib-26-67
MIT LIBRARIES DUPL
3
TOflO
1
DDbSfllflD
2