What a BPR case study asks that other case studies don't
Most business case studies ask you to understand a company. A business process reengineering case study asks you to judge a surgery. The unit of analysis isn't the firm — it's a process: order fulfilment, claims handling, invoice approval, new-product approval. Michael Hammer's 1990 Harvard Business Review article "Reengineering Work: Don't Automate, Obliterate" and the 1993 book he wrote with James Champy, Reengineering the Corporation, set the definition most courses still use: the fundamental rethinking and radical redesign of processes to achieve dramatic gains in cost, quality, service and speed. Three words in that definition carry the marks: fundamental, radical, and dramatic.
So when your assignment hands you a reengineering case, it usually wants four things from you:
- A map of the old process — steps, hand-offs, waiting time, and where the waste hides.
- The redesign logic — which of Hammer's shifts the company made: sequential tasks turned into parallel ones, checks folded into the work, workers given decision rights, one person handling the whole case.
- Before-and-after evidence — cycle time, cost per transaction, error or rework rates, throughput. Numbers, not adjectives.
- A judgement — was this genuine reengineering, or a tidied-up process improvement with a fashionable name?
That last bullet is where grades are won. Because reengineering promises dramatic change, a modest result is a finding. If the case shows cycle time falling 8%, you should be asking whether the company actually redesigned anything, or just bought software. Your essay becomes an argument, which is also why it helps to draft your claim early with our thesis statement generator and then hold every paragraph against it.
Free tool: score the redesign with as-is / to-be numbers
Drop the case's own figures into the scorer. It computes the change for each metric, averages the improvement, and tells you whether the case reads as radical redesign or as routine tinkering. Nothing you type leaves your browser.
As-Is / To-Be Metric Scorer
100% private — runs in your browserUse the numbers the case gives you. If the case reports percentages, enter percentages; if it reports hours, enter hours. The scorer compares within each row, so units cancel out.
The verdicts are deliberately blunt. Under roughly 5% average improvement, the scorer calls it "polish, not reengineering" — a useful opening for your evaluation section. Between 5% and 25% it flags incremental improvement, which is exactly the kind of nuance that separates a B+ answer from an A one. Past 25%, the redesign passes the "dramatic" test and your essay should shift to asking how the gains were achieved and what risks they carried.
The 5-step approach we use for BPR case studies
Work through the steps in order. Skipping step 2 is the most common reason reengineering essays drift into plot summary.
Map the old process first
List the as-is steps, every hand-off, and every wait. Count hand-offs: each one is a delay and an error opportunity. This map is your baseline evidence.
Isolate the redesign logic
Ask what got eliminated, combined, or handed to the person doing the work. Tie each shift back to the process map you drew, so your reader sees cause, not coincidence.
Quantify the before-and-after
Use the scorer above. Quote the case's own figures, label any of your own calculations as estimates, and never invent a number the case doesn't contain.
Test the change against its risks
Reengineering cuts roles, collapses departments and concentrates knowledge in single case owners. Cover the human side: redundancy, morale, retraining, and whether middle management resisted.
Deliver a reasoned verdict
Decide: radical redesign, incremental improvement, or automation wearing a BPR label. Justify with your evidence, then say what you'd have done differently.
Worked mini-outline (illustrative)
The skeleton below fits a 2,000-word assignment. The example company is illustrative — a fictional mid-sized furniture manufacturer called Oakline — so swap in your own case's facts.
1. Introduction — the decision at stake Case: Oakline Furniture (illustrative), order fulfilment redesigned in response to missed delivery promises. State your verdict in one sentence. 2. The old process and why it failed Sequential steps: sales enters order, credit checks it, warehouse confirms stock, production schedules, dispatch books couriers. 5 hand-offs, 12 working days. Waste: double data entry, batch processing at week-ends. 3. The redesign logic One order owner per customer; credit check folded into order capture; parallel scheduling; supplier EDI links. Map each shift to a reengineering principle. 4. Evidence: before and after Cycle time 12 days to 4; cost per order 45 to 21 (illustrative figures); rework down. Comment on what the numbers can and cannot prove. 5. Risks and failures to acknowledge Redundancies and morale, key-person risk with the order-owner role, lost checks now hidden inside software. 6. Verdict and recommendations Radical redesign achieved, but sustainability depends on training and a fallback when the single owner is absent.
Weak vs strong: writing the before/after paragraph
"After the reengineering project, Oakline's process became much more efficient. The new system streamlined operations and improved communication between departments, leading to better outcomes and higher customer satisfaction."
Why it fails: no numbers, no named process, no cause. "Streamlined" and "improved" could describe anything from a restructure to a new font. A grader can't award application marks for sentences that would survive being pasted into any essay about any company.
"Oakline's reengineering cut order-to-dispatch time from 12 working days to 4 (illustrative figures). The gain came from two specific shifts: a single order owner replaced five sequential hand-offs, and credit checking was folded into order capture instead of running as a separate approval stage. Cost per order fell from 45 to 21, though the case leaves staff turnover unreported — so the sustainability of those gains remains an open question."
Why it works: process named, numbers quoted, cause linked to effect, limits admitted. That last clause is what evaluation marks look like in practice.
The failure risks your BPR essay should flag
Reengineering has a reputation for being risky, and your essay earns credit for showing why. Cover these five, using the case's own evidence wherever possible:
- Automation dressed as redesign. If the "new process" is the old sequence running inside an ERP system, say so. Hammer's whole point was that speeding up a broken process still leaves a broken process.
- Change fatigue and headcount cuts. Radical redesign usually means fewer people doing the same work. Essays that mention only process gains read as though workers don't exist.
- Key-person risk. A single case owner concentrates knowledge. If that person is ill or quits, what happens? Strong answers spot this single point of failure.
- Checks that vanished. Folding control steps into software is fast — until an exception appears that the software never anticipated. Note what the case says about exceptions.
- No baseline. If the case never measured the old process, any "dramatic improvement" claim rests on memory. Point that out; it's a legitimate methodological critique.
If your brief also asks how the industry pressured the company into redesigning, a quick competitive scan with the Porter's Five Forces generator gives you the context paragraph almost every mark scheme rewards.
Before you submit: BPR case study checklist
Tap each item when it's done. All eight, and you've beaten most of the room.
- Old process mapped, with hand-offs and waits counted
- Every redesign shift tied to a named reengineering principle
- As-is and to-be figures quoted from the case (labelled if estimated)
- Verdict stated early and repeated in the conclusion
- At least two failure risks discussed with case evidence
- Hammer and Champy cited properly in your required style
- Word count inside the ±10% rule — check with the word counter
- Proofread aloud once for long sentences
Quiz: three BPR misconceptions
Quick check before you write. Pick an answer to see the reasoning.
1. A company buys a workflow system but keeps every approval step exactly as before. Is that reengineering?
Correct. Reengineering is about rethinking the process, not digitising the old one. Cost is irrelevant to the definition.
2. A BPR case reports a 6% average improvement across its metrics. What's the strongest line of analysis?
Right. The gap between the promise of dramatic gains and a 6% result is the analysis. Hunt for what constrained the redesign.
3. Your case says nothing about how staff reacted to the redesign. Should you mention it?
Correct. Flagging missing evidence is a strength, not a weakness. Inventing facts is the one unforgivable move in case work.
Need a second pair of eyes on your BPR draft?
If the deadline is close and the process map still looks like spaghetti, a quoted, deadline-bound writer can take the draft off your hands — analysis, structure and references included. Tell us the case, the word count and the due date.
Frequently asked questions
How is a BPR case study different from a change management case study?
The lens. Change management cases ask how people were moved from A to B; BPR cases ask whether the process itself was fundamentally redesigned. If your brief mentions Kotter or Lewin, it's change management — write about communication and resistance. If it mentions cycle time, hand-offs and radical redesign, it's BPR. Some assignments want both; in that case use BPR to diagnose the process and change management to discuss implementation.
Do I have to draw the process map?
Usually yes, and a simple one beats a fancy one: boxes for steps, diamonds for decisions, arrows labelled with waits. A hand-drawn-style flowchart inserted as a figure with a caption ("Figure 1: Oakline order fulfilment, as-is — illustrative") gives the grader application evidence at a glance. Keep it inside the page budget by letting the figure replace a paragraph of prose.
The case gives no numbers. Can I estimate the improvements?
You can reason qualitatively — "the elimination of three hand-offs should cut waiting time" — but label any quantity you produce as an estimate and show the reasoning. Never present an invented figure as if the case reported it. If your course allows outside sources, look for published figures on comparable processes and cite them; if not, stay inside the case.
Which citation style do BPR assignments usually use?
Follow your module handbook; it overrides everything. When the choice is open, Harvard author–date is common on business modules — our Harvard referencing generator formats books, journals and web sources, and the bibliography generator can add annotations if your rubric asks you to evaluate sources.
Can I use the scorer's verdict directly in my essay?
Use it as scaffolding, not as prose. The tool's categories (radical, incremental, polish) mirror the argument you should make in your own words, with the case's figures as evidence. Copy-pasting a tool's output sentence into an essay usually reads oddly — and it's your reasoning the grader marks, not the tool's.
What if my case ended badly — the redesign flopped?
Good. Failure cases make the sharpest essays. Diagnose why it failed: skipped baseline, no staff involvement, too broad a scope, leadership that lost interest. Tie each cause to evidence in the case, then propose what a competent redesign would have done instead. That structure walks you straight into top-band evaluation.
Was this guide useful?