J. Service Science & Management, 2010, 3, 265-271
doi:10.4236/jssm.2010.32032 Published Online June 2010 (http://www.SciRP.org/journal/jssm)
Exploring the Nature of Information Systems
Development Methodology: A Synthesized View
Based on a Literature Review
Daniela Mihailescu1, Marius Mihailescu2
1Jönköping International Business School, Jönköping, Sweden; 2School of Economics and Management, Lund University, Lund, Sweden.
Received July 18th, 2009; revised February 25th, 2010; accepted April 16th, 2010.
ABSTRACT
New Information Systems Development Methodologies (ISDMs) are suggested in the belief that their deployment would
be beneficial to consultants in their work. A large number of ISDMs already exist but their value has been questioned
and at the same time new methodologies continue to be introduced in an attempt to support and improve the practice of
information systems development work. What is not always clear from current studies is that ISDM is a multi-perspec-
tive and cross-discipline phenomenon. Although a large amount of knowledge of ISDM is available, different discipli-
nary interests have resulted in fragmented assessments of it. This paper intends to identify theoretical perspectives ap-
plied in the conceptualization of ISDM. A review of the literature on ISDM was conducted and four different theoretical
perspectives were identified: 1) system, 2) structure, 3) innovation, and 4) knowledge. While each perspective provides
various overarching depictions of ISDM, the synthesized view of ISDM provided in this study reveals the complexities
and ambiguities of a multifaceted phenomenon such as ISDM. Suggestions for an alternative conceptualization of ISDM
are provided in an attempt to facilitate the investigation of ISDM.
Keywords: Information Systems Development Methodology, CASE Tools, Software Process Innovation, Literature Review
1. Introduction
In response to the pressure for more efficiency and effec-
tiveness as well as flexibility and quality in Information
Systems Development (ISD), new development models
and methods, such as rapid product development, agile
software development, and component-based develop-
ment, have been suggested and are considered to be
beneficial to consultants in their work. Yet, the quality of
IS continues to be problematic, resulting in various out-
comes and, once again, calling into question the value of
the new information Systems Development Methodolo-
gies (ISDM). What is not always clear from current IS
studies is the fact that ISDM represents a multi-perspec-
tive and cross-level phenomenon of study. In line with
other authors [1,2], it is these authors’ contention as well
that ISDM have a central role in implementing or de-
signing IS and educating tomorrow’s professionals. At
the same time, the opinion of these authors is that exist-
ing descriptive and fragmented approaches to studying
ISDM provide contradictory results, on the one hand
reducing the likelihood of understanding and hence of
supporting the design of constantly evolving systems, on
the other hand limiting the relevance and value of our
theories and educational programs.
2. Challenging Issues Related to ISDM
The history of ISDM goes back to the 1960s and to the
use of computers by businesses and the emergence of
business applications, which represented a novel area of
interest registering a rapid expansion [3]. Since then, the
study of ISDM has attracted researchers across a range of
research fields offering a rich set of descriptions and ex-
planations of the ISDM phenomenon. Considerable at-
tention from practitioners and several research streams
has contributed to an impressive knowledge base for ef-
ficient and effective ways of developing information
systems (IS) which over the years have been formalized
and incorporated in a vast number of generic ISDM. De-
spite divergent opinions regarding the terminology and
related semantic aspects, ISDM is considered to repre-
sent a collection of interrelated components aimed to
support and improve the ISD practice [4,5]. In spite of
these efforts, the ISD continues to be problematic and

Exploring the Nature of Information Systems Development Methodology:
266
A Synthesized View Based on a Literature Review
hence the significance of the methodological assump-
tions and, implicitly, ISDM is questioned as well.
The understanding of ISDM and its value has changed
over the years from being a panacea for ISD, if used in a
prescriptive and consistent way, to being a necessary but
insufficient means in the development of IS [6,7]. More-
over, some of them are considered unsuitable for analyz-
ing, designing and managing unpredictable situations
characterized by complexity and uncertainty [8,9]. Addi-
tionally, ISDMs are often considered unsuitable for some
individuals and settings, and similar ISDMs in similar
settings apparently yield distinctly different results [3,9].
While some authors are critical to the exaggerated em-
phasis placed on ISDM and suggest the introduction of
improvisation [10] or amethodical thinking [9], others
offer a word of warning against returning to an era char-
acterized by an ad-hoc, trial-and-error, and person-de-
pendent ISD [11].
This body of literature provides a rich description of
the challenging issues related to ISDM and, in spite of
potential value, apparently the lack of it. In addition, al-
though a sizable body of literature in the IS field that
addresses various ISDM issues, the conceptualization
and assessment of ISDM appears to be fragmented re-
flecting different disciplinary interests and perspectives.
The purpose of this paper is to identify theoretical per-
spectives applied in the conceptualization of ISDM and
to present a synthesized view of ISDM that reveals the
complexities and ambiguities of a multifaceted phe-
nomenon such as ISDM. The method for selecting and
categorizing the literature is briefly described in the fol-
lowing section.
3. Method
We took ISDM as unit of analysis and used Google
Scholar beta to search through web databases by com-
bining following terms: systems development method or
methodology, CASE tools and software process innova-
tion. A type of snowball sampling technique was used as
a next step in the data collection process in order to iden-
tify additional studies by consulting the references listed
by the collected studies. Our exploratory search resulted
into a collection of 547 sources. From the sizable and
heterogeneous body of literature on ISDM we retained
the studies that stated a theoretical perspective or pre-
sented a definition of ISDM. The remaining papers were
analyzed and categorized based on the theoretical per-
spective on ISDM applied in the study. From the entire
set of articles we identified four different theoretical
perspectives on ISDM: 1) system, 2) structure, 3) inno-
vation, and 3) knowledge. Since the conceptualization of
ISDM was depicted differently within each perspective,
we analyzed each conceptualization with regard to its
scope in terms of content and features, and focus. The
next section presents the results of our literature review.
4. Theoretical Perspectives on ISDM
One of the conceptualizations of ISDM follows from
General System Theory [12], which helps to conceptual-
ize and explain complex and abstract concepts by con-
ceiving them as systems. A system is regarded as a col-
lection of complementary and interacting components
characterized by properties, capabilities, behavior and a
boundary which separates it from its environment, de-
signed to provide particular functionalities.
4.1 ISDM as System
The interpretation of ISDM as a system has been used by
several authors. For instance an interpretation of Systems
Methodology (SM) is epitomized as a:
“meta-system in its own right, incorporating skilled
people, organization, tools, methods, techniques, etc. The
SM is for individuals, teams and teams of teams, and can
address problems from the small to the global, from the
technological to the social and international.” [5]
This starting point emphasizes the importance of un-
derstanding ISDM as an indivisible whole consisting of
interacting but different types of components or subsys-
tems. In the realm of engineering research the efforts
have been directed toward providing procedural guidance
and ISDM components like methods, techniques, and
tools, in order to ensure efficiency and to:
 transform the software development from an ad
hoc craft activity into a controlled and consis-
tent production process [13]
 reduce software complexity, improve compre-
hensibility, promote reuse, and facilitate evolu-
tion [14]
Rather than considering human and societal compo-
nents, the focus of the engineering view is on the devel-
opment of generic artifacts. The field of method engi-
neering has particularly focused on the development and
composition of meta-methods [15].
In the area of IS the efforts have been concentrated on
the interaction between artifacts and human and social
components, as well as their properties. One field of re-
search which has focused on both development and use
of ISDM, or parts of it, by individual developers or
groups of stakeholders, is the field of ISD research. An
alternative way to define ISDM is as:
“an organized collection of concepts, methods (or
techniques), beliefs, values, and normative principles
supported by material resources … and a codified set of
goal-oriented ‘procedures’ which are intended to guide
the work and cooperation of the various parties (stake-
holders) involved in the building of an information sys-
tems application.” [4]

Exploring the Nature of Information Systems Development Methodology:
267
A Synthesized View Based on a Literature Review
Despite ongoing issues and diverse interpretations,
ISDM seems to include a collection of interrelated com-
ponents such as
 Paradigms―a fundamental set of assumptions
about knowledge, how to acquire it and about
the physical and social world, that provide a
way of thinking adopted by a professional
community and allow its members to share
similar perceptions and engage in commonly
shared practices [11,16]
 Approaches―a set of goals, fundamental con-
cepts and principles describing desirable fea-
tures of a product and the development process
model which represents the sequences of stages
through which a system evolves. They influ-
ence the interpretations and actions in systems
development and related methods, techniques,
and tools [17]
 Methods―defines the tasks and activities to
perform at least one complete phase of systems
development being based typically on a par-
ticular approach and associated with a set of
techniques, tools, and documentation [17,18]
 Techniques―procedure with a prescribed nota-
tion to perform and guide a development activ-
ity or a well-defined sequence of elementary
operations that more or less guarantee the
achievements of certain outcomes if executed
correctly [15,17]
 Development tools―embody a particular me-
thodology [19] and provide support in ISD
processes [15,20], enforcing a particular set of
steps and restricting developers’ choices [19]
This perspective provides a description of the structure
of ISDM and reveals the relation among ISDM compo-
nents and its role, i.e., to support potential stakeholders in
achieving their purposes, e.g., to develop an IS, to man-
age the development, or solve a problem. Alternative
conceptualizations of ISDM have been suggested by ap-
plying or integrating various theories including structura-
tion [21,22], innovation diffusion and adoption [23,24],
knowledge diffusion and assimilation [18,25,26], and
learning [3,8,27].
4.2 ISDM as Structure
ISDM is framed as a structure by Orlikowski [21,22],
who argues that technology in general and ISDM in par-
ticular represent “a kind of structural properties of or-
ganizations developing and/or using technology. That is,
technology embodies and hence is an instantiation of
some of the rules and resources constituting the structure
of an organization” [21]. Although the characteristics of
ISDM are not explicitly discussed by the author, she
makes a distinction between ISDM and CASE tools
categorizing the first as a radical innovation and the latter
as an incremental innovation. Hence, the implementation
of an ISDM is considered to result in a radical change or
reorientation of the organization, while the implementa-
tion of one of its components, e.g., the CASE tool com-
ponent, is considered to result in an incremental change
or variation. A product or process reorientation implies
radical changes and might lead to resistance or even re-
jection [22].
Based on ISD empirical literature, is suggested that
structures like ISDM might be invoked in the ISD con-
text by stakeholders in learning or knowledge acquisition,
conflict, negotiation, communication, influence, control,
coordination, and persuasion. Although the structuration
perspective does not insist on the content or properties of
ISDM like the previous strand of research, it provides the
view of ISDM as a means of change. [19]
4.3 ISDM as Innovation
Based on IS implementation model [28], which inte-
grates IS implementation research and Diffusion of In-
novation theory (DOI) [29], Huisman and Iivari found
that along with other individaual, organizational, task,
and environmental factors, the characteristics of ISDM
perceived by systems developers to influence deploy-
ment of ISDM are:
 relative advantage―the degree to which an
innovation is perceived as better than the idea it
supersedes
 compatibility―the degree to which an innova-
tion is perceived as consistent with existing
values, past experience and needs of potential
adopters
 trialability―the degree to which an innovation
may be experimented with on a limited basis
[24]
In a similar vein, but by combining DOI and Technol-
ogy Acceptance Model, it is founded that, besides social
pressure and organizational mandate, the characteristics
of ISDM in terms of usefulness and compatibility are
significant predictors for software developers’ intention
to use ISDM [23]. As showed by Venkatesh et al., who
reviewed the user acceptance literature and formulated a
Unified Theory of Acceptance and Use of Technology,
the two constructs relative advantage and usefulness are
similar and highlight individuals’ performance expec-
tancy [30]. In other words, at an individual unit of adop-
tion, ISDM is perceived as a potential means, which, if
used, enables gains in job performance. Moreover, the
deployment of ISDM is perceived to improve communi-
cation and the career of individual developers [31]. The
other two characteristics of ISDM, compatibility and
trialability, are perceived to remove barriers and are
therefore considered significant to facilitate intention

Exploring the Nature of Information Systems Development Methodology:
268
A Synthesized View Based on a Literature Review
formation and use.
An emphasis on individual developer perceptions is
considered to be suitable to inform suppliers and manag-
ers about developers’ beliefs about ISDM [23]. Yet, it is
also considered too narrow to be of much use for organi-
zations which adopt ISDM, because of its broadcaster-
receiver perspective on communication, which under-
emphasizes the challenges and the role of adopters [32].
Therefore, researchers drawing on a knowledge dif- fu-
sion perspective have centered their attention on analyz-
ing the barriers that can impede the transfer or the inte-
gration of knowledge within or across organizations and
communities.
4.4 ISDM as Knowledge
Drawing on a knowledge diffusion perspective, ISDM
has been conceptualized as a source of knowledge which
embodies “best practice” in ISD within an organization
or IS community [2,18]. Accordingly, ISDM is regarded
as an object that can be transferred through some form of
communication from a supplier side [18], and assimilated
through learning on the adopter side [25]. While these
sides have two distinct roles in relation to the ISDM, in
both cases the aim of the ISDM is to support or change
the knowledge base and hence the practice within an or-
ganization or IS community. Based on a knowledge
transfer perspective, it is argued that an external ISDM
has to be adapted and incorporated into the specific
knowledge base of an organization, forming in this way a
new and organization-specific knowledge which repre-
sents an important core capability of a software devel-
opment organization [1]. Focusing on the assimilation of
software process innovations, which represent a class of
complex innovation technologies, it is claimed that in-
novations of this type produce significant changes to a
group’s process for developing software applications. [33]
Additionally, such innovations have the potential to in-
crease returns on adoption having a high network poten-
tial but, when first introduced, generate high knowledge
barriers and low performance relative to current best
practices. According to the author, software process in-
novations impose a substantial knowledge burden on
adopters impeding their deployment due to characteris-
tics such as being:
 abstract―have an abstract and demanding sci-
entific base, are eventually not physically ob-
servable, are more difficult to explain requiring
a more active and prolonged learning period on
the part of adopters in order to grasp and de-
ploy them
 fragile―in the sense that they do not always
operate as expected, have core features that
must be replicated exactly to get expected re-
sults, create uncertainty for users, and require
more resources and “hand holding” during de-
ployment; performance in the laboratory repre-
sents a poor predictor of performance in prac-
tice
 trialable―are difficult to trial in a meaningful
way, are difficult to introduce and install in
stages, and in order to obtain benefits require
that organizations compress all learning about
them into a pre-implementation phase
 unpackaged―in the sense that adopters cannot
treat the technology as a “black box”, but must
acquire broad tacit knowledge and procedural
know-how to use it effectively, since the sub-
components of a technology cannot be tightly
bundled into a turnkey product that can be in-
troduced into organizations unchanged; users
are confronted with learning the operational
details of all components and their potential in-
teraction
Regarded from a short-time perspective, it seems that
ISDM creates problems for potential adopters who, as
suggested by Beynon-Davies and Williams, need to un-
bundle the simplified and “black-boxed” solutions pro-
vided by the supply side, and integrate them with locally
situated knowledge [18]. ISDM is considered as abstract,
simplified knowledge detached from practice [3,8]. Ac-
cording to the authors, ISDM represents a means of for-
malization and an instrument that can be used by indi-
viduals for setting goals and making decisions [8], a
means of transferring knowledge between experienced
and novice developers, and templates to guide the de-
velopment practice of new recruits [3]. The authors sug-
gest that formalized ISDMs are rarely applied in their
entirety and exactly as originally intended, but are uni-
quely enacted by developers in work practice, i.e., they
are adapted or tailored differently in any development
project.
ISDM has also been interpreted from a learning per-
spective [27]. Yet, according to the authors, ISDM is not
a holder of knowledge but an evolving artifact which
becomes understandable and meaningful as it is used.
Accordingly, ISDM has been interpreted as a boundary
object needed to mediate knowledge communication
within as well as between communities [27]. The sig-
nificant features of a boundary object, and hence of
ISDM, that facilitate communication, coordination and
collaboration are, according to Wenger:
 modularity―the object represents a combina-
tion of interrelated components which can be
attended by the users
 abstraction―the object provides a common
ground simultaneously allowing features spe-
cific to each user perspective
 adaptation―the product lends itself to different

Exploring the Nature of Information Systems Development Methodology:
269
A Synthesized View Based on a Literature Review
activities
 standardization―the resources in the product
are formalized indicating how to be used in a
particular context [34]
From this perspective, ISDM is not simply acquired
but must be created and communicated through the in-
teraction of members of a group who try to solve a par-
ticular work problem in practice [27]. Since ISDM repre-
sents the outcome of knowledge creation and learning,
which are situated, the perception of, and interest in
ISDM will therefore differ with regard to the position of
the participants. This position is different from the one
provided by the knowledge diffusion perspective, ac-
cording to which the relationship between participants is
based on a notion of control and formalization which
provides a way of exchanging information, i.e., the
ISDM is created by a supplier and communicated to po-
tential adopters. Underpinned by a learning perspective,
the studies frame ISDM as reminder that trigger knowl-
edge and as guides to interpretation and action in IS de-
velopment projects, thus representing a means of com-
munication, coordination, control, and production.
Each perspective on ISDM identified in this literature
review provides a different view on ISDM and its poten-
tial roles in different contexts. Table 1 summarizes the
Table 1.
Conception Scope: contents
(1) & features (2) Focus Sources
System
1) paradigm,
ap
p
roach, methods,
techniques, tools
2) generic,
formalized,
structured, reusable
Development
and deployment
of ISDM
components in
ISD projects
[4,5,11,15,
16,20,35,36]
Structure
1) methodology
and CASE tools
2) –
Deployment of
ISDM within
organization
[19,21,22]
Innovation
1) –
2) relative
advantage, com-
patibility and
trialability
Individuals’
deployment of
ISDM
[23,24,31]
Knowledge
1) –
2) abstract,
fragile, trialable,
unpackaged;
modularity,
abstraction,
adaptation,
standardization
Deployment of
ISDM between
individuals as
well as within
or between
collectives (e.g.,
groups,
organizations,
communities)
[1,2,8,18,
25-27]
four theoretical perspectives applied in the conceptuali-
zation of ISDM along with their scope and focus and,
due to space constraints, a limited example of sources.
5. Discussions
Although the literature review presented in this paper is
not exhaustive, it highlights different ways in which
ISDM has been conceptualized and addressed with re-
gard to particular disciplinary concerns. The literature
offers potential explanations for the dissension that con-
tinues to exist with regard to the nature and potential
value of ISDM. Firstly, it reveals a shifted focus from the
content of ISDM and its potential to support and guide
the development of IS and management of the develop-
ment process towards its characteristics and potential to
change, i.e., innovation, learning, and structuration. Sec-
ondly, the assessment of ISDM deployment in isolation
at individual [24], project [3], organization [21], or com-
munity [18] level, appears to be beneficial and to extend
human capabilities by providing support for e.g., produc-
tion, coordination, and collaboration. But, since these
levels are related in a nested hierarchy, ISDM deploy-
ment might have not only intended but also unintended
and, as indicated in the literature, unfortunately detri-
mental consequences, e.g., resistance, rejection, and
knowledge barriers. For instance, efficiency gains ex-
pected to be achieved in the development of IS as a result
of the introduction of ISDM within an organization
might be lost because of a lack of compatibility with us-
ers’ activities, values, or knowledge. Hence, a broad
conceptualization of ISDM seems to be an appropriate
point of departure in order to make sense of seemingly
contradictory findings.
Such a conceptualization would suggest that the main
purpose of ISDM, at least in general terms, is to extend
human capabilities which would allow human agents to
perform valuable functionings, i.e., those functionings
that one has reason to value [37]. A capability, as con-
ceived by Smith and Seward, who draw on realist social
theory and critical realism, represents a configuration of
three components, namely structure, agency, and cultural
system, which are considered necessary for the achieve-
ment of associated functionings [37]. However, a capa-
bility set delineated by the interaction of these compo-
nents embodies only potential functionings, while the
outcomes of actual functionings are considered to be
contingent on ambient conditions existent in the context
where the capabilities are instantiated. By regarding
ISDM as an intervention, the capabilities that such an
intervention should aim to ensure are those that develop
agential capacity and facilitate structural and cultural
opportunities. Thus, we may assume that lack of atten-
tion to all these three components, i.e., structure, agency,
and cultural system, will reduce the success of an ISDM

Exploring the Nature of Information Systems Development Methodology:
270
A Synthesized View Based on a Literature Review
intervention. In other words, in such an intervention it
will not be enough to develop and provide sophisticated
ISDM components or communicate and accumulate in-
formation and knowledge, but it will also be necessary to
facilitate their deployment and learning.
6. Conclusions
The synthesis of the fairly large and heterogeneous lit-
erature on ISDM presented in this study reveals the com-
plexities and ambiguities of a multifaceted phenomenon
such as ISDM. Based on the literature review, four theo-
retical perspectives on ISDM were identified: 1) system,
2) structure, 3) innovation, and 4) knowledge. While
each perspective regarded in isolation provides different
overarching depictions of ISDM, together they provide a
more nuanced picture of ISDM and its potential value in
different contexts. Our literature review of ISDM is lim-
ited by our selective and incomplete use of prior litera-
ture. For instance, an additional theoretical perspective
applied by Atkinson in order to explain the deployment
of ISDM, i.e., the actor-network theory, emerged late in
our work and we could not include it in our review [38].
Definitely, this should be examined in future research
since it may reveal additional valuable insights into the
role of ISDM within networks. We hope that our analysis
will inspire other scholars and help guide conceptually
sound investigations in order to reveal the scope, poten-
tial roles, and impact of ISDM.
REFERENCES
[1] P. Backlund, C. Hallenborg and G. Hallgrimsson, “Transfer
of Development Process Knowledge through Method
Adaptation and Implementation,” Proceedings of the
Eleventh European Conference in Information Systems,
Naples, Italy, June 18-21, 2003, pp. 122-125.
[2] J. Iivari, R. Hirschheim and H. K. Klein, “Towards a
Distinctive Body of Knowledge for Information Systems
Experts: Coding ISD Process Knowledge in Two IS Jour-
nals,” Information Systems Journal, Vol. 14, No. 4, 2004,
pp. 313-342.
[3] B. Fitzgerald, N. L. Russo and E. Stolterman, “Informa-
tion Systems Development: Methods in Action,” McGraw-
Hill Education, London, 2002.
[4] J. Iivari, R. Hirschheim and H. K. Klein, “A Dynamic
Framework for Classifying Information Systems Devel-
opment Methodologies and Approaches,” Journal of
Management Information Systems, Vol. 17, No. 3, 2000,
pp. 179-218.
[5] D. K. Hitchins, “Systems Methodology,” 2007. http://
www.hitchins.net/SysMethodology.html
[6] L. D. Introna and E. A. Whitley, “Against Method-Ism:
Exploring the Limits of Method,” Information Technol-
ogy & People, Vol. 10, No. 1, 1997, pp. 31-45.
[7] K. Lyytinen and D. Robey, “Learning Failure in Informa-
tion Systems Development,” Information Systems Jour-
nal, Vol. 9, No. 2, 1999, pp. 85-101.
[8] L. Mathiassen, “Reflective Systems Development,” Scan-
dinavian Journal of Information Systems, Vol. 10, No.
1-2, 1998, pp. 67-117.
[9] D. Truex, R. A. Baskerville and J. Travis, “Amethodical
Systems Development: The Deferred Meaning of Sys-
tems Development Methods,” Accounting, Management
and Information Technology, Vol. 10, No. 1, 2000, pp.
53-79.
[10] C. Ciborra, “The Labyrinth of Information: Challenging
the Wisdom of Systems,” Oxford University Press, Ox-
ford, 2007.
[11] D. Avison and G. Fitzgerald, “Information System De-
velopment. Methodologies, Techniques and Tools,” 4th
Edition, McGraw-Hill, New York, 2006.
[12] Von L. Bertalanffy, “General System Theory: Founda-
tions, Development, Applications,” George Braziller,
New York, 1968.
[13] D. Kafura, “A Survey of Software Metrics,” Proceedings
of the 1985 ACM Annual Conference on the Range of
Computing: Mid-80’s Perspective, Denver, Colorado,
1985, pp. 502-506.
[14] P. Tarr, H. Ossher, W. Harrison and Jr. S. M. Sutton,
“Degrees of Separation: Multi-Dimensional Separation of
Concerns,” Proceedings of the 21st International Confer-
ence on Software Engineering, Los Angeles, CA, USA,
May 1999, pp. 107-119.
[15] S. Brinkkemper, “Method Engineering: Engineering of
Information Systems Development Methods and Tools,”
Information and Software Technology, Vol. 38, No. 4,
1996, pp. 275-280.
[16] R. Hirschheim and H. K. Klein, “Four Paradigms of In-
formation Systems Development,” Communications of
the ACM, Vol. 32, No.10, 1989, pp. 1199-1216.
[17] M. Huisman and J. Iivari, “Deployment of Systems De-
velopment Methodologies: Perceptual Congruence be-
tween IS Managers and Systems Developers,” Informa-
tion & Management, Vol. 43, No. 1, 2006, pp. 29-49.
[18] P. Beynon-Davies and M. D. Williams, “The Diffusion of
Information Systems Development Methods,” Journal of
Strategic Information Systems, Vol. 12, No. 1, 2003, pp.
29-46.
[19] V. Sambamurthy and L. J. Kirsch, “An Integrative
Framework of the Information Systems Development
Process,” Decision Sciences, Vol. 31, No. 2, 2000, pp.
391-411.
[20] P. Beynon-Davies, “Information Systems: An Introduc-
tion to Informatics in Organizations,” Palgrave, Basing-
stoke, 2002.
[21] W. J. Orlikowski, “The Duality of Technology: Rethink-
ing the Concept of the Technology in Organizations,”
Organization Science, Vol. 3, No. 3, 1992, pp. 398-427.
[22] W. J. Orlikowski, “CASE Tools as Organizational Change:
Investigating Increment,” MIS Quarterly, Vol. 17, No. 3,

Exploring the Nature of Information Systems Development Methodology:
A Synthesized View Based on a Literature Review
271
1993, pp. 309-340.
[23] B. C. Hardgrave, F. D. Davis and C. K. Riemenschneider,
“Investigating Determinants of Software Developers’ In-
tentions to Follow Methodologies,” Journal of Manage-
ment Information Systems, Vol. 20, No. 1, 2003, pp.
123-151.
[24] M. Huisman and J. Iivari, “The Individual Deployment of
Systems Development Methodologies,” Lecture Notes in
Computer Science, Vol. 2348, 2002, pp. 134-150.
[25] R. G. Fichman and C. F. Kemerer, “The Assimilation of
Software Process Innovations: An Organizational Learn-
ing Perspective,” Management Science, Vol. 43, No. 10,
1997, pp. 1345-1363.
[26] E. Mustonen-Ollila and K. Lyytinen, “How Organizations
Adopt Information Systems Process Innovations: A Lon-
gitudinal Analysis,” European Journal of Information
Systems, Vol. 13, No. 1, 2004, pp. 35-51.
[27] G. Fischer and J. Ostwald, “Knowledge Communication
in Design Communities,” In: R. Bromme, F. Hesse and
H. Spada, Eds., Barriers and Biases in Computer-Medi-
ated Knowledge Communication, Kluwer Academic Pub-
lishers, Netherlands, 2003, pp. 1-32.
[28] T. H. Kwon and R. W. Zmud, “Unifying the Fragmented
Models of Information Systems Implementation,” In:
Boland, R. J. and Hirschheim, R. A. Eds., Critical Issues
in Information Systems Research, John Wiley & Sons,
New York, 1987, pp. 227-251.
[29] E. M. Rogers, “Diffusion of Innovations,” The Free Press,
New York, 1995.
[30] V. Venkatesh, M. G. Morris, G. B. Davis and F. D. Davis,
“User Acceptance of Information Technology: Toward a
Unified View,” MIS Quarterly, Vol. 27, No. 3, 2003, pp.
425-478.
[31] R. A. Johnson, B. C. Hardgrave and E. R. Doke, “An
Industry Analysis of Developer Beliefs About Object-
Oriented Systems Development,” The DATA BASE for
Advances in Information Systems, Vol. 30, No. 1, 1999,
pp. 47-64.
[32] S. Newell, J. A. Swan and R. D. Galliers, “A Knowl-
edge-Focused Perspective on the Diffusion and Adoption
of Complex Information Technologies: The BPR Exam-
ple,” Information Systems Journal, Vol. 10, No. 3, 2000,
pp. 239-259.
[33] R. G. Fichman, “The Assimilation and Diffusion of
Software Process Innovations, Unpublished,” Ph. D. Dis-
sertation, MIT Sloan School of Management, 1995.
[34] E. Wenger, “Communities of Practice: Learning, Mean-
ing, and Identity,” Cambridge University Press, Cam-
bridge, UK, 1998.
[35] C. Ghezzi, M. Jazayeri and D. Mandrioli, “Fundamentals
of Software Engineering,” 2nd Edition, Prentice Hall, UK,
2003.
[36] K. Kumar and R. Welke, “Methodology Engineering: A
Proposal for Situation-Specific Methodology Construc-
tion,” In: W. Cotterman and J. Senn, Eds., Challenges
and Strategies for Research in Systems Development,
John Wiley & Sons, New York, US, 1992, pp. 257-269.
[37] M. L. Smith and C. Seward, “Causal Theories and Citi-
zenship: Bridging the Theory-Data Gap in Sen’s Capabil-
ity Approach,” The 5th International Conference on the
Capability Approach: Knowledge and Public Action,
Paris, France, September 11-14, 2005.
[38] C. J. Atkinson, “The Soft Information Systems and Tech-
nologies Methodology: An Actor Network Contingency
Approach to Integrated Development,” European Journal
of Information Systems, Vol. 9, No. 2, 2000, pp. 104-123.