Business problems case studies: from symptom to cause

Why symptom vs cause decides your grade

A symptom is what you can see from the outside: falling repeat orders, a fuller complaints inbox, a queue at the returns desk. A cause is what makes the symptom rational: a reminder email switched off during a site migration, a packing station moved twice as far from the shelving, a bonus scheme that pays for speed and punishes care. The symptom is never the thing to fix; it is the thing to follow inward.

Markers read thousands of papers that treat the symptom as the problem and recommend ambitious remedies for it — "launch a loyalty scheme" for churn caused by broken delivery promises. The paper reads confidently and earns little, because the loyalty scheme would pour water into a bucket with the hole still in it. Diagnose the hole, and even modest fixes sound sharp.

The skill is trainable, which is what the drill below is for. Then we build the formal version: a diagnosis tree.

Drill: symptom or root cause?

Eight statements from an illustrative mail-order bakery (invented for practice). Call each one a symptom or a root cause, then read why.

Build a problem-diagnosis tree

A diagnosis tree is the written form of the inward search, and it fits any messy case. The method is general practice in problem solving:

1. State the problem precisely at the trunk. Not "sales are bad" but "repeat orders from subscription customers fell 18% over two quarters" (an illustrative figure — your case will supply its own).
2. Split into branches of "what causes this?" Each branch is a candidate mechanism: delivery reliability, product quality, price, communication, competitor moves. Aim for branches you could disprove with case evidence.
3. Test each branch against the facts you have. The case says complaint emails mention crushed boxes and late arrivals — those facts support the delivery branch and starve the price branch. Cross out what the evidence does not feed.
4. Keep asking "what causes that?" on the surviving branch. Late deliveries ← courier pickup capped at noon ← contract negotiated when volumes were half of today's. Stop when the next level would need data the case does not give you, and say so.
5. Draw the trunk-to-root path in one sentence. That sentence is your thesis, and the fixed point your recommendations must touch.

The same logic underlies the "5 whys" technique taught in quality management: ask why repeatedly until the answer stops being an observation and starts being a decision someone made. Two disciplines keep the method honest: every "why" needs a fact from the case under it, and you stop at the evidence, not at a comfortable villain.

The 5-step approach for a business problems case study

1. Inventory the symptoms. List every observable trouble in the case with its evidence: numbers, quotes, dates. Symptoms first, judgement later.
2. Cluster symptoms into themes. Three late-delivery clues and one crushed-box clue belong to one theme. Clusters turn a wall of facts into two or three candidate causes.
3. Trace the strongest cluster to a root. Build the diagnosis tree, keep the branch the evidence feeds, and stop at a decision, a policy, or a contract term — something that could actually be changed.
4. Set criteria and compare fixes. Speed, cost, reversibility, and how directly each fix touches the root. Name the criteria before you rank; it is the difference between evaluation and taste.
5. Recommend, and predict what un-watches. State the fix, the owner, the measure, and honestly note what might get worse temporarily (a new packing layout slows week one). That honesty is what "feasible" means to a marker.

Worked mini-outline (illustrative scenario)

Scenario, invented for practice: an online bakery sees repeat orders slide. The owner blames "competition". The case facts: complaint emails mention crushed boxes; delivery complaints cluster after 12:00; the courier contract caps pickups at noon; the packing station was moved away from the shelving in a spring refit.

1. Introduction. Context in two sentences; thesis: "declining repeat orders trace to a midday courier cutoff and a refit that doubled packing travel — both fixed internally for less than the cost of a discount campaign."
2. Symptom inventory. Repeat-order decline, complaint themes, timing pattern — each with its evidence from the case.
3. Clusters and the tree. Delivery-reliability cluster survives; price and competition branches are starved of case evidence and set aside explicitly.
4. Root statement. The noon cutoff (a contract decision) plus the layout change (an operations decision) make late, damaged deliveries a predictable output, not an accident.
5. Options against criteria. (a) afternoon courier slot, (b) restore packing-station adjacencies, (c) loyalty discount. Ranked on cost, speed, and root contact — the discount touches none.
6. Recommendation. Do (a) and (b); owner: operations; measure: complaint rate and repeat orders at 60 days; note the week-one disruption honestly.
7. Limits. Invented scenario; no competitor or margin data available in the case.

Pitfalls specific to problem-diagnosis papers

• Prescribing before diagnosing. If your recommendations appeared in paragraph one, the diagnosis is decoration. Reverse the order of work, not just the sections.
• Symptom inflation. Listing eight symptoms as if they were eight problems usually means two causes wearing eight coats. Cluster first.
• Blaming the market by default. "Competition" explains everything and is falsified by almost any internal fact. Test internal causes first because you can act on them.
• Unfalsifiable branches. A tree branch you could never disprove with case evidence is philosophy, not analysis. Cut it.
• Roots nobody can change. A "root cause" like "the founder's personality" stalls the paper — keep tracing to a decision, policy or contract term.
• Silent trade-offs. Every fix costs something. Papers that admit the cost of their own recommendation read more credible, not less.

Six diagnostic questions that beat the obvious one

Flip each card: front is the question everyone asks, back is the question that moves you toward a cause.

Diagnosis checklist

• Every symptom in my paper has evidence attached (number, quote or date from the case).
• Symptoms are clustered into two or three candidate causes before any judging.
• My diagnosis tree's surviving branch is fed by case facts, not assumptions.
• The root cause is a decision, policy or contract term someone could change.
• Fix options are ranked against criteria I stated before ranking.
• My recommendation names an owner, a measure and a review point.
• I admit at least one trade-off or temporary cost of my own fix.
• Illustrative or invented details are labelled, and real-company facts come only from the case or cited sources.

0 of 8 steps

Free tools that help with diagnosis papers

• Thesis statement generator — the trunk-to-root sentence is your thesis; draft and test three shapes of it.
• Word counter — symptom lists are word-hungry; keep the diagnosis and options sections fed instead.
• SWOT analysis generator — internal weaknesses often hold the root cause; scan systematically instead of by hunch.
• Readability checker — diagnosis trees sprawl in prose; find the 40-word sentences and cut them.

Frequently asked questions

Was this page useful? 👍 Yes 👎 Not really