IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 28, NO.

12, DECEMBER 2002 1135

Explaining Software Developer Acceptance of

Methodologies: A Comparison of Five
Theoretical Models
Cynthia K. Riemenschneider, Bill C. Hardgrave, Member, IEEE Computer Society, and Fred D. Davis

Abstract—Many organizations attempt to deploy methodologies intended to improve software development processes. However,
resistance by individual software developers against using such methodologies often obstructs their successful deployment. To better
explain why individual developers accept or resist methodologies, five theoretical models of individual intentions to accept information
technology tools were examined. In a field study of 128 developers in a large organization that implemented a methodology, each
model explained significant variance in developers’ intentions to use the methodology. Similar to findings from the tool adoption
context, we found that, if a methodology is not regarded as useful by developers, its prospects for successful deployment may be
severely undermined. In contrast to the typical pattern of findings in a tool context, however, we found that methodology adoption
intentions are driven by: 1) the presence of an organizational mandate to use the methodology, 2) the compatibility of the methodology
with how developers perform their work, and 3) the opinions of developers’ coworkers and supervisors toward using the methodology.
Collectively, these results provide surprising new insights into why software developers accept or resist methodologies and suggest
what software engineering managers might do to overcome developer resistance.

Index Terms—Software development, methodologies, intention models, technology acceptance model, theory of planned behavior,
diffusion of innovations.

1 INTRODUCTION

F UELED by the information technology (IT) revolution, the

Digital Economy has arrived in the United States—six
major economic studies have recently concluded that the
production and use of IT contributed half or more to the
acceleration of U.S. productivity growth in the second half
of the 1990s. Real business investment in software increased
from $82 billion in 1995 to $149 billion in 1999 [20]. Similar
trends are anticipated globally. However, some evidence
suggests that software development is not improving as it
should: Quality is increasing at a slower rate than expected,
productivity has actually declined 13 percent in recent
years, and up to 75 percent of all development efforts are
considered failures [25], [65]. This “software crisis” [23]
threatens the continued expansion of the Digital Economy.
Improving software development processes has been and
remains a top concern of IT management [11], [18], [28], [46].
Methodologies are not a panacea for all software
development problems. Nevertheless, research indicates
their use is generally related to increases in productivity
and quality as well as reductions in time and effort [27],
[30]. Despite the existence of methodologies for several
decades, only about half of all organizations actually follow
a methodology [22], [24], [53], [56]. Why are methodologies
. The authors are with the Sam M. Walton College of Business Information
Systems Department, University of Arkansas, Business Building, Room
204, University of Arkansas, Fayetteville, AR 72701-1201.
E-mail: {criemen, whardgra, fdavis}@walton.uark.edu.
Manuscript received 27 Apr. 2001; revised 22 Oct. 2001; accepted 22 Feb.
2002.
Recommended for acceptance by Luqi.
For information on obtaining reprints of this article, please send e-mail to:
tse@computer.org, and reference IEEECS Log Number 114059.
0098-5589/02/$17.00 ß 2002 IEEE
Authorized licensed use limited to: ALTRAN. Downloaded on March 10,2021 at 14:21:06 UTC from IEEE Xplore. Restrictions apply.
not used more? Research to date has yet to answer this
question [66]. Organizations that attempt to deploy meth-
odologies frequently encounter substantial resistance from
individual developers [39]. Therefore, the specific research
question driving the present research is: What are the
determinants of individual software developers’ intentions
to use methodologies within organizations attempting to
deploy them? Previous research on this question is limited
and exploratory, and there is minimal established theory
(e.g., [35], [38], [52], [53]).
According to Pfleeger [50], the field of software en-
gineering needs to better understand the role of people in
the adoption process, drawing upon social science models
as appropriate to further this understanding (p. 121):
There is little reported in the software engineering literature
about how each aspect relates to successful software
technology diffusion. Much of our understanding of these
issues is anecdotal; we can draw stronger conclusions about
successful technology transfer if our understanding is
broadened using careful studies of representative situations.
Accordingly, we examine five existing models of
individual acceptance of information technology tools in
the domain of individual acceptance of methodologies. These
models include the Technology Acceptance Model (TAM),
TAM2, Perceived Characteristics of Innovating (PCI),
Theory of Planned Behavior (TPB), and the Model of
Personal Computer Utilization (MPCU). Because each of the
five models of tool acceptance was originally derived from
more general theories of motivated human behavior, we
expect them to generalize to some extent beyond the
domain of tool use intentions to encompass methodology
use intentions. There is not sufficient justification for
1136 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING,
assuming, without empirical validation, that the models
from the tool acceptance domain would be applicable to the
methodology acceptance context. This is a key motivation
for why the present study was conducted.
Although usage of a technology tool is clearly different
from usage of a methodology, there are certain points of
similarity, suggesting that some tool adoption determinants
may be applicable to methodology adoption decisions. For
example, both tool and methodology use are workplace
behaviors with potential consequences for job performance
and rewards, and both require effort and skill to learn and
use. However, the five models examined may behave
somewhat differently due to three typical differences
between the domain of individual IT tool acceptance, for
which these five models were developed, and the present
domain of methodology acceptance among software devel-
opers. First, the degree to which adoption of the target
innovation has been mandated by senior management
tends to be greater for methodologies than for tools. Second,
the magnitude of behavioral change entailed by adopting a
methodology is greater than that of a tool. Third, the greater
emphasis on the use of project teams for organizing
software development work increases the relevance of
coworker influences compared to use of individual IT
productivity tools. As will be seen, the set of models
examined here includes constructs reflecting the external
influences of organizational and group pressures on
individual intentions to use, as well as individual adopter
concerns regarding the extensiveness of behavioral change
required.
In this study, a Fortune 1000 organization implemented a
custom methodology, which moved them from an environ-
ment having no methodology at all to an environment
guided by the new methodology (the methodology is
described in more detail in the Appendix). In our analysis
of the five explanatory models, four determinants of
intentions to use the new methodology were found
significant: usefulness, voluntariness, compatibility, and
subjective norm. These findings indicate that a methodolo-
gy’s usefulness and compatibility with existing work
processes heavily influence its acceptance. Also, contrary
to common beliefs, acceptance of the methodology is not
assured just because it is mandated by the organization,
although developers do place value on the opinions of
coworkers and supervisors in forming their use decision.
The remainder of the paper is organized as follows:
Section 2 provides an overview of prior research in
methodologies. Section 3 discusses the models compared
in this study. Section 4 describes the research methods used,
and Section 5 provides the results. Finally, Section 6
discusses the implications of the study and suggests future
areas for research.
2 BACKGROUND
2.1 Methodologies
We define a methodology as a comprehensive guide to
developing a system. Examples of methodologies include
those that can be purchased, such as Ernst and Young’s
Navigator and Accenture’s METHOD/1, or acquired in the
Authorized licensed use limited to: ALTRAN. Downloaded on March 10,2021 at 14:21:06 UTC from IEEE Xplore. Restrictions apply.
VOL. 28, NO. 12, DECEMBER 2002
public domain via books and Web sites, such as Structured
Systems Analysis and Design Methodology (representing
the structured development paradigm) and the Rational
Unified Process (representing the object-oriented para-
digm). Many companies create their own or extensively
modify existing methodologies to better fit their organiza-
tion [19], [66]. The methodology used by the organization
in this study was created by a consultant for its own
internal use.
The Software Engineering Institute’s Capability Maturity
Model (CMM) explains the importance of methodologies.
The CMM measures the effectiveness of an organization’s
software development capability by identifying five levels
of maturity that lay successive foundations for process
improvement [49]. Level-1 indicates an immature software
organization in which development is inconsistent and
lacks common software development processes (i.e., meth-
odologies are not used). At Level-2, an organization begins
to demonstrate repeatability in their development process
primarily through basic project management and measure-
ments (i.e., the beginnings of a methodology). Level-3 is
characterized by increased efficiency, with fully documen-
ted software processes (i.e., a methodology is fully
deployed). At Level-4, software processes are quantitatively
understood and controlled. At Level-5, use of common
software processes has become routine and automatic.
As characterized by the successive maturity levels of the
CMM, standardizing development processes via methodol-
ogies is important for several reasons. Standardization of
the development process puts the burden on the process
rather than the developer. Thus, developers’ skills become
more interchangeable, which is critically important given
today’s shortage and high turnover of software developers.
Standardization can improve productivity [40] and, by
providing a common vocabulary for documentation, can
reduce maintenance effort, which consumes up to 80 percent
of the IT budget [31]. In general, higher levels of maturity
have been empirically linked to higher system quality,
better match with functional requirements, and lower cycle
time, effort, and cost [27], [41], [49]. Unfortunately,
according to a recent CMM maturity profile, almost half
of all companies assessed are at Level-1 [56]. Because the
CMM assessment process is generally voluntary and the
participants are self-selected, it is projected that the true
industry percentage of Level-1 organizations is closer to
75 percent [68]. Furthermore, more than 75 percent of
organizations assessed at Level-1 never return to have a
reassessment, suggesting the initial attempt to adopt/
develop a methodology may have been abandoned [1].
The adoption of a methodology represents a significant
change in work practices, and many developers are
resistant to such change [50]. As a result, “The expenditure
of time and effort in implementing a software development
methodology makes it one of the most serious areas of
concern in modern IS” [53, p. 647]. The difficulty organiza-
tions face in successfully deploying methodologies is clearly
a problem warranting continued research attention.
RIEMENSCHNEIDER ET AL.: EXPLAINING SOFTWARE DEVELOPER ACCEPTANCE OF METHODOLOGIES: A COMPARISON OF FIVE...
2.2 Prior Research on Software Developer
Intentions to Use Methodologies
There has been little previous research specifically addres-
sing the determinants of individual software developers’
intentions to use or not use methodologies mandated by their
organization. Pfleeger [50, p. 122] suggests that “researchers
should look for examples of technology transfer and assess
them to understand the key variables that make adoption fast
and effective.” An exploratory study by Roberts et al. [52],
[53] uncovered potential factors that might affect the
implementation of methodologies. Using exploratory factor
analysis on 88 survey items, the authors interpreted five
perceptual factors that may possibly be linked to methodol-
ogy acceptance among individual developers: organiza-
tional transition (preparedness and enforcement),
management support, process transition (understanding
the new process), use of models by the process, and external
support. However, the Roberts et al. [52], [53] study was not
theoretically grounded, employed psychometrically unvali-
dated measures, and did not assess the relationship between
the derived factors and individual developer usage inten-
tions or behaviors [67]. In the context of object-oriented
systems development, Johnson et al. [35] used Ajzen’s [7]
belief elicitation pretesting procedure to identify specific
salient beliefs underlying the attitude, subjective norm, and
perceived behavioral control constructs of the Theory of
Planned Behavior. However, they did not empirically test
the relationships between these elicited beliefs and the
TPB constructs, developer intentions, or usage of object-
oriented systems development. Khalifa and Verner [38]
developed a model of the determinants of software devel-
opers’ usage of waterfall and prototyping methodologies
based partly on Triandis’ [60] model of human behavior.
Although their model did not employ psychometrically
validated scales of theoretical constructs, this is the most
theoretically justified of the previously reported studies of
individual developer adoption of methodologies. Khalifa
and Verna [38] found that perceived process quality and
facilitating conditions significantly explained use of proto-
typing (R2 ¼ :178) and waterfall (R2 ¼ :317) methodologies.
Some individual-level research has been done that did
not directly address adoption of methodologies per se, but
rather the adoption of specific tools (such as CASE) and
techniques (such as object-oriented programming) com-
monly used within a methodology [48], [64]. This is a key
distinction since adoption of methodologies represents a
much more radical change than adopting tools and
techniques [47], [53]. Further, tools and techniques can be,
and often are, used outside the context of a methodology
[19], [63]. Chau [14] found ease of use, usefulness, and long-
term consequences to be significantly related to CASE tool
usage. Iivari [33] identified several variables significantly
linked to a broad-based measure of CASE usage, which
included effectiveness, potential, naturalness, encourage-
ment, and routinization. Kozar’s [39] qualitative interviews
suggested that compatibility and management support
were important in the decision to adopt a new technique
for eliciting user requirements. Leonard-Barton [42] found
that training, attitude toward innovations, and perceived
client preferences were statistically different between
adopters and nonadopters of a structured analysis techni-
que. Sultan and Chan [57] found the organizational-level
Authorized licensed use limited to: ALTRAN. Downloaded on March 10,2021 at 14:21:06 UTC from IEEE Xplore. Restrictions apply.
1137
variables of centralization, formalization, and management
support to be significant differentiators between individual
adopters and nonadopters of object-oriented programming.
Agarwal and Prasad [3] also looked at programming tool
acceptance, but focused on the intention to use a specific
language, C, by a group of COBOL programmers. Using a
combination of the Theory of Planned Behavior, the
Technology Acceptance Model, and several external factors
(such as training), Agarwal and Prasad were able to explain
approximately 76 percent of a COBOL programmer’s
intention to use C (with a sample size of 50). Although
these individual-level studies include constructs that
appear among the five models of tool usage intention being
adapted to the methodology usage context in the present
study, they exhibit various limitations. Some previous
studies did not explicitly model the determinants of
intentions and/or did not use established psychometrically
validated instruments. These previous studies focused on
the adoption of tools or techniques as opposed to the
adoption of an entire methodology.
Overall, there is a dearth of research in the software
engineering literature about the determinants of methodol-
ogy acceptance [50]. The only prior studies that directly
pertain to individual-level adoption of methodologies are the
preliminary exploratory studies by Roberts et al. [52], [53],
Johnson et al. [35], and Khalifa and Verner [38]. Other related
research addresses adoption of specific tools or techniques
that may be used within a methodology, rather than adoption
of a methodology per se. Other tangentially-related types of
studies, such as descriptive and contingency approaches,
have addressed methodology usage patterns and the
performance consequences of matching the methodology to
the specific context, but have not studied the determinants of
individual developer intentions to adopt a methodology
(e.g., [4], [13], [21], [24], [26], [32], [34], [36], [45], [51]). The
present study goes beyond prior research by investigating an
individual’s behavioral intention to use methodologies mandated by
their organization. Due to the absence of established theore-
tical models in the particular domain of individual-level
intentions to adopt methodologies, five established models
of individual-level intentions to adopt IT tools are adapted:
TAM, TAM2, PCI, TPB, and MPCU. We will examine the
degree to which these tool adoption models generalize to the
domain of methodology adoption.
3 EXPLANATORY MODELS
Several theoretical models have been introduced in the IS
literature regarding the determinants of voluntary indivi-
dual intentions to adopt IT tools in the workplace. These
draw from various reference field paradigms, have many
similarities as well as differences, and have generally been
validated in the context of individual-level, end-user
productivity tools, such as personal computers, word
processing, spreadsheets, electronic mail, and graphics
software. Although it is not known how well any of them
will generalize to the domain of adopting a methodology,
our logic is that each model is an abstraction and
simplification of the true process by which developers form
intentions to use methodologies and will inherently either
highlight or downplay particular mechanisms operating in
1138 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING,
this domain. Thus, the models will provide alternative
views into the specific phenomenon of methodology
acceptance. In this section, each model is briefly summar-
ized, focusing on the direct determinants of usage inten-
tions (and not on antecedents of those direct determinants).
Interested readers can find more detailed theoretical
development and empirical validation of each model in
the referenced articles.
3.1 Technology Acceptance Model (TAM)
Davis et al. [17] and Davis [16] introduced the Technology
Acceptance Model (TAM) to predict and explain knowledge
worker adoption of information technology applications in
the organizational workplace (e.g., electronic mail, word
processing, and graphics software). TAM posits that
intentions to use a target system are jointly determined by
individuals’ perceived usefulness, which is the extent to
which the person thinks using the system will enhance his
or her job performance, and perceived ease of use, the
extent to which the person perceives using the system will
be free of effort. Across numerous studies, perceived
usefulness typically has a strong influence on usage
intentions, and perceived ease of use often has a significant
secondary effect (for recent review, see [61]).
3.2 TAM2
TAM2 is an extension of TAM designed to encompass both
voluntary and mandatory usage situations by including two
additional constructs. Subjective norm, defined as the
degree to which people think that others who are important
to them think they should perform the behavior, was found
to be a significant determinant of intention for the use of
tools in mandatory usage contexts [62]. Venkatesh and
Davis [62] show that perceived voluntariness, defined as
the extent to which potential adopters perceive the adoption
decision to be nonmandatory, significantly moderates the
direct effect of subjective norm on intention to use.
3.3 Perceived Characteristics of Innovating (PCI)
Moore and Benbasat [44], drawing from the extensive work
on diffusion of innovations by Rogers [54], published an
instrument to measure what they term “perceived char-
acteristics of innovating” (PCI) regarding adoption of
personal workstations. Seven constructs were represented
in the PCI instrument. These include relative advantage,
which is the degree to which an innovation is perceived as
being better than its precursor, and complexity, which is the
degree to which an innovation is perceived as being
difficult to use. Noting the conceptual equivalence, Moore
and Benbasat [44] used Davis’ [16] perceived usefulness
scale to measure relative advantage and ease of use scale to
measure complexity (in reversed direction). The PCI
instrument also included measures of compatibility, result
demonstrability, image, and visibility. Compatibility refers
to the degree to which an innovation is perceived as being
consistent with the existing values, needs, and past
experiences of potential adopters; result demonstrability
refers to the degree to which an innovation is perceived to
be amenable to demonstration of tangible advantages.
Image refers to the degree to which use of an innovation
is perceived to enhance one’s image or status in one’s social
system, and visibility refers to the degree to which the
Authorized licensed use limited to: ALTRAN. Downloaded on March 10,2021 at 14:21:06 UTC from IEEE Xplore. Restrictions apply.
VOL. 28, NO. 12, DECEMBER 2002
results of an innovation are observable by others. Moore
and Benbasat [44] also included a measure of voluntariness,
which is defined and measured the same by Venkatesh and
Davis [62]. Although Moore and Benbasat [44] did not
report the relationship between the seven PCI constructs
and usage or usage intentions, Agarwal and Prasad [2]
reported empirical support for PCI as a model of intentions
to use the World Wide Web.
3.4 Theory of Planned Behavior (TPB)
The Theory of Planned Behavior, introduced by Ajzen and
his colleagues in social psychology [6], [8], [10], [55], posits
three primary determinants of intention: perceived beha-
vioral control, subjective norm, and attitude. Perceived
behavioral control refers to one’s perceptions of internal
or external constraints on performing the behavior.
Consistent with findings by Chau [14] and Taylor and
Todd [58], we represent distinct internal and external
subdimensions of perceived behavioral control as separate
constructs. Subjective norm is defined and measured the
same as in TAM2. Attitude refers to one’s degree of
favorableness or unfavorableness towards performing a
target behavior, and is conceptually equivalent to TAM’s
usefulness construct.
3.5 Model of Personal Computer Utilization (MPCU)
Thompson et al. [59] introduced a model of personal
computer utilization (MPCU) based on Triandis’ [60] model
of interpersonal behavior from social psychology. The
model includes the social factors construct, which refers
to the individual’s internalization of the reference groups’
subjective culture, and interpersonal agreements that the
individual has made with others. MPCU’s affect construct
refers to the positive or negative emotional reactions an
individual associates with a particular act. The Triandis [60]
model includes perceived consequences and Thompson et
al. [59] delineate three types: two near-term and one long-
term. Near-term consequences include complexity, defined
and measured as essentially the reverse of perceived ease of
use in TAM, and job fit, defined and measured equiva-
lently to perceived usefulness in TAM. Career conse-
quences, the dimension of long-term consequences of use,
refers to outcomes that have a payoff in the future, such as
increasing the flexibility to change jobs or increasing the
opportunities for more meaningful work. Finally, Thomp-
son et al. [59] include facilitating conditions, which are
factors in the environment that make an act easy to do. This
construct parallels the external perceived behavioral control
construct of TPB and we equate the two.
The five models have both common and unique
constructs (Table 1). All models have a construct equivalent
to perceived usefulness (relative advantage in PCI, attitude
in TPB, job fit in MPCU). TAM’s ease of use construct has a
reversed counterpart in complexity within both PCI and
MPCU. Subjective norm appears in TAM2 and TPB, and in
MPCU as social factors, although no such construct appears
in TAM or PCI. Affect appears in MPCU, but not in the
other models. The external subdimension of perceived
behavioral control appears in TPB, and in MPCU as
facilitating conditions, whereas the internal perceived
behavioral control subdimension is unique to TPB among
RIEMENSCHNEIDER ET AL.: EXPLAINING SOFTWARE DEVELOPER ACCEPTANCE OF METHODOLOGIES: A COMPARISON OF FIVE...
TABLE 1
Construct Map
these models. PCI is the only model in this set that includes
compatibility, result demonstrability, image, and visibility,
although it omits subjective norm, internal and external
perceived behavioral control, and career consequences.
Voluntariness appears in TAM2 and PCI, but not in TAM,
TPB, or MPCU. Finally, the career consequences construct
appears in only MPCU among this set of models. Each
model is tested as theorized by examining the hypothesized
direct determinants of behavioral intention.
4 METHOD
4.1 Sample
A questionnaire was distributed to each of the 185
application developers in a Fortune 1000 company
approximately six weeks after the introduction of their
new methodology (the methodology is described in the
Appendix). One hundred twenty-eight developers com-
pleted the instrument for a response rate of 69 percent. The
average age of the developers was 36 years with a reported
average of 10 years of development experience. The
average number of years the developers had been with
the company was five. Of those participating in the study,
45 were female, 74 were male, and 9 did not report their
gender. The participants in the study were developers of
all levels in the organization and they represented the
gamut of IT job functions in the organization.
4.2 Measures
The questionnaire was constructed using validated mea-
surement scales from previous research, as discussed in
Section 3. The behavioral intention items were adapted
from standard scales such as those used by Ajzen and
Fishbein [9], Venkatesh and Davis [62], and Taylor and
Todd [58]. Usefulness and ease of use items were taken
from the original Davis [16] instrument. Voluntariness,
Authorized licensed use limited to: ALTRAN. Downloaded on March 10,2021 at 14:21:06 UTC from IEEE Xplore. Restrictions apply.
1139
compatibility, result demonstrability, image, and visibility
scales were adapted from Moore and Benbasat [44]. PBC-I,
PBC-E, and career consequences included items from Chau
[14] and Thompson et al. [59]. Subjective norm items came
from Venkatesh and Davis [62] and Ajzen and Fishbein [9].
Pilot testing of the instrument led to slight rewording of
some items and the elimination of the affect items, which
did not appear to be appropriate in the context of
methodologies (affect pertains to an emotional response).
The elimination of the affect construct is consistent with
prior studies of this type [58].
Measurement scales are provided in Table 2. Factor
analyses confirmed the a priori factor structure for each
model.1 Cronbach alpha coefficients, as well as means,
standard deviations, and intercorrelations of all constructs
are provided in Table 3. Alpha reliabilities ranged from .77
to .95, indicating acceptable internal consistency [12]. Not
surprisingly given their source, each individual construct
was significantly correlated with behavioral intention.
5 RESULTS
Each model (TAM, TAM2, PCI, TPB, MPCU) was tested
individually using least-squares regression analysis. Re-
gression diagnostics were checked for each model, which
led to the deletion of two data points whose residuals were
identified as outliers, violating the normality assumption
for residuals. Once these two points were deleted, no
significant violations of regression assumptions were
found. Standardized variables were used as suggested by
Aiken and West [5]. Table 4 shows the results of each model
test, delineating the varying names of the constructs as well
1. Due to space limitations, factor analyses are not presented. All
constructs were validated in prior studies and in all cases in the present
study, items loaded on the factors as expected with no cross loadings
exceeding .30.
1140 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 28, NO. 12, DECEMBER 2002

TABLE 2
Measurement Scales

1. ADM is an acronym for Application Development Methodology, a pseudonym for the true methodology name, which is disguised in order to protect
the anonymity of the company where the data was collected.
2. The true company name was used on the actual instrument but is not used here to protect the anonymity of the company where the data was
collected.

as the beta coefficients and significance levels. Additionally,
the R2 and adjusted R2 values are provided. Usefulness
(p < :001) was the only significant variable in TAM, while
usefulness (p < :001), subjective norm (p < :01), and volun-
tariness (p < :01) were significant in TAM2. In testing the
PCI, we found relative advantage (p < :001), voluntariness
(p < :001), and compatibility (p < :05) to be significant. In
TPB, attitude (p < :001) and subjective norm (p < :01) were
significant. In MPCU, job fit (p < :001) and social factors
(p < :01) were significant.
6 DISCUSSION
To identify the significant determinants of individual
software developers’ intentions to use a new methodology
introduced into their organization, we adapted five
previously established theoretical models of individual-
level user acceptance of IT tools: TAM, TAM2, PCI, TPB,
and MPCU. Despite some commonalities between these
domains, there are also important differences. Compared
to adopting an IT tool, adopting a methodology tends to
be more mandatory than voluntary, and more radical
than incremental. Because it was unclear a priori whether
tool adoption models would be effective in explaining
methodology adoption, the present empirical investigation
was needed. In order to offset the risk that there are
potential determinants of methodology adoption that
were not found significant for tool adoption, we included
all direct determinants of intention from each of the
specified models in order to more fully represent
potentially relevant determinants.
Across the five models, four determinants of usage
intentions were found significant in at least one model:
usefulness (all five models), subjective norm (TAM2, TPB,
and MPCU), voluntariness (TAM2 and PCI), and compat-
ibility (PCI). None of the five original models contained all
four significant intention determinants. In moving from the
domain of IT tools to methodologies, there was one main
similarity in the pattern of significant intention determi-
nants: Usefulness was a strong and highly significant
determinant of intentions to use the methodology in the
present study, as typically found in the domain of tool
acceptance [2], [17], [43], [58], [59].
There were several important differences in the pattern
of significant intention determinants in the present meth-
odology domain compared to previous tool adoption
studies. Three constructs often found significant in previous
tool acceptance studies, ease of use (e.g., [17], [43], [59],

Authorized licensed use limited to: ALTRAN. Downloaded on March 10,2021 at 14:21:06 UTC from IEEE Xplore. Restrictions apply.
RIEMENSCHNEIDER ET AL.: EXPLAINING SOFTWARE DEVELOPER ACCEPTANCE OF METHODOLOGIES: A COMPARISON OF FIVE...
TABLE 3
Intercorrelations, Means, Standard Deviations, and Cronbach Alphas for All Constructs
[62]), perceived behavioral control—internal [43], [58], and
perceived behavioral control—external [43], [58], were
found nonsignificant in the present study. Compatibility
has not typically been found significant in tool adoption
studies (e.g., [2]), but was found significant in the present
methodology domain. Subjective norm, which has been
found significant in some tool intention studies (e.g., [58],
[59], [62, Studies 3 and 4]) and nonsignificant in others (e.g.,
[17], [43], [62, Studies 1 and 2]), was found significant in the
present research. Voluntariness and compatibility, both
significant determinants of methodology use intentions in
the present study, were found nonsignificant as determi-
nants of tool use intentions in some prior research [2] and
significant in other previous studies (e.g., [15], [29], [33]).
Overall, these findings suggest that, as the behavioral
domain changes from tool use to methodology use, there is
a reduction in the relevance of how easy or hard the
behavior is to perform and whether or not one possesses
adequate internal or external resources to perform it. There
is an increase in the relevance of subjective normative
pressure to perform the behavior, the perception of a
formal mandate (the inverse of voluntariness), and the
compatibility of the target behavior with individuals’
current ways of performing their work. This is consistent
with the observation that, compared to tool adoption,
methodology adoption is a more fundamental and radical
change to the behavioral processes in conducting one’s
work and is more apt to be a mandatory than voluntary
innovation. Thus, while the models as a group successfully
generalized from the domain of tool adoption to metho-
dology adoption, there was a different pattern of which
Authorized licensed use limited to: ALTRAN. Downloaded on March 10,2021 at 14:21:06 UTC from IEEE Xplore. Restrictions apply.
1141
model determinants were significant. This shift in pattern
of adoption determinants correspond to a large extent to
the known differences between methodology and tool
usage contexts, namely, that methodology use is more
radical and mandatory than tool use.
6.1 Practitioner Insights
This research provides important new insights for mana-
ging the effective introduction and deployment of a
methodology within an organization. A common pitfall is
for senior managers to assume that, once the organizational
decision to adopt a methodology has been made, it is
sufficient to issue an official policy mandating use of the
new methodology in order to guarantee successful deploy-
ment. Our findings disconfirm this assumption, demon-
strating instead that individual developer acceptance is far
from assured even in the presence of an organizational
mandate. Other important drivers of methodology accep-
tance exist beyond the target user’s perception that the
adoption decision is mandatory.
First and foremost, if a methodology is not regarded as
useful by developers, its prospects for successful deploy-
ment may be severely undermined. Of all of the external
pressures impinging upon professional knowledge workers
in an organizational setting, few are as influential as the
performance measurement and reward structure. There-
fore, to the extent a methodology is not useful, that is, it
does not enable developers to be more productive and
achieve higher levels of performance in their job and,
therefore, they are not likely to use it in a sustained manner,
even if it is organizationally mandated. Demonstrating the
1142 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 28, NO. 12, DECEMBER 2002

TABLE 4
Regression Analysis of Theoretical Models

individual productivity benefits (i.e., usefulness) of the
methodology may help shape a developer’s intention to
adopt. However, in the words of Leonard-Barton [42, p. 7],
for many methodologies “the benefits from adoption are
long-term and they accrue to the organization as a whole;
whereas, the costs are immediate and they are incurred by
individual analysts or programmers.” Such adverse effects
on developer productivity, according to our model, would
tend to strongly erode adoption intentions (i.e., the strong
relationships between usefulness and intention as demon-
could be altered to reward individual developers directly
for organizational-level performance improvements.
The more compatible a mandated methodology is with
how developers perform their work, the more likely they are
to form intentions to use it, especially if it is perceived to be
useful. Since a methodology is a comprehensive specifica-
tion of the steps and procedures to be used throughout all
phases of the software development process [31], the more it
departs from the current work processes of any given
developer, the less likely that developer will be to intend to
strated by the  in each model suggest a reduction in
usefulness will significantly reduce intention.). Positive
consequences for the organization cannot offset negative
consequences for the individual. To enhance the probability
of successful deployment, such mismatches between orga-
nizational and individual productivity benefits must be
eliminated, for example, by altering the nature of the
methodology to provide greater individual performance
improvement. Or the performance measurement system
Authorized licensed use limited to: ALTRAN. Downloaded on March 10,2021 at 14:21:06 UTC from IEEE Xplore. Restrictions apply.
adopt it. Professional knowledge workers such as software
developers usually evolve work practices that they find
effective and have come to rely on to produce effective work
output. There is significant effort and uncertainty involved
in learning and routinizing new work patterns. Managers
can do several things to overcome this barrier to successful
deployment. Management would be wise to explicitly
demonstrate instances of the new methodology’s compat-
ibility with existing work practices. If there are particular
RIEMENSCHNEIDER ET AL.: EXPLAINING SOFTWARE DEVELOPER ACCEPTANCE OF METHODOLOGIES: A COMPARISON OF FIVE...
parts of a new methodology that especially depart from
current practice, but which are not vital to the effectiveness
of the methodology, these may be modified to be brought
into greater alignment with current practice. Rather than
attempting to convert from current practice to the new
methodology in a single step (the “big bang” approach), it
might be possible to design a migration path in which
developers adopt parts of the methodology incrementally,
in each step experiencing improved productivity. Training
can be designed to undo existing work habits and routines
while propelling developers along such a migration path. In
any case, when selecting a methodology, managers should
take into consideration, all else being equal, how compatible
the methodology is to current work practices.
Our research shows that subjective norm exerts a distinct
influence on intentions to adopt a methodology above and
beyond usefulness, voluntariness, and compatibility. This
tells us that, even if developers regard a mandated
methodology as both useful and compatible with their
current work practices, they may still avoid using it because
coworkers or supervisors think they should not be using it.
Developers may be motivated to behave in compliance with
such social influences if salient referents possess sufficient
influence over them [62]. For example, developers who
believe that a mandated methodology would be useful and
compatible for them personally may work amongst peers
and supervisors who actively oppose its use. In order to
sustain a balance of equitable social exchange, or to avoid
damaging key work relationships, such developers may
avoid using the methodology despite its merits. Manage-
ment may be able to devise persuasive communication
strategies designed to reduce the developers’ perceived
strength of peers’ and coworkers’ counterimplementation
desires, or to attenuate their motivation to comply with
such subjective norms.
6.2 Future Research Directions
The present research shows that mandating methodology
use by software developers does not guarantee that the
methodology actually will be used. By demonstrating the
significant roles of usefulness, subjective norm, and
compatibility above and beyond voluntariness, several
worthwhile avenues of future research are apparent. There
is a need for research to integrate the findings of the
various models presented here. Also, any additional
determinants of methodology acceptance should be identi-
fied and incorporated into the model. The fact that data
was collected from a single organization may limit the
generalizability of these findings, although the specific
methodology studied employs the traditional structured
development process and is therefore highly representative
of the domain of methodologies to which we would like to
generalize [39]. Future research should attempt to confirm
these findings in other organizations.
Future research needs to address whether the boundary
conditions of the models extend to the adoption of other
software development innovations such as CASE tools or
development techniques, and whether it will prove useful
for other nonsoftware development process innovations,
such as new organizational structures and engineering
processes. In fact, we were surprised at the lack of
acceptance studies in the various engineering disciplines.
Perhaps this study can serve as a foundation for studies of
Authorized licensed use limited to: ALTRAN. Downloaded on March 10,2021 at 14:21:06 UTC from IEEE Xplore. Restrictions apply.
1143
methodology acceptance in a variety of engineering
domains beyond software engineering.2 This study sur-
veyed developers shortly after the introduction of the
methodology (i.e., postadoption). Are the same variables
significant preadoption? Are the same variables significant
after a longer period of time? Overall, the present study lays
the foundation for at least three paths for future research:
1) improving the models (i.e., increasing explanatory
power) in the existing domain of individual-level intentions
to adopt methodologies, 2) extending the boundary condi-
tions of the models by adapting it to other domains (e.g.,
software development tools and techniques, and nonsoft-
ware development processes), and 3) investigating the time
sensitivity of the models.
6.3 Conclusion
Five established models of individual-level intentions for
tool adoption (TAM, TAM2, PCI, TPB, MPCU) were used to
provide insights into methodology adoption. This is the first
study to empirically test these models in a methodology
context. Extending the boundaries of these models from the
domain of tools to methodologies has demonstrated their
resilience in adapting to a new domain and the differences
required by the new domain. This research also contributes
toward an integrative body of research needed in software
engineering by establishing the foundation for a new theory
of methodology acceptance. By identifying the determi-
nants of acceptance, prescriptive models can be enhanced
and contingency models of methodology use may be
extended from a focus on effectiveness of a methodology,
if used, to a focus on whether or not a methodology will be
used in the first place (e.g., [13], [21], [26], [32], [51]). From a
practical perspective, insights into acceptance provided by
the study suggest better strategies for introducing meth-
odologies and avoiding situations where resources (money
and time) have been spent on methodologies that are not
used [50]. By knowing the determinants of a developer’s
intention, management can take appropriate action to
increase the adoption of a new methodology. Overall, from
both theoretical and practical perspectives, this study fills a
significant gap in software engineering research.
APPENDIX
DESCRIPTION OF THE METHODOLOGY
Description of methodology examined in this study. The
research site was a Fortune 1000 company with approxi-
mately 185 application developers. The methodology, based
on the structured development paradigm, was custom-
created for the company’s internal use under the leadership
of an external consultant. In this case, the organization
was moving from an environment of no prescribed
processes in place (i.e., Level-1 CMM; no methodology) to
an environment guided by an organization-wide metho-
dology (at least Level-2 CMM).
The methodology is comprehensive, providing process
directions for the complete life cycle. It includes specifica-
tions for the use of tools at various project stages by various
parties, including users. The methodology, while compre-
hensive, is adaptable to many different project types (e.g.,
small, large; new development, maintenance). For example,
2. The authors wish to thank one of the reviewers for this suggestion.
1144 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING,
a director could use the methodology to launch a new
project and assign team members. The exact portions of the
methodology, such as producing ERDs or prototypes to be
used by various types of developers, such as programmers
and database administrators, are determined by project
characteristics (i.e., the methodology established a contin-
gency model for methodology adaptation).
All employees were provided a hardcopy of the
methodology (approximately 150 pages) and access to an
on-line version with embedded links to tools and templates.
When the new methodology was launched, all developers
within the organization were instructed via a formal written
policy statement from the chief information officer to begin
using the methodology for all projects.
Epilogue: Effectiveness of the new methodology. For
this organization, measures of methodology effectiveness
six months after implementation revealed several major
improvements. Based on a comparison of 2,251 projects
before the methodology with 280 projects after the
methodology, the company found:
an increase in on-budget performance of 18 percent,
1.
a reduction in the number of late projects by 26 percent,
2.
a reduction in average days late by 25 percent,
3.
higher customer satisfaction, and
4.
less training time required for new hires and for
5.
transfers among teams.
This comparison reveals a strong improvement in effec-
tiveness after the implementation of the methodology for
many different projects.
ACKNOWLEDGMENTS
The authors are grateful to the Information Technology
Research Center at the University of Arkansas for financial
support of this research.
REFERENCES
[1] I. Aaen and J. Damsgaard, “Software Process Improvement: What
Management Tends to Forget,” Information Systems: Current Issues
and Future Changes, Proc. IFIP WG8.2 and WG8.6 Joint Working
Conf., pp. 89-110, Dec. 1998.
[2] R. Agarwal and J. Prasad, “The Role of Innovation Characteristics
and Perceived Voluntariness in the Acceptance of Information
Technologies,” Decision Sciences, vol. 28, no. 3, pp. 557-582, 1997.
[3] R. Agarwal and J. Prasad, “A Field Study of the Adoption of
Software Process Innovations by Information Systems Profes-
sionals,” IEEE Trans. Eng. Management, vol. 47, no. 3, pp. 295-308,
Aug. 2000.
[4] R. Agarwal, A. Sinha, and M. Tanniru, “Cognitive Fit in
Requirements Modeling: A Study of Object and Process Meth-
odologies,” J. Management Information Systems, vol. 13, no. 2,
pp. 137-162, Fall 1996.
[5] L. Aiken and S. West, Multiple Regression: Testing and Interpreting
Interactions. Newbury Park, Calif.: Sage, 1991.
[6] I. Ajzen, “From Intentions to Action: A Theory of Planned
Behavior,” Action Control: From Cognition to Behavior, J. Kuhl and
J. Beckmann eds., New York: Springer Verlag, pp. 11-39, 1985.
[7] I. Ajzen, Attitudes, Personality, and Behavior. Chicago: Dorsey Press,
1988.
[8] I. Ajzen, “The Theory of Planned Behavior,” Organizational
Behavior and Human Decision Processes, vol. 50, pp. 179-211, 1991.
[9] I. Ajzen and M. Fishbein, Understanding Attitudes and Predicting
Social Behavior. Englewood Cliffs, NJ: Prentice-Hall, 1980.
[10] I. Ajzen and T. Madden, “Prediction of Goal-Directed Behavior:
Attitudes, Intentions, and Perceived Behavioral Control,”
J. Experimental Social Psychology, vol. 22, pp. 453-474, 1986.
Authorized licensed use limited to: ALTRAN. Downloaded on March 10,2021 at 14:21:06 UTC from IEEE Xplore. Restrictions apply.
VOL. 28, NO. 12, DECEMBER 2002
[11] J. Brancheau, B. Janz, and J. Wetherbe, “Key Issues in Information
Systems Management: 1994-1995 SIM Delphi Results,” MIS
Quarterly, vol. 20, no. 2, pp. 225- 242, June 1996.
[12] F. Brown, Principles of Educational and Psychological Testing. New
York: Holt, Reinhart, and Whinston, 1976.
[13] R. Burns and A. Dennis, “Selecting the Appropriate Application
Development Methodology,” DATA BASE, vol. 17, no. 1, pp. 19-
23, 1985.
[14] P. Chau, “An Empirical Investigation on Factors Affecting the
Acceptance of CASE by Systems Developers,” Information &
Management, vol. 30, pp. 269-280, 1996.
[15] W. Chin and A. Gopal, “Adoption Intention in GSS: Relative
Importance of Beliefs,” Data Base Advances, vol. 26, pp. 42-64, 1995.
[16] F. Davis, “Perceived Usefulness, Perceived Ease of Use, and User
Acceptance of Information Technology,” MIS Quarterly, vol. 13,
no. 3, pp. 318-339, Sept. 1989.
[17] F. Davis, R. Bagozzi, and P. Warshaw, “User Acceptance of
Computer Technology: A Comparison of Two Theoretical Mod-
els,” Management Science, vol. 35, no. 8, pp. 982-1003, Aug. 1989.
[18] G. Dickson, R. Leitheiser, J. Wetherbe, and M. Nechis, “Key
Information Systems Issues for the 1980’s,” MIS Quarterly, vol. 8,
no. 3, pp. 135-159, Sept. 1984.
[19] G. Dietrich, D. Walz, and J. Wynekoop, “The Failure of SDT
Diffusion: A Case for Mass Customization,” IEEE Trans. Eng.
Management, vol. 44, no. 4, pp. 390-398, Nov. 1997.
[20] Digital Economy 2000,U.S. Department of Commerce, Economics
and Statistics Administration, http://www.ecommerce.gov, 2000.
[21] M. El Louadi, Y. Pollalis, and J. Teng, “Selecting a Systems
Development Methodology: A Contingency Framework,” Informa-
tion Resources Management J., vol. 4, no. 1, pp. 11-19, Winter 1991.
[22] B. Fitzgerald, “Formalized Systems Development Methodologies:
A Critical Perspective,” Information Systems J., vol. 6, pp. 3-23, 1996.
[23] W. Gibbs, “Software’s Chronic Crisis,” Scientific Am., pp. 86-95,
Sept. 1994.
[24] R. Glass, “A Snapshot of Systems Development Practice,” IEEE
Software, vol. 16, no. 3, pp. 110-111, May/June 1999.
[25] R. Glass, “The Realities of Software Technology Payoffs,” Comm.
ACM, vol. 42, no. 2, pp. 74-79, Feb. 1999.
[26] B. Hardgrave, R. Wilson, and K. Eastman, “Toward a Contingency
Model for Selecting an Information System Prototyping Strategy,”
J. Management Information Systems, vol. 16, no. 2, pp. 113-136, 1999.
[27] D. Harter, M. Krishnan, and S. Slaughter, “Effects of Process
Maturity on Quality, Cycle Time, and Effort in Software Product
Development,” Management Science, vol. 46, no. 4, pp. 451-466,
Apr. 2000.
[28] C. Hartog and M. Herbert, “1985 Opinion Survey of MIS
Managers: Key Issues,” MIS Quarterly, vol. 10, no. 4, pp. 351-
361, Dec. 1986.
[29] M. Hebert and I. Benbasat, “Adopting Information Technology in
Hospitals: The Relationships between Attitudes/Expectations and
Behavior,” Hospital and Health Services Administration, vol. 39, no. 3,
pp. 369-383, 1994.
[30] J. Herbsleb, A. Carleton, J. Rozum, J. Siegel, and D. Zubrow,
“Benefits of CMM-Based Software Process Improvement: Initial
Results,” Technical Reports CMU/SEI-94-TR-013 and ESC-TR-94-
013, Software Eng. Inst., Carnegie Mellon Univ., Aug. 1994.
[31] J. Hoffer, J. George, and J. Valacich, Modern Systems Analysis and
Design, second ed. Reading, Mass.: Addison-Wesley, 1999.
[32] G. Howard, T. Bodnovich, T. Janicki, J. Liegle, S. Klein, P. Albert,
and D. Cannon, “The Efficacy of Matching Information Systems
Development Methodologies with Application Characteristics
—An Empirical Study,” The J. Systems and Software, vol. 45,
pp. 177-195, 1999.
[33] J. Iivari, “Why are CASE Tools not Used?” Comm. ACM, vol. 39,
no. 10, pp. 94-103, Oct. 1996.
[34] R. Johnson and B. Hardgrave, “Object-Oriented Systems Devel-
opment: Current Practices and Attitudes in Industry,” J. Systems &
Software, vol. 48, no. 1, pp. 5-12, 1999.
[35] R. Johnson, B. Hardgrave, and E. Doke, “An Industry Analysis of
Developer Beliefs About Object-Oriented Systems Development,”
The DATA BASE for Advances in Information Systems, vol. 30, no. 1,
pp. 47-64, 1999.
[36] M. Jones and K. Arnett, “Current Practices in Management
Information Systems,” Information & Management, vol. 24, no. 2,
pp. 61-69, 1993.
RIEMENSCHNEIDER ET AL.: EXPLAINING SOFTWARE DEVELOPER ACCEPTANCE OF METHODOLOGIES: A COMPARISON OF FIVE...
[37] M. Keil, “Pulling the Plug: Software Project Management and the
Problem of Project Escalation,” MIS Quarterly, vol. 19, no. 4,
pp. 421-443, Dec. 1995.
[38] M. Khalifa and J. Verner, “Drivers for Software Development
Method Usage,” IEEE Trans. Eng. Management, vol. 47, no. 3,
pp. 360-369, Aug. 2000.
[39] K. Kozar, “Adopting Systems Development Methods: An Ex-
ploratory Study,” J. Management Information Systems, vol. 5, no. 4,
pp. 73-86, 1989.
[40] M. Krishnan, T. Mukhopadhyay, and D. Zubrow, “Software
Process Models and Project Performance,” Information Systems
Frontiers, vol. 1, no. 3, pp. 267-277, 1999.
[41] M.S. Krishnan, C.H. Kriebel, S. Kekre, and T. Mukhopadhyay,
“An Empirical Analysis of Productivity and Quality in Software
Products,” Management Science, vol. 46, no. 6, pp. 745-759, 2000.
[42] D. Leonard-Barton, “Implementing Structured Software Meth-
odologies: A Case of Innovation in Process Technology,” Interfaces,
vol. 17, no. 3, pp. 6-17, May/June 1987.
[43] K. Mathieson, “Predicting User Intentions: Comparing the Tech-
nology Acceptance Model with the Theory of Planned Behavior,”
Information Systems Research, vol. 2, no. 3, pp. 173-191, 1991.
[44] G. Moore and I. Benbasat, “Development of an Instrument to
Measure the Perceptions of Adopting an Information Technology
Innovation,” Information Systems Research, vol. 2, no. 3, pp. 192-222,
1991.
[45] C. Necco, C. Gordon, and N. Tsai, “Systems Analysis and Design:
Current Practices,” MIS Quarterly, vol. 11, no. 4, pp. 461-475, Dec.
1987.
[46] F. Niederman, J. Brancheau, and J. Wetherbe, “Information
System Management Issues for the 1990s,” MIS Quarterly, vol. 15,
no. 4, pp. 475-500, Dec. 1991.
[47] W. Orlikowski, “CASE Tools as Organizational Change: Investi-
gating Incremental and Radical Changes in Systems Develop-
ment,” MIS Quarterly, vol. 17, no. 3, pp. 309-340, Sept. 1993.
[48] P. Palvia and J. Nosek, “An Empirical Evaluation of System
Development Methodologies,” Information Resources Management
J., vol. 3, no. 3, pp. 23-32, 1990.
[49] M.C. Paulk, C.V. Weber, S.M. Garcia, M.B. Chrissis, and M. Bush,
“Key Practices of the Capability Maturity Model,” Technical
Report CMU/SEI-93-TR-25, Version 1.1, Software Eng. Inst.,
Carnegie Mellon Univ., Feb. 1993.
[50] S.L. Pfleeger, “Understanding and Improving Technology Trans-
fer in Software Engineering,” J. Systems and Software, vol. 47, nos. 2-
3, pp. 111-124, July 1999.
[51] D. Ratbe, W. King, and Y. Kim, “The Fit Between Project
Characteristics and Application Development Methodologies: A
Contingency Approach,” J. Computer Information Systems, vol. 40,
no. 2, pp. 26-33, 1999-2000.
[52] T. Roberts, M. Gibson, and K. Fields, “System Development
Methodology Implementation: Perceived Aspects of Importance,”
Information Resources Management J., vol. 12, no. 3, pp. 27-38, July-
Sept. 1999.
[53] T. Roberts, M. Gibson, K. Fields, and R. Rainer, “Factors that
Impact Implementing a System Development Methodology,”
IEEE Trans. Software Eng., vol. 24, no. 8, pp. 640-649, Aug. 1998.
[54] E. Rogers, Diffusion of Innovations, third ed. New York: Free Press,
1983.
[55] D. Schifter and I. Ajzen, “Intention, Perceived Control, and Weight
Loss: An Application of the Theory of Planned Behavior,”
J. Personality and Social Psychology, vol. 49, pp. 843-851, 1985.
[56] Software Engineering Institute, Process Maturity Profile of the
Software Community 1999 Year End Update, Mar. 2000, http://
www.sei.cmu.edu/sema/pdf/2000mar.pdf.
[57] F. Sultan and L. Chan, “The Adoption of New Technology: The
Case of Object-Oriented Computing in Software Companies,”
IEEE Trans. Eng. Management, vol. 47, no. 1, pp. 106-126, Feb. 2000.
[58] S. Taylor and P. Todd, “Understanding Information Technology
Usage: A Test of Competing Models,” Information Systems
Research, vol. 6, no. 2, pp. 144-176, 1995.
[59] R. Thompson, C. Higgins, and J. Howell, “Personal Computing:
Toward a Conceptual Model of Utilization,” MIS Quarterly, vol. 15,
no. 1, pp. 125-143, Mar. 1991.
[60] H. Triandis, “Values, Attitudes, and Interpersonal Behavior,”
Nebraska Symp. Motivation, 1979, H. Howe and M. Page eds.,
pp. 195-259, 1979.
Authorized licensed use limited to: ALTRAN. Downloaded on March 10,2021 at 14:21:06 UTC from IEEE Xplore. Restrictions apply.
1145
[61] V. Venkatesh, “Creation of Favorable User Perceptions: Exploring
the Role of Intrinsic Motivation,” MIS Quarterly, vol. 23, no. 2,
pp. 239-260, June 1999.
[62] V. Venkatesh and F. Davis, “A Theoretical Extension of the
Technology Acceptance Model: Four Longitudinal Field Studies,”
Management Science, vol. 46, no. 2, pp. 186-204, Feb. 2000.
[63] I. Vessey and R. Glass, “Strong vs. Weak Approaches to Systems
Development,” Comm. ACM, vol. 41, no. 4, pp. 99-102, Apr. 1998.
[64] I. Vessey, S. Jarvenpaa, and N. Tractinsky, “Evaluation of Vendor
Products: CASE Tools as Methodology Companions,” Comm.
ACM, vol. 35, no. 4, pp. 90-105, Apr. 1992.
[65] R. Whiting, “Development in Disarray,” Software Magazine, vol. 18,
no. 12, p. 20, Sept. 1998.
[66] J. Wynekoop and N. Russo, “Systems Development Methodolo-
gies: Unanswered Questions,” J. Information Technology, vol. 10,
pp. 65-73, 1995.
[67] S. Yadav, N. Shaw, L. Webb, and C. Sutcu, “Comments on ‘Factors
that Impact Implementing a System Development Methodology,’”
IEEE Trans. Software Eng., vol. 27, no. 3, pp. 279-281, Mar. 2001.
[68] E. Yourdon, “Where’s the Basis for Year 2000 Optimism?”
Computerworld, vol. 32, no. 7, p. 68, 1998.
[69] R. Zmud, “An Examination of ‘Push-Pull’ Theory Applied to
Process Innovation in Knowledge Work,” Management Science,
vol. 30, no. 6, pp. 727-738, June 1984.
[70] R. Zmud, “Diffusion of Modern Software Practices: Influence of
Centralization and Formalization,” Management Science, vol. 28,
no. 12, pp. 1421-1431, Dec. 1982.
Cynthia K. Riemenschneider is an assistant
professor of information systems in the Walton
College of Business at the University of Arkan-
sas. Her research has appeared in Information
Systems Research, Information and Manage-
ment, The Journal of Computer Information
Systems, and others. She currently conducts
research on IT and small businesses, IT adop-
tion, and people in IT.
Bill C. Hardgrave holds the Edwin and Karlee
Bradberry Chair in Information Systems and is
the executive director of the Information Tech-
nology Research Center in the Walton College
of Business at the University of Arkansas. His
research interests include software develop-
ment, software process improvement, object-
oriented development, and adoption of software
development innovations. He has published in
such journals as The Journal of Management
Information Systems, Communications of the ACM, IEEE Software, The
DATA BASE for Advances in Information Systems, Information &
Management, Journal of Systems and Software, and Educational &
Psychological Measurement, among others. He is a member of the IEEE
Computer Society.
Fred D. Davis is a professor, David D. Glass
Chair, and the department chair of Information
Systems at the Walton College of Business,
University of Arkansas. His research on user
acceptance of information technology and com-
puter-assisted decision making has appeared in
MIS Quarterly, Management Science, Decision
Sciences, and Organizational Behavior and
Human Decision Processes.
. For more information on this or any computing topic, please visit
our Digital Library at http://computer.org/publications/dlib.