Applied Case Analysis - KBA13 Academy

PCS-S04 · Module 5 — Cases and Application · Lesson 5.1 · Study time: 80 minutes · Language: English

Learning objectives

By the end of this lesson you will be able to:

Construct a case study of security sector governance with a defensible unit of analysis and boundary.
Use a case to test a proposition rather than merely to illustrate one.
Judge what can and cannot be generalised from a single case.
Present a case analysis in a form a practitioner could act on.

Key terms

Case: A bounded instance of a phenomenon, selected for what it can tell you about something beyond itself. Boundaries are chosen by the analyst and must be justified.
Typical, deviant and critical cases: Three selection logics. Typical cases probe a mechanism; deviant cases expose the limits of a theory; critical cases are chosen because if the theory fails here it fails anywhere.
Process tracing: Examining the sequence of events inside a case to test whether a proposed causal mechanism actually operated, rather than inferring cause from correlation across cases.
Analytical generalisation: Generalising to a theoretical proposition rather than to a population. A single case cannot tell you how common something is; it can show that a mechanism exists.
Counterfactual: A disciplined statement of what would plausibly have happened had one factor differed. Useful only when the alternative path is specified and constrained by what was actually possible.

Lesson

Selecting and bounding a case

This lesson. Applied Case Analysis belongs to Module 5 — Cases and Application of PCS-S04 Security Sector Governance, taught in the School of Peace, Conflict and Security Studies. Work through the written lesson first, then the slide deck below, then the activity. Every element on this page is live HTML text: it can be enlarged, printed, searched, read aloud by assistive technology and machine-translated without loss.

A case is not simply an example. It is a bounded instance selected because of what it can establish about something larger, and the selection logic must be stated. If you want to know whether a mechanism can operate at all, a single well-documented instance is sufficient. If you want to know whether it usually operates, one case cannot tell you and you should not pretend otherwise. Choosing a case because the data happened to be available is legitimate only if you say so and discuss what that convenience excludes.

Bounding is equally consequential. In studying security sector governance you must decide where the case stops in time, in space and in organisational scope. Move the start date back two years and a decision that looked sudden becomes the last step of a long process. Widen the organisational boundary and an internal failure becomes a systemic one. There is no neutral boundary; there is only a stated boundary with reasons, which a reader can then evaluate or vary.

Using a case to test rather than illustrate

Illustration takes a conclusion you already hold and finds an instance that fits. It is common, it is comfortable, and it establishes nothing, because for almost any claim about security sector governance some supporting instance can be found. Testing means specifying in advance what you would expect to observe inside the case if the proposition were true, and what you would expect if it were false, and then looking. The value comes entirely from having written down the expectations before the examination.

Process tracing is the workhorse method here. Instead of correlating inputs and outputs, it asks whether the intermediate steps that the proposed mechanism requires actually left traces. If a framework such as Galtung’s violence triangle implies that a particular deliberation, document or delay must have occurred, then the absence of that trace is genuine evidence against the mechanism, not merely a gap in the record — provided you have first established that the trace would have been recorded had it existed.

Reading a case in Security Sector Governance

Approach any case in security sector governance through four passes. The first pass establishes chronology: what happened, in what order, on what dates, with sources. Do this before interpretation and resist the urge to explain while you are still assembling. The second pass identifies actors, their stated positions, their actual interests and the constraints they were under. The third pass locates the decision points — the moments where a different choice was genuinely available — and asks what information was held at each one.

The fourth pass is the analytical one: applying the concepts from Module 1 and the frameworks from Module 2 to ask why this case turned out as it did rather than in one of the ways it could have. This is also where you check for hindsight contamination. Decisions that look obviously wrong in retrospect were frequently reasonable given what was known at the time, and an analysis that cannot distinguish a bad decision from an unlucky outcome is not yet a professional analysis.

Generalising responsibly

The honest formula is that a case can establish existence, mechanism and plausibility, but not frequency. From one case of security sector governance you may legitimately conclude that a mechanism can operate, that certain conditions are sufficient in at least one setting, and that a theory which forbids the observed outcome is wrong. You may not conclude that the pattern is common, typical or increasing. Those claims require a different design and stating them from a single case is the most frequent overreach in case-based writing.

Say what your case cannot support as explicitly as what it can. Far from weakening the work, this strengthens it: a reader who sees the limits stated accurately extends more trust to the claims that remain. Then specify the study that would test frequency — the population, the sampling strategy, the measure. That paragraph converts a limitation into a research agenda and is regularly the difference between a competent submission and a distinguished one.

Worked example: two boundaries, two conclusions

Take a documented failure in security sector governance. Bound the case tightly — one organisation, the six months around the event — and the analysis will identify proximate causes: a missed signal, an unclear responsibility, a decision taken with incomplete information. All of these will be true, and the natural recommendations will be procedural: better checklists, clearer escalation, more training.

Now rebound the same case — the sector, ten years, including the regulatory environment and the funding model. The same events now appear as a predictable output of incentives that rewarded throughput over verification, in an organisation that had absorbed several similar near-misses without change. The proximate causes have not disappeared; they have been reframed as symptoms. The recommendations change accordingly, and so does the identity of the person who has to act. Neither boundary is wrong. What would be wrong is choosing one without noticing that you chose.

Slide deck

A ten-slide presentation of this lesson, built in HTML so that it prints, translates, enlarges and reads aloud on any device.

Slide 1 of 10