Action Research in IS: When the Researcher Is Also the Intervener

Most research methods keep the researcher at arm's length from the phenomenon. You observe, you survey, you interview, you analyze. What you do not do is intervene. You do not walk into an organization and change something and then study the change you caused. That separation is supposed to protect your findings from contamination. The researcher is meant to be a neutral observer, not a participant in what is being observed.

Action research throws that separation out. The whole point is that the researcher goes into a real organizational setting with a real problem and helps solve it, while simultaneously studying the process of solving it. The knowledge that emerges comes from the doing, not from observing others do. And in IS, where the problems we study are almost always situated in organizations dealing with real pressures, this is not a strange methodological choice. It is, in some ways, the most natural fit the discipline has.

Kurt Lewin is usually credited with formalizing the idea in the 1940s, developing what became a cyclical model of planning, acting, observing, and reflecting. The cycle does not end at one pass. You act, you learn from what happened, you refine the plan, you act again. This iterative structure distinguishes action research from a one-shot intervention and gives it its research character. You are not just a consultant who implemented a system. You are a researcher who is building knowledge through successive cycles of engagement and reflection.

Richard Baskerville brought this tradition seriously into IS research, and my reading of the IS methods literature suggests his work with Trevor Wood-Harper in the 1990s did the most to establish what canonical IS action research looks like. The argument was that IS is well suited to action research because the phenomena IS studies, technology implementation, system use, organizational change driven by IT, are all things that happen in organizational contexts that actively want solutions, not just explanations. A hospital implementing an electronic records system does not need a study that describes adoption patterns across a thousand hospitals. It needs help understanding why this implementation is struggling and what to do about it. Action research can produce that help while also producing knowledge that extends beyond the particular hospital.

Baskerville's formulation of the action research cycle in IS typically runs through five stages: diagnosing the problem in collaboration with organizational members, planning the action to address it, taking the action, evaluating the results, and specifying the learning that emerged. The stages look clean in a diagram and considerably messier in practice. Diagnosing the problem requires building trust with organizational members, understanding organizational politics, and distinguishing the presenting problem from the underlying problem. Those are not research activities in a narrow sense. They are organizational engagement activities that require skills a standard methods course does not always teach.

The dual role problem is the one that follows action researchers everywhere. Are you a consultant or a researcher? This is not just a semantic question. Consultants are accountable to the client. Researchers are accountable to the discipline. Consultants want the intervention to succeed because their reputation and their fees depend on it. Researchers want to learn from what happened, even if, especially if, the intervention fails or produces unexpected results. These are different postures, and they create real tensions. If your intervention is not working, the consultant's instinct is to adjust and fix it. The researcher's instinct is to sit with the failure long enough to understand what it reveals. Combining both instincts in the same person, in the same project, in the same organizational context, is genuinely hard.

This connects to the rigor versus relevance debate that sits just below the surface of most methodological discussions in IS. Action research is almost always high on relevance. You are working on a real problem that a real organization actually cares about. The findings speak to practice because they emerged from practice. But rigor is harder to demonstrate, because the traditional tools for rigor, control over variables, replication, hypothesis testing against baseline conditions, are not available when you are in the middle of a living organizational intervention. You cannot hold the organization constant while you manipulate one variable. The organization is doing what organizations do, which is change continuously and in ways you cannot fully control or predict.

The response from action researchers has generally been to argue that rigor means something different in this tradition, not less, just different. Rigor in action research means careful documentation of the cycles, transparent reflection on what the researcher did and why, honest accounting of what worked and what did not, and clear articulation of the theoretical learning that emerged from the cycles. Some frameworks require that the findings be validated with organizational members, that the interpretation of events be checked against participant accounts. This is a different kind of validity check than a Cronbach's alpha, but it is a check.

The question I find most interesting is when IS problems genuinely require action research. The answer is not obvious. Some IS problems are well enough understood that a survey study can tell you what you need to know. Some require the kind of deep contextual knowledge that ethnography provides, but do not require intervention. Action research is most appropriate when the problem is inherently practical, when the knowledge needed to solve it is not yet available in the literature, and when the act of solving it is itself where the learning lives. ERP implementations, organizational transitions to new technology platforms, the introduction of AI tools into complex work environments, these are all candidates. They are problems where the contextual complexity is so high that laboratory conditions would miss the point, and where the organizational setting is willing to have a researcher present through the whole messy process.

What IS often does instead, and I say this having read a lot of IS papers that claimed to do action research, is use "action research" to describe what was really a consulting project with a methods section. The difference is whether the researcher was genuinely building and iterating on theoretical knowledge through the cycles or simply implementing a solution and writing about it afterward. The canonical action research framework Baskerville describes requires that the research problem be formulated at the start in theoretical terms, that each cycle generate theoretical learning, and that the final contribution speak to IS knowledge, not just to the client organization's problem. That is a real constraint. It rules out a lot of work that gets labeled action research because it happened inside an organization.

I think IS is actually better positioned for action research than most disciplines, for exactly the reason Baskerville argued. The organizations we study want solutions, not descriptions. That willingness to be a research site is an asset. The question is whether IS researchers, and IS journals, are willing to accept the methodological messiness that comes with it.