What Your Dead Projects Know That Your Retrospectives Don't

Every team has a graveyard. You probably know where yours is — some combination of a dusty Notion folder, a GitHub org full of archived repos, and a Confluence page nobody's updated since 2021. You walk past it every day without really looking at it.

That's a mistake.

Most engineering teams are pretty good at running postmortems. Something blows up, you schedule a blameless meeting, you document what went wrong, you close the ticket. But postmortems are reactive by design. They look at one failure in isolation. What they almost never do is zoom out and ask: why does this keep happening?

That's what a graveyard audit is for.

The Difference Between a Postmortem and a Pattern

Here's the thing about individual failure reviews — they're great at explaining what happened, but they're lousy at explaining why it keeps happening. You can run a postmortem on every shelved project for five years and still miss the fact that every single one of them died at the same organizational chokepoint.

A graveyard audit is different. Instead of examining one failure deeply, you're examining all of them broadly. You're looking for the signal buried in the noise of accumulated disappointment.

Think of it like this: a single broken window tells you someone threw a rock. A dozen broken windows in the same neighborhood tells you something about the neighborhood.

Your abandoned projects are the broken windows. The audit tells you about the neighborhood.

How to Actually Run One

A graveyard audit doesn't have to be a massive undertaking. Here's a practical framework that works for teams of most sizes.

Step 1: Inventory everything. Pull together a complete list of every project that was started and not shipped in the last three to five years. Cancelled features count. Shelved prototypes count. That internal tool someone built and then quietly stopped maintaining — that counts too. Don't filter anything out yet.

Step 2: Categorize the cause of death. For each project, assign a primary reason it didn't make it. Keep the categories broad: resource reallocation, scope creep, technical blocker, lost champion, market shift, never prioritized. You're not looking for nuance yet, you're looking for distribution.

Step 3: Map the timeline. When in the project's lifecycle did it die? Early exploration? Mid-prototype? Final polish? This is often the most revealing step. Teams are frequently shocked to discover that 70% of their abandoned work dies at exactly the same stage.

Step 4: Look for the organizational fingerprints. Who killed each project? Not in a punitive way — you're not looking to assign blame. You're looking for patterns in decision-making authority. Was it always a leadership change? Always a Q4 budget crunch? Always the same team that got pulled onto something else?

Step 5: Cross-reference with what shipped. Finally, look at the projects that did make it. What was different? What did the survivors have that the casualties didn't? Sometimes the answer is quality or timing. More often, it's something structural — a sponsor who stayed, a team that wasn't interrupted, a scope that was ruthlessly contained.

What Teams Actually Find

The results of graveyard audits tend to fall into a few recurring categories.

The most common finding is what you might call the handoff graveyard — a disproportionate number of projects that died the moment they were transitioned from one team to another. The original builders had context and momentum. The receiving team had neither. The project never recovered.

Another frequent pattern is the almost-launch trap. Projects that got to 80% completion and then stalled out indefinitely. These are particularly painful because they represent the most sunk cost. They're also often the most recoverable — which is why they're rarely killed officially and instead just slowly starve.

A third pattern that shows up regularly: the invisible dependency killer. Projects that died not because of anything wrong with the project itself, but because they were waiting on something else — an API that never stabilized, a platform decision that never got made, a data pipeline that was always six weeks from ready.

One product team at a mid-sized SaaS company ran their first graveyard audit and discovered that eleven of their last fourteen abandoned projects had a single thing in common: they'd all been assigned to engineers who were simultaneously on-call for production support. Not occasionally. Consistently. The audit didn't just reveal a pattern — it revealed a structural policy that was silently destroying innovation capacity.

The Psychological Barrier

Here's why most teams don't do this: it feels bad. Digging through your failures is uncomfortable in a way that a single postmortem isn't. A postmortem is contained. A graveyard audit is a panoramic view of everything that didn't work, and that can feel like an indictment of the whole operation.

That discomfort is actually a signal worth paying attention to. If reviewing your abandoned work feels threatening, that's often because the patterns it reveals implicate decisions made at levels above the individual contributors. Graveyard audits have a way of pointing upward.

The teams that do these well treat them less like autopsies and more like archaeology. You're not there to assign guilt. You're there to understand the terrain.

Making It a Practice

The real value of a graveyard audit isn't the one-time insight — it's what happens when you make it a regular practice. Teams that run these annually start to build institutional memory around their own failure modes. They catch the patterns earlier. They start asking, before a project even kicks off, does this look like the kind of thing we tend to kill at the prototype stage?

That's not pessimism. That's pattern recognition. And pattern recognition is how good labs get better.

Your graveyard isn't a source of shame. It's a data set. The question is whether you're going to let it sit there collecting dust, or actually put it to work.