A master’s student hands out 200 questionnaires to employees of one bank, runs a regression and titles the project “a case study of Bank X”. The examiner asks a simple question: what exactly is the case, and why this bank? The student has no answer, because what they ran was a narrowly scoped survey, not a case study.
Case study research has its own logic. It investigates a contemporary phenomenon in depth and in its real-world context, especially when the boundary between phenomenon and context is blurred, and it relies on several sources of evidence. Done well, it answers the “how” and “why” questions that large surveys cannot reach. Done badly, it becomes a long description that concludes nothing.
Which questions suit a case study
The design is strongest when the question is about process and mechanism: how a university rolled out blended learning, why a regional hospital’s digital records project stalled in year two, how a cooperative keeps its younger members. It is weak when the question is “how many”, “what percentage” or “which factor matters most across the whole sector”. Those need large samples.
A useful test: if you cannot pull the phenomenon out of its setting without losing its meaning, a case study is a sensible choice.
Defining the case: the unit of analysis
A case can be an organisation, a programme, a decision, an event, a group or a process. The same bank can host very different cases: the bank itself (an organisation), the 2021–2023 core-system replacement project (a programme), or the decision to close twelve branches (a decision). Pick the wrong unit and your data drift away from your question.
Quick check: write your research question and underline the main noun. That noun is usually your case. If the question is “why was the core-system project delayed?”, the case is the project, not the bank, and you probably do not need to interview the marketing team.
Drawing boundaries: time, place and people
Boundaries tell the reader what is inside the case and what counts as context. State three of them explicitly in your methods chapter:
- Time: from when to when. “From project approval in Q1 2021 to go-live in Q3 2023.”
- Place and units: headquarters and the two pilot branches, excluding branches that migrated later.
- People: the project board, staff in the two pilot branches and the software vendor; not customers.
Without boundaries, case researchers fall into the collect-everything trap: forty interviews, hundreds of pages of documents and no idea where to cut.
Single case or multiple cases
| Design | When it makes sense | Main risk |
|---|---|---|
| Single case | Typical, extreme, rare or critical cases; longitudinal cases | Hard to show findings are not just local quirks |
| Multiple cases, theoretical replication | You want to see whether a mechanism reappears in similar settings | Each case gets shallower with the same resources |
| Multiple cases, contrasting | You compare conditions that lead to different outcomes | Selecting on known outcomes can bias the comparison |
| Embedded case | One large case with sub-units, such as departments in a school | Analysing the sub-units and forgetting the case-level question |
For a master’s dissertation, two to four cases is a realistic ceiling. A doctorate can do more, but six shallow cases are worth far less than three deep ones.
Select cases on purpose, not for convenience
Your reason for choosing a case must be analytical, not simply “I work there”. Using access is fine, but you still need to say what this case can teach that others cannot. Common selection logics:
- Typical case: resembles most others, so you can study the ordinary mechanism.
- Deviant case: unusually successful or unsuccessful, revealing conditions the theory missed.
- Critical case: if the theory holds anywhere, it must hold here; if it fails here, the theory is in trouble.
- Most-similar pair: two colleges of the same size in the same region, one of which retains students while the other does not.
If you study your own workplace, say so and describe how you limit insider bias: who cross-checks your coding, whether you interview your own manager, and whether participants know about your dual role.
Multiple sources and a chain of evidence
A case study is persuasive when different sources converge. Six common ones are documents such as minutes and internal reports, archival records such as operational data, interviews, direct observation, participant observation and physical artefacts such as the software itself. A conclusion resting only on the project manager’s account is weak; the same conclusion backed by meeting minutes and the system’s error logs is much stronger.
Build a case study database: a structured folder holding every document, transcript and field note, named by date and source. Then maintain a chain of evidence so that a reader can trace each claim back to specific material. In practice a three-column spreadsheet does the job: claim, evidence, document code.
Analysis: pattern matching and explanation building
Do not stop at a chronological narrative. Three techniques move you from “what happened” to “why”:
- Pattern matching: before analysing, write down what the theory predicts (for example, if middle managers do not back the project, delays will cluster at approval stages). Then compare with what you observed.
- Explanation building: propose an initial explanation, test it against the first case, revise it, test it against the second. Keep a log of each revision.
- Rival explanations: state at least two alternative accounts of the same outcome and show the evidence that rules them out. Examiners probe this more than anything else.
Generalise to theory, not to a population
The familiar challenge is “what can one case tell us?” The answer is that case studies do not generalise statistically from sample to population; they generalise analytically to theory. Your findings show how a mechanism works and under which conditions, so others can test it elsewhere. Spell out those conditions, such as organisation size, ownership and stage of development, rather than claiming the results “apply to banks in general”.
Checklist before you submit the methods chapter
- The question is a “how” or “why” question tied to a real setting.
- The case is defined in one sentence with time, place and people boundaries.
- The selection rationale is analytical, and any access advantage is disclosed.
- At least three types of evidence, with a chain-of-evidence table.
- Theoretical propositions or an initial framework to match against.
- A section on rival explanations.
- The scope of generalisation is stated as concrete conditions.
Next step: write a 100-word paragraph that defines your case and its boundaries, and send it to your supervisor before booking your first interview. That paragraph decides what you collect, and what you can safely ignore, for the next six months.
Câu hỏi thường gặp
Is a case study qualitative or quantitative?
It can be either or both. The design is defined by in-depth study of a case in its real context, not by the type of data. Many case studies combine interviews with an organisation’s own operational figures.
How many interviews do you need for a case study?
There is no fixed number. It depends on how many stakeholder groups sit inside your case boundary and how far other sources already corroborate the story. Usually you want several people per key role so accounts can be compared.
Can I do a case study at my own workplace?
Yes, but disclose your role and describe how you reduce insider bias, for example by having an outsider cross-check your coding and making sure participants can decline without consequences. Think carefully about interviewing people you manage or who manage you.
What is the difference between a case study and a survey of one company?
A survey of one company measures attitudes or behaviour of a group with a single instrument. A case study examines a phenomenon in context using several sources of evidence and usually answers questions about process or mechanism.
Can you generalise from a single case study?
You can generalise analytically, showing that a mechanism operates under certain conditions. You cannot generalise statistically to a population, and your write-up should not claim to.
