Case Studies
Read enough project post-mortems and something slightly deflating becomes obvious: the failures are not exotic. The same handful of things go wrong, in the same order, for reasons that were visible early. That is inconvenient for storytelling and extremely useful for anyone running a project next month.
In short
- Successful and failed projects differ on a small, consistent set of variables — not on talent or budget.
- Every one of those variables is set early, usually in the first two weeks.
- Case studies mislead in two predictable ways: hindsight makes causes look obvious, and nobody writes up the boring successes.
- Read them for decisions and their timing, not for narrative.
What the comparison actually shows
How case studies mislead
They are useful, and they distort in ways worth knowing about before you draw conclusions from one.
- Hindsight makes causes look obvious. Once you know a project failed, the warning signs are unmissable. At the time they were three items among fifty, and half of them looked like ordinary noise. Beware any account where the failure seems inevitable from paragraph two — it is being narrated backwards.
- Nobody writes up boring successes. The published record is skewed towards spectacular failures and dramatic rescues. Most successful projects are undramatic and produce no story at all, which means the record over-represents heroics and under-represents the thing that actually works: doing ordinary practices consistently.
- Single causes are almost always wrong. “It failed because of poor requirements” compresses a chain of six things. It’s memorable and it removes exactly the detail you would need to act.
- Context travels badly. What worked for a forty-person regulated programme may be actively harmful on a five-person internal build. Read for the mechanism, not the practice.
Reading one well
Four questions turn a story into something usable:
When was it decidable?
Find the last moment the outcome could still have been changed cheaply. That’s the point the story is really about, and it is almost always far earlier than the crisis.
Who knew, and did they say?
In most failures somebody saw it coming. The interesting question is what happened to the warning — whether it wasn’t raised, wasn’t heard, or was heard and not acted on. Three different fixes.
What was the mechanism?
Not “communication was poor” but how information failed to move. A mechanism transfers to your project; an adjective doesn’t.
Is my project doing this now?
The only question that matters. A case study you agree with and act on nothing from has cost you fifteen minutes and taught you nothing.
The pattern underneath
If the five rows in the diagram share anything, it is this: each one is about how quickly the project could learn it was wrong.
Bad news arriving early, changes being priced, a sponsor being available, “done” being written down, past lessons being read — all five shorten the gap between a mistake happening and somebody noticing. Given the cost-of-change curve, shortening that gap is worth more than any amount of care taken during the work itself.
It also explains something that otherwise looks strange in the record: projects with unremarkable teams and modest budgets routinely outperform better-resourced ones. They weren’t better at building. They were faster at finding out.
A note on how these are written
The cases in this chapter are composites — assembled from patterns that recur across many projects rather than describing any single organisation. That is deliberate: identifiable case studies tend to be either sanitised beyond usefulness or written by someone with a stake in the account. Composites let the mechanism stay honest.
The most valuable case studies available to you, though, are not in this chapter. They are your own organisation’s last three projects, which share your constraints, your stakeholders and your peculiarities — and which is why 7.3 Knowledge Transfer spends so long on making them findable.
How this looks in AB
The five rows in the diagram are all observable in a project’s own records rather than requiring a survey. In AB Projects: how long items sat blocked before anyone escalated, whether change requests carry a cost line, how often the sponsor commented, whether tasks had acceptance criteria before they were started, and whether the previous project’s Wiki was opened during this one’s planning.
None of that is a report anyone runs. But it means a retrospective can be evidence-based — the change-history tab holds the actual timeline, so “we found out late” can be checked rather than remembered.
What this chapter covers
Traits of Successful Projects
What projects that go well have in common — which turns out to be a short list of unglamorous habits applied consistently.
Lessons from Failed Projects
How failures actually unfold, the warning signs available months in advance, and why they get missed.
Terms used on this page
- Hindsight bias
- The tendency, once an outcome is known, to see it as having been predictable. It makes every failure look avoidable and every warning sign look obvious. More →
- Survivorship bias
- Drawing conclusions only from the cases that got written up. The published record over-represents drama and under-represents projects that were quietly fine. More →
- Root cause
- The underlying reason something happened, as opposed to its visible symptom. Rarely singular, which is why one-line explanations of failure are usually wrong. More →
- Cost of change
- The observation that fixing a problem gets dramatically more expensive the later it is found. The reason early detection outperforms careful execution. More →
- Post-mortem
- A review held after something went wrong. Most published case studies are post-mortems, which is part of why the record skews towards failure. More →
- Lessons learned
- The reusable conclusions from a project. Your own organisation’s are worth more than anyone else’s, because they share your constraints. More →
Related reading
1.2 Why Project Management Matters
The five failure modes and the cost curve that makes early detection so valuable.
7.2 Retrospective and Evaluation
How to produce your own case studies, in a form the next team can use.
3.4 Risk Management
Where other people’s failures belong on your project: on the register, with a trigger.