How to Actually Analyse a Case Study (Without Just Summarising It)

I bombed my first case study so badly the lecturer asked me to stay behind after class. It was a 14-page disaster about a supermarket chain haemorrhaging market share, and I’d treated it like a history essay wrote 2,000 words describing what happened, threw in a SWOT diagram I’d copied from the textbook, and called it analysis. The feedback was two sentences long: “You told me the story. You didn’t tell me what to do about it.”

That’s the trap. Case studies aren’t stories. They’re puzzles with missing pieces, and your job is to argue not narrate.

A case study dumps you into a real (or realistic) mess: a company bleeding cash, a hospital policy backfiring, a school intervention that half-worked. You get incomplete information, conflicting stakeholder views, and usually one looming decision point. The Harvard Case Method, which most business schools lean on, literally puts you in the protagonist’s chair and asks: what now?

Your marker isn’t hunting for the “correct” answer. They want to see three things: can you spot what actually matters, can you apply theory without forcing it, and can you back your recommendation with evidence from the text? The Harvard Graduate School of Education breaks this down neatly: situational analysis, framework application, problem-solving. Nail those three, and you’re already ahead of half the cohort.

I used to read case studies once, front to back, like a novel. Terrible idea. Now I do two passes, and it changes everything.

Pass one: Skim for context. Read the intro, the final paragraph, and any financial tables or exhibits. You’re not analysing yet you’re mapping the terrain. Who’s the decision-maker? What’s the deadline? What’s at stake?

Pass two: Go in with a pen. Circle every number that feels significant. Underline quotes where stakeholders contradict each other. Note the gaps what’s not being said? The University of Southern California’s writing guide calls this “active reading,” but really it’s just refusing to be a passive consumer. I keep a scrap paper next to me and jot down every stakeholder, every figure, every constraint. By the end, I’ve got a messy inventory of raw evidence. Only then do I let myself form an opinion.

Most cases hand you symptoms dressed up as problems. Declining sales. Staff walking out. Customer complaints spiking. But symptoms are easy. Your job is to dig.

I use a stripped-down 5 Whys approach. Let’s say the case says sales dropped 18% last quarter. Why? Because foot traffic fell. Why? Because a competitor opened two blocks away. Why are customers choosing them? Because delivery takes 24 hours instead of five days. Suddenly the problem isn’t “declining sales” it’s operational speed. That completely changes your recommendation. If you’d stopped at the symptom, you’d have proposed a marketing campaign. Now you know you need logistics reform.

This sounds obvious until you’re 1,200 words into an essay arguing the wrong thing. I’ve done it. Don’t do it.

Students love framework shopping. SWOT, PESTEL, Porter’s Five Forces, VRIO, Balanced Scorecard they cram them all in like it’s a theory buffet. It looks impressive for about three sentences, then it falls apart because none of them are applied with any depth.

Pick one or two that genuinely fit. For most business cases, SWOT (Strengths, Weaknesses, Opportunities, Threats) is a solid starting point because it forces you to look inward and outward simultaneously. If the case is heavy on regulatory or market-wide pressures, PESTEL (Political, Economic, Social, Technological, Environmental, Legal) helps you map external forces without rambling. The Harvard GSE guide warns against cherry-picking categories to fit your pre-existing opinion apply the framework systematically, even when it surfaces weaknesses in your own argument.

Some cases are pure narrative. Others dump raw data on you survey results, financial statements, patient outcome metrics. If you’re in psychology, education, or public health, you’ll likely face the hybrid: a story plus a spreadsheet.

Don’t panic. I separate the two tasks. First, analyse the narrative to understand the human dynamics. Then test your assumptions against the data. Maybe the case implies staff morale is the core issue, but the engagement survey shows satisfaction is actually average it’s workload distribution that’s the outlier. The data corrects your intuition. That’s the point.

If you’re not confident with statistical software yet, that’s fine. But if your grade depends on running ANOVA or regression on that dataset, there’s no shame in getting help with SPSS assignment support to make sure your numbers are solid while you focus on the argument. I’ve seen smart students lose marks because their interpretation was sharp but their t-test was backwards. Fix the technical gap honestly rather than bluffing.

Markers read fast. Give them a clear path.

Introduction (2–3 sentences): What’s the case about, what’s the core problem, and what’s your main recommendation? No throat-clearing. Get to it.

Background (1 short paragraph): Set the scene with relevant facts only. Prove you read it. Don’t retell the whole story.

Analysis (the bulk): Apply your framework, present your evidence, connect the dots. Use subheadings if you’re covering multiple angles finance, operations, HR, whatever.

Alternatives (brief): What else did you consider? Why did you reject it? This shows you’re not just arguing from gut feeling.

Recommendation (specific, actionable): Who does what, and by when? “Improve communication” is useless. “The operations director should implement daily 10-minute stand-ups across all shifts, starting Monday week 3” is something someone could actually do.

Conclusion (reflective): What does this case teach us about the broader topic? The USC guide suggests linking back to course theory and being introspective what assumption did you have to challenge?

I’ve made all of these. Here’s the shortlist.

Overgeneralising. One case study doesn’t prove universal law. Write “in this specific context, the evidence suggests…” not “this proves all companies must…”

Confirmation bias. You’ll form a hunch ten minutes in. Fight it. Actively look for evidence that disproves your theory. If the case includes a manager who disagrees with your solution, engage with their view. Dismissing it looks lazy.

Ignoring limitations. Every case has holes missing data, ambiguous timelines, perspectives left out. Pointing this out doesn’t weaken you; it shows intellectual maturity. Research on common case study pitfalls confirms that acknowledging constraints and triangulating evidence builds trust with your reader.

Weak sources. If you bring in outside research, use credible stuff peer-reviewed journals, industry reports, official documentation. Not a 2014 blog post you found on page four of Google.

Do three things. Read it aloud awkward phrasing and logical jumps reveal themselves instantly. Check that every recommendation is tethered to a specific fact, figure, or quote from the case. If you can’t point to the evidence, it’s speculation, not analysis. Finally, proofread your citations. Sloppy referencing makes even a strong argument look careless.

Case studies are meant to be messy. They mirror real life: incomplete information, competing priorities, no perfect answer. Your lecturer isn’t looking for genius. They’re looking for structured thinking, evidence-based reasoning, and the humility to admit where the data runs out.

Start with the real problem. Everything else follows from there.