Data projects fail in familiar ways. A migration lands and the finance dashboard quietly shows different totals. A new ingestion job works for a fortnight and then chokes on a column someone renamed upstream. A DataOps pre-mortem exists to find those stories before they happen: you assume the project has already gone wrong, then list why.

The exercise has more than one shape, though, and the shape you choose changes what you learn. Here is a no-nonsense comparison of three formats, with a verdict on when each earns its time.

Format one: the written solo pass

Everyone on the team gets the project brief and a single prompt: “It is the end of next quarter and this pipeline project failed. Write down the five most likely reasons.” People answer alone, in a shared document, within a day or two.

What it does well. It is cheap, it respects people’s calendars, and it gives quiet engineers equal footing with confident ones. You also get a written trail, which helps when someone asks in three months why a certain safeguard exists.

Where it falls short. Nobody builds on anybody else’s idea. A schema worry from one engineer and a staffing worry from another never get connected, even though together they describe one serious problem. Written answers also run generic (“poor communication”) unless the prompt is tight.

Format two: the live workshop

This is the classic version. Ten to fifteen people, one room or one call, a facilitator, and about an hour. After a silent writing round, the group reads out reasons, clusters them and votes on the scariest.

What it does well. The conversation surfaces links between worries. Someone from analytics mentions that a report depends on a nightly file, and the platform engineer realises that file is exactly what the migration might delay. Those cross-team collisions are the whole value of the format.

Where it falls short. It costs real hours of expensive people, and it only works with a facilitator who stops the room from turning into a debate about solutions. It can also tilt toward whoever is most senior.

Format three: the walk-the-flow pre-mortem

The third format is more particular to data work. Instead of free brainstorming, the team traces the path of the data from source to consumer on a whiteboard and, at each handoff, asks: “If this stage were the reason we failed, what would have happened?” Sources, landing zones, transforms, the warehouse, the reports and the people who read them each get a turn.

What it does well. It is systematic. Because the prompt is tied to a stage, you rarely end up with vague answers, and gaps in ownership show up as awkward silences (“who actually watches that landing bucket?”).

Where it falls short. It can miss failures that live outside the flow, such as a budget cut, a key person leaving or a regulatory change. It also needs a decent diagram before you begin, which not every team has.

Side by side

• Time cost: solo pass is lowest, workshop is highest, walk-the-flow sits in between.
• Quality of ideas: workshop and walk-the-flow beat the solo pass on depth; the solo pass wins on diversity of voices.
• Best for: solo pass for small changes, workshop for large cross-team programmes, walk-the-flow for a pipeline rebuild.
• Biggest risk: solo pass gets shallow, workshop gets dominated, walk-the-flow gets narrow.

Many teams combine them. Run the solo pass first so everyone arrives with their own list, then use a shorter workshop to cluster and rank.

What to do with the list

Whatever format you pick, the finishing step is the same and it is the one people skip. Take the top handful of failure reasons and attach a concrete pre-launch action to each: a row-count comparison between old and new tables, a contract test on an upstream feed, a rehearsal of the restore path for the warehouse. If a reason cannot be turned into an action, turn it into a signal you will watch, such as late arrivals or growing null rates.

For ideas about what typically breaks in streaming and analytics work, our piece on why live analytics stalls and how teams stop the stalls is a useful companion, and the notes on how DataOps shows up in actual team projects give context on what a healthy setup looks like.

One more category of failure to include

Data pipelines are software, and they ship through automation that can itself be tampered with or misconfigured. If your pre-mortem list has nothing about the build and deploy path, add a line for it. Engineers who want a primer on that side can read the DevSecOps Now blog, which covers securing CI/CD pipelines, then bring the vocabulary back to their own review.

Who should sit in the room

Whichever format wins, invite at least one person who consumes the data, not just the people who move it. Analysts and report owners notice failures that engineers never see, like a metric that is technically fresh but means something different after the change. A finance partner or a product manager adds the same kind of grounded realism, and their worries tend to be the ones that make a project look like a failure to the business even when every job is green.

The verdict

If you only get one session this quarter, run the walk-the-flow version for a rebuild or migration, because the stage-by-stage prompt produces specifics. For smaller changes, the solo pass is enough. Reserve the full workshop for programmes where many teams touch the same data and nobody has the whole picture.

Either way, keep it short, write down the actions and revisit the list once the project is halfway through. The goal is not to predict the future, only to make the likely failures a little less of a surprise.