You have a go-live date for a migration, a new CI pipeline or the first release of a service, and the team feels good. This is the right moment for a one-hour exercise that most teams skip: a pre-mortem. The goal is to assume the project failed, then find out why while changes are still cheap. This how-to takes you through preparation, facilitation and follow-up in order, so you can run your first session next week without special tools. It suits students building lab projects and working engineers alike.<\/p>\n
Pick something with a real deadline and real consequences: a migration, a pipeline rebuild, a team’s first on-call rotation. Hold the session when the plan exists but is still flexible, ideally a few weeks before the critical date. If the plan is already frozen and deployed, the exercise turns into a post-mortem.<\/p>\n
Aim for five to eight participants who see different parts of the work: developers, operations, a tester, someone from support, and ideally a person who will consume the result. If you are a learner on a team project, include whoever will review or use what you build. Diverse views matter more than seniority.<\/p>\n
Put it where everyone can see it. For example: “It is two months after go-live. The migration has been rolled back and customers are unhappy.” Make it concrete and a little dramatic; vague premises produce vague notes. Avoid blaming language such as “because the team failed.” The premise describes the outcome only.<\/p>\n
Give everyone eight minutes with cards or a shared document. One cause per card. Encourage specifics, such as “the database backup restore was never timed” instead of “data problems.” Silence is important at this stage, because it prevents the most confident voice from steering the list.<\/p>\n
Go round the group, each person reading one card at a time, and stack similar ones together. Clusters usually reveal themselves: environments, access, knowledge, timing, communication, delivery path. Name each cluster in a few words. Repeated notes show where the team’s shared worry sits, even when nobody had mentioned it aloud before.<\/p>\n
If your project involves shipping code, make sure at least one cluster addresses how changes travel from commit to production. This is a place where assumptions pile up: credentials stored in convenient places, build steps nobody has reviewed, dependencies pulled in automatically. The blog on DevSecOps Now<\/a> is devoted to securing CI\/CD pipelines, so a few minutes on it before the session can help the group ask sharper questions. Keep the session conceptual: you are looking for unexamined links, not designing defences on the spot.<\/p>\n Ask each person to place three votes on the clusters they consider most dangerous. Then ask a second question: which of these are cheapest to address right now? The overlap of “dangerous” and “cheap to fix” is your first action list. For high-cost, low-likelihood items, decide whether a safeguard is warranted or whether you accept the risk and write that down.<\/p>\n For each chosen cluster, write an action in the form “who does what by when.” Examples:<\/p>\n If an action has no name and no date, it is not an action. Resist the urge to produce a long list; five to eight items are plenty.<\/p>\n Actions should end up in the same place as other project tasks, whether that is a tracker, a board or a document. Findings that live only in the notes of the meeting fade within days. A longer strategy read, such as this piece on a skills roadmap behind organisation-wide IT change<\/a>, can help you place these actions in a larger plan, particularly if your project is one stage of a long change effort.<\/p>\n Schedule a fifteen-minute check at each milestone. Which imagined failures are now more likely? Which have faded? What new ones appeared? Over time, you will see which kinds of notes tend to come true in your organisation and adjust your attention accordingly. That local knowledge improves every subsequent session.<\/p>\n For learners, the pre-mortem builds a habit that interviewers and managers value: reasoning about failure before it happens. It sharpens your problem-solving, because every imagined failure needs a causal chain. If you want to deepen that skill, an article on developing critical thinking for technical problem solving<\/a> complements the exercise nicely. And a look at the gaps students commonly need to fill<\/a> gives you prompts for the knowledge column of your list.<\/p>\n Print this and bring it along: the premise, the date, the participants, the clusters with vote counts, the chosen actions with owners and due dates, and the date of the next check. Keeping it to a single page makes it easy to share and hard to ignore.<\/p>\n Run the session once on a small project, learn what works in your team, and adapt the steps. The format is simple enough that the main variable is honesty. Teams that are willing to say, in a calm room, how their plan could fall apart usually find that it holds up much better when the real date arrives.<\/p>\n","protected":false},"excerpt":{"rendered":" A ten-step walkthrough for running a pre-mortem on a migration, pipeline rebuild or first release: invite, imagine failure, cluster, rank, assign and revisit.<\/p>\n","protected":false},"author":5,"featured_media":1960,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[486],"tags":[],"class_list":["post-1959","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops"],"_links":{"self":[{"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/posts\/1959","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/comments?post=1959"}],"version-history":[{"count":1,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/posts\/1959\/revisions"}],"predecessor-version":[{"id":2030,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/posts\/1959\/revisions\/2030"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/media\/1960"}],"wp:attachment":[{"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/media?parent=1959"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/categories?post=1959"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/tags?post=1959"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Step 7: Rank by likelihood and cost<\/h2>\n
Step 8: Turn clusters into actions<\/h2>\n
\n
Step 9: Link the findings to your plan<\/h2>\n
Step 10: Revisit at milestones<\/h2>\n
Skills the exercise quietly builds<\/h2>\n
Troubleshooting the session<\/h2>\n
\n
A one-page template<\/h2>\n