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

{ [email protected]; [email protected] }

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