What "analyse the case" actually means in your brief
When a brief says writing a case study analysis, it is asking for a specific product: an argued diagnosis, not a summary with opinions. The grader wants to see a chain — evidence from the case, a problem defined beneath its symptoms, causes traced downward, a named theory that explains those causes, and a recommendation that could only belong to this case. Every link in that chain is a place to earn or lose marks.
The fastest self-check before you write anything: can you finish the sentence "the real problem is ____, and my recommendation is ____ because ____" using only case evidence? If yes, you are ready to draft. If not, the five moves below will get you there — they are the same chain, taken one step at a time, and the case study analysis example page shows the finished chain annotated section by section.
The 5-move method: facts → problems → causes → theory → recommendation
Move 1 — Extract the facts that matter
Reread the case with one question: which facts would change the decision? Write each as a single line with its location — exhibit number or page. Ten sharp facts beat a page of summary, and later sections will cite these lines by number.
Move 2 — Name the problem, not the symptom
Falling sales, rising turnover, missed deadlines — symptoms. The problem is the constraint that produces them. Test any candidate by asking "and what is causing that?" If you can keep asking, you have not reached the problem yet. State it in one sentence.
Move 3 — Trace the causes down
Ask why three times and write each level: symptom → nearer cause → root cause. Most cases have two or three interacting causes; argue which is primary and say what evidence supports it. This move is where "critical analysis" marks live.
Move 4 — Bring in theory to explain, not decorate
A framework earns its place when it explains your causes: Five Forces showing where profit pressure comes from, a motivation theory explaining why exits spiked, a strategy lens naming the trade-off. Cite the framework by name and say what it reveals here.
Move 5 — Recommend against explicit criteria
Shortlist two or three options, name your criteria (cost, speed, risk, reversibility), pick one, and give the because-clause that points back to moves 2–4. Add the first step and the main risk with its mitigation. A recommendation with no arrow back to the analysis is a guess.
Evidence discipline: cite the case, not the world
Three habits separate strong analyses from confident-sounding ones. First, anchor every claim: "queues exceed eight minutes (exhibit 3)" can be challenged; "queues are clearly terrible" cannot even be discussed. Second, stay inside the case: no outside market data, no figures you remember from the news — if the case lacks a number, name what you would collect. Third, label what is yours: interpretation is allowed and required, but mark it as interpretation ("the pattern suggests…"), so the grader sees evidence and inference as separate layers.
When your framework tables get long, build them in a tool and keep the interpretation in prose. The SWOT builder, PESTLE builder and Five Forces builder each export clean text you can paste into an appendix while the analysis section keeps the argument.
Framework picker: SWOT, PESTLE or Five Forces?
Three questions, one recommendation. Answer honestly — the picker matches your brief and evidence to the tool that reads that kind of world.
1. What does your brief ask you to examine?
2. Where does most of your evidence live?
3. Which question does the decision in your case turn on?
Answer all three and your recommended framework — with a link to its builder — appears here.
A note on combining: position (SWOT), environment (PESTLE) and industry (Five Forces) are layers, not rivals. Two of them used with evidence is a complete analysis for most briefs; three is a survey unless the word count is generous.
The 5-step analysis checklist
Run this against your draft before submission — each unticked item is a rubric row at risk.
- My problem statement names a cause-level problem, and I removed the symptom version from the final draft.
- Every factual claim in my analysis cites an exhibit or page from the case.
- My "why chain" is written out: symptom → nearer cause → root cause, with the primary cause argued.
- Each framework I used says what it reveals here — no matrix appears without interpretation.
- My recommendation names its criteria, its first step and its main risk with a mitigation.
- I can trace one arrow from the recommendation back through theory and causes to a numbered fact.
The same paragraph, weak and strong (illustrative retail case)
Both versions analyse the same illustrative retail case — a store chain with rising staff turnover after a scheduling change. Flip between the tabs and watch where the marks go.
The company has a big problem with staff turnover. Employees are leaving and it costs the company money and time. The company should improve its HR practices and make employees happier so that fewer people leave. Motivation is important in this situation.
Why it scores poorly: no numbers, no exhibit references, "turnover" treated as the problem rather than a symptom, the framework named but never used, and the recommendation could be pasted into any HR paper ever written.
Store turnover reached roughly a third of front-line staff within a year of the new scheduling system (case p. 7), against the stable picture in exhibit 4 — turnover here is a symptom, not the problem. The change removed shift predictability, which motivation theory treats as a hygiene factor: its absence drives exits even where pay is unchanged. Pay raises would therefore miss the cause. The fix is scheduling reform first — the pilot store that returned to fixed rosters two months ago is the natural test — with retention pay only for roles the exit data shows are hardest to fill.
Why it scores well: claim → evidence (page and exhibit cited) → symptom/cause separation → named theory doing explanatory work → a recommendation with a built-in test. Every sentence is falsifiable from the case, which is exactly what a grader can reward.
The makeover pattern generalises: replace every adjective with a number or citation the case supports, push every claimed problem one "why" deeper, and make the framework interpret instead of introduce.
Prioritising recommendations: the two-axis test
When your analysis produces more options than the word count can defend, sort them on two axes: impact on the core problem and feasibility inside the case's constraints (money, time, people). High impact plus high feasibility is your recommendation. High impact but low feasibility becomes a phased option — name the pilot. Low impact but easy becomes a quick win you mention in passing. Low on both gets one honest line: considered and rejected, because saying what you would not do, and why, is analysis too.
Keep the two-axis sorting visible in your text — one sentence per rejected option — because graders reward decision behaviour: criteria, comparison, commitment. That behaviour, not the framework vocabulary, is what "recommendation justified" means on a rubric. For the fuller paper around this analysis — executive summary, background, references — follow the case study structure guide, and the definitions page if you are still deciding what genre your brief actually wants.
A copyable analysis skeleton
Copy this into your document and fill it top to bottom — the order of the fills is the order of the moves.
BUSINESS CASE STUDY ANALYSIS SKELETON 1. Problem statement: [the constraint behind the symptom, one sentence] 2. Evidence lines: - [fact 1] (exhibit _) - [fact 2] (p. _) - [fact 3] (exhibit _) 3. Why chain: [symptom] -> [nearer cause] -> [root cause] Primary cause: [one], because [evidence]. 4. Theory lens: [framework] shows [finding in this case]; [course theory] explains [root cause] by [mechanism]. 5. Options vs criteria: A / B / C judged on [cost, speed, risk, reversibility] 6. Recommendation: [option] because [arrow back to moves 2-4]. First step: [...]. Main risk: [...], mitigated by [...]. 7. What would change my mind: [assumption] — if it fails, [adjustment].
The analysis is due before you have read the case twice?
A quoted, deadline-bound writer can produce the argued diagnosis for you — you set the case, framework and deadline, and see the price before you commit.
Frequently asked questions
How long should a business case study analysis be?
Whatever your brief sets — but the internal share matters more than the total. Problem, causes and theory deserve at least half the words; the recommendation with its justification most of the rest; case description under a quarter. If your analysis section is thinner than your background section, the grader will notice before you do.
Should the analysis be in first person?
Most courses want third person, but decision-focused classes often allow I or we when you commit to a recommendation — "I recommend X" reads as ownership, not ego. The brief and your department style guide decide; when silent, third person with active verbs is the safe default.
Can I use frameworks the professor did not teach?
Usually yes, if you explain the framework and justify why it fits this case better than the taught alternatives. Check the rubric first: named frameworks must appear. An extra lens is a bonus argument — never a substitute for the required one.
What if I cannot find a single root cause?
Say so. Name the two or three candidate causes, test each against the case evidence, and argue which is primary. Real cases have interacting causes, and an honest multi-cause diagnosis with a argued ranking scores better than one forced root cause the evidence only half supports.
How do I keep the analysis under the word count?
Cut framework description, not argument. The grader knows what SWOT stands for; they want to know what your SWOT proved. One interpretation sentence per framework beats a paragraph of definitions — and if you need to see where the words actually are, run the draft through the word counter before trimming blind.
Did the 5 moves clarify it?