Hospital administrators rarely lose sleep over the glamorous parts of a project. What goes wrong is usually mundane: a form that asks for the wrong thing, a callback that never happens, a rule nobody told the front desk about. A heart surgery pre-mortem is a short, structured exercise for catching those problems early. Before a new online appointment-request process goes live, the team imagines that it has already failed, writes down why, and then fixes the likeliest causes while that is still cheap. This post uses a question-and-answer format to walk through how to run one for a purely administrative change. It is informational and says nothing about clinical care.
What exactly is a pre-mortem, and how is it different from a risk register?
A risk register asks people what might go wrong, and people answer politely and briefly. A pre-mortem changes the premise. You tell the room that six months have passed, the new enquiry process has been quietly withdrawn, and everyone is embarrassed. Now the question is not “what could happen?” but “what happened?” That shift in tense gives colleagues permission to say the unflattering things they were already thinking. The front-desk lead admits the form is too long. The billing clerk points out that nobody agreed who answers evening messages.
The result is usually longer and blunter than a register. It is also easier to rank, because each item reads like a story with a cause and a consequence rather than an abstract hazard label.
Which administrative changes deserve one?
Anything that changes what a worried family experiences before they ever meet a clinician. Typical candidates for a cardiac centre include a new online page for requesting a consultation slot, a revised process for sending records ahead of a visit, a new way of confirming appointments by message, or a change in how out-of-town visitors are given directions and arrival instructions. Each of these is small enough to seem safe, and that is exactly why the optimism runs unchecked.
Who should be in the room?
Include those who will operate the process day to day: reception staff, the call-centre or enquiry desk, whoever handles records, a representative from billing, and someone from the IT or web team. If you can, invite a person who is not close to the project and have them play the sceptical patient relative. Aim for six to nine people so nobody can hide. One facilitator keeps time and writes; nobody defends the plan during the session.
How do you actually run the session?
- State the failure plainly. Write one sentence on the board, such as “The new request process has been rolled back because families found it confusing and staff stopped trusting it.”
- Silent writing first. Give everyone five minutes to jot down reasons, one per note, without talking. This stops the most senior voice from setting the agenda.
- Read out and cluster. Group similar notes. Themes tend to appear fast: unclear wording, missing hand-offs, timing gaps, data that does not travel between systems.
- Vote on likelihood and damage. Each person marks the causes they think are most probable and most painful. Do not argue the votes.
- Convert the top causes into actions. Every top cause needs a concrete countermeasure, a named person and a review date before the meeting ends.
What failure causes show up again and again?
Four families of cause appear in most hospital administration pre-mortems. The first is wording. A field labelled “reason for visit” invites a paragraph of worry, while the desk only needed a short category. A form that mixes administrative questions with sensitive details leaves families unsure what is safe to type and what should wait for a conversation with the care team.
The second is hand-offs. An online request lands in an inbox that one person monitors, and that person is on leave. Nothing in the process says what happens to a request that sits unanswered, so it simply sits. Families interpret silence as indifference.
The third is timing. A promised response window is shorter than the desk can honestly meet, or the confirmation message goes out before a slot is actually held. Either way, families are told one thing and experience another, and complaints start in that distance.
The fourth is parallel systems. The paper register, the spreadsheet and the new web form all hold slightly different versions of the same family’s details. Somebody retypes entries between them, and the retyping is where errors creep in.
Can you give a worked example in a heart centre setting?
Imagine the centre introduces an online page for families to ask about a first consultation. In the imagined failure story, three things went wrong. Relatives abroad could not tell which time zone the callback window referred to, so they missed the call and assumed nobody had phoned. The page offered no way to say that a translator would be needed, so staff discovered the language gap only on the day. And the page confirmed receipt in friendly language that sounded like confirmation of a booking, so a few families arrived without a slot.
Each of those points converts neatly into a countermeasure: state the time zone in the callback message, add a single optional language field, and rewrite the confirmation so it clearly says “request received, a coordinator will contact you.” None of this needed new software; it needed someone to imagine the failure first.
Where do technology and security fit in?
Any process that moves patient-related details through a website or message platform has a technical side, and a pre-mortem should include someone who can speak to it. Typical imagined failures here are access permissions that were left too broad during testing, a connector between the web form and the records system that breaks silently after an update, or credentials that were shared in a hurry and never changed. These are the same families of problem that software teams discuss when they harden their release pipelines. Readers who want a general feel for that discipline can browse the DevSecOps blog covering CI/CD pipeline security for ideas; the habits translate loosely to hospital web teams even though the settings are different.
How do you keep the pre-mortem from becoming a gloom session?
Time-box it. Forty-five minutes for the imagining, fifteen for the actions. Insist that every worry ends in a countermeasure or a decision to accept it, so the room does not leave feeling heavier than it came in. Celebrate what the exercise found: a single paragraph rewrite that prevents a week of confused calls is a genuine saving.
It also helps to make the exercise routine rather than exceptional. Teams that run one for every patient-facing change, however small, soon find that colleagues stop treating it as criticism and start treating it as quality control.
Why does the first contact matter so much?
Administrative clarity does not stand alone. Families researching a heart centre often read about emergency cardiac surgery hospitals and the support offered afterwards and about telehealth-supported follow-up after cardiac surgery. If the enquiry process at the start is muddled, the careful information on those pages never gets a chance to help. A smooth first contact is the foundation that the later material rests on.
What should you do after the session?
Circulate the one-page list within a day while memories are fresh. Pilot the countermeasures with a handful of real requests and ask the desk what they noticed. Then schedule a short follow-up, about a month after launch, to compare the imagined failures with the actual ones. You will probably find that some of the predictions were wrong and a few unpredicted problems appeared, which is fine; the aim was never prophecy. The aim was to swap a vague sense of confidence for a specific, shared list of things to watch.
Run honestly, a pre-mortem costs one meeting and a stack of sticky notes. It protects families from avoidable confusion at a stressful moment, and it protects staff from defending a process they quietly knew was shaky.