Kickoff is a week out. The schedule is ready, the team is staffed, the sponsor has signed the charter. Everything looks the way a project that’s about to succeed is supposed to look.
At exactly this moment, before anyone has written a single line of code or sent the first email to the client, I sit down with the team for forty-five minutes and ask: “let’s say this project failed spectacularly. It’s six months from now, everything went wrong. What happened?”
Why I ask about failure before anyone’s had a chance to cause any
A standard risk list, drawn up at project start, has a weakness that rarely gets said out loud: it asks people about the future in the conditional. “What could go wrong?” assumes nothing has happened yet, so the answers come back careful, generic, and polite to everyone in the room. Nobody wants to be the person who announces, on day one, that the solution architect has a history of disappearing at critical moments.
The premortem flips the question by a hundred and eighty degrees. It doesn’t ask what could go wrong. It assumes it already has, and asks what happened. That small grammatical shift does something a standard risk list doesn’t: it lifts the burden of prediction off people and replaces it with the burden of describing something that supposedly already occurred. It’s easier to tell the story of a failure than to accuse someone of it in advance.
The technique was described by psychologist Gary Klein in “Performing a Project Premortem” (Harvard Business Review, September 2007), and its underlying mechanism is called prospective hindsight: imagining a future event as though it has already happened dramatically increases the number of reasons people can come up with for it — a finding that’s well documented in decision-making research, not just something I’ve noticed in the room.
What those forty-five minutes actually look like
You don’t need anything for this beyond a whiteboard, some index cards, and the team that will actually run the project — not just the leads.
The first five minutes are pure scene-setting. I say it plainly: the project is over, six months have passed, and it failed spectacularly. Not “a minor delay” — a failure someone might write up in an internal post-mortem afterward. Specificity in the scene makes a real difference: “something went wrong” produces generic answers, while “the project ran so far over budget that the board froze the next phase” produces concrete causes.
The next fifteen minutes are silence and index cards. Everyone writes down, alone, without comparing notes with their neighbor, as many reasons for the failure as they can think of. This step can’t be skipped or shortened, because the whole strength of the method sits in everyone thinking independently first, before hearing anyone else’s answers. A group that starts discussing out loud right away locks onto the first three ideas and stops looking further.
The following fifteen minutes are for gathering. Everyone reads their cards out loud, without judging in the moment whether a given reason is plausible. You group the similar ones, write down all of them, even the ones that sound like dark humor — the most uncomfortable answers are often the ones closest to the truth.
The last ten minutes are the only point where you filter. Out of the whole list, the group together picks three to five reasons that feel most real and that something can actually be done about, right now, before the start. The rest gets written down and set aside, not deleted.
What this actually surfaces in the room
Picture a team rolling out a system for a retail chain. During the premortem, someone writes on a card: “the project failed because the regional manager on the client’s side, who was supposed to support us during on-site testing, in reality never had the time for it, and nobody checked that before kickoff.” Nobody would write that on a standard risk list — it sounds like an accusation against a specific person. Framed as “this already happened,” it’s just a description of what took place, and that makes it easier to say.
The second thing that comes up regularly: technical risks and relationship risks end up mixed together in the same conversation, which standard risk workshops rarely do, because they sort them into separate categories. “It failed because the integration with the warehouse system turned out harder than we assumed” and “it failed because the sponsor lost interest after two months of silence” land on the same list, side by side, because from the vantage point of failure, both are equally true.
One honest note before you go
A premortem doesn’t prevent anything by itself. Naming a risk on a card doesn’t make it disappear, and a list drawn up at kickoff that nobody ever revisits is just a nicer-looking drawer to file it in. If you want the other half of this habit — what to actually do once a named risk materializes — that’s a different conversation, closer in spirit to a blameless post-mortem than to a pre-kickoff workshop.
The value of those forty-five minutes sits somewhere else: a handful of people on the team said things out loud that they normally wouldn’t say in front of anyone above them, and you, as the PM, heard them on day zero — not in the week they’re already coming true. What to do once one of the named risks actually materializes is a different conversation and a different habit, worth its own piece.
If you’ve got a kickoff coming up in the next few weeks, try this instead of the standard risk list. Ask the team exactly how this project failed spectacularly, and see who’s the first to put down their pen.
All situations described in this article are based on real events, but contain no company names, no individual names, and no data from any specific project.
