Pre-Mortem Cadence: Planning the Week Around Where Work Will Break
Most execution rhythms are built around looking backward and forward in familiar ways. Teams review what shipped, plan what comes next, and check whether commitments are on track. What they rarely do is ask, in a structured way, where the next week is most likely to fail. A pre-mortem flips the usual question. Instead of assuming the plan will hold and reacting when it doesn't, the team imagines that a deliverable has already slipped and works backward to find the reasons. This article describes how to run that exercise as a short, repeatable part of a weekly rhythm, without adding a heavy meeting or new tooling. It is a general working method. Your team should adapt it to its own size, stage, and workflow.
Why a Pre-Mortem Fits Into an Existing Rhythm
A pre-mortem is a planning technique in which a group assumes that a future outcome has already gone wrong and then explains, in concrete terms, how that happened. The value comes from the framing. People are often reluctant to voice doubts about a plan in an open discussion, because raising risk can feel like negativity or disloyalty to the schedule. When the scenario is that the launch has already slipped, naming the causes feels like analysis rather than complaint.
For busy teams, the trick is to attach the exercise to something that already happens. Most teams have some form of weekly planning, a standup, or a status review. A pre-mortem can take ten to fifteen minutes at the end of planning, before the week's priorities are locked. It doesn't need its own calendar slot or a separate document. The output is a short list of likely failure points that the week's plan then has to account for.
Running the Exercise in Fifteen Minutes
Start by listing the three to five commitments that matter most for the coming week. These should be the items that would visibly hurt if they slipped: a release, a client deliverable, a decision that unblocks others. Keep the list short. A pre-mortem over forty items produces forty shallow answers.
Next, state the assumption of failure out loud. A useful phrasing is: it is Friday afternoon, and this item did not ship. Ask each person to write down, privately and for one minute, the first reason that comes to mind. Then collect the reasons on a shared surface and group them. Typical categories include waiting on an input from another person, an estimate that was too optimistic, a dependency nobody confirmed, a review step that was not scheduled, or competing work that pulled attention away.
Finally, convert the most plausible reasons into one concrete action each. A vague note such as 'design might be late' is not an action. 'Confirm with design by Tuesday that the asset review slot is booked' is. Assign an owner to each action and record it wherever the team tracks commitments. Limit yourself to the two or three reasons that seem both likely and costly, so the output remains manageable.
Questions Worth Asking During the Exercise
The quality of a pre-mortem depends on the questions. Several prompts tend to surface useful answers. Which item on this list depends on someone who has not yet confirmed they can deliver? Which estimate was made by someone who will not be the person doing the work? What would have to be true about another team's schedule for this to succeed, and do we know it is true? Which step is most often skipped when we are rushed, such as testing, legal review, or handoff documentation?
It also helps to ask what would be the first visible sign of trouble. If the answer is 'we would notice on the due date,' the team has a monitoring gap. Pairing each risk with an early signal, such as a card that has not moved in several days or a reply that has not arrived, makes the risk easier to catch before it becomes a missed date. The point is not to predict every problem. It is to make the most likely ones visible while there is still time to act.
A Checklist for the First Few Weeks
If your team is new to this practice, a simple checklist keeps the first attempts consistent. Before the session, confirm that the list of commitments contains no more than five items and that each has a named owner. During the session, make sure every person has a chance to write a reason before discussion begins, so that louder voices do not anchor the group. After the session, verify that each selected reason has a corresponding action, that the action has an owner and a date, and that the actions are recorded where the team will see them during the week.
At the end of the week, briefly review which predicted failures actually occurred. You are not grading the team. You are calibrating. If the same category of risk appears every week, such as unconfirmed dependencies, the cause is probably structural and deserves a permanent fix, like a standing check with the other team. If the predicted risks rarely materialize, the list may be too cautious or the questions too generic, and the prompts should be sharpened.
Teams should also be realistic about limits. A pre-mortem does not eliminate surprises, and it will not catch every failure. It is one lightweight habit among several in an execution rhythm, and it works best when people trust that raising a concern will be met with a plan rather than blame. Leaders who want the practice to last should model it by naming their own likely failure points first.