paper I want to fix it - clean it up -organize it and add
1
An Elaborated Action Design Research Process Model
Matthew Mullarkey and Alan Hevner
Information Systems and Decision Sciences
Muma College of Business
University of South Florida
Tampa, FL 33620
{ mmullarkey@usf.edu; ahevner@usf.edu }
Citation: M. Mullarkey and A. Hevner (2018). An Elaborated Action Design
Research Process Model, European Journal of Information Systems, In Press.
Abstract: This research essay proposes an elaborated process model for applying the Action Design
Research (ADR) approach to immersive industry-based projects. Building on the original ADR
concepts, we identify four distinct types of ADR cycles for diagnosis, design, implementation, and
evolution of the growing artifact-based solution. Each ADR cycle moves through activities of
problem formulation, artifact creation, evaluation, reflection, and learning. Rapid iterations of ADR
cycles provide a well-defined process map for managing and performing an emergent ADR project.
The proposed model supports multiple entry points based on the current state of the problem
environment and the goals of the ADR project. The elaborated ADR process model provides a more
flexible yet disciplined inquiry into the initiation, conduct, reflection, and presentation of rigorous
and relevant ADR projects.
Keywords: Action design research (ADR), Design science research ( D S R ) , ADR process model,
Co-creation, Iterative intervention cycles, Entry points
1 Introduction
Action design research (ADR), presented in the seminal paper by Sein, Henfridsson, Purao, Rossi, and Lindgren
(2011), provides an insightful structured process model for combining the activities of action research (AR) (Susman
and Evered, 1978) and design science research (DSR) (Hevner, March, Park, and Ram, 2004). ADR is used effectively
in many research projects and, because of its ever-expanding applications, the ADR concepts and process model
continue to grow and evolve to meet the demands of new and challenging environments.
A recent research project of ours employs an ADR approach to the design and development of a novel artifact
instantiation in a new IT solution class – an Inter-Organizational Social Networking Information System (IO SNIS) –
also known as an Enterprise Social Network System. The project required that we intervene in situ with practitioners
in the mid-market private equity (MMPE) domain who are interested in opportunities associated with the cost and
efficacy of online social networking to identify deal-making opportunities in the MMPE space (Mullarkey, Hevner,
and Collins, 2013). During the performance of this research, we identified several key opportunities to more fully
elaborate and actualize the ADR process model in order to aid the conduct of each intervention cycle and to make
more explicit the knowledge generation in ADR studies. Our immersive experience in this project provided the
occasion to reflect on how an elaborated ADR process model could better support users to structure the key decisions
2
and activities necessary to rigorously apply ADR. Section 2 expands on our project experiences. This leads in Section
3 to a detailed discussion of the elaborated ADR process model. In Section 4, we present a brief review of recently
published ADR projects and analyze their mappings to the new process model. Section 5 discusses the implications
and applications of the proposed model. The final Section 6 presents our conclusions, research limitations, and
directions for future research.
2 Reflecting on an ADR Project
In our IO SNIS research project, we faced the challenge of applying ADR to a complex, ‘wicked’ problem where no
artifact existed to address the opportunities and problems of replicating offline inter-organizational social behavior in
an online environment. (Appendix A provides a more detailed overview of the research context.) To begin, we focused
on the initial diagnosis and design of an innovative information system as a problem solution. We found that every
iteration of our intervention with practitioners provided opportunities to build and evaluate needed design artifacts.
These early artifacts included defining concepts, system requirements, problem and solution models, design principles,
and design features. Long before we actually built an instantiated system, these iterative ADR cycles added
increasingly greater design knowledge from the abstraction, evaluation, reflections, and learnings for each artifact.
For the initial design of our ADR process, we adapted the BIE (build, intervention, evaluation) stage in the ADR
process model as presented in Sein et al. (2011). A key contribution of the BIE cycle is the close integration of artifact
build and evaluation in context. We identified and defined the problem context and then demonstrated the importance
of an innovative artifact solution with the client organization. We determined at the outset that the ADR process must
generate design knowledge that creates innovative artifacts and addresses an organizational need for intervention.
Following the dictates of action research, we conducted this investigation of the phenomenon through multiple
iterative interventions of the researcher-practitioner team in the problem domain. Throughout these iterative
interventions, we recorded our adaptations and alterations to the ADR process model for later reflection toward the
development of the elaborated model presented here.
Once we had agreement among the researchers and practitioners on the problem and its theoretical grounding but
before we could “realize” (i.e. implement) an instantiated information system, we found that we needed to better
understand the problem space, i.e. perform problem diagnosis activities. We observed in the ADR process that these
activities occur as a function of the artifact build, intervention, and evaluation (BIE) stage of the process. We found
that before the organization (or researchers for that matter) were willing to invest in the realization of the ensemble
information system, a significant set of interventions were required that focused on first diagnosing the need for an
ensemble artifact and then additional interventions were required to jointly create possible conceptual designs for the
ensemble artifact. Each iterative intervention cycle produced different artifacts for these activities of diagnosis and
design.
As we studied our use and adaptation of the ADR process, we recognized that the iterative, emergent cycle of
researcher-practitioner intervention could be better visualized as a sequence of iterative cycles of four different types
(diagnosis, design, implementation, and evolution) instead of packing all activities into a single Build, Intervention,
and Evaluation (BIE) stage. We recognized that the various contributions to knowledge throughout the ADR process
3
would differ as the ensemble artifact creation emerged gradually through the stages of diagnosis to design to
implementation and eventually to evolution over time. We also realized that the variety of socio-technical artifacts
produced by a research project is dependent on the starting state of the problem environment and the goals of the
project.
Finally, we recognized that in ADR researchers could and should emphasize the contribution to knowledge of
every single artifact built and evaluated in each iterative cycle. The elaborated ADR process model as presented in the
next section unpacks the steps within each ADR cycle, emphasizes the intervention possible in each stage, values each
artifact built and evaluated, and positions those artifacts on a longitudinal expression of design and implementation of
ensemble information systems.
By identifying an agile pattern of interventions within and between each of these ADR cycles, we also support
the possibility of multiple ADR project entry points. We posit that researchers conducting ADR might start a project
anywhere along the timeline of ensemble system instantiation. For example, a researcher might have missed the
opportunity to participate in an organization’s initial activity to diagnose the need for a system. In that case, the
researcher might start their interventions in the building and evaluation of design artifacts. Equally possible in our
experience, the researcher might only have access to intervene in situ once the system is in its implementation or
evolution stage at a given organization. In each of these cases, we believe it to be essential for clear understanding to
communicate explicitly which stage of ensemble artifact instantiation is at play in the ADR project.
3 Elaborating the Action Design Research Process Model
The original ADR process model identifies a four-stage approach to the application of the AR paradigm in a DSR
study. (See Sein et al. (2011), Figure 1, p. 41.) The four stages are:
1) Problem Formulation
2) Building, Intervention, and Evaluation (BIE)
3) Reflection and Learning
4) Formulation of Learning
The first three stages form an iterative cycle with the research (i.e. learning) results captured and formalized in the
final stage. To assess their ADR method, the authors of the seminal paper ground their study with an example of an
ADR project they conducted with Volvo to adapt a competence management system (CMS) for use by IT and human
resources (HR) knowledge workers (Lindgren, Henfridsson, and Schultze, 2004). Their discussion of the ADR method
draws from that case. The authors enter the research study with an implemented IT instantiation in use by the
organization under study. Their point of entry for the research focuses on the existing artifact (TietoPersona/HR) as
an IT solution class of CMS. They begin their ADR study in the Problem Formulation stage by working through an
“examination of HR literature [to identify that] TietoPersona/HR lacked the dynamism necessary...” [p. 46]. They
describe the next step,
“Based upon the results of the problem formulation stage, the ADR team decided to explore a new
direction. The BIE stage was initiated by envisioning CMS that employed a skill based (as opposed
to job based) model of competence…”
Thus, given their point of entry, the authors iterate from an existing system via a reformulation of the organizational
4
motivation to requirements for a new instantiated ensemble system. They then iterate through the design and then the
implementation of that new ensemble system in the IT solution class chosen.
Thus, in the first BIE stage of the ADR project, they investigate the problems with the existing artifact and
research various options to modify the artifact in several iterative cycles with the practitioners until it becomes clear
that the environment requires a modified CMS artifact. They describe their intervention with the practitioners as
occurring in the BIE stage 2 of ADR. In action research (AR) though, prior researchers including Sussman and Evered
(1978, p. 588-589) find an opportunity for, and in fact encourage, researcher-practitioner intervention in “all or nearly
all phases” of the cyclical process of action research.
In our research project, we applied the ADR process to a problem where no ensemble system existed to address
the problem of replicating offline inter-organizational social behavior in an online enterprise environment. We were
initially unsure of the need for a new artifact. Thus, before we were able to use the ADR stages on an existing
instantiation we needed to investigate aspects of the problem at a much earlier point of entry. We needed to consider
and evaluate the fundamental principles of how and why social networks exist, how they exist to impact PE firms, and
how instantiations of Social Networking Information Systems (SNIS) for Inter-personal networks (e.g. Facebook)
might inform the nature of SNIS for the PE Firm. These activities all appeared to us to be types of diagnosis that are
needed before designing a new ensemble instantiation.
3.1 Elaborating the Activities in an ADR Cycle
The ADR approach itself is quite new and benefits from continual elaboration that marries experience with one or
more ADR engagements and with additional grounding in the action research and DSR paradigms. The two concepts
at the heart of AR are i) the researcher and practitioner co-creation and ii) the iterative intervention cycles (Baskerville,
1999). We find that the details of the BIE engagement in ADR in Sein et al. (2011) are in large part left open to
interpretation by the researcher. Our ADR experience (Mullarkey et al., 2013, Mullarkey and Hevner, 2015) led us to
unpack the BIE stage in ADR to show that (1) intervention is a core concept in the ADR process and should occur
with each ADR cycle and (2) the activities of evaluation (E), reflection (R), and learning (L) occur in each ADR
intervention cycle. We found that our practitioners could better relate to a very explicit ADR Cycle (Figure 1) as
compared to the BIE diagram (Sein et al., 2011, Figure 1, p. 41.)
Figure 1 elaborates on the activities and principles we find inherent in any ADR intervention cycle. Each
intervention cycle (applying the ADR principles of Reciprocal Shaping and Mutually Influential Roles) supports the
full range of ADR activities from problem formulation and planning to artifact creation, evaluation, reflection, and
formalization of learning. The new insight here is that we make explicit the abstracted artifact built and evaluated in
every ADR cycle. We also require the reflection and learning to be performed in every cycle – in large part because
it informs the problem formulation for the next ADR cycle. The elaborated ADR cycle capitalizes on gaining an
understanding of the different nature of the artifacts produced within each intervention cycle and what is
communicated to researchers and practitioners at the completion of that cycle (McKay and Marshall, 2001).
5
Figure 1: The Elaborated Action Design Research (ADR) Cycle
The Artifact Creation activity involves the creation and implementation of the artifact. We observe that the exact
nature of the artifact created will depend upon the stage of the ADR process in which the researcher-practitioner team
is currently engaged. There are many types and forms of artifacts that can be created in any ADR cycle or anywhere
along the ADR process continuum. The building and evaluation of innovative socio-technical artifacts (be they
constructs, design principles, features, models, tools, and/or instantiations) is the key to DSR. At any given point of
entry for an ADR effort, it becomes apparent that the nature and type of artifact being built and the approach and
criteria for evaluation are dependent on that point of entry and the type of intervention that occurs with practitioners.
We show the key ADR concepts (intervention, guided emergence, co-creation) at the center of the cycle as
fundamental to the conduct of each activity on the cycle. We also expect every cycle to go through a Problem
Formulation, Artifact Creation, Evaluation, Reflection, Learning sequence of activities. The elaborated ADR cycle
incorporates the key activities and principles of the current ADR process model with the key addition of the Artifact
abstraction activity as a generalization of the build activity. We complement the original seven ADR principles found
in Sein et al. (2011) with a new Principle 8 – Abstraction that supports the creation of different levels of artifact
abstraction for the current state of research goals in the problem environment (Gregor and Hevner, 2013). An ADR
engagement will normally move through multiple intervention cycles that shift among stages of diagnosing, design,
implementation, and evolution. We posit that the ADR cycle as elaborated can be used as a generic template at all the
different stages in the elaborated ADR process.
3.2 Elaborating the ADR Stages
Figure 2 provides a view of our proposed four-stage ADR Process model with clear paths of forward progress and
feedback loops as required by the emerging project. The important insight we discovered in our project and in our
6
review of ADR projects in literature is that each of the stages supports multiple iterations of the ADR intervention
cycle seen in Figure 1 of Problem Formulation/Action Planning (P), Artifact Creation (A), Evaluation (E), Reflection
(R), and Formalization of Learning (L).
As we discovered in our ADR project, the researcher-practitioner intervention can begin with a thorough
investigation and diagnosis of the problem domain and an evaluation of IT solution classes. The goals of this first
ADR stage, which we term the Diagnosis stage, are to analyze the importance of the problem domain and the relevance
of the IT solution class to research and practice with mutual agreement among the researcher-practitioner team
(Mullarkey and Hevner, 2015). This involves identifying the relevant kernel design theories, any existing socio-
technical artifacts, and the goals of the ADR project. There are two critical areas of learning during the Diagnosis
stage. The researcher must understand the application domain of the project to include specific knowledge of the
practitioner’s organization with its strengths, weaknesses, opportunities, and constraints. At the same time, the
practitioner must become aware of the existing knowledge base of research and practice in the fields of study that will
inform the design and evolution of the intervention artifact.
Figure 2: The Four ADR Stages
Our emphasis on diagnosis often leads the researcher and practitioner to spend more time and effort in initiating
ADR. This emphasis is consistent with the ‘four pragmatic premises’ outlined by Baskerville and Myers (2004) if we
are to insure that the built artifact informs both research and practice. This emphasis on diagnosis also supports a more
abductive reasoning approach as proposed by Lee, Pries-Heje, and Baskerville (2011) where more than one possible
solution – and even a ‘do nothing’ solution – to a given problem may exist in the design and implementation of a
useful IS artifact. In our project, we went through two iterations of the Diagnosis cycle to discover and define the
problem domain and to evaluate adjacent solution domains (Mullarkey et al., 2013). The artifacts that are built and
evaluated in a diagnosis stage can be requirements definitions, technical specifications, and conceptualizations of the
problem and solution domains.
The second key stage in our research project focused on the identification and conceptualization of the proposed
artifact design. We term this the Design stage of the ADR process. It provides a set of activities over the search space
of possible design candidates. Through one or more iterative cycles within the design stage, design principles emerge
that address the problem class identified via diagnosis and move toward the implementation of an IT solution. Here
7
collaborative intervention with co-creation activities are essential as the researcher-practitioner team create designs
that incorporate innovative ideas to solve the given problems. Human cognitive and social skills are applied to make
clear contributions to both the problem environment and the knowledge base of the field (McKay and Marshall, 2001;
Hevner et al. 2004).
The Design stage may be iterated as the problem solution evolves over time in the research project. In our project,
we iterated through two Design cycles as we developed and evaluated design features and then formulated design
principles for the desired IO SNIS system. Typical artifacts designed and built in the ADR Design cycles include
design principles, design features, models, architectures, and implementation methods. Sein et al. (2011) make the
design stage an implicit activity within their BIE stage. We find that a more explicit separation of the Diagnosing from
Design and Design from Implementation stages is more consistent with our experience.
The third stage of the ADR process supports the instantiation of artifacts through an Implementation activity at
the client organization. In the Implementation cycles for our project, we are actively engaged in building and
evaluating our inter-organizational social networking information system as a software system instantiation at the
MMPE client. A real-life intervention provides the opportunity to perform on-site evaluations of the efficiency and
effectiveness of the proposed design as realized in situ. Typical artifacts abstracted and evaluated in the ADR
Implementation cycle include systems, algorithms, programs, databases, and processes.
Finally, we propose a fourth ADR stage as the Evolution of the artifact over time as the problem environment
changes and the artifact solution evolves to meet these changes. We note that the evolutionary processes of problem
re-formulation, technology advancements, design improvements, refactoring, and continual re-engineering
interventions may be a long-term organizational project and will continue to generate knowledge useful to researcher
and practitioner. We find that there is a need to re-consider instantiated artifacts at some point after implementation
and during or after adoption as to how they evolve over time. In Section 4, we provide evidence that many other ADR
research projects iterated flexibly within and between these four stages.
3.3 Multiple ADR Process Entry Points
Another key observation gained from our ADR project is that different problem environments will require different
entry points for initiation (Mullarkey and Hevner, 2015). We argue that the abstraction of artifacts at all ADR stages
informs research and practice and that the nature of innovative artifacts are often different depending upon the ADR
stage involved. In addition, many research-worthy artifacts exist long before the full instantiation of an information
system, including models, constructs, design principles, and innovative design features. All of which researchers
should consider potential contributions to research and practice. The distinction we draw in Figure 2 is that DSR
artifacts can be built and then evaluated in each cycle of any given ADR stage. The artifact built in a given cycle is
built and evaluated in order to address the problem formulated in that ADR cycle. Each iteration learns from one or
more prior cycles and modifies the problem formulation for the next cycle of the research project.
Thus, there are separate starting points possible in any ADR intervention by researcher-practitioner teams. If the
ADR activity begins with an initial goal of identifying design principles (possibly, because the team already has a
solid grasp from prior work on the problem and solution domains) then the team will tend to enter the ADR Process
with one or more ADR Design cycles. The formalization of learning in each of those cycles will lead either to another
8
cycle in the definition of design artifacts or it could propel the ADR investigation onward to an ADR Implementation
stage or directionally back in the process model to better understand the problem in an ADR Diagnosis stage.
The nature of research communication (e.g. publication) also favors a focus on parsimonious pieces of ‘bite-sized’
research contributions. Publication typically allows for a research focus on only a part of any given IS technology,
class of problem, class of solution, or stage in an ADR study. Having a more detailed ADR process that provides
multiple points of entry for researchers facilitates the consideration of research contributions often required to obtain
publication in top-tier journals. As an applied discipline, IS research frequently demands a cyclical process of
abstraction, evaluation, iteration, and modification of theories, constructs, artifacts, and impacts where a clearly
understood starting point is needed as researchers identify and communicate the contributions of their research.
To visualize multiple points of entry, we find it informative to overlay the ADR process stages on the DSR process
(DSRP) model of Peffers, Tuunanen, Rothenberger, and Chatterjee (2007) as seen in Figure 3. We appropriate the
multiple entry points of the DSRP model to position the interventions in the ADR stages. This alignment clearly shows
that four potential entry points for the ADR process are possible and it identifies where the communication of an ADR
entry point enables the researcher to better position the research and communicate its contribution to research, practice,
and innovative artifact development. In fact, the Peffers et al. (2007, p. 72) authors speculate that the DSRP model
“could be used as a structure to present action research.”
Figure 3: ADR Process and DSR Process Models Overlay (Ref: Peffers et al., 2007)
Based on this mapping, we propose four entry points for the elaborated ADR process model as described in Table
1. These entry points provide clear options for project starting points that support well-defined goals and directions
for researcher/practitioners teams as they begin their immersive collaboration.
9
Table 1: Elaborated ADR Entry Points
Entry Point Titles Description Activities Questions
Problem Centered Understand and define the
specific research problem;
Understand and define the
solution space
Problem Identification;
Motivations and Goals for
ADR Project
What is the problem to be
solved in practice?
What are the research
goals of the project?
Why do existing solutions
fall short?
Objective Centered Explore the design
options based on project
objectives;
Generate design
knowledge of what is
feasible in the solution
space
Solution Design;
Development of Design
Principles
What would a better
artifact accomplish?
What are its critical
design principles and
features?
What is possible?
What is feasible?
Development Centered Develop an ensemble
instantiated artifact (e.g.
system to address
research problem;
Demonstrate satisfactory
solution
Solution Implementation;
Demonstration of
Solution
How does the instantiated
artifact solve the
problem?
How to evaluate the
goodness of the solution?
Observation Centered Observe existing system
in context;
Identify possible
evolution opportunities
for system improvements
Improvement Goals;
Evolution Possibilities for
Existing Systems
How has the solution
continued to solve the
problem?
How has the problem
changed and demanded
changes/ improvements to
the solution?
3.4 The Fully Elaborated ADR Process Model
Integrating the proposed extensions from the previous three subsections, we suggest an elaborated ADR Process
Model as presented in Figure 4.
Figure 4: The ADR Process Model with Research Entry Points
10
We believe that for any given problem class and innovative technology solution class, the research point of entry
could occur at any one of the stages in an ADR investigation. In fact, we argue that the researcher-practitioner team
has an obligation to identify the point of entry that motivates their current ADR study. We also observe that the
ultimate goal in ADR as in DSR is the production of one or more innovative artifacts. Since the nature and type of
innovative artifact identified, built, and evaluated will vary with the ADR stage involved, the new process model will
facilitate the knowledge creation and communication by articulating the point of entry for the research conducted.
When performed in adherence with the ADR method, the artifact within each intervention cycle will be constructed
by the researcher-practitioner team in the problem space and be relevant to the problem at that point on the research
continuum of the ADR process model.
Peffers et al. (2007) discuss their DSR process model as being structured in a “nominally sequential order” but
go to lengths to assure the researcher that there “is no expectation that researcher(s) would always actually proceed in
sequential order from activity 1 through activity 6” in the DSRP. (p.92). They find that a DSR project might “start at
almost any step and move outward.” Likewise, we find that multiple entry points in ADR provide the project team
with the flexibility to support interventions and contributions along the complete project life cycle.
In summary, we see the elaborated ADR process model with multiple entry points as a very effective way for
researchers to visualize and communicate the goals and execution steps of their ADR project. The model clearly shows
the ADR Stages, the activities within each of the ADR stages, the problem class, the IT solution class, the intervention
domain, and the innovative artifacts being created and evaluated with in each cycle. We contend that this elaborated
ADR process model significantly improves the facility with which ADR researchers can conduct research in this
paradigm and consistently report knowledge contributions.
4 Evaluating the Elaborated ADR Process Model
To provide a level of face validity to our proposed elaborated ADR process model, we study a selected set of ADR
projects that have been reported in the research literature since the appearance of the Sein et al. (2011) paper. Our
evaluation method is similar to the pragmatic analysis approach used by Peffers, Rothenberger, Tuunanen, and Vaezi
(2012) in their investigation of the extant literature on how DSR artifacts are evaluated. We identified a convenience
sample of published papers that reported completed ADR projects with clearly defined artifacts. We began by reviewing
all citations of the Sein et al. (2011) found in a Google Scholar online search at the beginning of 2017. Across this group
of 761 research papers, we found a representative sample of research projects that use ADR in real-world application
contexts. After eliminating papers that reported on the same project, we narrow the sample to a group of 80 papers. In-
depth reading of these articles found that 20 papers describe projects which create identifiable IS artifacts.
Consequently, we analyze these 20 articles (see Table in Appendix B) that we consider a representative sample of the
ADR literature.
We coded each of the 20 reported projects on the IT Solution Class, the Problem Class, the Intervention Domain,
and the Artifact produced. We found a wide range of application domains including record management, smart cities,
Internet of Things, virtual reality, and knowledge management across multiple industries. Our primary goal in our
analyses is to map each of the ADR projects to the newly proposed ADR process model of Figure 4 in order to identify
evidence of research entry points and ADR stages of intervention. We look to see if, in fact, real ADR studies enter the
11
ADR continuum at different stages of intervention. Second, we attempt to understand the number and types of
intervention cycles reported in the ADR paper. Third, we consider the potential benefits to researchers and practitioners
of the proposed elaborated ADR process model as used as a means of creation and communication of knowledge.
We order the research projects in Appendix B by their discovered entry points. We find that a detailed reading of
the 20 articles allows us to classify the authors’ motivations for the conduct of the research, which leads to identifying
a starting point for their research inquiries. In the 20 examples, twelve projects have problem-centered entry points.
These projects are motivated to create and evaluate Diagnosis artifact types to include nascent design theory, critical
success factors, problem definition, and requirements definition. These projects begin by questioning the reason for an
IT/IS instantiation to solve a particular need. In many cases, they show an iteration within the Diagnosis ADR cycle
and in some cases the research documents further intervention cycles in the Design, Implementation, and Evolution
ADR stages from the initial Problem Centered entry point.
Four projects are identified to have objective-centered entry points. These projects are motivated by the researcher-
practitioner desire to understand what a “better artifact would look like” (Peffers et al., 2007). The articles describe
situations where the need for the IT Solution is not in doubt. In these cases, the ADR interventions create and evaluate
Design artifact types including design principles, features, constructs, and models.
Two projects have a development-centered entry point. Here the ADR interventions tend to evaluate existing
instantiations. Where the instantiation evaluation depends upon multiple stakeholders and/or utility in multiple
settings/environment, multiple iterations within the Implementation ADR stage are described. Where the evaluation
questions the utility of the instantiation, a feedback iteration of the Design ADR stage occurs. The remaining two
projects have observation-centered entry points and the ADR researcher-practitioner effort starts with an implemented
instantiation with a goal to support the effective Evolution of the existing artifacts.
Nine of these ADR projects describe a situation where the ADR effort stayed in the ADR stage associated with the
entry point. In many of these projects, the articles describe more than one ADR cycle iteration within that ADR stage.
They also tend to describe one or more artifacts generated by the multiple ADR cycles.
Several of the ADR studies, however, also offer exemplars where the research describes movement between more
than one ADR Stage. Our research project, for example, as reported in Mullarkey et al. (2013), begins with a problem-
centered entry point. We perform two Diagnosis intervention cycles in order to fully understand the practitioner
application domain and potential IT solution class options. Once sufficient understanding of the problem is achieved,
the project advances in the ADR process to the Design intervention stage. Again, we perform two Design intervention
cycles in order to develop conceptual model artifacts of a proposed IO SNIS for MMPE firms. As another example, the
project descripted in Schacht et al. (2015) identifies the movement of the ADR researcher-practitioner interactions from
Diagnosis to Design to Implementation and then from Implementation to Design to Implementation. The research
describes the ways in which multiple iterative cycles occurred within these stages and how the learnings within stages
informed movement to the next stage. Keijzer-Broers et al. (2016) describes a similarly complex evolution of the ADR
Process within and between ADR Stages.
Overall, we find the use of the terminology and framework of the elaborated ADR process model enhances the
communication and understanding of the ADR stages that occurred. To illustrate, Westin and Sein (2015) describe the
12
execution of multiple ADR cycles along the path from initial diagnosis to design, implementation, and evolution of a
fully implemented instantiation of an innovative Information Quality System (IQS) in the construction-engineering
domain. Examining their timeline of the project (Figure 4, p. 10), it appears that the intervention team conducts several
iterations of the ADR cycle in a phase they call Problem Formulation and that we term Diagnosis. Their multiple
iterations ultimately lead to the definition of a new design concept for a data quality control system – the IQS. The first
half of their next stage – BIE 1 – describes the conduct of design specifications and basic architecture development. In
our model, those iterative efforts would occur in the Design stage of the ADR process where the intervention team has
a specific objective in mind but intervenes to create and evaluate the design principles, features, and architectures. The
second half of their BIE 1 describes the iterative ADR cycle activities we term Implementation. At this stage the team
is development-centered around having “implemented the first set of rules for TestP…implemented automatic IQ5-
report…starting training of end-users” (Westin and Sein, 2015, p. 16). Then, the authors report an evaluation of the
consequences of the implementation that forces the intervention team to re-diagnose and re-define the problem and
solutions domains. Our ADR process model would describe that same progression as a return to the Diagnosis stage.
The project then enters BIE 2 which is a series of iterative cycles back through Design to Implementation and the start
of Evolution for the new technology solution.
The ADR project analyses shown in Appendix B provide a representative, but by no means exhaustive, typology
of cases cross-referenced by ADR stage, entry point, problem class, IT solution class, intervention domain, and
designed artifact. An ADR project typology of this nature at once reinforces the richness of the elaborated ADR
process model and the importance of establishing the research goals and starting points of the ADR project. The
majority of the cases identified in this survey are problem-centered and start with the ADR Diagnosis stage. The ADR
research projects that do not start with Diagnosis, however, can be described more effectively in the context of the
appropriate entry point. Moreover, when an ADR project demonstrates a feedback iteration from Implementation to
Design or from Design to Diagnosis, the proposed process model facilitates the communication of the process at play,
the artifact(s) constructed and evaluated, and the design knowledge gained. There are interesting opportunities for
researchers to better understand and evaluate the goals and results of ADR projects based on their entry points into
research.
5 Discussion
The elaborated ADR process model proposed in this essay is the result of the authors’ experiences in performing an
ADR project on a challenging real-world project. The model elaborations were identified and developed through
‘hands-on’ experience and were found necessary in order for us to complete the research project. We note that this
research approach is quite similar to the research approach in the seminal Sein et al. (2011) ADR paper. Their
conceptual ADR model was built from experiences in a research project on competence management systems at Volvo
IT. They saw a need for an innovative ADR process model and filled it. We have done the same with our elaborated
ADR process model, which elaborates and complements the original process model.
Each of our proposed extensions supports a fuller understanding of how researcher/practitioner teams perform
ADR research:
13
• The ADR intervention cycle of Figure 1 clearly identifies the need for the five activities of Problem
Formulation/Planning (P), Artifact Creation (A), Evaluation (E), Reflection (R), and Learning (L) in every
performed ADR intervention cycle. The recognition that a new artifact at varying levels of abstraction is built in
every cycle is explicitly highlighted. We add an eighth ADR principle to expressly encourage researchers to
identify the socio-technical artifact built and evaluated within each ADR cycle at its appropriate level of
abstraction. Guided by the eight ADR principles, a fuller understanding of the goals and activities of each well-
defined ADR intervention cycle is achieved. This ‘chunking’ of the overall project into well-defined iterative
cycles provides invaluable management guidance and it insures the discipline of evaluation, reflection and
learning within each cycle.
• The four different ADR stages of Figure 2 effectively unpacks the overloaded BIE stage of the original process
model. By distinguishing stages of Diagnosis, Design, Implementation, and Evolution, the project team can better
understand and achieve clear goals with different artifacts produced to achieve those goals. Each of these four
stages has a distinct set of objectives, techniques, set of artifacts and results for use in the application domain.
• The ADR entry points shown in Figure 4 support essential understandings of project goals and offer ADR teams
a means to communicate how they get started in their ADR research study. We draw from the entry point
rationales found in the Peffers et al. (2007) paper to build a similar argument that ADR research teams enter a
project at different points of problem and solution maturity. Every project must assess their goals and intended
research contributions to determine the right starting point in the ADR process model. Then as learning evolves
based on the completion of ADR stages, the research project will discover its most effective path of movement in
the process model to achieve a desirable set of artifacts and research contributions.
• The elaborated model provides a more detailed, open, and transparent view of the activities of an ADR project.
Such transparency allows the researcher-practitioner teams greater opportunities to evaluate and analyze the
socio-technical artifacts produced and the resulting changes made to the application context in iterative cycles.
The ethical and political implications of what it means to design and implement an improved solution can be more
effectively addressed in this more open ADR process model (Agerfalk and Wiberg, 2018).
Current and future ADR research teams can use the elaborated ADR process model to develop research designs that
better reflect their project goals and support clearer project management and research designs. Two issues that deserve
further discussion are the perception of the ADR stages as a ‘waterfall’ model and the overloaded use of the term
‘problem.’
5.1 Scheduling ADR Stages
As we discovered in our ADR project review in Section 4, many of the projects move flexibly among the four ADR
stages. There is clear evidence that teams move between these ADR process stages in both forward and backward (i.e.
feedback) directions. The flexible movement between ADR stages supports an agile, sprint-based approach that aligns
with the goals of many organizational ADR projects. While these four stages of Diagnosis, Design, Implementation,
and Evolution are on a natural continuum as shown in Figure 2 there is no implied ‘waterfall’ progression in execution.
Project teams may perform the ADR stages in any order based on the entry point of the project and the results of prior
14
stages in the project execution.
5.2 Problem as an Overloaded Term
It is always a challenge to use overloaded terms, such as ‘problem,’ in precise ways as we develop conceptual research
models. In this essay, we use ‘problem’ in three distinct forms:
• The Problem Formulation and Planning activity happens within each intervention iteration of the four ADR stages.
• The problem Diagnosis stage occurs when the research team performs an ADR intervention cycle in order to
analyze the problem domain and IT solution class for the conduct of the research.
• The Problem-Centered entry point denotes that the research project begins at a point where the problem domain
is not well understood and the first ADR stage to be performed is a Diagnosis cycle.
Based on common usage of these terms, we would find it inconvenient and confusing to substitute other terms for
‘problem’ to describe these concepts. We are confident that the extended discussions in Section 3 sufficiently clarify
our use of the above ideas.
6 Conclusions, Limitations, and Future Directions
The Action Design Research (ADR) paradigm has been effectively and consistently applied in a number of interesting
research contexts as illustrated by the example papers surveyed in Section 4. As its use expands, researchers will gain
new understandings of how best to perform ADR and will continually evolve the ADR techniques and processes
accordingly. Thus, the goals of this essay are to present an elaborated ADR process model based on reflections and
learnings from a challenging and immersive ADR project that we performed in the context of inter-organizational social
networks for deal making in mid-market private equity firms.
The elaborated ADR process model supports the researcher-practitioner teams in several important ways. Every
research project faces the immediate question of “Where do we start?” The presence of multiple entry points with clear
definitions allows the team to investigate their project goals and identify the entry point that best aligns with the project’s
purpose. Next, the ability to view the project as a well-defined sequence of discrete, well-defined intervention cycles
(i.e. research chunks) provides an essential intellectual control to the project management and the strategic planning of
the project directions. An understanding of the emergent, iterative nature of successive intervention cycles keeps the
goals and resources of the ADR project bounded, under management control, and consistent with the action research
paradigm. Another key insight is the longitudinal nature of an ADR project. The system artifacts under study will evolve
over time and multiple ADR projects may research the underlying issues and opportunities for the same system. The
evolution stage of the elaborated ADR model specifically differentiates the initial design context and subsequent
evolutionary design contexts.
A key addition to the activities in the ADR intervention cycle is the inclusion of the Artifact Creation activity. This
activity highlights the essential artifact build activities that are central to the DSR process. We contend that each ADR
intervention cycle must introduce an impactful artifact into the application context. The abstract nature of the new socio-
technical artifact will vary depending on the ADR stage of the intervention (Gregor and Hevner, 2013). Thus, a
Diagnosis artifact may be a concept or a nascent theory. A Design artifact may be a model, method, or set of design
principles. An Implementation artifact may be a system instantiation. An Evolution artifact may be a new or improved
15
artifact of any of these types. This important insight is captured by our addition of the new ADR Principle 8, Abstraction,
which states that every ADR intervention cycle will introduce an artifact at the appropriate level of abstraction for the
stage of project activity and goals.
The proposals in this paper derive from our experiences in a single focused ADR project. This is a limitation in
that a different set of experiences in a different project context may lead to a different set of recommendations and
elaborations of the ADR process. To mitigate this limitation, we consider these models of the ADR cycle and the
elaborated ADR process in the context of other key published ADR exemplar cases. Our goal is to share this set of
learnings with the ADR community in hopes of providing a richer and more complete ADR process model for future
use in a manner that aids in the execution and the communication of results of ADR studies. Over the past three years,
the authors of this essay have presented these ideas to approximately 800 students, faculty, and industry researchers
as a rigorous approach for performing ADR projects. The model has been received enthusiastically and has been
applied effectively in a number of industrial and doctoral ADR projects demonstrating a compelling ‘proof of use’
validation (Nunamaker, et al., 2015). We believe that as more IS researchers understand and apply the elaborated ADR
methods that the field will engage in more relevant research projects that will support better resonance with practitioners
and industry stakeholders (Drechsler et al., 2016).
An important direction for further research is the inclusion of design theory development in the ADR process
model. A question remains as to where in the model this activity should be placed. Baskerville (1999) speaks to the
opportunity to have theory emerge through iterations of action research cycles. He finds that a theoretical contribution
emerges through the increased understanding of the nature of the problem and the IT solution class that offers a
measure of generalizability. McKay and Marshall (2001) suggest that two iterative cycles occur simultaneously and
in parallel in what we call an ADR Cycle. They propose that one cycle tends to inform research even as the other cycle
is informing practice. Both articles suggest that an important distinction from consulting, when conducting AR, is this
generation of guidance that informs research. We believe that the elaborated ADR process model can offer a way to
generate nascent theory emergence through each iterative intervention within and between stages in ADR Process. A
future direction is to employ the proposed ADR process model to not only inform practice and research on the
development of innovative artifacts but also to iterate the nascent, emergent design theory to inform IT artifact design
and use across problem domains, IT solution classes, and intervention domains (Venable, 2006).
Another important direction for future research is the application of the elaborated ADR process model to the
conduct of specific projects with practitioners that demonstrate its utility across various applications of design based
research. There may be a need for further elaborations and adaptations of the model in different application domains,
such as healthcare, education, or government. Further, practitioners from multiple application areas can be brought
together in common ADR projects by use of a shared process model and produce innovative artifacts of value across
disciplines.
Finally, like any rigorous research method, the detailed ADR intervention cycle (Figure 1) and the ADR stages
in the elaborated ADR process model (Figure 4) can and should continue to evolve with procedures, techniques, and
outcomes that increase the disciplined inquiry into the action research and design science research paradigms. A future
direction will be to specify learnings that further elaborate the ADR processes and methods as used in actual projects.
16
Our initial survey of ADR papers serves to highlight areas of intersection (IT solution class x artifact type x problem
class x entry point) that may be un(der)explored across the corpus of interesting IT artifacts, systems, and solutions.
Identification of these gaps can provide researchers and editors with a means to identify and evaluate the research and
practice contribution potentials of additional ADR studies. We contend that ADR researchers have an opportunity to
report knowledge contributions by the number and types of ADR cycles conducted at one or more stages in the ADR
Process in their formalization of knowledge contributions.
References
Agerfalk, P, Wiberg, M (2018) Pragmatizing the Normative Artifact: Design Science Research in Scandinavia and
Beyond. Communications of the Association of Information Systems, In press.
Baskerville RL (1999) Investigating information systems with action research. Communications of the Association
of Information Systems 2(19), 1-32.
Baskerville R, Myers M (2004) Special issue on action research in information systems: making IS research
relevant to practice – foreword. MIS Quarterly 28(3), 329–335.
Bilandzic M, Venable J (2011) Towards participatory action design research: adapting action research and design
science research methods for urban informatics. Journal of Community Informatics 7(3), 1–17.
Coenen T, Donoshe V, Ballon P (2015) LL-ADR: action design research in living labs. In Proceedings of the
2015 48th Hawaii International Conference on Systems Sciences, pp 4029–4038, IEEE
Dibia, V. (2015) An affective, normative and functional approach to designing user experiences for wearables.
Proceedings of the International Conference on Information Systems (Pre-ICIS) PTC’15 Networked Planet,
AIS, 1-12.
Dreschler A, Hevner A, Gill G (2015) Beyond rigor and relevance: Exploring artifact resonance. Proceedings of the
49th Annual Hawaii International Conference on System Sciences (HICSS49), Hawaii.
Gregor S Hevner A (2013) Positioning and presenting design science research for maximum impact,” MIS Quarterly
37(2), 337-355.
Hevner AR, March ST, Park J, Ram S (2004) Design science in information systems research. MIS Quarterly
28(1), 75–115.
Keijzer-Broers, W., Florez-Atehortua, L., de Reuver, M. (2016) Prototyping a health and wellbeing platform: an
action design research approach. Proceedings of the 2016 49th Hawaii International Conference on System
Sciences, 2016 IEEE, 3462-3471.
Lee JS, Pries-Jeje J, Baskerville R (2011) Theorizing in design science research. In 6th International Conference on
Design Science Research in Information Systems and Technology (DESRIST), Milwaukee.
Lepinen H, Rossi M, Tuunainen VK (2012) Design principles for inter-organizational systems development – case
Hansel. (K Peffers et al Eds) pp 52-65, DESRIST 2012, LNCS 7286.
Lindgren R, Henfridsson O, Schultze U (2004) Design principles for competence management systems: a
synthesis of an action research study. MIS Quarterly 28(3), 435–472.
Maccani G, Donnellan B, Helfert M (2014) Action design research in practice: the case of smart cities. (MC
Tremblay et al Eds), pp 132-147, DESRIST 2014, LNCS 8463.
Marjanovic O (2013) Organizational design of innovative education – insights from a combined design and action
research project (J vom Brocke et al Eds), pp 212-227, DESRIST 2013, LNCS 7939.
Mayer J, Roder A, Hartwig J, Quick R (2014) A self-service MSS design from a new-generation manager
perspective. (MC Tremblay et al Eds), 164-179, DESRIST 2014, LNCS 8463.
McKay J, Marshall P (2001) The dual imperatives of action research. Information Technology & People 14(1), 46-
59.
Menschner, P., Leimeister, J.M. (2012) Devising a method for developing knowledge-intense, person-oriented
services – results from early evaluation. Proceedings of the 2012 45th Hawaii International Conference on
System Science (HICSS), 1502-1511.
17
Mullarkey MT, Hevner A, Collins R (2013) Inter-organizational social networks: an action design research study. In
Proceedings of the SIGPRAG 2013Workshop, pp 1–11, Milan.
Mullarkey MT, Hevner A (2015) Entering action design research. (B. Donnellan et al Eds), pp 121-134, DESRIST
2015, LNCS 9073.
Niemi, E, Laine, S (2016) Competence management system design principles: action design research. Proceedings
of the Thirty-seventh International Conference on Information Systems, Dublin 2016, 1-18.
Noce I, Carvalho, JA (2014) Business and technology integrated management: a case of e-government for
assessing the impact of policies. In Proceedings of ICEGOV2014, pp 1–4, Guimaraes, Portugal, October 27-30.
Nordstrom, M, Axelsson, K (2011) Practitioners’ motives as a key issue in organizing practice research
collaboration. Systems, Signs & Actions, 5(1), 133-146.
Nunamaker, J, Briggs, R, Derrick, D, Schwabe, G (2015) The last research mile: Achieving both rigor and relevance
in information systems research, Journal of Management Information Systems 32(3), 10-47.
Peffers, K, Rothenberger, M, Tuunanen, T, Vaezi, R (2012) Design science research evaluation. DESRIST 2012,
LNCS 7286, Springer-Verlag, Berlin Heidelberg, 398-410.
Peffers, K, Tuunanen R, Rothenberger MA, Chatterjee S (2007) A design science research methodology for
information systems research. Journal of Management Information Systems 24(3), 45–77.
Pluijment, NJ., Molnar, WA.,Proper, HA. (2013) Research approach in enterprise engineering: a matter of
engineering. CAiSE 2013 Workshops, LNBIP 148, X. Franch and P. Soffer (eds.), Springer-Verlag 2013, 73-
86.
Schacht, S, Morana, S, & Maedche, A (2015) The evolution of design principles enabling knowledge reuse for
projects: an action design research project. Journal of Information Technology Theory and Application, 16(3),
5.
Sein M, Henfridsson O, Purao S, Rossi M, Lindgren R (2011) Action design research. MIS Quarterly 35(1), 37–
56.
Sherer S (2014) Advocating for action design research on IT value creation in healthcare. Journal of the Association
for Information Systems 5(12), 860–878.
Susman G, Evered R (1978) An assessment of the scientific merits of action research. Administrative Science
Quarterly 23(4), 582–603.
Tanskanen, K, Holmstrom, J, Ohman, M (2015) Generative mechanisms of the adoption of logistics innovation: the
case of on-site shops in construction supply chains. Journal of Business Logistics, 36(2), 139-159.
Tunkelo, T, Hameri, AP, Pigneur, Y (2013) Improving globally distributed software development and support
processes – a workflow view. Journal of Software: Evolution and Process, 25(12), 1305-1324.
Venable J (2006) The role of theory and theorizing in design science research. In Proceedings of the First
International Conference on Design Science Research in Information Systems and Technology (DESRIST),
pp 24-25, Claremont, CA, USA, February 24-25.
Westin S, Sein M (2015) The design and emergence of a data/information quality system. Scandinavian Journal of
Information Systems 27(1), Article 1.
18
Appendix A: Research Project Summary
As researchers with expertise in Design Science Research (DSR) and Action Design Research (ADR), the authors
were invited to participate in a collaborative research project with a Mid-Market Private Equity (MMPE) firm that
was exploring opportunities to build an inter-organizational social network information system (IO SNIS). Their
problem revolved around the need to identify and close proprietary deals to acquire (or divest) a corporate entity. On
the surface, this problem seems to be a relatively simple class of problems until one realizes that the typical MMPE
firm only completes two or three deals per year, each with enterprise values ranging from $10-$250 million. A
prototypical firm in this space might have a portfolio of just 5-15 corporate entities at any given time. Notably, the
scale of this problem domain is impressive. In April 2015 alone there were 231 completed U.S. private equity deals
totaling more than $86 billion in capital invested. Moreover, the number of deals in April 2015 was up five percent
from the prior month (Cook M&A Advisory Services, 2015).
There are only two ways to find a MMPE deal: (1) Commit to a public auction of an entity that is for sale and
succeed as the highest bidder, or (2) Use the firm’s social network to identify a proprietary deal to buy or sell a
company that is not in the public private equity domain. Of the two approaches, the second typically offers the greatest
value to the MMPE for the equity committed (Sutton Place Strategies, 2012).
Historically, MMPE firms, including our research partner organization, built their IO SN through an expensive
commitment of time and resources on meetings, site visits, tele/video-conferences, trade association participation, and
multi-media marketing. Our research with the MMPE firm combined with existing industry research indicated that
these firms spent 35-50% of expenses on finding deals with a heavy emphasis on locating proprietary deals through
the firm’s network of brokers, lawyers, limited partners, business owners, and consultants. Incredibly, the average
MMPE has visibility to just 21.1% of deals in their target landscape (Sutton Place Strategies, 2012). Our MMPE firm
wanted to know if there was a more effective and less expensive approach for building and maintaining a social
network using an information system. They desired a digital, online social network that could replicate their “offline”
social network much the same way that inter-personal SNIS (like Facebook and LinkedIn) have affected the landscape
of social interaction.
Our investigation began with a diagnosis of the problem domain and IT solution classes. We researched social
network theory and the advantages, disadvantages, and linkages to offline social networks of the relatively new
interpersonal SNIS. We evaluated all the digital networks for MMPE in existence and ascertained that although the
firm was paying for online services that were advertised as private equity networks, these networks were really
vehicles for the conduct of deal transactions. Short-term, non-contractual inter-organizational networks like these are
typical of market-based transactional environments. Social-based inter-organizational environments, on the other
hand, are typified by long-term, cooperative, reciprocal interaction based upon resilient trust (Mullarkey, 2012). Our
MMPE was not participating in any online social networks. Until we intervened with a theory-ingrained investigation
of what it really meant to be a true ‘inter-organizational social network,’ the practitioners did not recognize that their
online, transactional, low-trust, short-term PE networks could not replicate their offline social behaviors – and
therefore would never identify non-auctioned, proprietary PE deals.
19
As we followed the ADR method of Sein et al. (2011), we noticed that before we could move to system design,
we needed cycles of problem diagnosis to investigate the nature of social networking between organizations. Our first
ADR diagnosis cycle produced a theoretical construct of inter-organizational social networking and a second cycle,
informed by the first, identified all MMPE digital networks used in the domain and evaluated them against the
theoretical construct of the first cycle. Both cycles generated interesting artifacts to evaluate and knowledge that
informed future ADR design cycles. Upon reflection and learning in these first two cycles, we discovered the need to
unpack the ADR steps in BIE into separate diagnosis and design stages with different artifact abstractions (Mullarkey
and Hevner, 2015).
Upon completion of these first two diagnosis cycles, we identified that the online PE networks that the firm was
participating in (and paying significant sums to join) were simply more efficient ways to gain visibility to those non-
proprietary (and less attractive) deals already publicly offered. More importantly, after five years of participation in
these market-based online networks, the firm had not completed a single deal from these sources. We also identified
that the design of an inter-organizational SNIS would have to be somehow similar to but different from the existing
IP SNIS. SN theory demonstrated that individuals interact differently than the ways that organizations interact socially.
We recognized that there appeared to be no examples of SNIS for MMPE (Mullarkey, 2012). The learnings from two
diagnosis cycles informed our approach to the design stage of our ADR study.
In our design stage we first dissected the features of IP SNIS that distinguished them from the way individuals
interacted in social networks offline. This feature set was our first design artifact and was evaluated to inform the
second cycle in the design stage. Our second design cycle, built and evaluated a set of principles for the design of an
inter-organizational SNIS that could take advantage of the features of IP SNIS and adapt them to the fundamental
nature of inter-organizational social behavior. These innovative design principles were evaluated through an
intervention with the firm and generated learnings and reflection that were able to inform the movement of the project
to a development team to implement the design through the creation of an instantiated IO SNIS.
Consequently, our ADR study generated the observation that unpacking BIE and explicitly abstracting innovative
artifacts in iterative intervention cycles are fundamental and necessary to the conduct of rigorous ADR studies. We
used these insights to inform our development of the elaborated ADR process model presented in this essay.
References:
Cook M&A Advisory Services (2015) PE industry update April 2015. 212 West Kinzie Street, Chicago, IL 60654.
Mullarkey MT (2012) Socially immature organizations: a typology of social networking systems with
organizations as users. In Proceedings of CSCW 2012, pp 281–292, ACM.
Mullarkey MT, Hevner A (2015) Entering action design research. (B. Donnellan et al Eds), pp 121-134, DESRIST
2015, LNCS 9073.
Sein M, Henfridsson O, Purao S, Rossi M, Lindgren R (2011) Action design research. MIS Quarterly 35(1), 37–
56.
Sutton Place Strategies (2012) SPS deal origination analytics 2011. 757 Third Avenue, 20th Floor, New York, NY
10017.
20
Appendix B: Listing and Analyses of Representative ADR Projects
ADR Project Stages/EntryPoint Knowledge Contributions
Bilandzic M, Venable J (2011)
Towards participatory action design
research: adapting action research and
design science research methods for
urban informatics. Journal of
Community Informatics 7(3), 1–17.
Diagnosis
Design
Implementation
-
Problem Centered
IT Solution Class: Urban Informatics (UI)
Problem Class: Shared community or societal issues (non-profit)
Intervention Domain: Ubicomp
Artifact: Innovative UI Design Features and Ensemble artifact
Lepinen H, Rossi M, Tuunainen VK
(2012) Design principles for inter-
organizational systems development – case Hansel. (K Peffers et al Eds) pp
52-65, DESRIST 2012, LNCS 7286.
Diagnosis
Design
-
Problem Centered
IT Solution Class: Relationship management system (RMS)
Problem Class: Stakeholder engagement & power differences in inter-organizational
(IO) relationship management
Intervention Domain: Public organization
Artifact: Design Principles for IO RMS
Marjanovic O (2013) Organizational
design of innovative education – insights from a combined design and
action research project (J vom Brocke
et al Eds), pp 212-227, DESRIST
2013, LNCS 7939.
Diagnosis
Design
-
Problem Centered
IT Solution Class: Team net based learning (TNBL) systems
Problem Class: Large lecture classes for information systems
Intervention Domain: Large classroom environment higher education
Artifact: Model and eventual instantiation
Maccani G, Donnellan B, Helfert M
(2014) Action design research in
practice: the case of smart cities. (MC
Tremblay et al Eds), pp 132-147,
DESRIST 2014, LNCS 8463.
Diagnosis
Design
-
Problem Centered
IT Solution Class: Smart city maturity model (SCC CMF)
Problem Class: Digitally connecting internet of things to sustainable city
Intervention Domain: Dublin city with public council and private corporation
Artifact: Model
Coenen T, Donoshe V, Ballon P
(2015) LL-ADR: action design
research in living labs. In Proceedings
of the 2015 48th Hawaii International
Conference on Systems Sciences, pp
4029–4038, IEEE
Diagnosis
-
Problem Centered
IT Solution Class: Virtual Reality (VR)
Problem Class: Living labs where new systems are tested in simulated “real-life”
Intervention Domain: Societal (non-organizational) context
Artifact: Innovative VR Constructs
Westin S, Sein M (2015) The design
and emergence of a data/information
quality system. Scandinavian Journal
of Information Systems 27(1), Article
1.
Diagnosis
Design
Implementation
Evolution
-
Problem Centered
-
Problem Centered
IT Solution Class: Information data quality control systems
Problem Class: Insufficient Data/Information Quality (DQ/IQ)
Intervention Domain: Construction engineering with paradigm of concurrent
engineering
Artifact: Information Quality System (IQS)
Nordstrom, M., Axelsson, K. (2011)
Practitioners’ motives as a key issue in organizing practice research
collaboration. Systems, Signs &
Actions, 5(1), 133-146.
Diagnosis (4 iterations reported)
-
Problem Centered
IT Solution Class: Knowledge Initiatives (KI)
Problem Class: IS Systems Maintenance and Update
Intervention Domain: Simulation with role play involving eight organizational experts
Artifact: Principles for KI design
Pluijment, NJ., Molnar, WA.,Proper,
HA. (2013) Research approach in
enterprise engineering: a matter of
engineering. CAiSE 2013 Workshops,
LNBIP 148, X. Franch and P. Soffer
(eds.), Springer-Verlag 2013, 73-86.
Diagnosis (1 iteration reported)
-
Problem Centered
IT Solution Class: Enterprise Engineering
Problem Class: Enterprise systems selection and deployment
Intervention Domain: Interviews with key systems stakeholders
Artifact: Critical Success Factors for system selection and deployment
Tunkelo, T., Hameri, AP., Pigneur, Y.
(2013) Improving globally distributed
software development and support
processes – a workflow view. Journal of Software: Evolution and Process,
25(12), 1305-1324.
Diagnosis (Many iterations)
Design (Many iterations)
Implementation (1 iteration reported over
1 year)
Evolution (anticipated)
-
Problem Centered
IT Solution Class: Software Process Improvement (SPI)
Problem Class: Distributed software platform development
Intervention Domain: Multinational post-merger/acquisition legacy systems
Artifact: SPI KPIs, Reengineered software platform, Reengineered software process
Mullarkey MT., Hevner AR., Collins,
RW. (2013) Inter-organizational
social networks: an action design
research study. In Proceedings of the
SIGPRAG 2013Workshop (Milan),
1–11.
Diagnosis (2 iterations)
Design (2 iterations)
-
Problem Centered
IT Solution Class: Social Networking Information Systems (SNIS)
Problem Class: Social network dependent organizations
Intervention Domain: A US Mid-Market Private Equity firm (MMPE)
Artifact: Innovative Design Principles
21
Keijzer-Broers, W., Florez-Atehortua,
L., de Reuver, M. (2016) Prototyping
a health and wellbeing platform: an
action design research approach.
Proceedings of the 2016 49th Hawaii
International Conference on System
Sciences, 2016 IEEE, 3462-3471.
Diagnosis (1 iteration – 11 stakeholder interviews)
Design (3 iterations: 1 iteration of 59
interviews; 2 iterations of focus groups)
Implementation (4 parallel scrum
iterations; 3 iterations of user workshops)
Evolution (1 iteration of multiple
stakeholder experience survey)
-
Problem Centered
IT Solution Class: Integrated Daily Living Health and Wellbeing Patient Platform
Problem Class: Prototype an IT platform to inform healthcare providers of patient
needs
Intervention Domain: Elderly patients in Living Lab environment
Artifact: 3 Design Features, Functional Requirements, Non-functional Requirements,
Defined Platform Framework, Critical Design Issues, Project Plan, Architecture
Template, Mockups, Alpha version of Platform, Market release Prototype
Patient/Provider Platform
Schacht, S., Morana, S., & Maedche,
A. (2015) The evolution of design
principles enabling knowledge reuse
for projects: an action design research
project. Journal of Information
Technology Theory and Application,
16(3), 5.
Diagnosis ( 3 iterations total - 1
secondary source; 1 interview iteration
with 27 stakeholders; 1 secondary
literature iteration)
Design (5 iterations – 1 design decision iteration; 1 design concepts iteration;
series of three focus groups)
Implementation (2 iterations – 1 simulated KMS artifact; 1 instantiation)
Design (2 iterations – 1 adaptation of design principles; delineation of 4 design
principles)
Implementation ( - instantiate Just Know;
a Knowledge Reuse artifact as a Pilot)
-
Problem Centered
IT Solution Class: Knowledge Management System (KMS)
Problem Class: Design and redesign of a KMS
Intervention Domain: Financial services provider
Artifact: Meta-requirements, Preliminary design principles, Functional requirements,
Design decisions, Conceptual design, Pilot simulated KMS artifact, Pilot KMS
instantiation informed by “Knowledge Reuse”
Noce I, Carvalho, JA (2014) Business
and technology integrated
management: a case of e-government
for assessing the impact of policies. In
Proceedings of ICEGOV2014, pp 1–4, Guimaraes, Portugal, October 27-30.
Design
-
Objective Centered
IT Solution Class: Integrated Business Intelligence Management Systems (BIMS)
Problem Class: Public sector business management practices
Intervention Domain: Public institution – the Court of Auditors, Mato Grosso, Brazil
Artifact: Innovative Ensemble BI Design
Dibia, V. (2015) An affective,
normative and functional approach to
designing user experiences for
wearables. Proceedings of the
International Conference on
Information Systems (Pre-ICIS)
PTC’15 Networked Planet, AIS, 1-12.
Design (5 applications x 2 iterations)
-
Objective Centered
IT Solution Class: Wearable digital device (Samsung Gear 2) Human Computer
Interface (HCI)
Problem Class: Software creation for wearable devices
Intervention Domain: Examination of design aspects of the Gear 2 crowdsourcing
contest – one developer team, 5 applications, with cross-team technical exchanges
Artifact: Six User interaction design principles
Niemi, E., Laine, S. (2016)
Competence management system
design principles: action design
research. Proceedings of the Thirty
Seventh International Conference on
Information Systems, Dublin 2016, 1-
18.
Design (7 iterations – 2 primary interviews, 1 secondary data collection, 4
participatory workshops)
-
Objective Centered
IT Solution Class: Competence Management Systems (CMS)
Problem Class: Generalizing design principles from KnoMe software solution
Intervention Domain: Siili Solutions PLC competence management service
Artifact: Five Design Principles
Mayer J, Roder A, Hartwig J, Quick R
(2014) A self-service MSS design
from a new-generation manager
perspective. (MC Tremblay et al Eds),
164-179, DESRIST 2014, LNCS
8463.
Design
-
Objective Centered
IT Solution Class: Management support system (MSS)
Problem Class: Identification of subjective information needs in functional
requirements definition
Intervention Domain: Software development
Artifact: Design guidelines
Sein M, Henfridsson O, Purao S,
Rossi M, Lindgren R (2011) Action
design research. MIS Quarterly 35(1),
37–56.Lindgren, Henfridsson, and Schultze 2004
Implementation
Design
Implementation
-
Development Centered
IT Solution Class: Competence Management Systems (CMS)
Problem Class: Knowledge intensive organizations
Intervention Domain: Volvo IT, HR workers
Artifact: Innovative adaptation of CMS using a new skill-based paradigm
22
Menschner, P., Leimeister, J.M.
(2012) Devising a method for
developing knowledge-intense,
person-oriented services – results
from early evaluation. Proceedings of
the 2012 45th Hawaii International
Conference on System Science
(HICSS), 1502-1511.
Implementation (4 iterations in situ)
-
Development Centered
IT Solution Class: Knowledge-Intense Person-Oriented Services (KIPOS) Information
Systems
Problem Class: Realizing IT instantiations for systematic development of an IS
Intervention Domain: Development of a KIPOS on Nutritional Advisory for Obesity
Artifact: Rapid Implementation using EPOS Method of a new KIPOS Instantiation
Sherer S (2014) Advocating for action
design research on IT value creation in
healthcare. Journal of the Association
for Information Systems 5(12), 860– 878.
Evolution
-
Observation Centered
IT Solution Class: Electronic Medical Record/Electronic Health Record
Problem Class: Healthcare effectiveness
Intervention Domain: Healthcare Providers
Artifact: Extended Ensemble EMR/EHR
Tanskanen, K., Holmstrom, J.,
Ohman, M. (2015) Generative
mechanisms of the adoption of
logistics innovation: the case of on-
site shops in construction supply
chains. Journal of Business Logistics,
36(2), 139-159.
Evolution (1 iteration - 55 stakeholder
interviews across 3 stakeholder groups;
1iteration – experts synthesis of design propositions)
-
Observation Centered
IT Solution Class: Construction Logistics IT Systems (On-site Shop) VMI
Problem Class: Generalize constructs, theory, and principles of innovative
instantiated system
Intervention Domain: Construction site logistics IS users
Artifact: Design Theory, Design Constructs