“Who decided to go with that supplier?” In a review of a project that ended badly, this question is one of the first to be asked. Someone raises a hand or looks down, and from that moment the conversation is about the person, not about the decision.
Meanwhile the decision may have been a good one. The supplier had the best references, the shortest lead time and a sensible price. Six months later they lost two key people and the delivery fell apart. On the day of the choice nobody knew that, including the supplier.
The outcome is not the same thing as the decision
Two things make up an outcome: the quality of the decision, and what happened afterwards that nobody had any influence over. A good decision can end badly. A bad decision can end well, because it just happened to work out.
Psychology has a name for this: outcome bias. Knowing the ending, we judge the decision through that ending and stop remembering how much was known at the moment of the choice. After the fact everything looks obvious. “It was clear that company was too small.” On the day of the decision it wasn’t clear, it was one of five risks on the list.
In projects this bias is especially expensive, because reviews happen mainly when something has gone wrong. A project that succeeded rarely gets taken apart. As a result, bad decisions with a lucky ending pass unnoticed, and good decisions with an unlucky ending get labelled as mistakes.
What the team learns from a review like that
People draw a conclusion quickly, just not the one that was intended. Instead of “make better decisions” they hear “don’t make decisions you can get blamed for”.
The effects show up in the next projects. The biggest supplier gets chosen, even if it is the worse one, because nobody will question that choice. Every decision gets three signatures so that responsibility is spread thin. The risks that were worth taking disappear from the plan, and with them goes the chance of anything better than an average result.
The other side is just as costly. A PM who got away with a bad decision is praised and repeats the same move in the next project. This time the luck may run out.
How to review decisions instead of outcomes
The point is not to stop holding anyone accountable for anything. The point is to hold people accountable for what they had influence over. In practice four things help.
Write the decision down on the day it is made. Three lines: what we chose, what we knew, which options were dropped and why. Without that record, a review six months later rests on memory, and memory already knows the ending. A premortem before kickoff gives you the list of risks that were known at the time.
In the review, start with the question about knowledge. What was known then? What could have been checked and wasn’t? Only the answer to the second question says anything about the quality of the decision.
Separate bad luck from negligence. People leaving the supplier is bad luck. Not asking how many people the delivery depends on is negligence. Both can produce the same outcome, but only the second one has a lesson in it.
Review the projects that succeeded, too. Even one a quarter. In my experience, successful projects contain just as many questionable decisions as failed ones, it’s just that nobody went looking for them.
A review like this takes longer than pointing at someone. What it gives you is a team that isn’t afraid to decide, and in a project that is worth more than one accurately assigned blame.
One question for this week
Think back to the last decision in your project that was judged a mistake. Was it judged by what was known on the day of the choice, or by how it ended?
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.
