I’m Krzysztof Nyrek
a Project Manager Storyteller Writer

The Premortem: Naming What Could Kill Your Project Before It Starts

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.

Your Client’s ‘Done’ Is Not Your Team’s ‘Done’

The invoice went out on Friday, the same day the team closed the last item in Phase 2’s scope. Per the contract: the reporting module delivered, acceptance tests passed, status green.

On Tuesday, one sentence came back from the client: “this isn’t what was supposed to be built, we can’t use it.”

Both sides were right. That’s the part that’s hardest to explain to anyone who wasn’t in the room.

Two different kinds of “done,” and neither one is fake

It’s worth separating this from what usually gets discussed under Definition of Done. That argument happens inside a team, between a developer and a PM, about whether a card on the board really meets the criteria written on it. It’s a dispute over a shared vocabulary.

This is something else. The delivery team’s “done” is defined by a document: the scope in the contract, the functional spec, the acceptance criteria signed off at the start of the phase. The client’s “done” is defined by something no document ever covers — a picture of how their business will run once all of this actually works. That picture formed months earlier, during the sales conversation, in a sentence like “and then our accounting team won’t have to retype all of this by hand anymore.” Nobody wrote that sentence into the spec, because it sounded like an obvious given, not a requirement. This is the same gap that makes scope and product value pull in different directions if nobody names it early.

So when the reporting module lands exactly as specified, and accounting still has to retype something by hand because the export comes out in a format nobody pinned down, the vendor is right about the letter of the contract. The client is right about the entire reason they ordered it in the first place.

This dispute only ever explodes at the contract boundary, never before

Inside a project, among people who talk to each other every day, a mismatch in definitions surfaces early and cheaply, because someone asks about it at standup or during a sprint review. At the contract boundary, between two organizations, something different happens: for weeks or months, both sides communicate through documents, status reports, and emails rather than direct working conversation. The gap doesn’t surface, because nobody has a natural moment to check for it — until the moment something is actually supposed to happen: sign-off, payment, go-live.

That’s why this problem always detonates in the same place: at the end of a phase, at the invoice, at the signature on the acceptance protocol. Not because nobody noticed the difference earlier. Because until that moment, nobody had to name it — both sides could go on living with their own, separate version of what was being built.

Who on the client’s side even gets to say “done”

There’s a second thing that sets this apart from the internal team version of the dispute: on the client’s side, “done” is almost never one person’s opinion. The sponsor who signs the acceptance protocol may be satisfied, because they see the contracted scope delivered. The team that actually has to use the thing day to day may be furious, because nobody asked them whether it works the way they need it to.

Picture a service-ticket system rollout. The client’s sponsor accepts the project because the system does exactly what the spec said: intakes tickets, assigns them to technicians, generates a monthly report. A month later it turns out the field technicians are still calling the dispatcher directly, because the mobile app is too slow on weak signal — a condition nobody tested for, because the spec said “mobile access,” not “mobile access on weak signal in the field.” The protocol is signed, the invoice is paid, and the project is still considered a failure inside the client’s company, because the people who were supposed to benefit from it are loudly saying nothing has changed.

To the vendor, this looks unfair — they formally did what they were asked to do. To the client, this looks like confirmation that the vendor delivered a document, not a solution.

What I do to have this conversation earlier, not at invoice time

There’s one thing I now build into every major phase before work even starts: I ask the client for one sentence, written in future tense, describing the day after go-live from the point of view of the person who will actually use the thing — not from the sponsor’s point of view. Not “ticket system deployed,” but “a field technician reports an issue from their phone and sees confirmation within a minute, even on weak signal.”

That sentence almost always surfaces something no document had, because it forces the sponsor to go talk to someone who’ll actually use it, before that conversation happens anyway, in a much worse moment.

The second thing: at phase acceptance, instead of asking “does this meet the spec,” I ask “who specifically on your side should test this before we sign the protocol, and has that person already seen it.” If the answer is that they haven’t, that’s exactly the moment to push the signature out by a week, instead of pushing the whole relationship out by a quarter once the problem surfaces on its own.

One honest note before you go

This doesn’t close the gap between sales and delivery down to zero. Some of what a client imagined during the sales conversation genuinely can’t be predicted until the product is actually running in their day-to-day reality.

What it does is lower the cost of the moment the gap surfaces. A conversation about what’s missing, held a week before the protocol is signed, is cheaper than the same conversation held a month after the invoice, when one side feels cheated and the other feels unfairly judged.

Try it at your next phase acceptance. Before anyone signs the protocol, ask who’s actually going to use this — and whether that person has already seen it with their own eyes.

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.

The Silent Two Weeks: What ‘On Track’ Status Reports Are Hiding

Six weeks in a row, the project status looked exactly the same. Green, no risks worth a mention, nothing for leadership to worry about. In week seven, on the review call, someone said the deadline was slipping by a month.

Here’s the unsettling part: nobody had lied. Every one of those six statuses was honest at the moment it was written.

A green status isn’t a lie. It’s a snapshot.

A project status is a photograph taken on a single day, not a forecast. It tells you how the work looks today, at the exact moment someone hit “save” — not the trajectory the work is actually on. A team can be running at full speed, hitting every sprint commitment, and still be heading straight into a wall, because the problem was never in what got done. It was in what nobody had checked yet.

Picture an integration project with three teams working in parallel: frontend, backend, and a client-side team responsible for the input data. Each one reports green, because each one is delivering what it committed to this sprint. Nobody reports that the data coming from the client — the data everything else depends on — is still sitting in a format from two years ago, and nobody has checked whether it will even map cleanly. That’s not a risk that belongs to any one of the three teams. It belongs to all of them, which in practice means it belongs to none of them.

Debt builds in the places a status report isn’t allowed to look

A status report tracks tasks, not assumptions. The most expensive problems in a project almost always live in the assumptions:

• the integration will behave the way the vendor’s documentation says it will,
• the client will deliver the data on time,
• the one person who understands the legacy system will still be reachable when questions come up.

None of these assumptions has a row in the task tracker, so none of them can turn red until somebody deliberately writes it down as a risk.

This is the actual mechanism that keeps a “green” status alive longer than it should. Raising a risk feels like admitting something is wrong, and nobody wants to be the person who kills the good mood in the room, especially while the problem is still theoretical. It’s easier to say “we’re keeping an eye on it” than “this could cost us three weeks,” because the second sentence will need explaining later, and the first one commits to nothing. If you want a structured way to have that harder conversation instead of avoiding it, that’s exactly the gap this practical guide to communicating project issues is built to close.

So the risk waits. Not because someone is hiding it, but because the threshold for “serious enough to mention” sits higher than the threshold at which it actually starts threatening the deadline.

Two weeks isn’t a coincidence. It’s the typical response time.

Across most projects I’ve taken over mid-flight, the pattern looks similar: from the moment a problem becomes visible to the person closest to the work, to the moment it shows up on a status report in a form the sponsor can actually understand, roughly two weeks pass. Sometimes shorter, sometimes longer, but the order of magnitude repeats, because the mechanism is the same every time.

First, someone on the team notices something is off and mentions it in half a sentence during standup, which gets buried under the next three topics. A week later, the same thing comes back as a question to the PM in the hallway. Only once the problem is solid enough that it can no longer be closed with one sentence does it reach the official status — and at that point it looks like it happened in a week, because for the sponsor, it did. For the team, it had already been alive for two weeks, in conversations the PM either never heard or heard and never translated to project scale.

What I check instead of asking “are we on track”

I stopped asking “are we on track” at status meetings. That question only has one comfortable answer, and everyone in the room knows it.

Instead, I ask: “what would have to happen in the next two weeks for us to go off track?” That question assumes such a thing exists, so the answer “nothing” becomes a sentence someone has to consciously say out loud, not a default shrug. People start listing things they’d previously only discussed among themselves: an untested component from an external vendor, a person out on leave nobody has backfilled, data that was supposed to arrive last week and still hasn’t.

The second thing I do is even simpler. When someone drops a half-sentence at standup like “well, we’ll see how that works for the client,” I write it down as something to check, not as a comment to forget. Most of those sentences never turn into anything. The ones that do almost always showed up first in exactly this shape: half a joke, on the margins, two weeks before anyone named it a risk out loud.

One honest note before you go

This isn’t a method that eliminates surprises. Projects will keep drifting, because some things genuinely can’t be predicted more than two weeks before they happen.

What it does change is one thing, and that’s enough to make it worth doing: it shortens the distance between the moment someone on the team already knows something is wrong and the moment you find out. Two weeks of difference is, in practice, the difference between quietly adding a week of buffer and explaining a month of delay to a sponsor at a meeting you had nothing ready for.

Try it at your next status. Instead of asking whether it’s green, ask what would have to happen for it to stop being green.

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.