Space programs have a long habit of looking backward. After a lost vehicle or a scrubbed launch, review boards assemble a timeline, trace causes and publish lessons. A newer habit moves that exercise earlier: before a mission flies, the team pretends it has already failed and writes the post-mortem in advance. The practice is usually called a pre-mortem, and in spaceflight planning it is quietly spreading from big agencies into small payload teams and student projects. Below: where the habit stands, what the evidence says, and a format a small team can borrow.
Why optimism is the default failure mode
Every mission plan is written by people who want it to succeed. That sounds harmless, yet it shapes what gets written down. Schedules assume that tests pass on the first attempt, that suppliers deliver on the date promised and that the launch window opens on time. Risks that feel embarrassing or vague tend to stay out of the document. The plan reads as a story with one ending.
Psychologists who study planning describe the same pattern in many fields: teams predict their own projects more cheerfully than they would predict a stranger’s. The pre-mortem is a counter-move built on a small trick of framing. Saying “the mission has failed, so what happened?” gives people permission to be specific and a little pessimistic. Nobody is being negative about the project; they are simply completing an assignment.
What the pre-mortem is, and what it is not
The mechanics are modest. Gather the people who touch the mission, from the engineers to the person who books the range time. State the premise plainly: it is some months from now and the mission did not achieve its goal. Give everyone a few quiet minutes to write down the reasons, then collect them without debate. Only afterward do you cluster the causes and decide which ones deserve action.
It differs from a risk register, which lists known hazards with owners, and from a design review, which asks only whether the design is correct. The pre-mortem hunts for hazards nobody listed, including people, procurement and paperwork.
What the failure stories tend to say
When teams run the exercise honestly, the imagined failures cluster in a few places, and very few are exotic. The common themes look like this.
- Interfaces between groups. A unit mismatch, a connector assumption or a software handoff that two teams each believed the other had verified.
- Schedule compression. A late delivery pushes testing into a smaller space, and the test that was cut turns out to have been the one that mattered.
- Orbit and timing assumptions. The chosen orbit shapes everything from communication windows to how long a spacecraft survives. A beginner’s grasp of a primer on low Earth orbit already hints at why: altitude changes lifetime, coverage and the number of passes available for contact.
- Single-person knowledge. The one engineer who understood the ground software goes on leave in the critical week.
- Paperwork and approvals. Licences, frequency coordination and range scheduling are slow, and slow things fail quietly.
- Software and its supply chain. Flight and ground code is assembled from many parts, and the build and delivery path is itself something that can fail or be tampered with.
That last item deserves a note, because space teams now borrow from ordinary software practice. A DevSecOps site such as DevSecOps Now keeps a blog on securing CI/CD pipelines, and a mission team reading it would recognise the concern: the code that reaches the spacecraft passes through a build chain, and that chain deserves its own imagined failure.
Worked example: a small satellite that never reached the plan
Consider an illustrative university team preparing a small satellite for a shared launch. In an ordinary planning meeting, the list of concerns is short: the radio, the battery, the deployment mechanism. In a pre-mortem, the written-down failures look different. One person imagines the satellite deployed perfectly but silent, because the ground station schedule never matched the passes. Another imagines a launch slot lost because the integration paperwork was filed a week late. A third imagines the team’s only flight-software builder graduating before the mission flew.
None of these is dramatic, and each one is cheap to prevent in week two. Book the ground station early, put the paperwork deadline on the wall and pair a second student with the software builder. The same ideas are far more expensive in month ten, which is the whole argument for doing the exercise early.
What the evidence supports, and what it does not
It is worth being honest about the evidence. The pre-mortem has a respectable theoretical basis, especially the finding that imagining an event as already having happened helps people generate more concrete reasons for it. In practice, though, most reports of its value are accounts from teams that adopted it rather than controlled comparisons. Treat it as a well-reasoned habit, not a guarantee.
It also has failure modes of its own: it becomes a ritual held once and never revisited, senior voices speak first, or the list grows long with no owner for the follow-up.
Running one for your own orbital project
The format scales down well. A club building a high-altitude balloon payload or a school team studying satellites can run it in an hour. A few suggestions keep it useful.
- Write the premise on the board. One sentence, with the goal named. For a communications-themed project, it helps to refresh the basics first; an easy walk through geostationary orbits is a fair reminder of why a satellite’s position dictates which antennas and delays you live with.
- Collect silently first. Cards or a shared document, one reason per card, no names required.
- Group by theme, then vote. Ask which three themes would hurt most and which are cheapest to address now.
- Attach an owner and a date to each chosen item. A concern without both is only a mood.
- Return to the list at milestones. Revisit it when the design freezes and again before shipping hardware.
If your project involves explaining orbital concepts to newcomers on the team, a refresher such as this overview of Earth orbit for new learners can level the room before the exercise starts. People who understand the basics write sharper failure stories.
The next few years of this practice
The trend favours earlier, smaller and more frequent versions. Rather than one grand review, teams run a quick imagined-failure session at each phase: concept, build, integration and launch campaign. The questions get more specific as the mission does, and the hit rate improves because each round feeds on the last.
The deeper lesson is cultural. A team that can say “here is how we might fail” in a normal meeting, without anyone feeling accused, is a team that will also say “I think I made a mistake” on a hard day. That habit is worth more than any single list. So before the next big milestone, set aside an hour, name the failure in advance and write down the reasons. The mission will still be hard, but fewer of its problems will be surprises.