Quantum computing attracts large amounts of optimism, and optimism is a poor guide to planning. A company starts a quantum computing project because the idea is exciting, a few experiments run, and then the work stalls for reasons that were visible from the start. A pre-mortem is a plain way to see those reasons early. You imagine the project has ended without results and ask why. This explainer uses ordinary language to show how the exercise works for a quantum computing effort, and why emerging technology needs it more than most.
Why emerging technology fails in predictable ways
When a field is young, nobody has a long record of what normally goes wrong. That makes teams rely on stories from announcements, which mostly describe successes. A pre-mortem corrects the imbalance. Instead of asking “what is the best outcome?”, it asks “what is the most ordinary way this could end badly?”, and ordinary failures are shared across technologies: unclear goals, missing skills and unrealistic timing.
A quick plain-language picture of the technology
A classical computer stores bits that are either zero or one. A quantum computer uses quantum bits, or qubits, whose behaviour lets some calculations be organised in ways classical machines cannot easily match. The word “some” matters. Quantum machines are not faster at everything, and today’s devices are sensitive to noise, which limits how long and how reliably they can compute. Keeping these basics in mind is the first defence against disappointment.
Imagining the failure: six stories
Suppose a team has spent a year on a quantum initiative, and the result is a shrug. Here are the likely reasons, each with a plain remedy.
The problem never needed a quantum machine
The team picked a task because it sounded suitable, then discovered a well-tuned classical method solved it well enough. Remedy: before building anything, write down the best classical approach and its results. The quantum attempt must beat that line or at least offer a clear reason for trying. A good primer on where the technology could help is the article on how quantum methods tackle tough optimisation tasks.
The goal was a headline, not a question
“Be quantum-ready” sounds like a goal but names no result. Remedy: phrase the work as a question that could be answered either way, such as “does this approach produce better solutions on this kind of dataset?”
The hardware was noisier than the plan assumed
Early plans often presume stable results. Real devices return noisy output, so experiments need repetition and careful interpretation. Remedy: budget time for repeated runs, and plan on simulators for development.
Only one person understood the work
Quantum skills are scarce, and a single expert’s departure can end a project. Remedy: pair people, write short notes, and make sure at least two people can explain the current state to a newcomer.
Expectations outran evidence
Managers read a headline about quantum machines breaking locks or transforming learning and assume results are imminent. Articles such as the one on what quantum computing may mean for machine learning are best read as directions of research, not delivery dates. Remedy: tell sponsors in writing what you expect to learn each quarter and what you do not expect.
Nobody planned for the security timeline
Parts of the quantum story touch on cryptography. The piece on why Shor’s algorithm worries people who rely on today’s encryption explains the concern in simple terms. A pre-mortem question here is organisational: if the concern became real sooner than hoped, who in your company would own the response, and do they know it? Keep the discussion conceptual; the aim is clear ownership, not technical detail.
Why the comparison matters so much
Of the six stories, the first is the one that most often ends projects quietly. If nobody wrote down the classical result at the start, nobody can say later whether the quantum attempt was an improvement, a tie or a loss. Keep that baseline in a document everyone can see, and update it whenever the classical side gets better. Teams occasionally find that the act of building a strong classical baseline solves the original business problem on its own, which is a happy outcome even if it is not the one the project was named for.
Borrowing a habit from delivery security
The thinking above is common among people who protect software delivery. DevSecOps Now covers DevSecOps topics and its blog looks at securing CI/CD pipelines; its readers constantly ask where an automated path could fail. A quantum team can apply the same question to its experiment pipeline, from data preparation to result review.
How to run the session
- State the project’s question in one sentence.
- Declare that a year has passed with no useful result.
- Have each person list reasons silently for five minutes.
- Group them, then choose the three most likely and most costly.
- Attach an action, a person and a date to each one.
- Re-read the page at the halfway point.
What success looks like
A good outcome is modest. The team knows what it is trying to learn, has a classical baseline for comparison, shares knowledge between at least two people and reports honestly to its sponsors. The project might still conclude that quantum methods are not yet useful for the problem, and that is a valid and valuable result, because it is a result.
The pre-mortem protects exactly that kind of honesty. In a field where excitement is high and evidence is still accumulating, the most useful thing a team can do is plan for the unremarkable ways it might fail, and fix them while they are still small.
