# The pre-mortem before go-live: a 30-minute meeting that gets clients to say what they are holding back > At the last meeting before go-live, everyone reports green. Change one question and the worries nobody wants to raise come out. Original: https://fdetimes.net/en/guides/pre-mortem-before-go-live/ Go-live is two weeks away. At the steering meeting, each person reports on their part: the integration works, the evals have cleared the threshold, the operations team has been trained. Nobody objects. But experience tells you that a meeting this smooth is usually missing something. Gary Klein, the psychologist who developed the pre-mortem method about 30 years earlier (as of 2021), explains the phenomenon bluntly. In meetings like these there is always an unspoken pressure: nobody wants to voice doubts for fear of disturbing the harmony of the group. For an FDE the pressure is greater, because two organisations sit at the same table, and nobody wants to be the one who makes the other side lose face. You stand between the two sides, so you are also the best-placed person to break that silence. The pre-mortem is the cheapest tool for the job. It requires no special authority, only the ability to run a meeting. ## One question changes how people talk Ask "where could this project go wrong?" and you usually get safe answers. A pre-mortem asks a different question. In Klein's description, the facilitator tells the group that the plan they have just discussed has failed, then has each person write down the reasons on their own. His 2007 article in Harvard Business Review turns on the same assumption: the project being planned has *just* failed. Wikipedia uses a medical comparison. A conventional plan critique asks what might happen to the patient. A pre-mortem assumes the patient has died and asks why. The technique draws on research into "prospective hindsight" by Mitchell, Russo and Pennington in 1989: standing in an imagined future and looking back. The cleverest part lies in the participants' incentives. Klein observes that once failure is treated as a given, people show how smart they are through the quality of the problems they raise. Naming a risk is no longer seen as a lack of faith in the project, but as a contribution. **Key point:** Once the project is treated as already failed, the person who names a risk becomes the clear-sighted one. ## Rehearsing a 30-minute session with a client Picture a scenario. You are deploying an LLM agent that triages insurance claims for an insurer. In the room are the client's sponsor, the head of operations, an IT engineer responsible for the core system, a claims handler and you. Klein reckons a session like this can take as little as 20-30 minutes. The script below keeps Klein's private writing and round-by-round turns. The last two steps, the vote and the hand-off, come from Atlassian's template and from the practice of the UK government's digital health team. **Minutes 0-3, the opening.** Read out the line you have prepared, word for word: "It is three months after go-live. The project has failed: the agent has been switched off and staff have gone back to doing the work by hand. Each of you, write down the reasons this happened." The line must be in the past tense and concrete. Say "suppose it might fail" and the effect is gone at once. **Minutes 3-8, write alone, no discussion.** Each person writes their own reasons. This silent step matters, because it keeps frontline staff from being swept along by the sponsor's view. The UK digital health team adds a step here: splitting the room into a "disaster team" and a "success team". With five people, you can ask one or two to write about the opposite scenario: three months on, the agent has succeeded. Why? Answers such as "claims handlers trusted the agent because they could see the reasoning behind each triage decision" tell you what must stay in scope and must not be cut when the schedule gets tight. **Minutes 8-20, go round the room.** Klein advises the facilitator to go first, candidly, to set an example, and for each person to give only one reason per turn. You might open with a weakness of your own: "My eval set was built from last year's claims, and this year's triage rules have changed." Then the claims handler might say that staff did not trust the agent, so they rechecked everything and no time was saved. The IT engineer might point out that the core system caps API calls at peak hours. Things like this are rarely said in an ordinary steering meeting. **Minutes 20-25, the vote.** The list is usually longer than you can deal with. The UK digital health team has everyone place dot votes to pick the three biggest risks and the three biggest opportunities. Do the same: the three risks become things to fix, the three opportunities become things to protect in the go-live plan. **Minutes 25-30, hand out the work.** Each of the top three risks must have an owner and a deadline. In the insurance scenario, that might look like this: you add 200 claims under the new rules to the eval set by Friday. The head of operations picks two staff to run a parallel trial for a week. The IT engineer confirms the API limit, and you add a queue. ## Templates exist, but adapt them to the client For large, multi-party projects, Atlassian's Team Playbook has a longer version ready to use: 3-11 people, about 60 minutes, with a silent brainstorm, a vote on the top risks and actions assigned with owners and deadlines. On the client side, two adjustments are needed. First, invite the real users, because the sponsor rarely knows where the agent will break in day-to-day work. Second, hold the session early, about two weeks before go-live, so there is time to fix things; a meeting the day before go-live only makes everyone more anxious. The lesson from the UK digital health team is that the value lies in action. Colin Pattinson writes that the meeting brought out risks nobody had anticipated, and the team was able to deal with several of them in time. In his view, a pre-mortem forces you to face problems before they wreck the project later. ## The mistakes that turn a pre-mortem into a complaints session The most common mistake is saying "might fail" instead of "has failed". It is a small change in wording, but listeners slip back into a defensive stance and you get safe answers again. The second is letting the most senior person go first with a harmless reason, such as "maybe we were short of time". Klein wants the facilitator to go first so the room dares to speak plainly too. A harmless reason in the first turn sends the opposite signal: keep it gentle here. So agree with the sponsor beforehand that the first reason must be something genuinely uncomfortable, or go first yourself. The third mistake is ending the meeting with 30 risks and no owners. A list without owners and deadlines is only a record of everyone's worries. The last mistake is inviting only your own team. Then you hear only the risks you already knew about. ## Turning the meeting into evidence on your CV If the FDE job descriptions you are targeting mention working with stakeholders or managing risk, a pre-mortem you have facilitated is good evidence of that ability. But only if you can say what it changed. Go back to the insurance scenario. A weak CV line would be "Organised a pre-mortem before go-live". A strong one says who took part, what was found and what was fixed: "Facilitated a pre-mortem with 4 client stakeholders two weeks before go-live; uncovered evals out of step with new rules and a peak-hour API limit on the core system, and resolved both before launch." In interviews, "tell me about a time you prevented an incident" is the place for the detail. Give the opening line you used, the claims handler's reason the sponsor had never heard, and the parallel trial that followed. Interviewers want to see that you go looking for problems, not just fight fires after they break out. The next time a steering meeting goes suspiciously smoothly, you need not argue with anyone. Just ask the room: if the agent has been switched off three months from now, why do you think it happened? **Try this week:** - Pick a deployment that is about to go live, book 30 minutes with the client, and invite frontline users, not just the sponsor - Write out the opening line ('It is three months after go-live, and the project has failed') and practise saying it aloud once before the meeting - Open with a real reason for failure that sits in your own part of the work, so everyone sees it is safe to speak plainly ## Sources - [The Pre-Mortem Method: A practical way to do risk assessment (Gary Klein, Psychology Today)](https://www.psychologytoday.com/ie/blog/seeing-what-others-dont/202101/the-pre-mortem-method) - [Performing a Project Premortem (Harvard Business Review)](https://hbr.org/2007/09/performing-a-project-premortem) - [Pre-mortem (Wikipedia)](https://en.wikipedia.org/wiki/Pre-mortem) - [How to Run Pre-Mortem Exercises [Templates Included] | Atlassian](https://www.atlassian.com/team-playbook/plays/pre-mortem) - [Pre-mortems: identifying opportunities and risks (Colin Pattinson, Digital Health and Social Care blog)](https://digitalhealth.blog.gov.uk/2018/09/20/pre-mortem-identifying-opportunities-and-risks/) - [Pre-mortems: identifying opportunities and risks (Colin Pattinson, Digital Health and Social Care blog)](https://digitalhealth.blog.gov.uk/2018/09/20/pre-mortems-identifying-opportunities-and-risks/)