Design Science Research & Action Research
Session at a Glance
Design Science Research — artefacts, the Peffers et al. process model, evaluation methods; Action Research — the cyclical process, participatory approaches, insider/outsider dynamics; comparing DSR and AR
Completing a DSR process map or AR cycle plan; finalising and submitting the complete methodology chapter outline (consolidating Weeks 9–12)
2 hrs Lecture + 12 hrs Lab/Project
Methodology chapter outline due — design, instruments, sampling, and procedures specified
Learning Objectives
By the end of this session, you will be able to:
- Apply the Peffers et al. (2007) Design Science Research process model — problem identification, objectives, design & development, demonstration, evaluation, and communication — to structure a BCA or applied BBA capstone that produces a designed artefact
- Design a rigorous DSR evaluation strategy selecting from the evaluation method inventory (technical experiments, case studies, field studies, simulations, expert surveys) based on the artefact type and evaluation objectives
- Structure an Action Research study using the cyclical process of diagnosing, planning, acting, evaluating, and specifying learning — distinguishing AR from consultancy and from conventional case study research
- Navigate the ethical and practical challenges of action research, including dual roles (researcher and practitioner), power dynamics, organisational politics, and the management of participant expectations
- Synthesise your methodology decisions from Weeks 9–12 into a complete, coherent methodology chapter outline that specifies your research design, instruments, sampling strategy, analytical procedures, and quality criteria
Session Planner
Suggested breakdown of the 4-hour contact session.
| Time | Segment | Activity | Mode |
|---|---|---|---|
| 0:00–0:08 | Opening | Recap Weeks 9–11; transition: "Most of you will use quantitative, qualitative, or mixed methods. But two other approaches — DSR and Action Research — are powerful when your capstone involves building something or changing something." | Whole class |
| 0:08–0:30 | Lecture 1 | Design Science Research: the artefact as contribution; Peffers et al. process model (6 activities); DSR evaluation methods; DSR in BCA and applied BBA capstones | Lecture |
| 0:30–0:50 | Lecture 2 | Action Research: the cyclical process; participatory approaches; researcher positioning (insider/outsider); ethical challenges; AR in BBA and BCA contexts | Lecture |
| 0:50–1:10 | Activity | Approach matching: given 8 capstone scenarios, determine whether DSR, AR, or a conventional QUAN/QUAL design is most appropriate. Justify the choice. | Pairs |
| 1:10–1:25 | Discussion | Share and debate approach choices; discuss the boundary cases where DSR and AR overlap or where neither is appropriate | Whole class |
| 1:25–1:40 | Break | — | — |
| 1:40–2:05 | Lecture 3 | DSR vs. AR vs. conventional research — a comparison framework. Methodology outline consolidation: structuring a complete methodology chapter from Weeks 9–12 decisions. Common gaps and how to address them. | Lecture |
| 2:05–3:30 | Lab Work | Part A: Complete DSR process map or AR cycle plan; Part B: Methodology outline consolidation — synthesise Weeks 9–12 into a complete methodology chapter structure; Part C: Peer methodology audit | Individual/Pairs |
| 3:30–3:50 | Methodology Clinic | Open Q&A — students raise unresolved methodology questions; facilitator addresses common patterns of incompleteness or inconsistency | Whole class |
| 3:50–4:00 | Exit Ticket | Submit methodology outline; identify the section where you have the least confidence | Individual |
1. Design Science Research — Research Through Building
Design Science Research (DSR) is a research paradigm in which knowledge is produced through the act of designing and evaluating an artefact that addresses a real-world problem. Unlike natural or social science paradigms that seek to describe, explain, or predict, DSR seeks to create and evaluate — the contribution is the artefact itself AND the design knowledge derived from its construction. DSR is the dominant methodology in information systems research and is directly applicable to BCA capstones that produce software, algorithms, frameworks, or systems — and to BBA capstones that produce business models, process designs, or assessment frameworks.
Design Science Research is a research paradigm that creates and evaluates IT artefacts intended to solve identified organisational problems (Hevner et al., 2004). The artefact — which may be a construct, model, method, or instantiation — is the contribution, but the research contribution also includes the design knowledge generated through the process of creating and evaluating it. DSR answers the question: "Can we build something that solves this problem, and what do we learn from building it?" This distinguishes DSR from routine system development (which solves a problem but may not produce generalisable knowledge) and from conventional empirical research (which produces knowledge but not a working solution).
1.1 The DSR Artefact — Four Types
| Artefact Type | Definition | Examples (BCA) | Examples (BBA) |
|---|---|---|---|
| Construct | The conceptual vocabulary of a domain — the concepts, terms, and notation used to describe problems and solutions | A taxonomy of API failure modes; a classification scheme for technical debt types; a formal ontology for cloud service descriptions | A framework of digital maturity dimensions for Indian SMEs; a classification of consumer trust signals in e-commerce; a typology of fintech business models |
| Model | A representation of reality that captures relationships among constructs — a set of propositions or statements expressing relationships | A predictive model for software defect density based on code and process metrics; a computational model for optimising cloud resource allocation; a domain model for healthcare information exchange | A maturity model for ESG reporting practices; a consumer decision-making model for omnichannel retail; a stakeholder influence model for CSR strategy |
| Method | A set of steps (an algorithm, process, or guideline) used to perform a task — methods describe HOW to do something | A method for migrating legacy monolithic applications to microservices architecture; an algorithm for detecting code-mixed hate speech; a protocol for privacy-preserving data sharing among hospitals | A method for conducting digital due diligence in M&A; a process framework for designing inclusive fintech products; a stakeholder engagement method for sustainability reporting |
| Instantiation | A working system — the implemented artefact that demonstrates feasibility and enables evaluation in a real context | A working mobile application for farmer-to-consumer direct sales; a deployed chatbot for mental health first aid; a functioning face recognition attendance system | A dashboard for real-time ESG metric tracking; a decision support tool for supplier sustainability assessment; a simulation game for teaching entrepreneurial finance |
1.2 The Peffers et al. (2007) DSR Process Model
The most widely cited DSR methodology, the Peffers et al. process model provides six activities that structure a DSR project. The activities are presented sequentially but are iteratively applied — DSR is inherently cyclical.
Define the specific research problem and justify the value of a solution. The problem must be real, significant, and not adequately addressed by existing solutions. Output: A problem statement grounded in literature and/or practice. Capstone connection: Your Week 3 problem statement and Week 7 proposal introduction serve this function. For DSR, the problem statement must make clear why existing artefacts are insufficient — what gap the new artefact fills.
Infer the objectives of a solution from the problem definition. What should the artefact accomplish? Objectives may be quantitative (accuracy ≥ 90%, response time ≤ 200ms) or qualitative (the artefact should be usable by non-technical managers, should integrate with existing workflows). Output: A set of measurable or evaluable objectives. Key distinction: DSR objectives are about what the artefact SHOULD DO, not about what IS (that is the domain of natural/social science RQs).
Create the artefact. This is the core activity — the actual building. The design must be grounded in theory (kernel theories from the literature that inform the design) and justified with reference to the objectives. Output: The artefact — construct, model, method, or instantiation. Capstone connection: Your methodology chapter must describe HOW you designed and developed the artefact — the architecture, the design decisions, the technologies used, the iterative refinements. This is not a "Development" section that lists technologies; it is a research narrative of design choices and their rationale.
Show that the artefact works — that it can solve one or more instances of the problem. This may be a proof-of-concept implementation, a case study, a simulation, or an experiment. Output: Evidence of feasibility. Capstone reality: Demonstration proves the artefact CAN work. The next activity — evaluation — proves HOW WELL it works and under what conditions. Both are required.
Assess how well the artefact satisfies the objectives defined in Activity 2. Evaluation must be systematic, rigorous, and linked to the objectives. Output: Evidence of how well the artefact works, compared to its objectives and (ideally) to alternative solutions. See Section 1.3 for evaluation methods.
Communicate the problem, the artefact, its utility and novelty, the rigour of its design, and its effectiveness to relevant audiences — both academic and practitioner. Output: Your capstone dissertation. The dissertation IS the communication of the DSR study.
1.3 DSR Evaluation — The Evaluation Method Inventory
Evaluation is where many DSR capstones fall short. Students demonstrate that the artefact exists but do not systematically evaluate how well it satisfies its objectives. The following inventory (based on Peffers et al., 2012; Venable et al., 2016) provides the menu of evaluation methods from which you select the combination appropriate to your artefact.
| Evaluation Method | What It Assesses | Artefact Type | Example in a Capstone |
|---|---|---|---|
| Technical Experiment | Performance, accuracy, efficiency under controlled conditions | Method, Instantiation | Compare the response time and accuracy of your code-mixed NLP model against baseline models on a standard benchmark dataset; test your load-balancing algorithm on simulated traffic patterns at varying loads |
| Case Study | Artefact's effectiveness in a real organisational context — depth over breadth | Instantiation, Method | Deploy your inventory management system in one retail store for 4 weeks and measure its impact on stockout rates, order accuracy, and staff time compared to the previous manual system |
| Field Study / Pilot | Artefact's effectiveness across multiple real contexts — more breadth than a case study | Instantiation, Method | Pilot your employee onboarding process framework in 3 organisations of different sizes and industries; measure adoption rate, user satisfaction, and process efficiency improvements |
| Simulation | Artefact's behaviour under conditions that cannot be tested directly (scale, cost, ethics) | Model, Method, Instantiation | Simulate your traffic management algorithm on a city-scale traffic model with 100,000 vehicles — testing scenarios that cannot be safely or practically created in the real world |
| Expert Survey / Delphi | Artefact's perceived utility, completeness, usability, or correctness as judged by domain experts | Construct, Model, Method | Present your digital maturity framework to a panel of 12 CIOs and digital transformation consultants; collect structured feedback on completeness, clarity, and practical utility using a standardised questionnaire |
| Logical / Formal Proof | Artefact's formal correctness — mathematical or logical validity | Construct, Model, Method | Formally prove that your consensus algorithm satisfies safety and liveness properties; analytically establish the computational complexity and correctness of your algorithm |
| Usability Testing | Artefact's ease of use, learnability, efficiency, and user satisfaction | Instantiation | Conduct a usability test with 15 target users performing 5 standard tasks; measure task completion time, error rate, and System Usability Scale (SUS) scores |
The most common DSR capstone failure: the student builds a working system and writes a development report describing what they built, what technologies they used, and what the screens look like. This is a development project, not design science research. To qualify as DSR, the capstone must: (a) identify a problem through engagement with literature AND practice, (b) derive design objectives from that problem, (c) design the artefact using kernel theories (not just "I picked React because I know it"), (d) evaluate the artefact rigorously against the objectives, and (e) articulate the contributions to design knowledge — what did we learn about designing this class of artefact that can inform future designs? The artefact is necessary but not sufficient. The design knowledge is the research contribution.
2. Action Research — Research Through Change
Action Research (AR) is a research approach in which the researcher intervenes in a real-world situation to solve a practical problem AND generate scholarly knowledge. The researcher is not a detached observer but an active participant in the change process — working collaboratively with practitioners to diagnose problems, design interventions, implement changes, evaluate outcomes, and learn from the experience. AR is appropriate when your capstone involves working with an organisation to address a real problem while simultaneously studying that process.
Action Research is an iterative inquiry process that integrates theory and practice to solve pressing organisational problems while generating scholarly knowledge (Coghlan, 2019). It is characterised by: (a) a cyclical process of diagnosing, planning, acting, and evaluating, (b) collaboration between researcher and practitioners, (c) the dual goal of practical problem-solving and knowledge generation, and (d) the researcher's active involvement in the situation being studied. AR is not consulting — consulting solves the problem and leaves. AR solves the problem AND produces publicly shareable knowledge about the solution process and its outcomes.
2.1 The Action Research Cycle
Collaboratively identify and define the problem with organisational stakeholders. This is not the researcher diagnosing from outside — it is a joint process of problem framing that draws on both theoretical knowledge (the researcher's) and practical knowledge (the practitioners'). Methods: Stakeholder interviews, focus groups, document analysis, process observation. Output: A shared problem definition and a set of research questions that address both practical and theoretical concerns.
Design the intervention — what will be done, by whom, when, and with what expected outcomes. The plan must be grounded in theory (why do we expect this intervention to work?) AND feasible within the organisational context. Methods: Collaborative workshops, theory-driven intervention design, stakeholder validation. Output: An action plan with specific actions, timelines, responsibilities, and theoretically grounded hypotheses about expected outcomes.
Implement the planned intervention. The researcher is actively involved — facilitating workshops, training staff, designing processes, or implementing systems. Critical requirement: Document everything. The action phase generates the data that will later be analysed. Keep a research journal; collect meeting minutes, emails, artefacts produced; conduct post-action interviews with participants. Output: The implemented change AND the data documenting the implementation process.
Assess the outcomes of the intervention — both intended and unintended, both objective (did the metric improve?) and subjective (how do participants perceive the change?). Compare outcomes to the theoretically grounded expectations from Phase 2. Methods: Pre-post measurement of key metrics; post-intervention interviews; stakeholder reflection workshops; analysis of process data. Output: An evaluation of the intervention's effectiveness, including an analysis of WHY it produced the observed outcomes.
Identify what was learned — both the practical learning (what should the organisation do next?) and the theoretical learning (what does this action research contribute to knowledge?). This is where AR transitions from problem-solving to research. Output: Contributions to theory (how does this AR study extend, challenge, or refine existing theory?) AND implications for practice (what should practitioners take away?). Then: The cycle may repeat — diagnosis of the new situation after the intervention, planning further action, and continuing the cyclical process.
2.2 Researcher Positioning — The Insider/Outsider Spectrum
| Position | Characteristics | Strengths | Risks | Mitigation Strategies |
|---|---|---|---|---|
| Insider (Practitioner-Researcher) | You are a member of the organisation you are studying — an employee, manager, or intern conducting research within your own workplace | Deep access to people, processes, and data; pre-existing trust relationships; understanding of organisational culture and politics; lower barriers to implementation | Role confusion (are you a researcher or an employee?); political entanglement (your findings may threaten colleagues or superiors); taken-for-granted assumptions that blind you to what an outsider would see; difficulty maintaining critical distance | Explicit role negotiation at the start (written agreement with the organisation); reflexive journal documenting your dual role and its influence; outsider validation (have a peer or supervisor who is NOT in the organisation review your interpretations); transparent reporting of your positionality |
| Outsider (Academic-Researcher) | You enter the organisation specifically to conduct research — you are not an employee and have no prior relationship | Critical distance; ability to question taken-for-granted practices; fewer political entanglements; easier to maintain research rigour | Access barriers (gatekeepers may limit your exposure); trust deficits (participants may not be candid); superficial understanding of context; interventions may not be sustained after you leave | Prolonged engagement (spending enough time in the organisation to build trust and understanding); member checking with insider collaborators; collaborative design of interventions (so they are owned by the organisation, not just by you); explicit knowledge transfer at the end of the study |
2.3 Action Research vs. Consulting vs. Case Study
| Dimension | Action Research | Consulting | Case Study Research |
|---|---|---|---|
| Primary Goal | Solve a practical problem AND generate scholarly knowledge | Solve a practical problem; produce a deliverable for the client | Understand a phenomenon in its real-world context; produce scholarly knowledge |
| Researcher Role | Active participant in the change process; collaborator with practitioners | Expert advisor; may implement or recommend | Observer (participant or non-participant); does not intervene to change the situation |
| Outcome | Changed organisational practice + published research findings | Client report, recommendation, or implemented solution; typically confidential | Research findings; the organisation is not necessarily changed by the research |
| Knowledge Type | Actionable knowledge — knowledge derived from AND for action; both practical and theoretical | Client-specific knowledge; not intended for generalisation or publication | Descriptive, explanatory, or theoretical knowledge about the case |
| Generalisability | Theoretical generalisation — the learning from the AR cycles contributes to theory that can inform other contexts | Not intended to generalise; bounded by the client engagement | Analytical or theoretical generalisation (not statistical); case-to-theory, not case-to-population |
| Key Risk | Drifting into consulting (prioritising problem-solving over knowledge generation); lack of rigour in data collection; political co-optation | Producing recommendations that are not implemented; client dissatisfaction | Superficial engagement; inability to access deep organisational processes; treating a study of an organisation as a case study without case study methodology |
Action Research places the heaviest demands on the capstone researcher. You must simultaneously: manage an organisational intervention (project management skills), maintain research rigour (data collection and analysis skills), navigate organisational politics (interpersonal and political skills), and produce scholarly knowledge (academic writing skills). It is not recommended for students who have not previously worked in or with organisations. But for those who can manage these demands, AR produces the richest integration of theory and practice possible in a capstone — and often the most compelling contribution to both academic knowledge and organisational practice.
3. DSR, Action Research, and Conventional Research — Choosing Your Approach
3.1 When Each Approach is Appropriate
| Approach | Core Question | Best When... | Not Appropriate When... |
|---|---|---|---|
| Conventional Empirical (QUAN, QUAL, MM) | "What is the relationship between X and Y?" or "How do people experience Z?" | Your RQs ask about existing phenomena — relationships, experiences, patterns, processes — that you can study without building something or changing something | Your primary contribution is a designed artefact; you need to intervene in the situation to answer your RQs; the phenomenon cannot be studied without creating or changing it |
| Design Science Research | "Can we build X to solve problem Y, and what do we learn from building it?" | Your capstone produces a designed artefact (system, model, method, framework); the artefact is your primary contribution; your RQs concern whether and how well the artefact works | You are not building or designing anything; the artefact already exists and you're studying its adoption or impact (that is conventional research on the artefact, not DSR); you cannot evaluate the artefact's effectiveness |
| Action Research | "What happens when we intervene to solve problem Y in context Z, and what do we learn about the process?" | You have access to an organisation that needs a real problem solved; you can implement and evaluate a change; you are prepared for the dual researcher-practitioner role; the process of change is as important as its outcomes | You cannot intervene (only observe); the organisation expects consulting (a solution, not research); you lack the practical and political skills to navigate organisational dynamics; the capstone timeline is too short for even one AR cycle (planning + acting + evaluating typically requires 8–12+ weeks) |
3.2 The Boundary Cases — Where Approaches Overlap
You build an artefact (DSR) and evaluate it through a case study in one organisation. This is DSR with a case study evaluation method — the primary paradigm is DSR, and the case study serves the evaluation activity. Your methodology chapter should be structured around the Peffers model, with the case study described as the evaluation approach. This is common in BCA capstones.
You facilitate an organisational change (AR) that involves developing a new process framework or assessment tool (artefact). The artefact is developed and evaluated WITHIN the AR cycle. This is AR that includes artefact development — the primary paradigm is AR, and the artefact is one output of the AR process. Your methodology chapter is structured around the AR cycle.
You study an organisational change over time but do not intervene — you observe. This is a longitudinal case study, NOT action research. The distinguishing feature is the researcher's role: observer (case study) vs. active participant in the change (AR). If you are not intervening, you are not doing AR, regardless of how long you study the organisation.
You build an artefact but do not evaluate it (beyond basic functional testing). This is a development project, NOT DSR. Rigorous evaluation against the design objectives is what distinguishes DSR from system development. If your capstone timeline does not permit evaluation, you do not have a DSR capstone — you have a development project, and you should frame it differently or extend your timeline.
3.3 Three Decision Paths — Worked Examples
| Scenario | Recommended Approach | Why |
|---|---|---|
| A BCA student wants to build a code-mixed sentiment analysis model for Hindi-English tweets and compare its performance against existing models | DSR | The primary contribution is a designed artefact (the model). The evaluation (performance comparison on benchmark data) is a core DSR activity. The student is not intervening in an organisation; they are building and evaluating a technical artefact. |
| A BBA student works in an HR department and wants to redesign the company's onboarding process, implement the new process, and study its impact on new hire retention and satisfaction | Action Research | The student is an insider with access to implement change. The research involves intervention (redesigning and implementing a process) and studying outcomes. The dual goal — improve onboarding AND generate knowledge about onboarding process design — is characteristic of AR. |
| A BBA student wants to study how Indian startups make pricing decisions for their first product — interviewing 20 founders and analysing the themes | Conventional Qualitative (Phenomenology or Grounded Theory) | The student is studying an existing phenomenon (pricing decisions) without building an artefact or intervening in the startups. There is no designed artefact (DSR) and no organisational change process the researcher is participating in (AR). This is straightforward qualitative research. |
| A BCA student wants to work with a hospital to develop and deploy an AI-based patient triage system, studying both the system's accuracy AND how clinicians adapt their workflows around it | DSR + Embedded Case Study or AR | This is a boundary case. If the primary contribution is the triage system and its evaluation, DSR with an embedded clinical case study is appropriate. If the primary focus is the process of introducing AI into clinical workflows and how the organisation adapts, AR may be more appropriate. The choice depends on whether the artefact or the change process is the primary research focus. |
4. Consolidating Your Methodology Chapter — From Weeks 9–12 to a Complete Outline
Weeks 9–12 have equipped you with the methodological vocabulary and decision frameworks needed to design a rigorous capstone. This section helps you consolidate those decisions into a complete methodology chapter outline — the milestone deliverable for this week.
4.1 The Complete Methodology Chapter Structure
| # | Section | Source | Key Decisions to Document | Common Gaps |
|---|---|---|---|---|
| 1 | Research Paradigm & Design | Week 2, 9, 10, 11, 12 | Paradigm (post-positivist, interpretivist, pragmatist, DSR); research design type (experiment, survey, phenomenology, GT, case study, convergent MM, DSR, AR); design justification — why this design for these RQs | Naming the design without justifying it. "This study uses a survey design" — but why survey rather than experiment, secondary data, or qualitative? The justification must connect the design to the RQs. |
| 2 | Population, Sampling & Sample | Week 9, 10, 11 | Target population (defined precisely); sampling frame; sampling technique (probability or purposive, which specific type); sample size and its justification; inclusion/exclusion criteria; for MM: relationship between QUAN and QUAL samples | Vague population ("Indian consumers"); no sampling frame; convenience sample presented as representative; sample size without calculation or justification; no mention of non-response or dropout |
| 3 | Instrumentation / Data Collection | Week 9, 10, 11 | Instruments (survey, interview protocol, experiment protocol, observation guide, secondary dataset); instrument development process; construct-to-item mapping; piloting/pretesting; for adopted scales: source, original reliability, permission if required | Instruments described vaguely ("a survey was administered"); no construct-to-item mapping; no piloting; adopted scales cited without original reliability; no mention of how instruments were developed or adapted |
| 4 | Data Collection Procedures | Week 9, 10, 11, 12 | Step-by-step procedure from recruitment to data storage; when and where data was collected; by whom; how consent was obtained; how data was recorded and stored; how confidentiality was maintained; for AR: description of the intervention and the researcher's role | Procedures described at too high a level for replication; no mention of recruitment process; consent procedure mentioned but not described; data storage and security not addressed; for AR: researcher role not specified |
| 5 | Data Analysis Plan | Week 9, 10, 11 | Specific analytical techniques named and justified; for QUAN: which statistical tests, for which RQs, assumption checking; for QUAL: which analytical approach (thematic analysis, GT coding, narrative analysis), by whom, with what procedures; for MM: integration procedure | "The data will be analysed using SPSS/Excel" — naming software is not an analysis plan; no mapping of techniques to RQs; assumption checks not mentioned; for QUAL: "themes will be identified" without specifying how |
| 6 | Quality / Rigour Strategies | Week 9, 10, 11 | For QUAN: validity framework (internal, external, construct, statistical conclusion) and mitigation strategies; for QUAL: trustworthiness criteria (credibility, transferability, dependability, confirmability) and strategies; for MM: integration quality criteria | Quality criteria named but not operationalised; "validity and reliability will be ensured" without describing how; trustworthiness strategies listed as keywords without procedure; no reflexivity statement in qualitative research |
| 7 | Ethical Considerations | Week 6 | Consent procedures; confidentiality and anonymity measures; data security and storage; risk assessment and mitigation; vulnerable populations; ethics approval status; for BCA: algorithmic fairness, dual-use, data provenance | Generic ethics paragraph applicable to any study; no study-specific risks identified; "ethics approval will be obtained" without specifying from which committee, when, and what documentation is required |
| 8 | Limitations | All weeks | Methodological limitations acknowledged — not just listed, but their implications for findings are explained; design choices that involve trade-offs are identified; strategies to mitigate limitations are described | No limitations section; generic limitations ("sample size could have been larger"); limitations acknowledged but their implications for the trustworthiness of findings are not discussed |
4.2 Methodology Outline Self-Audit
Before submitting your outline, verify each of the following. A "No" response identifies a gap that must be addressed before the methodology chapter is complete.
- Can another researcher replicate my study from this outline? If they cannot — if they would have to guess at sampling, instruments, or analytical procedures — the outline is insufficient.
- Is every methodological choice justified? For each decision (design, sampling, instrument, analysis technique): is there a reason grounded in the RQs, the literature, or the practical constraints? Or is the choice presented as self-evident?
- Are my RQs and my methodology aligned? For each RQ: which specific data will answer it, collected through which method, analysed through which technique? If an RQ has no clear path from data to answer, the RQs or the methodology (or both) need revision.
- Have I acknowledged what my methodology CANNOT do? Every methodology has blind spots — questions it cannot answer, populations it cannot reach, conclusions it cannot support. Have I identified mine?
- Is my methodology feasible within the capstone timeline? Does the sampling plan account for recruitment time? Does the analysis plan account for the learning curve of unfamiliar techniques? Is the scope achievable with the resources available?
Think Deeper — Cross Questions
Discuss in pairs before sharing with the class.
A BCA student builds a machine learning model for crop disease detection from leaf images. They train on a public dataset, achieve 94% accuracy on the test set, and conclude the model is "effective." The student claims this is Design Science Research. Critique this claim. What is missing from the DSR process? Specifically: where is the problem identification grounded in practice? Where are the design objectives? Where is the evaluation beyond accuracy — usability, deployment feasibility, comparison with alternative solutions? At what point does a well-executed ML project become DSR, and what distinguishes it from a well-executed ML project that is NOT DSR?
You are a BBA student working as an HR intern. You propose an Action Research capstone: you will redesign the company's performance appraisal system, implement the new system, and study its impact. Your supervisor approves. Three months in, the HR Director tells you: "Forget the research — we need this system launched by end of quarter. Stop collecting data and just get it done." How do you respond? This is the classic AR tension: the organisation's practical needs collide with research requirements. What could you have done at the START of the project to prevent or mitigate this situation?
Compare the evaluation logic of DSR with the validity logic of quantitative research. DSR evaluates "does the artefact work?" Quantitative research evaluates "are the findings valid?" Are these fundamentally different forms of evaluation, or are they expressions of the same underlying concern — that knowledge claims must be warranted by evidence? What would a DSR study gain from applying quantitative validity criteria to its evaluation? What would a quantitative study gain from thinking about its instruments as DSR artefacts?
Reflect on your methodology decisions across Weeks 9–12. Identify one decision you made early (Week 9 or 10) that you would now make differently based on what you learned in Weeks 11–12. What changed your thinking? Was it exposure to a new approach (DSR, AR, MM), a deeper understanding of your original approach, or a recognition that your initial choice was not the best fit for your RQs? What does this reflection reveal about the relationship between learning about methodology in the abstract and applying methodology to a specific research problem?
Quick Check — Approach Matching
For each capstone scenario, select the most appropriate research approach.
1. "I will develop a load-balancing algorithm for cloud resource allocation, implement it in a simulation environment, and compare its performance (response time, resource utilisation, cost) against three existing algorithms under varying workload conditions."
2. "I am an employee at a manufacturing company. I will work with the operations team to identify bottlenecks in the production process, co-design improvements, implement them over 3 months, measure the impact on throughput and defect rates, and analyse what factors enabled and inhibited the change."
3. "I will survey 300 employees across 10 IT companies to examine the relationship between flexible work arrangements, work-life balance, and job satisfaction. I'll use hierarchical regression to test whether work-life balance mediates the flexibility-satisfaction relationship."
4. "I will develop a sustainability assessment framework for SME suppliers, validate it through expert review with 10 supply chain managers, pilot it in 3 companies, and refine it based on pilot feedback. The final framework includes dimensions, indicators, and a scoring methodology."
Knowledge Check — Interactive Quiz
Test your understanding of DSR and Action Research.
Q1. According to Peffers et al. (2007), which activity in the DSR process model distinguishes DSR from routine system development?
Q2. What is the fundamental distinction between Action Research and consulting?
Q3. In Hevner et al.'s (2004) DSR framework, what are the four types of artefacts that DSR can produce?
Q4. Which of the following is the MOST important risk for an insider Action Researcher (e.g., an employee studying their own organisation)?
Q5. A student builds a working mobile app for their capstone and submits a report describing the app's features, the technologies used, and screenshots of the interface. The report does not include problem identification from literature, design objectives, evaluation against those objectives, or design knowledge contributions. Is this Design Science Research?
Lab Activity — DSR Process Map & Methodology Consolidation
Part A: Complete Your DSR Process Map or AR Cycle Plan (40 min)
If using DSR: Complete a DSR process map using the template below. For each of the 6 activities, document: (a) what you will do in your capstone, (b) the specific output, (c) the methods you will use, and (d) the connection to your RQs or design objectives.
| Activity | What I Will Do | Output | Methods | Connection to Objectives |
|---|---|---|---|---|
| 1. Problem Identification | ||||
| 2. Solution Objectives | ||||
| 3. Design & Development | ||||
| 4. Demonstration | ||||
| 5. Evaluation | ||||
| 6. Communication |
If using AR: Complete an AR cycle plan documenting: the diagnosis (problem, stakeholders, their perspectives), the planned action (intervention design, theoretical grounding, expected outcomes), the action implementation plan, the evaluation approach (metrics, methods, data sources), and the learning objectives (practical and theoretical).
Part B: Methodology Outline Consolidation (60 min)
Using the 8-section methodology structure (Section 4.1), create a complete methodology chapter outline. For each section:
- Write the heading and 2–3 bullet points summarising what the section will contain.
- Note the source of your decisions (which week's work informs this section).
- Flag any gaps — decisions you haven't yet made, details you haven't yet specified, literature you need to consult.
- Estimate word count for each section (aim for 2,500–4,000 words total for the complete methodology chapter).
Part C: Peer Methodology Audit (30 min)
Exchange methodology outlines with a partner. Using the self-audit questions (Section 4.2) as your framework:
- Replicability check: Could you replicate this study from the outline? Flag every missing detail that would force you to guess.
- Alignment check: For each RQ, trace the path from data to answer. Is there a clear line — RQ → instrument → data → analysis → answer? Flag gaps.
- Feasibility check: Given the capstone timeline and resources, can this methodology be executed? Flag unrealistic scope.
- Gap check: Which of the 8 methodology sections is weakest? What specific information is missing?
Exit Ticket
Submit with your methodology outline.
- Submit your complete methodology outline. Which section did you find most difficult to specify, and why?
- If using DSR: What evaluation methods will you use, and how do they map to your design objectives? If using AR: What is your position on the insider-outsider spectrum, and what is your primary strategy for managing the risks of that position?
- If you are NOT using DSR or AR: Briefly justify why a conventional quantitative, qualitative, or mixed-methods design is more appropriate for your RQs than DSR or AR would be.
- What is the single biggest gap remaining in your methodology — the decision you still need to make or the detail you still need to specify?
- On a scale of 1–10, how confident are you that your methodology can be executed within the capstone timeline and resources? If below 7, what needs to change?
Key Takeaways — Week 12
Building an artefact is necessary but not sufficient for DSR. To qualify as research, the project must: ground the problem in literature and practice, derive design objectives, design using kernel theories, evaluate rigorously, and articulate design knowledge contributions. Without these, it is development, not DSR.
AR is not consulting and not case study. It requires active intervention, collaborative diagnosis and planning, systematic evaluation, and the generation of both practical solutions and scholarly knowledge. The dual role — researcher and change agent — is both AR's greatest strength and its greatest risk.
DSR, AR, and conventional empirical research answer fundamentally different types of questions. Choose the approach that matches what you are asking. A study of what IS (relationships, experiences, patterns) requires conventional methods. A study of what we can BUILD requires DSR. A study of what happens when we CHANGE something requires AR.
The methodology chapter outline submitted this week is not a formality — it is the blueprint for the next 18 weeks of capstone execution. Gaps, vagueness, or misalignment in this outline will become problems during data collection and analysis. The time to identify and fix them is now.
Facilitator Notes
Preparation Checklist
- Prepare 2–3 exemplar DSR capstone dissertations (or published DSR papers) — one BCA, one BBA if available. Annotate them to show the 6-activity process model applied in practice. Students struggle to see what DSR "looks like" on the page; exemplars bridge this gap.
- Prepare 2–3 exemplar AR capstone dissertations or published AR papers — one showing insider AR, one showing outsider AR. Highlight the researcher positionality statement and the description of the AR cycles.
- Prepare the 8-scenario approach-matching activity cards. Include: 2 clear DSR scenarios, 2 clear AR scenarios, 2 clear conventional scenarios, and 2 boundary cases (DSR+case study, AR+DSR artefact). The boundary cases generate the richest discussion.
- Prepare a methodology outline exemplar — a complete, annotated outline showing all 8 sections with the level of detail expected. This serves as the standard against which students self-audit.
- For BCA cohorts: have the Hevner et al. (2004) and Peffers et al. (2007) papers available as core DSR references. For BBA cohorts interested in AR: have Coghlan (2019) "Doing Action Research in Your Own Organization" as the core reference.
- Coordinate with supervisors: review the methodology outlines within one week of submission. Flag students whose methodology outlines have significant gaps or misalignments — a 15-minute intervention now prevents months of methodological confusion.
Common Student Difficulties
- Equating DSR with "building something": BCA students especially assume that any capstone producing software is DSR. Correct this: DSR is a specific research methodology with a defined process, not a label for any project that involves coding. The Peffers model must be explicitly followed and documented.
- AR scope creep: Students proposing AR underestimate the time required for even one complete AR cycle (diagnose → plan → act → evaluate → learn). An AR capstone requires access to an organisation, willingness to change, and 8–12+ weeks for implementation and evaluation. If these conditions are not met, steer the student toward a more feasible methodology.
- DSR evaluation gap: Students plan to evaluate their artefact only through functional testing ("it works on my machine") or a brief demo. DSR evaluation must be systematic, linked to design objectives, and rigorous. Push students to specify: what are you measuring, against what criteria, using what methods, with what evidence?
- Insider AR without safeguards: Students conducting AR in their own workplace often underestimate the political and ethical risks. Require: (a) a written agreement with the organisation specifying the research purpose, data collection, and publication plans, (b) a detailed positionality statement in the methodology, and (c) a plan for managing dual-role conflicts.
- Methodology outline as a list of headings: Students submit outlines that say "3.1 Sampling" with no content beneath. An outline must contain the substance of the decisions — not just the headings. The self-audit questions (Section 4.2) should be applied before submission; if the answer to any is "No," the outline is incomplete.
Pacing Tips
- This is the final week of Unit 2 (Methodology). The methodology clinic (final 20 minutes) is a valuable formative assessment — students voice uncertainties that they haven't raised in one-on-one supervision. Listen for patterns: if multiple students have the same gap (e.g., unclear about how to specify their analysis plan), address it collectively rather than individually.
- Not all students will use DSR or AR — and that is expected. The primary value of this week for conventional-methods students is: (a) knowing that DSR and AR exist as options, (b) being able to justify why they chose conventional methods instead, and (c) using the methodology consolidation (Section 4) to complete their outline. Adjust lab time accordingly — DSR/AR students work on Part A; conventional students go directly to Part B.
- The methodology outline is a milestone with downstream consequences. Incomplete outlines will produce weak methodology chapters, which will produce execution problems during data collection and analysis. Invest proportionately in reviewing and feeding back on these outlines NOW — it is the highest-leverage quality intervention in the entire capstone process.
- Celebrate the completion of Unit 2. Students have moved from "What is research?" (Week 1) to "Here is my complete, specified, and feasible methodology" (Week 12). This is a significant intellectual achievement. Acknowledge it before the transition to Unit 3 (Data Collection).