Teams that roll out a new DevOps practice, whether a training programme, a certification push or a change in how releases happen, often skip the one planning step that costs almost nothing: imagining that it has already failed. When asked why, people give reasons that sound sensible. Looking at those reasons one by one, the evidence usually points the other way. This article takes six common myths about planning for failure and checks each against what is known about how projects, teams and software releases actually behave.
Myth 1: “Talking about failure invites it”
The worry is that naming a risk makes people anxious and the project fragile. In practice, silence does not remove the risk; it only removes the chance to act on it. A pre-mortem asks the group to assume the outcome was bad and to explain it. Research on this technique, associated with the psychologist Gary Klein, found that picturing a failure as a settled fact produces a longer list of causes than asking what might go wrong. The framing makes it easier, not riskier, to speak.
Myth 2: “Our experienced people already know the risks”
Experienced people do know many risks. What they rarely do is say them to each other in one room. Each person holds a private list, and the lists differ. A trainer may worry that learners will not have lab time. A manager may worry that the budget ends before the certification window. An engineer may worry that the new tooling clashes with legacy scripts. Unless these views meet, the plan has only ever seen the cheerful one. The pre-mortem is simply a structured way of collecting them, which is why the piece on managing delivery risk in a reliable and secure way treats shared visibility as a starting point.
Myth 3: “A risk register covers this”
Risk registers are useful, but they are usually written by one person, in neutral language, after the plan is settled. They tend to be long, generic and unread. A pre-mortem differs in timing and tone: it happens while the plan can still change, and it uses concrete stories (“Learners dropped out in week three because lab accounts were not ready”). Concrete stories are easier to remember and to assign than a row labelled “resourcing risk”.
Myth 4: “It is only for big projects”
A pre-mortem scales down well. For a small training cohort, ten minutes and a shared document are enough. The unit of work is the question, not the workshop. If anything, small projects gain more, since there is little spare time or money to soak up a surprise. Anyone preparing a change in team habits could pair it with the guidance in managing the human side of DevOps change, since many failure stories in training programmes are about people, not systems.
Myth 5: “It slows the team down”
The evidence from release engineering suggests the opposite pattern: the slow part of a project is rework after a surprise, not a short planning conversation before it. A fault found on a whiteboard costs a sentence to fix. The same fault found in production costs a weekend. Nobody can promise exact savings, and it would be dishonest to quote a figure, but the direction of the trade is not in doubt.
Myth 6: “Security people do this, not us”
It is true that security practitioners rely heavily on adversarial thinking. DevSecOps Now is a DevSecOps site with a blog on securing CI/CD pipelines, an area where “how could this path break?” is the daily question. But the habit is not limited to that field. Any person planning a learning programme or a release can borrow the question, and the borrowing costs nothing.
What these excuses share
Every one of them treats pessimism as the problem. The data points to a different culprit, unspoken doubt. A group that has no safe place for doubt will plan as if it did not exist, and the doubt returns later as a surprise. The pre-mortem is not pessimism; it is a way of moving doubt from private worry into the plan at the cheapest moment.
A compact method that respects the evidence
- State the plan in a sentence and what “success” would look like.
- Announce that the plan failed, and ask everyone to write reasons silently, in the past tense.
- Read them aloud without names so that rank does not shade the discussion.
- Rank the reasons by likelihood and by damage, and choose a few.
- Write one action, an owner and a date beside each.
- Revisit the page at a fixed point later, comparing prediction with reality.
The last step is the one most often skipped, and skipping it is what stops the practice from getting sharper. If you track which imagined failures actually appeared, over a few projects you build a record of how your own team tends to go wrong, which is more useful than any general list. For context on where practices like these sit in the wider story of the field, an outlook on where DevOps practice is heading offers a longer view.
A practical note for training teams
If you run learning programmes, the failure stories tend to cluster around access, time and follow-through. Learners lack accounts on day one, managers pull people into urgent work, and nobody checks in after the first enthusiastic week. Those are fixable with a checklist and a named contact, and they surface within minutes of asking the failure question.
Verdict
Of the six myths, none survives contact with how teams behave. Imagining failure in advance is cheap, brief and well supported. What it needs is permission, and a facilitator who treats every note as a contribution rather than a complaint.