How to Write a Case Study Analysis

Most weak case analyses solve the problem the case announces rather than the one it actually has.

Case study analysis is standard in business, law, nursing and social work, and it tests something specific: whether you can move from a messy set of facts to a defensible decision. Summarising the case earns almost nothing. The marks are in diagnosis, in the application of frameworks to evidence, and in recommendations someone could act on.

Read the case at least twice

Read once for the story, without notes, so you understand what happened. Read again with a pen, marking financial data, decision points, stakeholders, constraints and any statement that seems inconsistent with another. Cases are written with deliberate noise, and details that seem incidental on a first pass often turn out to be the crux.

Pay particular attention to the exhibits. Students routinely analyse the narrative and ignore the appendices, where the decisive numbers usually sit.

Diagnose the real problem

The problem a case announces is usually a symptom. “Sales have fallen in the northern region” is an observation; the problem might be a distribution bottleneck, a pricing mismatch, a competitor’s move, or a sales incentive that rewards the wrong behaviour. Weak analyses accept the presenting complaint and rush to solutions.

Work backwards from the symptom to its causes, and separate causes from consequences. A useful discipline is to state the problem in one sentence and then ask “why?” three times. If your answer changes at each step, you were previously working on a symptom.

Apply frameworks to earn insight, not to decorate

SWOT, Porter’s Five Forces, PESTLE and their equivalents are analytical tools, not sections to be filled in. A framework applied mechanically produces four boxes of obvious statements. A framework applied well surfaces something you would otherwise have missed.

Choose the tool that fits the question: Five Forces for industry structure and profitability; PESTLE for external pressures; SWOT to consolidate an analysis you have already done, not to begin one. And use only what the analysis needs. Three frameworks in a short paper usually indicates the writer was unsure which one mattered.

Ground every claim in the case

Assertions unsupported by the case are the fastest way to lose credibility. Every diagnostic claim should point to a fact, a figure or an exhibit. Where the case is silent, say so explicitly and state the assumption you are making – “the case does not give unit costs, so this analysis assumes they remained proportional to volume” is a mark of rigour, whereas quietly inventing the number is not.

Generate alternatives before choosing

An analysis that presents one solution invites the question of what else was considered. Set out two or three realistic options, evaluate each against consistent criteria – cost, feasibility, timeframe, risk, fit with the organisation’s capabilities – and then choose. Showing the alternatives makes the recommendation an argued decision rather than a preference.

Be honest about trade-offs. Every real option has a downside, and an analysis claiming otherwise reads as naive.

Make recommendations executable

Recommendations fail when they are aspirations. “Improve customer service” cannot be implemented, budgeted or measured. Strong recommendations name the action, the owner, the timeframe and the expected effect, and they follow logically from the diagnosis rather than appearing from nowhere.

• What exactly should be done?
• Who does it, and by when?
• What will it cost, at least approximately?
• How will anyone know whether it worked?
• What are the main risks, and how are they mitigated?

Structure for a decision-maker

Most case analyses follow a predictable shape: a brief statement of the situation, the problem diagnosis, analysis with supporting evidence, evaluated alternatives, the recommendation, and an implementation outline. Keep the situation summary short – your reader has read the case and does not need it retold. Where a rubric specifies a structure, follow it exactly; where it does not, lead with your conclusion rather than building to it, because that is how professional reports are read.

Use the numbers in the exhibits

Quantitative evidence carries disproportionate weight in case analysis because so few students engage with it. Even simple work – a margin calculation, a growth rate, a break-even point, a ratio compared across two years – moves an analysis from plausible to demonstrated. If the case supplies financial statements, calculate something from them rather than describing them. Where a figure surprises you, that surprise is usually the analytical thread worth following.

Write for the decision, not the assignment

The strongest case analyses read as though written for someone who has to act on Monday morning. That means stating the recommendation clearly rather than hedging, acknowledging what could go wrong, and being explicit about what you would need to know before committing further resources. Hedging every claim to avoid being wrong produces an analysis nobody could use, and markers recognise it as an absence of judgement rather than a display of caution.

Separate symptom, problem and cause

Cases open with symptoms — falling sales, rising turnover, a failed launch. The analytical work is tracing these to a problem and then to its causes, and skipping that chain is the commonest reason analyses feel superficial.

Ask “why” repeatedly until the answer stops changing. If your final answer is something the organisation can actually act on, you have reached a cause; if it is a market condition nobody controls, you have reached a constraint and need to look again for what is actionable within it.

Read the exhibits before the narrative

Case writers put the decisive information in the appendices, and most students read the story and skim the tables. Reversing that order is unusually effective: work out what the numbers say, then read the narrative to understand why. Anything in the data that contradicts the narrative is almost always the point of the case.

Use frameworks selectively

Applying four frameworks demonstrates familiarity with the syllabus and little else. Choose one or two that fit the question and apply them properly — a Five Forces analysis that identifies which force actually constrains profitability is worth more than four filled-in templates.

A framework that produces only obvious statements has been applied mechanically. If the output could describe any company in the sector, it has not done analytical work.

Quantify the recommendation

Recommendations gain credibility from numbers, even estimated ones. What will it cost, over what period, and what return is expected? Where the case supplies financial data, use it; where it does not, state your assumption and reason from it.

• Cost of the proposed action, at least in order of magnitude.
• Expected effect on the metric that defined the problem.
• Timeframe before the effect is visible.
• What you would need to know to be more confident.

Address implementation and risk

A recommendation without an implementation path is an opinion. Say who does what, in what order, and what could go wrong. Naming the two or three most likely failure modes and how you would detect them early is often where the strongest analyses distinguish themselves.

Write for the decision-maker

Lead with the recommendation rather than building to it. Keep the situation summary short — your reader has read the case. Use headings so sections can be found quickly, and put detailed working in appendices rather than the main argument. Case analysis is a professional genre, and reading like a professional document is part of the assessment.