Case study methodology in a thesis

The case study is one of the most used and most attacked methodologies in graduate research. Used, because it lets you study a messy contemporary phenomenon in its real context with a depth no survey can reach. Attacked, because every examiner has a version of the same question ready: what can you possibly generalize from one case?

That question has good answers, but they have to be designed in from the start, not improvised in the viva. This guide covers what a case study actually is, single versus multiple case designs, how to select and bound a case, data collection, the validity tests examiners apply, analysis strategies, and how to defend generalization when the question comes.

What case study methodology actually is

A case study is an empirical inquiry into a contemporary phenomenon within its real-life context, where the boundary between phenomenon and context is blurred and multiple sources of evidence are used. Three parts of that definition carry weight. Contemporary separates it from history. In context separates it from the experiment, which strips context away by design. Multiple sources of evidence separates it from a single-method interview study that merely calls itself a case study.

A case study is also defined by its unit of analysis: the bounded system you are studying. A case can be an organisation, a policy, a classroom, a project, a person, or an event, but it must have edges. If you cannot say what is inside the case and what is outside it, you do not yet have a design. You have a topic. State the unit of analysis in one sentence in the design chapter and return to it whenever a scope question arises, because most scope disputes are really boundary disputes.

Single case study or multiple case design

The first structural decision is how many cases. A single case is not automatically weaker, but it needs a stated rationale. The accepted rationales include:

• The critical case: it tests a well-specified theory, which should hold here if it holds anywhere, or fail here in a way that matters.
• The extreme or unusual case: the phenomenon appears in a rare, revealing form.
• The common case: it captures the circumstances of an everyday situation the literature has ignored.
• The revelatory case: you have access to something previously closed to research.
• The longitudinal case: the same case studied at multiple points in time.

How to select and bound your case

Multiple case designs run on replication logic, not sampling logic. You choose cases either because you predict similar results (literal replication) or because you predict contrasting results for reasons your theory anticipates (theoretical replication). Two to four well-chosen cases handled deeply beat eight cases skimmed. Each case in a multiple design gets its own within-case analysis before any cross-case comparison, and every additional case multiplies your workload accordingly.

Whether you study one case or four, selection is purposive, and you should defend it in exactly those terms. You are not drawing a random sample from a population. You are choosing the case that gives your research question the most analytical leverage. Say what made this case appropriate: its fit to the theory, its access, its position in the phenomenon, and which nearby alternatives you rejected and why. If access shaped the choice, admit it and show what the accessible case still offers the question.

Then bound it explicitly in three dimensions: time (which period the study covers), place and organisation (which sites, units, and groups are inside), and activity (which processes and decisions count as part of the case). Bounding decisions look like housekeeping, but they are the answer to half the difficult questions you will face later, from why you did not interview the regulator to why the analysis stops where it does.

Case study data collection: triangulate your sources

The signature strength of a case study is evidence triangulation. The classic source list runs:

• Documents: reports, minutes, emails, policies, internal memos.
• Archival records: service statistics, budgets, organisational charts, usage logs.
• Interviews: usually the spine of a thesis case study, from open conversations to structured protocols.
• Direct observation: site visits, meetings watched, conditions recorded.
• Participant observation: you take a role inside the case, with the access and the bias that brings.
• Physical and digital artefacts: tools, systems, objects the case produces or uses.

Build a case study database

You will not use all six sources, but a case study built on interviews alone is fragile, because it inherits every weakness of self-report. Pair interviews with at least one documentary or observational source that can confirm or contradict what people tell you. Keep a case study database: an organised store of all evidence, separate from the narrative you write about it, so another researcher could in principle trace every claim to an item of evidence. Digitise everything as you collect it, because a database assembled retrospectively is where evidence goes missing. Planning instruments and consent early helps, and the practical side is covered in How to collect research data for a thesis.

Manage the literature around the case with the same discipline. Keeping the framing papers in the Library gives you reading statuses and sentence-level provenance, so when you later quote the theoretical framing you can point to the exact sentence in the source, and the Ask and extract view answers pointed questions over a single paper when you need a specific passage fast.

The four validity tests examiners apply to case studies

Case study methodology has a standard quality framework, and examiners trained in it will apply the four tests whether or not you address them. Address them.

• Construct validity: are you measuring what you claim? Tactics: multiple sources of evidence, a chain of evidence from question to conclusion, and key informants reviewing the draft case report.
• Internal validity (for explanatory cases): does your causal story survive alternatives? Tactics: pattern matching, explanation building, and explicitly addressing rival explanations.
• External validity: what do the findings generalize to? Tactics: theory in single case designs, replication logic in multiple case designs.
• Reliability: could someone repeat your procedure? Tactics: a case study protocol written before fieldwork, plus the case study database.

Write a case study protocol before fieldwork

The cheapest of the validity tactics to implement is the protocol: a short document stating your research questions, field procedures, instruments, and analysis plan before you enter the field. It costs a day, disciplines the fieldwork, and answers the reliability question permanently, because the procedure exists independently of what you happened to do. A protocol also protects you against drift: six months into fieldwork it reminds you what the study set out to ask, and any deviation becomes a recorded decision rather than an accident.

Analysing case study evidence

Case study analysis is where most theses drift, because the evidence is heterogeneous and there is no single named test to run. Anchor yourself with a stated strategy. Pattern matching compares the pattern in your data with the pattern your theory predicted. Explanation building iterates toward a causal account, revising it as the evidence accumulates. Time-series analysis tracks how key variables moved across the life of the case. Cross-case synthesis, for multiple designs, treats each case as a separate study and asks what the set of within-case findings jointly supports. Name the strategy in the methods chapter and let the analysis chapters visibly perform it, because a named strategy that never reappears reads as decoration.

Whatever strategy you name, build a matrix that crosses your evidence against your propositions, so each cell records what each source says about each claim. An evidence matrix in the Synthesis Lab does this job for the published literature around your case, which keeps the framing chapters as auditable as the empirical ones.

Writing the case study chapters

Case studies live or die on the chain of evidence in the write-up. Every analytical claim should trace visibly to evidence: a quoted line, a document, an observation note, with enough identifying detail that the trail is auditable without breaking confidentiality. Anonymise consistently, and decide the anonymisation scheme before writing, because retrofitting pseudonyms across a hundred pages breeds errors.

Structure the narrative around the analysis, not the chronology, unless the chronology is the argument. A common trap is the fifty-page descriptive walk through everything you saw, followed by a thin analysis chapter. Description earns its place only when it carries the argument forward. When you draft the framing and discussion sections, grounded drafting in the Thesis Editor keeps every citation resolving to a real paper, verified against its full text, so the theoretical framing stays as defensible as the fieldwork. Quote sparingly but precisely: one well-chosen line tied to its source and context outweighs a paragraph of unattributed paraphrase, and examiners check quotes against claims.

Common case study pitfalls

The recurring weaknesses are predictable:

• No unit of analysis: the case has no stated boundaries, so the study sprawls.
• Interviews-only evidence dressed up as a case study.
• Case selection by convenience, defended as if it were by design.
• Description substituting for analysis.
• Generalization claims to populations that the design cannot support.
• No protocol and no database, so reliability questions have no answer.

Defending generalization: the viva question you will get

The examiner will ask what one case, or three cases, can generalize to. The answer is analytic generalization: case studies generalize to theory, not to populations. A well-designed case study shows that a theoretical proposition held, failed, or needed modification under specified conditions, and that claim travels to other settings where those conditions apply. You are doing what the experimentalist does with a single experiment, not what the survey researcher does with a sample. Prepare the phrase analytic generalization and be ready to define it, because naming the logic is half the answer.

Make the move concrete in your conclusion chapter: state which propositions your evidence supports, what boundary conditions you observed, and what a researcher in an adjacent setting should expect to transfer. Vague appeals to rich insight will not survive follow-up questions. A precise statement of what the case taught the theory will. That is the standard to design toward from the start: every weakness in the pitfall list above is cheap to prevent at the proposal stage and expensive to repair at examination, and a case study that prevents them is the strongest available way to answer a how or why question about a phenomenon you can actually reach.