Paper title (Paper Title style) Australasian Journal of Information Systems Cronholm, Gӧbel & Shrestha 2024, Vol 28, Research Article Collaboration in Action Design Research Received 7 Sep 2023, accepted 4 July 2024 after 1 round of review with Karlheinz Kautz as accepting Editor 1 Researcher-Practitioner Collaboration in Action Design Research Stefan Cronholm University of Borås, Sweden stefan.cronholm@hb.se, Hannes Göbel University of Borås, Sweden Anup Shrestha School of Business University of Southern Queensland, Australia Abstract Action Design Research (ADR) is a well-known research method within Design Science Research (DSR). An essential characteristic of the ADR method is the need for researcher- practitioner collaboration (RPC). While there is abundant research on RPC regarding information systems projects in general concerning explanatory and normative knowledge, there is very limited prescriptive knowledge on how to execute RPC in ADR projects. Successful collaboration in ADR projects is imperative since the development of socio- technical IT artefacts requires frequent interaction in organisational contexts. However, RPC can be hard to manage due to competing interests. Therefore, the purpose of this paper is to present prescriptive knowledge for how to manage RPC. We have analysed a collaborative ADR project consisting of several researchers and practitioners. Based on a grounded theory approach, we have developed theoretical models based on challenges identified in an ADR project. The models provide prescriptive knowledge regarding: shape the IT artefact based on organisational intervention, exploit the mutual dependency between developing design principles and IT artefacts, and contextualise and generalise learning. Each model involves logical relationships between: conditions for the challenges, actions taken to address the challenges and consequences of the actions taken. The guidelines were deducted from the models and consist of recommendations that could be considered in future ADR projects. Keywords: researcher-practitioner collaboration, action design research, ADR projects, design science research, academy-industry collaboration. 1 Introduction Design science research (DSR) has gained a lot of interest and has been established as a widely accepted research approach in Information Systems (IS) (e.g., Gregor & Hevner, 2013; Vaishnavi & Kuechler, 2015). One purpose of DSR is to design IT artefacts which are broadly defined as constructs (vocabulary and symbols), models (abstractions and representations), methods (algorithms and practices), and instantiations (implemented and prototype systems) (Hevner et al., 2004). This increasing interest has created a need for specific DSR methods (Venable et al., 2017; Cronholm & Göbel, 2019). One of the most popular research methods within DSR is Action Design Research (ADR) which draws on both design research (DR) and action research (AR) (Sein et al., 2011). With over a thousand citations indexed in Scopus and over 2000 citations according to Google Scholar, the ADR method is one of the most cited DSR methods. mailto:stefan.cronholm@hb.se Australasian Journal of Information Systems Cronholm, Gӧbel & Shrestha 2024, Vol 28, Research Article Collaboration in Action Design Research 2 Our analysis of the ADR method has revealed three significant characteristics. The first characteristic is the idea of combining DR and AR, which involves that the design of IT artefacts should be based on intervention in authentic organisational settings. The second characteristic is to respond to the dual mission of making theoretical contributions and assisting in solving the problems of practitioners. This double task stresses the importance of developing design knowledge such as design principles (as a form of nascent theory) and IT artefacts in parallel. It also accentuates the necessity of planning ADR projects to meet this requirement. The third characteristic of the ADR method is the strong encouragement for the generalisation of qualitative studies. Sein et al. (2011) state that problems, solutions and design principles should be generalised. This means that a contextual problem should be cast as an instance of a class of problems and that the designed artefact should be regarded as an instance of a solution class (ibid.). One purpose of generalisation is to reconceptualise learning to be valid more broadly outside a single-case study. The three characteristics target practitioners and the practitioners’ organisations, and hence several scholars regard the ADR method as a highly collaborative researcher-practitioner approach (e.g., Petersson & Lundberg, 2016; Haj-Bolouri et al., 2018; Cronholm & Göbel, 2019). It is evident that Sein et al. (2011) share this view when they state that “Researchers bring their knowledge of theory and technological advances, while the practitioners bring practical hypotheses and knowledge of organizational work practices” (p.43). This collaborative aspect of the ADR method aims to increase the organisational relevance of the designed artefact and encourage interaction between researchers and practitioners. Against this backdrop, we can conclude that a) the ADR method relies heavily on successful researcher-practitioner collaboration (RPC) in context and b) the three ADR characteristics influence how RPC is organised in ADR projects. Based on an analysis of an ADR project (see section 5), we have found that the ADR method provides excellent guidance regarding RPC on why to collaborate and what to collaborate on. However, the method provides limited literature support on how to collaborate, i.e., prescriptive knowledge. The lack of prescriptive knowledge could have a negative impact on project effectiveness and efficiency, the relationship between researchers and practitioners, and research goals (Segal, 2022). Our observation is also supported by other scholars who state that there is a need for prescriptive guidelines on RPC in ADR projects (Collatto et al., 2017; Haj-Bolouri et al., 2018; Cronholm & Göbel, 2019; Henriques & O’Neill, 2021). For example, Henriques & O’Neill (2021) emphasise that RPC collaboration is paramount in design-oriented projects in order to find the best solutions for socio-technical problems and that additional methods and guidance are required. As a complement to the existing guidance on why to collaborate and what to collaborate on, the purpose of this study is to suggest prescriptive knowledge (how to do) for RPC in ADR projects. Prescriptive knowledge is presented as a) theoretical models consisting of structures that explain relationships between conditions for RPC challenges, actions taken to address the challenges, and consequences of the actions taken and as b) guidelines that could be used in future ADR projects. We define a challenge as something that is regarded, either by researchers or practitioners, as a threat to successful collaboration (Cronholm & Göbel, 2022). A guideline is defined as practical information intended to advise people on how something should be done or what should be done about something (Cambridge Dictionary, 2023). We state that the theoretical models and guidelines advance existing knowledge concerning RPC in ADR Australasian Journal of Information Systems Cronholm, Gӧbel & Shrestha 2024, Vol 28, Research Article Collaboration in Action Design Research 3 projects. The models and guidelines can support future ADR projects and possibly other research DSR or IS projects involving collaboration between researchers and practitioners. Therefore, they target both researchers and practitioners. Our research question reads: how can RPC challenges in ADR projects be managed? Understanding challenges related to researcher-practitioner collaboration is critical to project planning, realisation and evaluation. Therefore, we have analysed an empirical research project guided by the ADR method, which we refer to as “the ADR project” in this article, in order to identify critical themes concerning RPC. This ADR project was chosen due to its composition of several researchers and practitioners who frequently interacted in order to fulfil the project goals. The following section presents a literature review concerning researcher-practitioner collaboration in ADR projects. After that, we describe the analysed ADR project. Next, we explain our research design. Then, we present the identified themes concerning researcher- practitioner collaboration. Next, we describe the theoretical models, followed by a presentation of the guidelines. After that, we discuss the findings. Finally, we draw conclusions and describe implications of our work to theory and practice. 2 Literature Review In order to identify existing knowledge on RPC within ADR projects, we searched the Scopus database, which is the largest within IS. The keywords used were “Action Design Research” and “Researcher-Practitioner Collaboration”. The reason for explicitly including these keywords was that we wanted to identify previous knowledge about the significant RPC characteristics of the ADR method (see section 1). The search within the Scopus database returned only seven articles. Out of these seven articles, three neither discussed collaboration nor ADR projects, and one of the articles reflected upon researcher-industry collaboration but not in ADR projects. Only three articles involved reflections on researcher-practitioner collaboration in ADR projects. Therefore, we expanded our literature search to include backward reference searching (i.e., snowball sampling, e.g., Naderifar et al., 2017), which meant that we reviewed relevant articles cited in the returned articles from the Scopus database. The expanded literature search resulted in four additional articles regarding RPC in ADR projects. The total return of seven articles limits the pool of extant wisdom that could be drawn upon to suggest ways to conduct RPC (see section 2.1). As mentioned in section 1, the ADR method draws on action research. Therefore, we extended the literature review further to also include experiences from action research (e.g., Rapoport, 1970; Susman & Evered, 1978), (see section 2.2). As mentioned in section 1, the ADR method draws on both action research and design research. 2.1 Knowledge about RPC Identified in ADR Projects First, Bilandzic and Venable (2011) have proposed an adapted research method called Participatory Action Design Research, which emphasises that the practitioner’s involvement should be extensive from the initial design to the final presentation of results. Their view of practitioners is that they are regarded as both subjects and co-researchers, which is similar to the one by Argyris and Schön (1989, p.613), who state that “causal inferences about the behaviour of human beings are more likely to be valid and enactable when the human beings in question participate in building and testing them”. Second, Matzner et al. (2018) have used Australasian Journal of Information Systems Cronholm, Gӧbel & Shrestha 2024, Vol 28, Research Article Collaboration in Action Design Research 4 the ADR method in order to develop a framework consisting of core RPC concepts in service research. The framework consists of an iterative process involving the following phases: a) formulate research needs, societal goals and political goals, b) formulate research and business goals, c) carry out design, analysis, development and full launch, and d) describe research and business outcomes. Third, Haj-Bolouri et al. (2016) have extended the ADR method by adding a front-end component, which is inspired by Participatory Action Research and Participating Design. One conclusion is that learning should be focused on all ADR stages. In addition, a participatory approach involving both researchers and practitioners co-creating knowledge should be explicit at each step of the ADR method. Fourth, Haj-Bolouri et al. (2018) have further analysed how scholars use the ADR method. They have identified three topics concerning RPC: a) how to balance the competing interests of organisational stakeholders with the interests of a research community, b) how to balance the practitioner need of a situated implementation of the designed IT- artefact against the research need to produce generalised knowledge and c) how to balance the findings between specific and generalisable research outcomes. Based on the three topics, Haj-Bolouri et al. (2018) have identified 11 themes that describe the use of ADR in practice. The themes are primarily problem-oriented, although some offer practical RPC advice such as a) presenting careful mutual elaboration of the key research issues, and b) organising workshops to involve stakeholders and identify essential priorities. Furthermore, Haj-Bolouri et al. (2018, p.144) state that “Due to reason that the methodology [the ADR method] is described in broad terms in the original paper by Sein et al. (2011), applications of the methodology in projects have revealed recurring issues that researchers and practitioners face in practice”. Fifth, vom Brocke et al. (2021) argue that DSR (including ADR) should be conducted within a continuous dialogue of research and practice using a dance metaphor. They state that academia and practice have to move together according to a joint “rhythm”; sometimes closer together, sometimes more on their own; sometimes more active, sometimes more passive; but in any given situation, there should be a mutual commitment towards a joint performance and the accomplishment of the project. They have suggested four guidelines to maximise the practical relevance: establishing a continuing relationship of mutual trust and respect, studying design where it happens, seeking and embracing opportunities to make an impact, and performing the DSR dance “on the fly”. Finally, Cronholm and Göbel (2022) have analysed an ADR project in order to identify how RPC challenges could be tackled. The paper is presented as a conference paper and is therefore regarded as research in progress. The identified challenges in that paper were: researcher intervention in practitioner contexts, reciprocal shaping between artefacts and design principles that emerged from theory and practice, and researcher and practitioner learning. The research presented in our study extends the previous research-in-progress publication through: a) a renewed analysis of prior knowledge of RPC in ADR projects, b) a re-analysis of data, and c) enhanced theoretical models demonstrating RPC challenges including actions taken. 2.2 Knowledge about RPC Identified in Action Research First, Rapoport (1970, p.499) defines action research as a research method that “aims to contribute both to the practical concerns of people in an immediate problematic situation and to the goals of social science by joint collaboration within a mutually acceptable ethical framework”. Moreover, he identifies three dilemmas: ethical dilemmas, goal dilemmas and Australasian Journal of Information Systems Cronholm, Gӧbel & Shrestha 2024, Vol 28, Research Article Collaboration in Action Design Research 5 dilemmas of initiatives. He concludes that the action researcher seeks to optimise ta balanced realisation of both the practical affairs of humans and the intellectual interests of the scientific community. Second, Susman and Evered (1978) present a method for action research that is proposed as an alternative to procedures emanating from positivist science. The cyclical method consists of five phases: diagnosing, action planning, action taking, evaluating and specifying learning. One purpose of the method is to support collaboration between researchers and practitioners and to generate theory grounded in action. Furthermore, the authors state that action research is future-oriented, collaborative, implies systems development, generates grounded theory, is agnostic and situational. Third, Avison (2001) discusses control mechanisms for action research projects. The primary purpose of the article is to suggest how the "double challenge" of combining both action and research can be overcome. He suggests three aspects of control that action researchers need to focus on: initiation (did the problem discover the research or vice versa?), authority (who is really in charge of the research project?) and formalisation (the degree of formal control structures such as contracts and letter of agreements). Fourth, Mathiassen (2002) reports from a research project in which researchers and practitioners worked together to understand, support, and improve systems development practices in four organisations. He proposes collaborative practice research to organise and conduct research into systems development practice based on close collaboration between researchers and practitioners throughout the whole process. Moreover, he presents four lessons learnt: organise collaborations as a loosely coupled system of related agendas; implement full learning cycles of understanding; supporting and improving practice; combine action research; experiments and practice studies; and establish basic documentation systems to support longitudinal practice studies. Finally, Te’eni et al. (2017, p.542) discuss how research and practice could be made more productive. For example, the authors suggest “… for researchers to influence practice, they need to engage in dialog with practitioners. It is as simple as that”. Furthermore, they argue that practitioners must hear and be heard when it comes to discussions about research of meaningful problems. The authors suggest a new procedure to bring practitioners into the discussion by developing and disseminating reviews of selected research articles that are tailored to the needs and the language of practitioners. One purpose of the procedure is to support researchers to influence practice and to engage researchers and practitioners in a structured dialogue. 2.3 Summary of Literature Review Our analysis of the existing literature has provided valuable insights regarding RPC. However, we can conclude that there is a need for developing complementary prescriptive knowledge about RPC supporting ADR projects. We have found that: a) Our literature review only revealed seven articles presenting RPC challenges in ADR projects. Consequently, there is limited knowledge on this topic; b) All the reviewed articles have developed models, methods or principles that involve different aspects of RPC. The type of knowledge identified is mainly explanatory (why to do something) and normative (what to do) but not prescriptive (how to do); c) The literature review also uncovers that several scholars agree on the need to develop additional knowledge concerning RPC and intervention in organisational contexts Australasian Journal of Information Systems Cronholm, Gӧbel & Shrestha 2024, Vol 28, Research Article Collaboration in Action Design Research 6 (e.g., Haj-Bolouri et al., 2018; Cronholm & Göbel, 2022) and d) There is a lack of guidelines concerning actions to take in order to address RPC challenges. 3 The ADR Project We have analysed a research project guided by the ADR method (Sein et al., 2011). The ADR method consists of four stages which are: a) Problem Formulation: to identify and conceptualise research opportunities based on existing theories and technologies; b) Building, Intervention and Evaluation: to realise the design of the artefact and articulate the design principles; c) Reflection and Learning: to move conceptually from building a solution for a particular instance to applying that learning to a broader class of problems; and d) Formalising of Learning: the situated learning from an ADR project should be further developed into general solution concepts, (see Sein et al., 2011 for a detailed description of the ADR method) (see Figure 1). Figure 1. The stages of the ADR method (Sein et al., 2011) The point of departure for this ADR project was that digital innovation is increasingly contributing to the growth of business. The awareness of the importance of service perspective and data analytics for increased innovation capability has encouraged organisations to search for digital tools to support their innovation efforts. However, the ADR project identified a lack of existing useful digital tools that assist towards achieving innovation. Consequently, the purpose of the ADR project was to develop design principles and a digital tool supporting Australasian Journal of Information Systems Cronholm, Gӧbel & Shrestha 2024, Vol 28, Research Article Collaboration in Action Design Research 7 organisations in their utilisation of data to improve the digital innovation process. The ADR project involved four researchers and nine organisations in Sweden. The organisations belonged to multiple sectors, were of different sizes (small, medium, and large), and were classified as service providers or service customers in the private or public sector. The industry sectors represented were the automobile industry, telecommunications, and IT. The roles of the participating practitioners involved were the following: IT Quality Manager, Head of Architecture and Solutions, IT consultants, Manager of Consumer Services, Business Manager, CEOs, IT Process Framework Manager, Software Developers, and Manager Consumer Sales. The researchers consisted of two professors and two PhD students from the field of IS. The project was conducted over a period of three years. The ADR project collected data from all the organisations by conducting interviews and organising workshops. Each interview lasted for approximately 1 hour each and each workshop lasted for 2-3 hours. The interviews were recorded and transcribed. All researchers and practitioners were deeply involved in the ADR project during the organisational interventions and in the design and evaluation of the digital tool. During the ADR project, we realised that the ADR project also provided an excellent opportunity to analyse RPC. This meant that we identified RPC challenges and actions taken to address the challenges in parallel with the fulfilment of the objectives of the ADR project. The reasons for utilising the ADR project for analysing RPC were: a) it consisted of frequent interactions between researchers and practitioners, which preferably took place in the participating organisations’ contexts, b) it provided access to organisational settings and c) it provided access to rich data from interventions in nine organisations. Initially, there was a rift between the researchers’ and practitioners’ interests in the ADR project. Based on this observation, we realised that RPC is more difficult in “practice than on paper”. Conboy (2009, p.329) states that it is essential to distinguish between the “documented method” and the “method-in-action”. The documented method is intended to serve as an ideal model for the development process (Iivari & Maansaari, 1998), while the method-in-action describes the way it may be used in a particular situation (Fitzgerald et al., 2002). Our study consists of an empirical analysis of an instantiation of the ADR method. 4 Research Design In this paper, the result of the ADR project is placed in the background, and the focus is on the RPC challenges that occurred in the ADR project and actions taken to address these challenges. Our overall research design has been both inductive and deductive. We commenced with an inductive analysis of an ADR project which resulted in three themes regarding RPC. These themes were then generalised into three corresponding theoretical models. Thereafter, the three models were integrated into an overarching model (see section 6). The models represent abstractions from the ADR project. In the next step, we deducted three guidelines from the themes and models with the purpose of developing prescriptive knowledge that could help future ADR projects to manage RPC challenges (see section 7). Moreover, we have also compared our findings with previous knowledge (see section 8). We collected data from both a researcher and practitioner perspective. We used the following sources: a) RPC statements in the ADR method, b) notes taken from discussions among the researchers and practitioners during project meetings and workshops, c) documentation of Australasian Journal of Information Systems Cronholm, Gӧbel & Shrestha 2024, Vol 28, Research Article Collaboration in Action Design Research 8 collaborative actions taken and d) project documentation. In total, data were collected from 15 project meetings and 23 interventions in the practitioners’ organisations (workshops). In order to collect data from practitioners, we conducted nine group interviews involving several representatives from each organisation. In order to collect data from a researcher perspective, we interviewed the researchers who intervened in the organisations and were active when designing and evaluating the digital tool. The RPC challenges were identified and analysed by the authors of this paper, who also participated in the ADR project. This meant that the authors of this paper had dual roles: a) developing design principles and a digital tool supporting organisations in their utilisation of data to improve digital services and b) reflecting upon the ADR project in order to create prescriptive knowledge concerning researcher-practitioner collaboration. In order to ensure that relevant data regarding RPC collaboration was collected, the three characteristics of the ADR method described in section 1 were used as a lens for collecting data, i.e., a) the design of IT artefacts should be based on intervention in authentic organisational settings, b) respond to the dual mission of making theoretical contributions and assisting in solving the problems of practitioners and c) encouragement for generalisation of qualitative studies. In order to analyse the collected data, we applied the Grounded Theory Method (GTM) to analyse RPC in the ADR project. Grounded theory is a qualitative research method that seeks to develop theories grounded in data. There were several reasons for selecting GTM. Urquhart et al. (2010) state that GTM “… has proved to be extremely useful in developing context-based, process-oriented descriptions and explanations of information systems phenomena” (p.358). Charmaz (2017, p.34) views GTM from a pragmatic perspective and adds that GTM is “interrogating the taken-for-granted” and “taking a deeply reflexive stance”. Moreover, GTM provides explicit, sequential guidelines for conducting qualitative research Strauss and Corbin, 1990). GTM exist in several types and versions (Chun et al., 2019; Goldkuhl & Cronholm, 2019). We have followed the open, axial and selective coding steps suggested by Strauss and Corbin (1990). One reason for selecting this version is that it strongly supports the application of an action-oriented paradigm in the axial coding step. Finally, in order to be transparent and claim rigour, we have followed the principles for qualitative research suggested by Klein and Myers (1999). In particular, we have applied the fundamental principles of the hermeneutic circle in order to understand the relationship between parts and the whole (i.e., the parts of the theoretical models and the core theme, see figures 3-6), the principle of contextualisation when identifying organisation-specific conditions, actions and consequences, the principle of abstraction and generalisation when developing the theoretical models, and the principle of multiple interpretations when interpreting the collected data. Next, we describe how the three coding steps and the development of guidelines were implemented in this study. 4.1 Open Coding – Generation of Categories In interpretive approaches such as GTM, the analyst makes various decisions about how to comprehend the data (Walsham, 1995). Risks concerning biased interpretation can be reduced by involving two or more researchers when searching for and analysing data. Therefore, two of the authors of this paper analysed the collected data individually with the purpose of creating categories and subcategories by grouping similar concepts. In the following step, the result of the individual analyses was jointly compared and reconciled. Moreover, we also Australasian Journal of Information Systems Cronholm, Gӧbel & Shrestha 2024, Vol 28, Research Article Collaboration in Action Design Research 9 made comparisons between data collected from the nine participating organisations in order to identify similarities and differences. Axial Coding – Identification of Relationships between Categories The purpose of the axial coding was to create theoretical models by identifying vertical and horizontal relationships between the categories. The vertical relationships in our analysis consist of superior categories and subcategories. The creation of horizontal relationships was supported by the action paradigm model consisting of three meta-categories: conditions, actions and consequences (Strauss & Corbin, 1990). A condition defines a specific circumstance and corresponds to the questions “why” or “what” (e.g., conditions for RPC challenges to appear). An action describes something that occurs under particular circumstances and corresponds to the question “how” (e.g., actions taken to address the condition). A consequence is a result dependent on the conditions and actions. It corresponds to the question of “what happens” if specific actions are carried out (e.g., consequences of the actions taken). The creation of horizontal relationships meant that the superior categories were additionally categorised in accordance with one of the meta-categories. We refer to units consisting of conditions, actions and consequences as themes. The themes were identified by iteratively moving back and forth between the open, axial, and selective coding steps. Each theme has been illustrated as a theoretical model. Selective Coding – Development of Theory and Identification of Core Category During the selective coding step, we developed an overarching theoretical model (core theme) that connected all the theoretical models created in the axial coding step. The purpose of the overarching model was to integrate the findings into a whole that represented the main topic of the study. Finally, we checked the content of the theoretical models and the relationships between the themes in order to ensure consistency and coherency. This meant that we re- analysed the theoretical model in terms of structure, logic and uniformity. Development of guidelines regarding RPC Finally, we have developed prescriptive knowledge in terms of guidelines. Gregor (2009) states that developing prescriptive knowledge involves creativity and imagination. In our study, this meant that we derived guidelines from the theoretical models developed during the steps of axial and selective coding. In order to formulate the guidelines, we have in particular focused on categories related to the meta-category “actions”. This meant that the actions have been further refined in order to provide detailed guidelines for RPC management. The formulation of the guidelines has been inspired by Hollnagel (2012), who suggests a structure consisting of a description of why something is important, what needs to be done, how to apply the guideline and who contributes with what. Besides these generic questions, we have added when in order to clarify the ADR stage(s) the guidelines apply to. The purpose of the guidelines is to support RPC in future ADR and DSR projects by providing clear examples and techniques. 5 Themes – conditions, actions and consequences The purpose of this section is to presented findings identified in the analysed ADR project. We have found RPC challenges oriented towards the three specific characteristics of the ADR method (see section 1) and more general RPC challenges (e.g., trust, balancing researcher and practitioner interests, establishing a researcher-practitioner agreement). In this paper, we are Australasian Journal of Information Systems Cronholm, Gӧbel & Shrestha 2024, Vol 28, Research Article Collaboration in Action Design Research 10 predominantly interested in ADR-specific RPC challenges. Consequently, we have omitted RPC challenges which are general and well-described in existing literature (e.g., Mathiassen, 2002; Te’eni et al., 2017). Our analysis of the ADR project has identified three themes concerning RPC: a) shape the IT artefacts based on organisational intervention, b) exploit the mutual dependency between developing design principles and IT artefacts, and c) contextualise and generalise learning. Moreover, our analysis of the three themes involved different aspects of reflection and learning, which supported us in suggesting prescriptive knowledge for RPC. In table 1, we demonstrate how the themes relate to the three ADR characteristics presented in section 1. Themes ADR characteristics Shape the IT artefacts based on organisational intervention. The combination of DR and AR, which involves that the design of IT artefacts should be based on intervention in authentic organisational settings. Exploit the mutual dependency between developing design principles and IT artefacts. The dual mission of making theoretical contributions and assisting in solving the problems of practitioners. Contextualise and generalise learning. Generalisation of qualitative studies. Table 1. Suggested themes related to ADR characteristics. The presentation of each theme follows the structure: a) Description of conditions (support) provided by the ADR method for addressing a challenge experienced in the ADR project. b) Presentation of actions taken in the ADR project to address the challenge. The actions taken were inspired by normative statements (what to do) in the ADR method and creative problem-solving discussions among researchers and practitioners in the ADR project. c) Descriptions of consequences of the action taken. d) Confirming quotes from researchers and practitioners to justify the themes. 5.1 Theme 1: Shape the IT artefacts based on organisational intervention The ADR method reflects the premise that IT artefacts are ensembles shaped by the organisational context during development and use. In order to find guidance for shaping the IT artefact, the ADR project examined the ADR method. The following statements were identified: a) “The emerging artifact, as well as the theories ingrained in it, are continuously instantiated and repeatedly tested through organizational intervention and subjected to participating members’ assumptions, expectations, and knowledge” (Sein et al., 2011, p.42). b) “The ADR method simultaneously supports the building of innovative IT artifacts in an organizational context and learning from the intervention while addressing a problematic situation” (Sein et al., p.38). Unquestionably, the statements above clearly indicate that organisational intervention is vital when shaping IT artefacts. The statements inform, in an excellent way, why intervention is essential and what should be done. Unfortunately, the ADR method does not inform how intervention can be organised in collaborative ADR projects. At the beginning of the ADR project, the researchers and practitioners realised that they had different motives for participating in the project. Therefore, the ADR project needed to reduce Australasian Journal of Information Systems Cronholm, Gӧbel & Shrestha 2024, Vol 28, Research Article Collaboration in Action Design Research 11 or eliminate possible tensions between researchers and practitioners, which could obstruct organisational intervention. The main objective for the practitioners was to develop a digital tool supporting them to improve data utilisation. The main objective of the researchers was to make theoretical contributions. However, both parties recognised that the fulfilment of the project goals was highly dependent on successful RPC. In order to develop a shared understanding of different motives and eliminate possible barriers to interventions, the ADR project identified individual and shared goals by organising a workshop where all the members of the ADR project participated. An example of a practitioner goal was to develop a digital tool supporting a structured innovation process, while an example of a researcher goal was to develop design principles supporting the development of such tools. These goals uncovered underlying motives for participation, and they guided the actions of the researchers and practitioners throughout the ADR project. Another challenge in the ADR project related to intervention was the question of collecting qualitative data for generalisation. Sein et al. (2011) state that the artefact represents a solution that could be generalised and that the “move from the specific-and-unique to generic-and- abstract” is a critical component of the ADR method. However, the design of an IT artefact always reflects the circumstances in the context where it is to be used. Therefore, the ADR project realised that it is not just a matter of moving from the specific to the generic; it is also a matter of creating a qualitative basis which can provide accurate and substantial conditions for generalisation. In the ADR project, this meant that the intervention in the organisations’ settings was regarded as a preparatory part of the generalisation process since the purpose was to collect contextual data that later could be used for abstraction and generalisation in the ADR stages “Reflection and Learning” and “Formalisation of Learning”. Consequently, the ADR project carefully collected contextual factors when intervening in organisational contexts and used method triangulation to increase the probability that generalisations could be made in accordance with contextual findings. We identified that the rigorous collection of contextual data from all the organisations resulted in a large and varied data quantity which described each organisation’s specific problems and solutions requirements. Furthermore, the observation that intervention was regarded as an essential part of the generalisation process created a better understanding of the ADR project as a research project. It could be argued that each organisation was only interested in its own contextual data, individual goals and problems, and solutions, and not in generalisations of data. However, the ADR project discovered that the organisations found it valuable to interact with each other in order to learn more about how other organisations tackled challenges related to innovation. Therefore, the ADR project organised workshops involving all the organisations with the purpose of sharing knowledge across organisations. Finally, the members of the ADR project realised that evaluating organisational intervention could be time-consuming and ad-hoc since there were no guidelines in the ADR method. Therefore, the ADR project developed an intervention strategy that was initiated by the researchers. However, the strategy was agreed upon collectively and formulated jointly by the researchers and the practitioners in a workshop involving all nine organisations. The strategy included the following steps: 1) Define the context, 2) Decide on intervention approach, and 3) Describe anticipated and unanticipated consequences. All decisions made about the planning of the ADR project were carried out in consensus between the researchers and practitioners. Next, the steps will be presented in detail. Australasian Journal of Information Systems Cronholm, Gӧbel & Shrestha 2024, Vol 28, Research Article Collaboration in Action Design Research 12 Step 1 Define the context The context was defined by describing the characteristics of the practitioners working place and included descriptions of: what is the nature of the work that is conducted, what roles (practitioners) should be involved in the intervention, what process should be analysed, what data are relevant and what digital systems were currently used. Examples of contextual characteristics collected during the ADR project were a specific focus on data related to the innovation process and adoption of a service-oriented perspective. The latter included value co-creation between service customers and providers. These characteristics were jointly defined by researchers and practitioners by identifying, documenting and agreeing upon boundaries. The context definition supported the ADR project to focus on what was considered as essential and what was regarded as being outside the scope of the project. The ADR project continuously revised the context definition due to project results and learning. Step 2 Decide on intervention approach The ADR project decided to use naturalistic intervention sessions, which meant that the interventions took place in the organisations’ settings (Venable et al., 2016). The purpose of the intervention sessions was to formatively evaluate the digital tool. Moreover, the sessions were influenced by Sprint Demonstrations (Schwaber & Sutherland, 2011), which is a short time- boxed period when a team works to complete a set amount of work. In addition, the ADR project also used techniques for root-cause analysis (Wilson et al. 1996) in order to identify problem causes and effects. Both these techniques were familiar to the practitioners. All the sessions involved both managers and operational staff in order to increase the possibility of collecting data from several perspectives. One intervention session involved the evaluation of the digital tool and follow-up interviews. The purpose was to collect feedback that could be used for a redesign of the digital tool and the development of the design principles. The ADR project conducted three iterations of the intervention sessions. In total, 23 sessions were carried out (2-3 sessions per organisation). The reason for ending the intervention session after three iterations was saturation in data, i.e., the marginal benefit of one more iteration was judged to be low. The result from each intervention session was considered as highly contextual (organisational- specific). In order to formulate meta-requirements (class of problems), a more generalised digital tool and generalised design principles, the ADR project organised workshops involving all the nine companies. In these highly interactive workshops, researchers and practitioners jointly agreed upon formulations on higher abstraction levels. Step 3 Describe anticipated and unanticipated consequences For each intervention session, anticipated and unanticipated consequences from evaluating the tool were identified (Sein et al., 2011). In order to keep track of the consequences through the iterations, the ADR project created a table consisting of three columns: anticipated consequences, unanticipated consequences and comments. An anticipated consequence corresponded to positive feedback while suggestions for improvement were considered as unanticipated consequences. Description of unanticipated consequences and comments were used for a redesign of that particular function of the digital tool. Furthermore, unanticipated consequences were again evaluated in the following iteration. The table of the anticipated and unanticipated consequences supported the ADR project to follow how the digital tool and design principles emerged over time. Australasian Journal of Information Systems Cronholm, Gӧbel & Shrestha 2024, Vol 28, Research Article Collaboration in Action Design Research 13 A consequence of the collaborative planning of the intervention strategy strengthened the convergence of shared understanding of different motives between the researcher and practitioners. Finally, the ADR project found that the intervention strategy supported efficient and effective interventions. We end the description of this theme by presenting quotes from researchers and practitioners: “The systematic intervention strategy guided us to organise the intervention in a way that encouraged learning between practitioners and researchers, and between practitioners themselves” (researcher) “The systematic intervention strategy supported transparency of the process and it also made the expectations of each other more transparent” (practitioner) “We appreciated the opportunity to evaluate the tool in our organisation since it meant that we had a real impact on the development” (practitioner) “We are happy to include ideas from researchers. In our systems development projects, we would never consider merging design requirements derived from theory with our own requirements” (practitioner) 5.2 Theme 2: Exploit the mutual dependency between developing design principles and IT artefacts The ADR method stresses the importance of developing design principles and IT artefacts. The design principles should emerge from the reconceptualising of the specific solution instance into a class of solutions, while the IT artefacts (the solutions) evolve as a result of iterative design and evaluation. We have identified helpful support in the ADR method for developing IT artefacts. However, we have not, to the same extent, found support for developing design principles. Consequently, there is an imbalance concerning the support for developing design principles and IT artefacts. The following support was found in the ADR method for developing design principles (Sein et al. 2011): a. “During BIE [Building, Intervention, and Evaluation], the problem and the artifact are continually evaluated, and the design principles are articulated for the chosen class of systems”. (p.42) b. “The design principles capture the knowledge gained about the process of building solutions for a given domain, and encompass knowledge about creating other instances that belong to this class”. (p.42) c. “Articulate outcomes as design principles”. (p.45) We recognise that there is an implicit relationship between some of the principles in the ADR method and theme 2. However, the added value of proposing this theme is that it helps to identify a detailed level of the relationships between the design principles, IT artefact, theory and empirical data (see figure 2). We also acknowledge the informative and well-structured case description at the end of the paper presented by Sein et al. (2011). The case description involves support for developing design principles and describes in an excellent way how design principles emerge over time. However, the case was conducted as an action research project and was later reconstructed as an ADR case. This means that the case was not conducted as a design-oriented ADR project and therefore it is unclear how the significant characteristics of the ADR method affected the development of the design principles. During the BIE stage, the ADR project discovered a mutual dependency between the development of the design principles and the digital tool. As mentioned above, the ADR method provides excellent support for developing the IT artefact and some support for developing design principles. However, there is no explicit support for exploiting the mutual Australasian Journal of Information Systems Cronholm, Gӧbel & Shrestha 2024, Vol 28, Research Article Collaboration in Action Design Research 14 dependency between the IT artefact and the design principles. This mutual dependency can be exploited in order to fulfil the project goals. The purpose of the emerging design principles was to guide the development of the digital tool. At the same time, the digital tool was a carrier of design knowledge that could be tested. This insight was based on feedback from the intervention sessions that involved the organisations’ evaluations of the digital tool. We realised that the evaluation of the digital tool not only affected the re-design of the digital tool but also provided valuable knowledge to refine the design principles. This understanding resulted in a decision that the digital tool and the design principles needed to be developed in parallel, which was something that the ADR project had to consider in the project planning. The mutual dependency between the development of the design principles and the digital tool consisted of: • The development of design principles was guided by empirical feedback from evaluating the digital tool. This meant that the digital tool provided a platform for evaluating the design principles. • The development of the digital tool was guided by the emerging design principles. This meant that enhancements of the design principles were used to shape the digital tool. The ADR project utilised the mutual dependency in order to balance competing interests. As mentioned in section 5.1, the researchers’ primary interest was to develop design principles while the practitioners’ primary interest was to design a digital tool. This meant that a significant action in the ADR project was to articulate the close relationship between the researchers’ primary interest in developing design principles and the practitioner’s primary interest in making the mutual dependency transparent. This transparency supported an increased understanding of how the researcher and practitioner interests could benefit from each other. Moreover, the feedback from evaluating the digital tool also resulted in new insights prompting the researchers to consult complementing theories such as resource-based theory (e.g., Penrose, 1959) and service-dominant logic (e.g., Vargo & Lusch, 2004. This meant that the ADR project utilised the empirical feedback as a guide for identifying complementing theories, which provided further knowledge for developing the design principles and the digital tool. Consequently, the formulation of the design principles and the development of the digital tool were based on theoretical insights and empirical evidence. Our analysis of the mutual dependency of the design principles and the digital tool (IT artefact) is illustrated in Figure 2. One example of this mutual dependency is related to resource liquefying. In the ADR project, resource liquefying was defined as the mobilisation and decoupling of resources from their related physical form or device (e.g., Lusch and Nambisan 2015). That is, more decoupled resources could increase the capability for service innovation. Based on this service-oriented theoretical statement, researchers formulated an initial design principle which inspired the ADR project to develop functionality that supports the liquefaction of resources. However, during the evaluation of the tool, the ADR project identified that there was a need to extend the functionality to include the possibility for users to communicate and share knowledge related to specific characteristics in the context, i.e., a communication protocol. Consequently, the ADR project redesigned the digital tool and modified the initial formulation of the design principles. Australasian Journal of Information Systems Cronholm, Gӧbel & Shrestha 2024, Vol 28, Research Article Collaboration in Action Design Research 15 Due to the increased understanding of the mutual dependency of the design principles and the digital tool, the collaboration between the researchers and practitioners was further motivated. This insight increased the acceptance of solving both the scientific problem and the problem that existed in practice, creating a better willingness to share knowledge. Moreover, the constant use of theories and empirical feedback created a solid grounding of the design principles and the artefact. Figure 2. Mutual dependencies between the design principles and the IT artefact. Another challenge in the ADR project was how to formulate design principles. The design principles were of interest to both researchers (as a form of theoretical knowledge) and practitioners (as practical guidance when designing IT artefacts). This means that the design principles had to be jointly verified by the researchers and practitioners. The examples of design principles provided by the ADR method consist of a title and a short description of attributes of the artefact (i.e., what components the artefact should include). The ADR project experienced a need for expressing design principles in a more advanced way that also involved action-oriented support (i.e., what actions the artefact should allow for) and justificatory support (arguments). Consequently, the ADR project conducted a literature review in order to identify standards for formulating design principles. The ADR project identified several valuable suggestions such as: March and Smith (1995), Chandra et al. (2015), Cronholm and Göbel (2018), Goldkuhl (2004), van Aken (2004) and Van den Akker (1999). The ADR project decided to follow the recommendation suggested by Van den Akker (1999) because it supported a structured description consisting of where to do (context), what to do, how to do and why to do. It also provided a logical structure and supported that design principles be formulated on the same abstraction level. These advantages were considered supportive because some members of the ADR project were novices regarding the development of design principles. The suggestion reads: If you want to design intervention X [for the purpose/function Y in context Z], then you are best advised to give that intervention the characteristics A, B, and C [substantive emphasis], and to do that via procedures K, L, and M [procedural emphasis], because of arguments P, Design principles IT artefact (digital tool) Theory Evaluation sessions governs the design of provides an evaluation platform for provides insights Insights for consulting complementing theory provides empirical evidence provides insights Australasian Journal of Information Systems Cronholm, Gӧbel & Shrestha 2024, Vol 28, Research Article Collaboration in Action Design Research 16 Q, and R. One example of a design principle formulated in the ADR project reads: “ If you want to design a digital resourcing system for the purpose of enabling actors in a service-oriented context to co-create novel value propositions in the discovery stage of the digital innovation process, then you are best advised to design the digital resourcing system to support actors in service-ecosystems so they can mobilise and decouple resources, and to do that via contextualised communication protocols, defined boundary objects and to store those resources as digital resources because it creates a sound data source fostering digital innovation.” Finally, we present some confirming quotes from researchers and practitioners regarding our findings: “The integration of theory into the IT artefact helped us to justify design solutions and in a cumulative way build further on existing knowledge” (researcher) “In the beginning of the project we were interested in tools for data utilisation, but now we are equally interested in the design principles” (practitioner) “The feedback from practitioners guided us when consulting theories that we initially did not think were relevant. It meant that we expanded our literature search in order to ingrain additional theories into the IT artefact” (researcher) 5.3 Theme 3: Contextualise and generalise learning Sein et al. (2011) explicitly state that ADR projects should move from the specific-and-unique to generic-and-abstract. They define three levels for this conceptual move: generalisation of the problem instance, generalisation of the solution instance, and derivation of design principles from the project results. The following support for generalisation was found in the ADR method: a. “The reflection and learning stage move[s] conceptually from building a solution for a particular instance to applying that learning to a broader class of problems”. Sein et al. (2011, p.44) b. “The situated learning from an ADR project should be further developed into general solution concepts for a class of field problems” Sein et al. (2011, p.44) c. “The action design researcher should generate knowledge that can be applied to the class of problems that the specific problem exemplifies” (Sein et al. 2011, p. 40) d. “Reconceptualizing the learning from the specific solution instance into design principles for a class of solutions” Sein et al. (2011, p.45). All these quotes convincingly explain why it is important to generalise and what should be done. However, the ADR project identified insufficient support for what actions to take in order to meet the generalisation requirement. This meant there was a need for guidelines due to the highly contextual nature of the organisational interventions. Moreover, the ADR project realised that it was important that the findings contribute to each organisation’s specific requirements (contextualisation) but also be valid to other organisations outside the project (generalisation). As mentioned in Section 4, the ADR project was carried out as a qualitative study. The problem of generalisation from qualitative studies is well-known (e.g., Baskerville et al., 2015). In order to meet this challenge, the ADR project utilised the fact that nine organisations participated in the project. The ADR project implemented two mechanisms to support generalisation: a) Arrangements of dyadic researcher-practitioner meetings with all the participating organisations. One dyadic meeting meant that 1-2 researchers interacted with one organisation (2-3 practitioners) at a time to jointly reflect on how the goals were fulfilled and to decide the next step in the process, Australasian Journal of Information Systems Cronholm, Gӧbel & Shrestha 2024, Vol 28, Research Article Collaboration in Action Design Research 17 b) Multi-organisational workshops that involved all the nine organisations and the researchers. In addition, we identified an interplay between the dyadic meetings and the multi-organisational workshops. For example, the contextual problems and requirements for developing the IT artefact were used as input for generalisation. At the same time, vague and unclear generalisations regarded as incomplete governed further collection of contextual data. This means that the generalisation process was conducted as a mix of a bottom-up and top- down approach. It also meant an iterative process of describing contextualised and generalised learning. More specifically, the ADR project was inspired by object-oriented techniques (e.g., Date 2006) such as UML diagrams (e.g., Blaha & Rumbaugh, 1991) supporting the formulation of a problem class and problem instances. These techniques supported the practitioners’ acceptance to move from the contextual instances of the problems to the general understanding of the problem class. The object-oriented technique also supported the generalisation of design principles. Another identified consequence was that the ADR project experienced the generalisation process as positive because it legitimises research as a profession. It also advises against a type of IT consultant behaviour that consists of merely solving an instance of a problem. Besides generalisation, the ADR method should support researcher and practitioner learning. Sein et al. (2011) state that principle 4, Mutually Influential Roles, particularly addresses the importance of mutual learning among the different project participants. However, the ADR project discovered that learning in the ADR method is mainly discussed in relation to researchers. The organisation of the dyadic meetings and multi-organisational workshops also contributed to practitioner learning. Furthermore, learning was also supported by a mix of researcher and practitioner presentations at a seminar and joint publications of scientific and technical papers. The process of co-authoring papers formalised insights and learning for both researchers and practitioners. Lastly, we present a few quotes from researchers and practitioners regarding our findings. “To identify a class of problems increases the possibility that the problem is true, new and interesting” (researcher) “One reason to participate in the project is to interact and learn from other organisations” (practitioner) “Applying object-oriented techniques when casting problem instances to a class was a critical success factor since the technique was well understood by both practitioners and researchers” (researcher) 6 Theoretical Models The purpose of section 6 is to generalise the three project-specific themes, presented in section 5, into corresponding theoretical models that are aimed to be valid to other ADR and DSR projects. Thereafter, we have created an integrated abstract wholeness illustrating how the three models are related to each other. Glaser and Strauss (2017) state that a substantive theory emerges from conceptual categories grounded in data. In our case, the substantive theory corresponds to theoretical models, which are induced from the analysis of the ADR project (see section 5). The development of the models involved the application of inductive reasoning, which means that the development of theory is based on the collected data, the observations made, and logical thinking (Strauss & Corbin, 1990). Furthermore, the generation of the models utilised theoretical sampling, Australasian Journal of Information Systems Cronholm, Gӧbel & Shrestha 2024, Vol 28, Research Article Collaboration in Action Design Research 18 which is a process of developing theory as it emerges (ibid.). The models also built further on previous knowledge (see discussion in section 8.2). As mentioned in section 4, the structure of the theoretical models follows the action-oriented paradigm consisting of three meta-categories: conditions, actions, and consequences. This means that they explicitly explain the relationships between the conditions for a challenge, the action taken to address the challenge, and the consequences of the actions taken (see Figures 3-5). The models should be interpreted in the following way: a) the conditions provide information about RPC challenges (i.e., the ADR statements informs about what to do but not how to do something), b) the collaborative actions taken provide information about how arrangements can be made to address the challenges and c) the consequences provide information about what will probably happen when the collaborative actions have been carried out. Detailed information about the actions, including supporting techniques, will be given when the guidelines are presented (see section 7). Figure 3. Model of Theme 1: Shape the IT artefact based on organisational intervention. Conditions “The emerging artifact, as well as the theories ingrained in it, are continuously instantiated and repeatedly tested through organizational intervention and subjected to participating members’ assumptions, expectations, and knowledge” (Sein et al., 2011, p.42). “The ADR method simultaneously supports the building of innovative IT artifacts in an organizational context and learning from the intervention while addressing a problematic situation” (Sein et al., p.38). Actions Collaboratively develop an intervention strategy: - Define the context. - Prioritise contextual characteristics. - Reciprocally shape the IT artefact and the organisational context. - Reflect on the implemented contextual characteristics. Consequences - Deepened understanding of the problem. - Organisational problems are viewed as knowledge- creation opportunities. - Agreed, systematic and transparent intervention. - Reduced tension between researchers and practitioners. - The functionality of the artefact is based on organisational relevance. - A solid basis for generalisation. Conditions “During BIE [Building, Intervention, and Evaluation], the problem and the artifact are continually evaluated, and the design principles are articulated for the chosen class of systems”. (Sein et al., 2011, p.42) Actions Collaboratively exploit the mutual dependency: - Create a protocol that describes how the mutual relationship between the design principles and IT artefact is utilised. - Describe anticipated and unanticipated consequences systematically. - Choose appropriate guidelines when formulating design principles. Consequences - Strengthened validation of design principles and IT artefact. - Articulated design principles for a chosen class of systems. - Increased practitioner acceptance of developing a solution as an instance of the problem and a class of problems. - Improved understanding of design principles. Australasian Journal of Information Systems Cronholm, Gӧbel & Shrestha 2024, Vol 28, Research Article Collaboration in Action Design Research 19 Figure 4. Model of Theme 2: Exploit the mutual dependency between design principles and IT artefacts. In the next step, we identified an overarching theoretical model that integrated the three themes. The purpose of the overarching model is to illustrate a wholeness showing how the three themes presented in Figure 3-5 are related to one another. Therefore, the overarching model constitutes an abstraction of these themes and is entitled “Researcher-practitioner collaboration: overarching ADR challenges and solutions”, which corresponds to the central topic of our study (see Figure 6). The overarching theoretical model was identified by Figure 5. Model of Theme 3: Contextualise and generalise learning. analysing the relationships between the three themes. The first one, “Shape the IT artefact based on organisational intervention”, was regarded as a condition for the other two themes since it establishes a critical point of departure for RPC. The second theme, “Exploit the mutual dependency between developing design principles and IT artefacts.”, is regarded as a central action since it constitutes a primary concern for RPC and is affected by the theme “Shape the IT artefact based on organisational intervention”. Finally, the third theme, “Contextualise and generalise learning”, is considered a consequence since the likelihood of learning will increase if the first and second themes are adequately addressed. Conversely, “contextualise and generalise learning” will probably be obstructed if ADR projects fail to manage the first and second main themes. 7 Guidelines The purpose of this section is to complement the theoretical models and themes presented above with three guidelines for RPC. The main difference between the theoretical models and the guidelines is that the theoretical models illustrate a wholeness consisting of conditions- actions-consequences while the purpose of the guidelines is to deepen the action-part of the theoretical models in order to offer concrete recommendations. That is, the guidelines aim to Conditions “The situated learning from an ADR project should be further developed into general solution concepts for a class of field problems” Sein et al. (2011, p.44). “Reconceptualizing the learning from the specific solution instance into design principles for a class of solutions” Sein et al. (2011, p.45). Actions Collaboratively contextualise and generalise learning: - Up-cast and down-cast between instances and classes. - Specify learning outcomes on two abstraction levels: contextualised and generalised. - Utilise the interplay between dyadic meetings and multi-organisational workshops as a means to move from the specific-and-unique to generic- and-abstract. - Identify an appropriate generalisation level. Consequences - Problem and solution instances are cast as classes. - Transparent move from contextualised and generalised learning. - Combined researcher and practitioner learning. - Learning between companies. Australasian Journal of Information Systems Cronholm, Gӧbel & Shrestha 2024, Vol 28, Research Article Collaboration in Action Design Research 20 make the theoretical models more actionable through providing more details, examples and techniques. The need for developing guidelines regarding RPC is supported by several Figure 6. The overarching theme on RPC challenges and solutions. scholars (e.g., Collatto et al., 2017; Haj-Bolouri et al., 2018; Cronholm & Göbel, 2018; Henriques & O’Neill, 2021). For example, Haj-Bolouri et al. (2018) state that the ADR method is a high- level framework and that there is a need for more concrete ways of working with the methodology. As mentioned in section 4, we have structured the guidelines according to the five generic components: why something is important to do, what needs to be done, how to apply the guideline, when something should be done (what ADR stage) and who can contribute. 7.1 Guideline 1: Strategize organisational intervention to identify contextual characteristics Why: Context awareness is crucial when using the ADR method because of the reciprocal relationship between the organisational context and an IT artefact. This means that the context affects the design of the IT artefact, and the IT-artefact affects the context. Sein et al., 2011, p.43) state that “Researchers bring their knowledge of theory and technological advances, while the practitioners bring practical hypotheses and knowledge of organizational work practices”. Therefore, the primary purpose of guideline 1 is to help researchers and practitioners to strategize organisational intervention collaboratively by systematically and simultaneously building and evaluating innovative IT artifacts and learning from the intervention while addressing a problem in a contextual situation. What: Collaboratively develop an intervention strategy. How: Action 1- Define the context. We define context as “Any information that can be used to characterise the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves” (Dey, 2001, p. 5). Based on the definition, we recommend that researchers and practitioners broadly identify contextual characteristics (quantitative and qualitative) that could potentially impact on the design. Action 2 - Prioritise contextual characteristics. In the second activity, we recommend that researchers and practitioners jointly prioritise the identified characteristics by assessing their perceived importance in influencing the IT artefact. The output from Condition: IT artefacts shaped by organisational intervention. Action: Exploit the mutual dependency between design principles and IT artefacts. Consequence: Contextualised and generalised learning. Researcher-practitioner collaboration: overarching ADR challenges and solutions Australasian Journal of Information Systems Cronholm, Gӧbel & Shrestha 2024, Vol 28, Research Article Collaboration in Action Design Research 21 Activity 2 consists of a structured list of characteristics systematically described at different priority levels. Action 3 - Reciprocally shape the IT artefact and the organisational context. Organisational intervention is always naturalistic (Venable et al., 2016), which can be carried out as a formative or summative evaluation (Scriven, 1996). In order to support reciprocal shaping, we recommend the ADR project to carry out evaluation episodes consisting of four steps: a) the researchers present the current status of the IT artefact to the practitioners, b) the practitioners test the IT artefact when working on an actual task while researchers are aware of contextual characteristics and take notes, c) the practitioners provide feedback and d) the researchers conduct individual interviews with the participating practitioners based on evaluation properties and contextual characteristics. Action 4 - Reflect on the implemented contextual characteristics: Since the process for organisational intervention is iterative, we recommend that researchers and practitioners, based on learnings from step 3, jointly review the implemented contextual characteristics and the potential need for changes of the context definition. Examples of questions that could be asked are: How does the IT artefact align with the context? What effects did the artefact have on the context? Did the context affect the use of the IT-artefact? When: Primary ADR stages are Problem Formulation, BIE, Reflection and Learning. Who: Researchers and practitioners contribute with their unique competences. 7.2 Guideline 2: Capitalise on the mutual dependency between the IT-artefact and design principles to support guided emergence Why: The primary purpose of capitalising on the mutual dependency between the emergent IT-artefact and the design principles is to increase the transparency and optimise validation of both the IT-artefact and design principles. What: Utilise the interplay between the emergent IT artefact and design principles. The knowledge gained from developing the design principles can be utilised to build the IT artefact and vice versa. How: Action 1 - Create a protocol that describes how the mutual relationship between the design principles and IT artefact is utilised. We recommend ADR projects to view the IT artefact as a platform for evaluation of the design principles and letting the emergent design principles govern the ongoing development of the artefact. This means to a) thoroughly describing how well-received functionality regarding the IT artefact affects the formulation of the design principles and b) informing on how emergent design principles affect the design of the IT artefact. This activity means creating explicit relationships between the IT artefact and a design principle. In order to support transparency of the mutual dependency, we recommend ADR projects to document the relationships in a table consisting of three columns: functionality of the IT artefact, design principles and comments. In order to support the transparency of the progress of the emergent IT artefact and design principles, we strongly advocate that the table includes both graphical and textual descriptions. Australasian Journal of Information Systems Cronholm, Gӧbel & Shrestha 2024, Vol 28, Research Article Collaboration in Action Design Research 22 Action 2 - Describe anticipated and unanticipated consequences systematically. We recommend that researchers and practitioners systematically analyse anticipated and unanticipated consequences during each BIE iteration. Anticipated consequences correspond to functionality in the IT artefact that is well received by the practitioners. Unanticipated consequences correspond to functionality that is in need of further development in the following BIE iteration. In order to keep track of anticipated and unanticipated consequences, we recommend ADR projects use a table consisting of three columns: anticipated consequences, unanticipated consequences and actions to be taken. The table is used when researchers and practitioners are planning the next BIE iteration. This iterative process ends when the researchers and practitioners agree that no further iterations are necessary. This systematic way of documenting anticipated and unanticipated consequences for each BIE iteration will support transparency, communication and learning between researchers and practitioners. Action 3 - Choose appropriate standards when formulating design principles. Design principles target both researchers and practitioners which means that they should be collaboratively formulated. In order to ensure that design principles are homogenously formulated, we recommend that guidelines are selected. There exist several standards for formulating design principles such as: March and Smith (1995), van Aken (2004), Goldkuhl (2004), Van den Akker (1999), Chandra et al. (2015) and Cronholm and Göbel (2018). All these suggestions build, in one way or another, on the formula “perform action A in order to obtain goal B”. We recommend that ADR projects scrutinise different alternatives and make choice according to the complexity of the circumstances. When: Primary ADR stages are BIE, Reflection and Learning, Formalisation of Learning. Who: Researchers contribute with design knowledge, standards for formulating design principles and technical skills. Practitioners contribute with suggestions for improvements (feedback). 7.3 Guideline 3: Exploit up-casting and down-casting to maximise contextualised and generalised learning Why: The primary purpose of recommending up-casting and down-casting is to support contextualised and generalised learning and to identify appropriate generalisation levels by traversing classes and instances both bottom-up (up-casting) and top-down (down-casting). What: Exploit contextual learning as a means of generalised learning. Contextual learning involves learning about instances such as specific characteristics (e.g., goals, needs and problems). Generalised learning means to up-cast the specified learning into learning about a class. How: Action 1 - Up-cast and down-cast between instances and classes. While guideline 1 focuses on the context, guideline 3 focuses on the process of moving from contextual findings to generalised learning. This means exploiting previous contextual learning to acquire generalised learning. In order to cast the problems and solutions as instances of a classes, we recommend ADR projects to utilise object-oriented techniques. (e.g., Date 2006). Using object-oriented techniques involves creating class diagrams and, for example, identifying properties, operations and processes of an instance (context) that also could be encapsulated within a class. The class acts as a blueprint and defines the Australasian Journal of Information Systems Cronholm, Gӧbel & Shrestha 2024, Vol 28, Research Article Collaboration in Action Design Research 23 structure and behaviour of instances. We recommend an up-casting (bottom-up) approach when creating classes of problems and solutions and their relationships to instances. However, the creation of classes also requires a down-casting (top-down) approach. The design knowledge created from a previous BIE iteration can be seen as a tentative class which can be down-casted and tested in the following BIE iteration. This means that new findings in the following iteration is tested against the tentative class to verify that it belongs to the class. The iterations consist of a continuous interplay between up- and down-casting. In addition, we recommend that theoretical sampling is conducted when a class is vague or unclear (Glaser & Strauss, 2017). Action 2 - Specify learning outcomes on two abstraction levels: contextualised and generalised. We recommend that learning is specified on both contextualised and generalised levels. The idea is that the contextualised learning works as a stepping stone for achieving generalised learning. This means that the specifics of a context need to be properly described before abstractions can be made. Moreover, a thorough description of contextual learning should be of extreme interest to the practitioners. Action 3 - Utilise the interplay between dyad meetings and multi-organisational workshops as a means to move from the specific-and-unique to generic-and-abstract. If the ADR project involves several organisations (or has the possibility to confirm results with other organisations outside the project), we recommend that the contextual data gathered from dyadic meetings are used as input to multi-organisational workshops. As mentioned in section 5.3, a dyadic meeting involves researchers and practitioners from one organisation. A multi-organisational workshop involves all the participating organisations and can be viewed as a tool for generalising problem and solution instances into problem and solution classes. This means that different problem and solution instances are jointly discussed in order to arrive at class descriptions that are based on consensus. A multi-organisational workshop is an arena for supporting generalised learning by creating abstract representations of design knowledge. Action 4 - Identify an appropriate generalisation level. Finding an appropriate generalisation level means being able to balance universality and utility (e.g., Lincoln & Guba, 1985). We recommend ADR projects to apply the framework developed by Winter (2013). The framework consists of four abstraction levels: situated knowledge (one of a kind), configurable knowledge (adaptations are needed), archetypical knowledge (generalisation is applicable for all problem situations that share specific properties and generic knowledge (one size fits all), (see section 8.3 for more information). When: Problem Formulation, BIE, Reflection and Learning, Formalisation of Learning. Who: Researchers contribute with techniques regarding generalisation. Practitioners contribute with confirmation and suggestions for improvements regarding the formulation of instances and classes. 8 Discussion Our discussion involves three parts: a) an argumentation for why we view the three themes as predominantly ADR specific, b) a comparison of what is new in our paper and previous knowledge, and c) a possible generalisation of our findings. Australasian Journal of Information Systems Cronholm, Gӧbel & Shrestha 2024, Vol 28, Research Article Collaboration in Action Design Research 24 8.1 Why are the findings predominantly ADR-specific? We argue that the theoretical models and guidelines are predominantly specific to ADR projects because their assembling is based on the three significant characteristics of the ADR method discussed in section 1: • The design of IT artefacts should be based on intervention in authentic organisational settings. • Respond to the dual mission of making theoretical contributions and assisting in solving the problems of practitioners. • Encouragement for generalisation of contextual design studies. We state that these characteristics are not prominent to the same extent in other DSR approaches/methods, or more general IS research methods. For example, the framework proposed in the seminal paper by Hevner et al. (2004) focuses on IT artefact development and does not consider organisational intervention and the role of the organisational context to an extent similar to that of the ADR method. Furthermore, Peffers et al. (2007) have suggested a promising DSR process model for developing IT-artefacts. However, the process model does not a) emphasise that IT artefacts emerge through intervention in organisational settings and does not b) not include support for generalisation or theory development. We can conclude that neither Hevner et al. (2004) nor Peffers et al. (2007) provide explicit prescriptive knowledge for RPC. There are also a few DSR methods that are oriented towards participatory DSR. For example, Soft Design Science Methodology (SDSM) (Pries-Heje et al., 2014) focuses on socio-technical aspects of IS and their integration into organisations and society. The stages in SDSM effectively guide the user of the methodology between the real world and the abstract world. However, the method does not consider the development of innovative IT artefacts to the same extent as the ADR method. Another DSR method is Participatory Action Design Research (PADR) (Bilandzic & Venable, 2011). Similar to ADR, PADR combines Action Research and Design Science Research. However, PADR is limited to supporting urban informatics. Moreover, PADR does not promote generalisation of contextual design studies. The last identified method that supports participatory DSR is also called Participatory Action Design Research (PADRE) (Haj-Bolouri et al., 2016). One purpose of PADRE is to suggest how reflection and learning can be integrated into each stage of the ADR method. This means that PADRE can be seen as an extension of the ADR method and thus involves the same three significant characteristics as the ADR method. In summary, none of these methods appear to offer explicit prescriptive knowledge for RPC. If we look at more general research methods such as Action Research (AR) (e.g., Susman & Evered, 1978; Avison et al., 2001; Cronholm & Goldkuhl, 2004), it is evident that AR supports intervention and knowledge emergence in authentic settings but pays little attention to abstraction and generalisation. Moreover, AR does not provide explicit support for IT artefact development. Against this backdrop, we argue that the theoretical models and guidelines developed in our study are highly relevant to consider when managing RPC in ADR projects. 8.2 What is new in our study? The purpose of this section is to compare theoretical models and guidelines (what is new) with the literature review (what is known) and statements in the ADR method in order to highlight our knowledge contribution. Australasian Journal of Information Systems Cronholm, Gӧbel & Shrestha 2024, Vol 28, Research Article Collaboration in Action Design Research 25 8.2.1 Comparison with the literature review Our literature review revealed that only a few studies present some form of advice or guidelines. The most interesting study was conducted by Haj-Bolouri et al. (2018) who identified three essential topics that researchers experienced when working with the ADR- method: a) how to balance the competing interests of the organisational stakeholders with the interests of a research community, b) how to balance the practitioner need of a situated implementation of the designed IT- artefact against the research need to produce generalised knowledge and c) how to balance the findings between specific and generalisable research outcomes. The purpose of their paper was to conduct a retrospective analysis of how ADR has been used in practice, not to provide guidelines for managing challenges regarding RPC. Our guidelines also suggest specific tools to be used when when moving from problem instances to a class of problems and supporting contextualised and generalised learning. Moreover, Henriques and O’Neill (2021) advocate that focus groups should be used in ADR projects in order to provide traceability between problems, requirements, solutions and artefacts. In addition, Henriques and O’Neill (2021) present statements such as “Rigorous and committed stakeholder engagement is a critical success factor in complex projects” and “The collaboration of stakeholders is paramount to find the best solutions for socio-technical problems”. These statements are clearly oriented towards what to do, while our study is oriented towards how to do something. Our literature review also uncovered a few dilemmas and models regarding RPC. For example, Rapoport (1970) discusses goal dilemmas between researchers and practitioners, which have been an important aspect when formulating our three themes. Furthermore, Susman and Evered (1978) argue that specifying learning is vital, which has contributed to the creation of theme 3 (contextualise and generalise learning). In addition, the research project conducted by Mathiassen (2002), which involved several researchers and organisations, inspired us to organise dyad meetings and multi-organisational workshops (see theme 3). When we compare these dilemmas and models with our study, we can conclude that our models extend previous knowledge with a structure consisting of the meta-categories: conditions, actions and consequences (see Figures 3-7). This means we have suggested a logic consisting of relationships between the categories identified in our study. It is important to note that we do not state that the conditions and the consequences are new. On the contrary, these are reasonably well-described in the existing literature. However, we argue that the actions per se are novel and also the actions viewed in a context consisting of conditions, actions and consequences. Based on our comparison between our study and previous knowledge, we state that our findings extend previous knowledge with guidelines and theoretical models that aim to support users of the ADR method when managing RPC. 8.2.2 Comparison with the ADR method In order to shed light on what is new in our study regarding the ADR method, we have compared statements and principles of the ADR method with the three guidelines suggested in our study. Firstly, Sein et al. (2011) state that “The emerging artifact, as well as the theories ingrained in it, are continuously instantiated and repeatedly tested through organizational intervention and subjected to participating members’ assumptions, expectations, and knowledge” (Sein et al., 2011, p.42). This informative statement describes what to do regarding organisational intervention and has inspired us to develop the guideline “Strategize organisational intervention for guided emergence”. The purpose of the guideline is to support Australasian Journal of Information Systems Cronholm, Gӧbel & Shrestha 2024, Vol 28, Research Article Collaboration in Action Design Research 26 organisational intervention through an intervention strategy collaboratively developed by researchers and practitioners. We state that the guideline complements the statements in the ADR method by informing about how organisational intervention could be conducted. Our guideline should primarily be viewed as a complement to the ADR Principle 1: 3: Reciprocal Shaping. Secondly, Sein et al. (2011) state that the outcomes of an ADR project should consist of an IT artefact and design principles. For example, they emphasise that “During BIE [Building, Intervention and Evaluation stage], the problem and the artifact are continually evaluated, and the design principles are articulated for the chosen class of systems” (p.42). This statement clearly describes what should be done and has inspired us to develop the guideline “Capitalise on the mutual dependency between the IT-artefact and design principles”. The purpose of the guideline is to support efficient validation of IT-artefacts and design principles by utilising their interplay. In addition, several scholars have reported that too much freedom regarding the formulation of design principles has resulted in that reusability cannot be taken for granted (e.g., Kruse & Seidel, 2016; Chandra Kruse & Seidel, 2017; Cronholm & Göbel, 2018). Therefore, our guideline also involves the recommendation to formulate homogenous design principles. Our recommendation specifically targets novice DSR/ADR scholars. The second guideline should primarily be viewed as a complement to the ADR Principle 6: Guided Emergence. Thirdly, Sein et al. (2011, p.44) state: “The situated learning from an ADR project should be further developed into general solution concepts for a class of field problems”. This is a conceptual move that involves contextualised and generalised learning. This statement has constituted a base for developing the guideline “Organise dyadic and multi-organisational interaction for contextualised and generalised learning”. The purpose of the guideline is to contribute to maximised contextualised and generalised learning. We argue that this guideline extends the statements in the ADR method regarding learning by illustrating the interplay between dyad meetings and multi-organisational workshops when casting the problem instance into a class of problems, reconceptualising the specific solution instance into a class of solutions, and specifying learning into design principles for a class of solutions. The third guideline should primarily be viewed as a complement to the ADR Principle 7: Generalised Outcomes. Finally, all the guidelines build on existing statements and principles in the ADR method. We state that the guidelines complement existing ADR statements primarily oriented towards describing what to do and why to do something. Our guidelines also involve suggestions for explicit techniques that could be applied to support the management of RPC. 8.3 Generalisation In section 7.1, we have argued that the identified themes are predominantly ADR-specific. By using the term predominantly, we mean that they are likely to appear in ADR projects but can also appear in other RPC projects involving similar goals, purposes and processes. That is, the themes are primarily but not necessarily exclusively associated with ADR projects. As mentioned above, generalisation is a common requirement for both quantitative and qualitative research studies. Our study is not an exception. In order to discuss the degree of generalisation of our theoretical models and guidelines, we have applied a framework developed by Winter (2013). The framework consists of four Australasian Journal of Information Systems Cronholm, Gӧbel & Shrestha 2024, Vol 28, Research Article Collaboration in Action Design Research 27 abstraction levels: “level 0 - situated knowledge”, “level 1 - configurable knowledge”, “level 2 - archetypical knowledge” and “level 3 - generic knowledge”. “Level 0 - situated knowledge” is defined as one of a kind, i.e., the solution is applicable only in a specific organisation for a specific process at a specific point in time. In our case, this refers to findings in the described ADR project (see section 5). “Level 1 - configurable knowledge” means that, based on either a refinement of archetypes (such as IT artefacts) or on a classification of real-world problems, many problem configurations are differentiated whose solutions are created from reusable modules by configuration or aggregation. If we compare this description to our study, we state that our theoretical models and guidelines are applicable to other ADR projects. In order to support the reuse of our findings in future research ADR projects, we have provided transparent descriptions and explanations. However, contextual adaptions might be needed. “Level 2 - archetypical knowledge” is defined as models applicable for all problem situations that share certain properties (e.g., process type, organisation type, project type/goals, available resources and/or skills). For example, level 2 could refer to other DSR projects using other DSR methods. In particular, we argue that our findings should be considered by other participatory DSR projects using other participatory DSR methods such as Soft DSR Methodology (Pries-Heje et al., 2014), Participatory Action Design Research (PADR, Bilandzic and Venable 2011), and Participatory Action Design Research (PADRE, Haj-Bolouri et al, 2016). “Level 3 - generic knowledge” is defined as one size fits all, i.e., the models are applicable to all organisations in all existing or possible worlds. In the context of generalising the results of our study, level 3 could denote IS projects in general. As stated earlier, the identified themes are predominantly ADR-specific but not necessarily exclusively related to ADR projects. However, regarding levels 3 and 4, we argue that our theoretical models and guidelines should be considered on these higher abstraction levels if they face similar RPC challenges. To conclude, we consider the theory projectable to other contexts with similar characteristics to the studied ADR project. The concept of projectability is introduced by Baskerville and Pries-Heje (2019) as an alternative to the more backwards-looking generalisability concept. 9 Conclusion In section 1, we stated that there was a lack of prescriptive support for RPC in the ADR method. However, we also recognised that the support in responding to the questions of why to collaborate and what to collaborate on is excellent. Thus, our study aimed to present prescriptive knowledge in terms of theoretical models and guidelines that can support RPC collaboration in ADR projects. Based on three central ADR characteristics, we have developed theoretical models consisting of three themes: shape the IT artefact based on organisational intervention, exploit the mutual dependency between developing design principles and IT artefacts, and contextualise and generalise learning. The structure of the models follows an action paradigm model consisting of the meta-categories conditions, actions and consequences, which provide explanatory relationships. We consider the models projectable to other contexts with similar characteristics to the studied ADR project. Moreover, we have developed three guidelines to support RPC. The three guidelines read: strategize organisational intervention to identify contextual characteristics, capitalise on the mutual dependency between the IT-artefact and design principles to support guided emergence, and exploit up-casting and down-casting to Australasian Journal of Information Systems Cronholm, Gӧbel & Shrestha 2024, Vol 28, Research Article Collaboration in Action Design Research 28 maximise contextualised and generalised learning. We can conclude that the actions taken in the analysed ADR project supported a) the ADR project to successfully manage the challenges in order to fulfil the project goals and b) researchers and practitioners to collaborate successfully. We regard our knowledge contribution as a complement to prior knowledge of RPC. We view the theoretical models and guidelines as prescriptive knowledge contributions to both practice and theory. The practice in our case consists of research projects involving researchers and practitioners. Thus, our knowledge contribution addresses ADR project management in particular and DSR and IS project management in general. The theoretical models and guidelines also constitute a theoretical contribution because they add new prescriptive knowledge about RPC. Our conclusions are based on the analysis of an ADR project and previous knowledge regarding RPC. This means that we have built further on previous knowledge on the management of RPC in ADR projects. To further strengthen the theoretical models and guidelines created in this study, we suggest that they will be evaluated in future projects facing RPC challenges. References Argyris, C., & Schön, D. A. (1989). Participatory action research and action science compared: A commentary. American Behavioral Scientist, 32(5), 612-623. http://dx.doi.org/10.4135/9781412985383.n6 Avison, D., Baskerville, R., & Myers, M. (2001). Controlling action research projects. Information Technology & People, 14(1), 28-45. http://dx.doi.org/10.1108/09593840110384762 Baskerville, R., & Pries-Heje, J. (2019). Projectability in design science research. Journal of Information Technology Theory and Application (JITTA), 20(1), 3. Bilandzic, M., & Venable, J. R. (2011). Towards Participatory Action Design Research: Adapting action research and design science research methods for urban informatics. Journal of Community Informatics, 7(3). http://dx.doi.org/10.15353/joci.v7i3.2592 Blaha M. & Rumbaugh J. (1991). Object-Oriented Modeling and Design With UML. Upper Saddle River, NJ, USA: Prentice-Hall. Cambridge Dictionary (n.d.). Guideline. Retrieved May 14, 2024. https://dictionary.cambridge.org/dictionary/english/guideline. Chandra Kruse, L., & Seidel, S. (2017). Tensions in Design Principle Formulation and Reuse. In Proceedings of Design Science Research in Information Systems and Technology. Chandra, L., Seidel, S., & Gregor, S. (2015). Prescriptive knowledge in IS research: Conceptualizing design principles in terms of materiality, action, and boundary conditions. In Proceedings of the Hawaii International Conference on System Sciences. http://dx.doi.org/10.1109/HICSS.2015.485 Charmaz, K. (2017). The power of constructivist grounded theory for critical inquiry. Qualitative inquiry, 23(1), 34-45. http://dx.doi.org/10.1177/1077800416657105 Chun Tie, Y., Birks, M., & Francis, K. (2019). Grounded theory research: A design framework for novice researchers. SAGE open medicine, 7, 1-18. http://dx.doi.org/10.1177/2050312118822927 http://dx.doi.org/10.4135/9781412985383.n6 http://dx.doi.org/10.1108/09593840110384762 http://dx.doi.org/10.15353/joci.v7i3.2592 http://dx.doi.org/10.1177/1077800416657105 http://dx.doi.org/10.1177/2050312118822927 Australasian Journal of Information Systems Cronholm, Gӧbel & Shrestha 2024, Vol 28, Research Article Collaboration in Action Design Research 29 Collatto, D. C., Dresch, A., Lacerda, D. P., & Bentz, I. G. (2018). Is action design research indeed necessary? Analysis and synergies between action research and design science research. Systemic Practice and Action Research, 31(3), 239-267. Conboy, K. (2009). Agility from first principles: Reconstructing the concept of agility in information systems development. Information systems research, 20(3), 329- 354. Cronholm S, & Göbel H. (2018). Guidelines Supporting the Formulation of Design Principles. In Proceedings of the 29th Australasian Conference on Information Systems. Sydney, Australia, Dec 3-5. http://dx.doi.org/10.5130/acis2018.ak Cronholm, S. & Göbel, H. (2019). Evaluation of Action Design Research. Scandinavian Journal of Information Systems, 31(2), 35-82. Cronholm, S., & Göbel, H. (2022). Action Design Research–Models for Researcher-Practitioner Collaboration. In Proceedings of the International Conference on Design Science Research in Information Systems and Technology, pp. 393-404. http://dx.doi.org/10.1007/978-3-031- 06516-3_29 Cronholm, S., & Goldkuhl, G. (2004). Conceptualising participatory action research–Three different practices. Electronic Journal of Business Research Methods, 2(2), 47-58. Date, C. J. (2006). An introduction to database systems. Pearson Education. Dey, A. K. (2001). Understanding and using context. Personal and ubiquitous computing, 5, 4-7. http://dx.doi.org/10.1007/s007790170019 Fitzgerald, B., Russo, N., & Stolterman, E. (2002). Information Systems Development: Methods in Action. London: McGraw-Hill. Glaser, B. G., & Strauss, A. L. (2017). Discovery of grounded theory: Strategies for qualitative research. Routledge. http://dx.doi.org/10.4324/9780203793206 Goldkuhl, G. (2004). Design Theories in Information Systems – A Need for Multi-Grounding, Journal of Information Technology Theory and Application, 6(2), 59-72. Goldkuhl G & Cronholm S. (2019). Grounded Theory in Information Systems Research – from Themes in IS Discourse to Possible Developments. In Proceedings of the International Conference on Information Systems, Dec 15-18, Munich Germany. Gregor, S. (2009). Building theory in the sciences of the artificial. In Proceedings of the 4th International Conference on Design Science Research in Information Systems and Technology, pp. 1-10. http://dx.doi.org/10.1145/1555619.1555625 Gregor, S., & Hevner, A. R. (2013). Positioning and presenting design science research for maximum impact. MIS quarterly, 37(2), 337-355. http://dx.doi.org/10.25300/MISQ/2013/37.2.01 Haj-Bolouri, A., Bernhardsson, L., & Rossi, M. (2016). PADRE: A method for participatory action design research. In Proceedings of the International Conference on Design Science Research in Information System and Technology (pp. 19-36). Springer. http://dx.doi.org/10.1007/978-3-319-39294-3_2 Haj-Bolouri, A., Purao, S., Rossi, M., & Bernhardsson, L. (2018). Action Design Research in Practice: Lessons and Concerns. In Proceedings of the European Conference on Information Systems (ECIS). http://dx.doi.org/10.5130/acis2018.ak http://dx.doi.org/10.1007/978-3-031-06516-3_29 http://dx.doi.org/10.1007/978-3-031-06516-3_29 http://dx.doi.org/10.1007/s007790170019 http://dx.doi.org/10.4324/9780203793206 http://dx.doi.org/10.1145/1555619.1555625 http://dx.doi.org/10.25300/MISQ/2013/37.2.01 http://dx.doi.org/10.1007/978-3-319-39294-3_2 Australasian Journal of Information Systems Cronholm, Gӧbel & Shrestha 2024, Vol 28, Research Article Collaboration in Action Design Research 30 Henriques, T.A. & O’Neill, H. (2021), Design science research with focus groups – a pragmatic meta-model, International Journal of Managing Projects in Business, 16(1), 119- 140. http://dx.doi.org/10.1108/IJMPB-01-2020-0015 Hevner, A. R., March, S. T., Park, J., & Ram, S. (2004). Design science in information systems research. MIS quarterly, 28(1), 75-105. http://dx.doi.org/10.2307/25148625 Hollnagel, E. (2012). Task analysis: Why, what, and how. Handbook of human factors and ergonomics, 383-396. http://dx.doi.org/10.1002/9781118131350.ch13 Iivari, J., & Maansaari. J., (1998). The usage of systems development methods: Are we stuck to old practices? Information and Software Technology, 40(9), 501-510. http://dx.doi.org/10.1016/S0950-5849(98)00077-9 Klein, H. K. & Myers. M.D. (1999). A Set of Principles for Conducting and Evaluating Interpretive Field Studies in Information Systems, MIS Quarterly, 3(1), 67-88. http://dx.doi.org/10.2307/249410 Lincoln, Y. S., & Guba, E. G. (1985). Naturalistic Inquiry, Newbury Park, CA: SAGE Publications. http://dx.doi.org/10.1016/0147-1767(85)90062-8 Lusch, R. F., & Nambisan, S. (2015). Service innovation. MIS quarterly, 39(1), 155-176. March S T & Smith G. (1995). Design and Natural Science Research on Information Technologies, Decision Support Systems, 15(4), 251-266. http://dx.doi.org/10.1016/0167- 9236(94)00041-2 Mathiassen, L. (2002). Collaborative Practice Research. Information Technology & People, 15(4), 321-345. http://dx.doi.org/10.1108/09593840210453115 Matzner, M., Plenter, F., Chasin, F., Betzing, J. H., & von Hoffen, M. (2018). New service development through action design research in joint research projects. In Proceedings of the 26th European Conference on Information Systems (ECIS). Naderifar, M., Goli, H., & Ghaljaie, F. (2017). Snowball sampling: A purposeful method of sampling in qualitative research. Strides in Development of Medical Education, 14(3), 1-6. http://dx.doi.org/10.5812/sdme.67670 Peffers, K., Tuunanen, T., Rothenberger, M. A., & Chatterjee, S. (2007). A design science research methodology for information systems research. Journal of management information systems, 24(3), 45-77. http://dx.doi.org/10.2753/MIS0742-1222240302 Penrose, E. T. (1959). The growth of the firm. White Plains, NY: Sharpe. http://dx.doi.org/10.4324/9780429056604-4 Petersson, A. M., & Lundberg, J. (2016). Applying action design research (ADR) to develop concept generation and selection methods. Procedia Cirp, 50, 222-227. http://dx.doi.org/10.1016/j.procir.2016.05.024 Pries-Heje, Jan, John R. Venable, and Richard Baskerville (2014) Soft Design Science Methodology. In O. E. Hansen, J. Simonsen, C. Svabo, S. Malou Strandvad, K. Samson & M. Hertzum (eds.), Situated Design Methods. MIT Press, Cambridge, MA, USA. http://dx.doi.org/10.7551/mitpress/9936.003.0008 http://dx.doi.org/10.5812/sdme.67670 Australasian Journal of Information Systems Cronholm, Gӧbel & Shrestha 2024, Vol 28, Research Article Collaboration in Action Design Research 31 Rapoport, R. N. (1970). Three dilemmas in action research: with special reference to the Tavistock experience. Human relations, 23(6), 499-513. http://dx.doi.org/10.1177/001872677002300601 Schwaber, K., & Sutherland, J. (2011). The scrum guide. Scrum Alliance, 21(19), 1. http://dx.doi.org/10.1002/9781119203278.app2 Scriven, M. (1996). Types of Evaluation and Types of Evaluator. Evaluation Practice, 17(2), 151- 162. http://dx.doi.org/10.1177/109821409601700207 Segal T. (2022, Dec 31). What is Prescriptive Analytics? Investopedia. https://www.investopedia.com/terms/p/prescriptive-analytics.asp Sein, M.K., Henfridsson, O., Purao, S., Rossi, M., & Lindgren, R. (2011). Action Design Research. MIS Quarterly, 35(1), 37-56. http://dx.doi.org/10.2307/23043488 Strauss, A., & Corbin, J. (1990). Basics of qualitative research. Sage publications. Susman, G., & Evered, R. (1978). An assessment of the scientific merits of action research. Administrative Science Quarterly, 23(4), 582-603. http://dx.doi.org/10.2307/2392581 Te’eni, D., Seidel, S., & Brocke, J. V. (2017). Stimulating dialog between information systems research and practice. European Journal of Information Systems, 26(6), 541-545. http://dx.doi.org/10.1057/s41303-017-0067-9 Urquhart, C., Lehmann, H., & Myers, M. (2010). Putting the ‘theory’ back into grounded theory: guidelines for grounded theory studies in information systems. Information Systems Journal, 20(4), 357–381. http://dx.doi.org/10.1111/j.1365-2575.2009.00328.x van Aken, J. (2004), Management Research Based on the Paradigm of the Design Sciences: The Quest for Field-tested and Grounded Technological Rules, Journal of Management Studies, 41(2), 219-246. http://dx.doi.org/10.1111/j.1467-6486.2004.00430.x van den Akker, J. (1999). Principles and methods of development research. In J. J. H. v. d. Akker, R. Branch, K. Gustafson, N. M. Nieveen, & T. Plomp, T. (Eds.), Design approaches and tools in education and training (pp. 1-14). Springer. http://dx.doi.org/10.1007/978- 94-011-4255-7_1 Vargo, S. L., & Lusch, R. F. (2004). Evolving to a new dominant logic for marketing. Journal of Marketing, 68(1), 1–17. http://dx.doi.org/10.1509/jmkg.68.1.1.24036 Vaishnavi, V. K., & Kuechler, W. (2015). Design science research methods and patterns: innovating information and communication technology. CRC Press. http://dx.doi.org/10.1201/b18448 Venable, J., Pries-Heje, J., & Baskerville, R. (2016). FEDS: a framework for evaluation in design science research. European journal of information systems, 25(1), 77-89. http://dx.doi.org/10.1057/ejis.2014.36 Venable, J. R., Pries-Heje, J., & Baskerville, R. L. (2017). Choosing a design science research methodology. In Proceedings of the 28th Australasian Conference on Information Systems (ACIS). Hobart, Australia, Dec 4-6. Vom Brocke, J. V., Weber, M., & Grisold, T. (2021). Design Science Research of High Practical Relevance. In Proceedings of the Engineering the Transformation of the Enterprise (pp. 115- 135). Springer, Cham. http://dx.doi.org/10.1007/978-3-030-84655-8_8 http://dx.doi.org/10.2307/2392581 Australasian Journal of Information Systems Cronholm, Gӧbel & Shrestha 2024, Vol 28, Research Article Collaboration in Action Design Research 32 Walsham, G. (1995). Interpretive case studies in IS research: Nature and method, European Journal of Information Systems, 4(2), 74-81. http://dx.doi.org/10.1057/ejis.1995.9 Wilson, P. F., Dell, L. D., & Anderson, G. F. (1996). Root Cause Analysis: A Tool for Total Quality Management. The Journal for Health Care Quality, 18(1). http://dx.doi.org/10.1111/j.1945- 1474.1996.tb00823.x Winter, R. (2013). Towards a framework for evidence-based and inductive design in information systems research. In Proceedings of the European Design Science Symposium (pp. 1-20). Springer, Cham. http://dx.doi.org/10.1007/978-3-319-13936-4_1 Copyright: © 2024 Cronholm, Gӧbel & Shrestha. This is an open-access article distributed under the terms of the Creative Commons Attribution-NonCommercial 3.0 Australia License, which permits non-commercial use, distribution, and reproduction in any medium, provided the original author and AJIS are credited. doi: https://doi.org/10.3127/ajis.v28.4281 http://dx.doi.org/10.1007/978-3-319-13936-4_1 http://creativecommons.org/licenses/by-nc/3.0/au/ https://doi.org/10.3127/ajis.v28.4281