Why your project was doomed before it started: ten behavioral biases that distort risk thinking, and how Risk Companion helps

Dams come in over budget by 96 percent on average. Rail projects by 40 percent. Roads by 24 percent. Bent Flyvbjerg's research across 2,062 capital investment projects, published in the Project Management Journal in 2021, produced those numbers — and his central finding is that they are not random. They are the predictable result of ten behavioral biases in project risk management that were present before the first stone was laid.

That is a different problem from the one most project teams think they have. The conventional assumption is that projects fail because of unexpected complexity, external shocks, or underestimated technical challenges. Flyvbjerg's data say otherwise. Projects fail because of the human beings planning them, and the failure is systematic enough to predict in advance.

De-biasing is possible. Structured processes, named accountability, and probabilistic analysis can interrupt the cognitive and political patterns that derail projects. None of that happens by accident, though.

The first two biases: when distortion is the plan

Strategic misrepresentation is the bias that tends to make people uncomfortable, because it is not a mistake. It is a deliberate choice to overstate benefits and understate costs in order to secure approval and funding. Flyvbjerg's research identifies it as widespread in infrastructure investment, and there is no reason to think private-sector capital projects are different, where budget approval works the same way.

The mechanism is straightforward enough. The person seeking approval knows an honest forecast might not clear the hurdle rate. So the numbers get adjusted — not dramatically, but enough to get the green light. By the time the real figures emerge, the project has momentum and the original sponsor has moved on.

Named ownership and transparent scoring are the practical counter. When every risk has a named owner and every assessment is recorded and auditable, adjusting a figure quietly becomes harder. Risk Companion's risk register keeps a full assessment history, so the trajectory of a risk score over time stays visible. A number that was revised downward before approval leaves a trace.

Optimism bias produces similar outcomes through a different mechanism. The distortion here is structural rather than deliberate. People consistently overestimate the probability that things will go well and underestimate the probability that they will not. Kahneman and Tversky called it the planning fallacy, and Flyvbjerg finds it across project types, geographies, and decades.

The practical result: cost estimates lean low, schedules lean tight, benefit forecasts lean high. Not because anyone lied, but because the people doing the estimating are human. Their reference point is a scenario where things go roughly as planned, and they weight that scenario too heavily.

The planning fallacy, uniqueness bias, and the base-rate fallacy

Three closely related biases sit underneath most project forecasting errors, even when the teams involved know about the research.

The planning fallacy comes from building forecasts from the best-case scenario upward rather than from the distribution of outcomes that similar projects have actually produced — a different failure from poor data, with a different fix. A team building a schedule is not deliberately ignoring history. They are focused on their plan, and the plan does not include the delays. Flyvbjerg's recommended fix is reference class forecasting: anchor your estimate in what projects of this type actually cost and actually took, then adjust from there.

Risk Companion's Monte Carlo simulation works in the same direction. Rather than a single-point estimate, the simulation samples from the distributions you define — minimum, most likely, maximum — across thousands of scenarios. The output is a range with percentile figures attached: P50, P85, P90. That is a distribution, and it is a considerably more honest representation of what the project is likely to cost than whatever the project team's working assumption happens to be.

Uniqueness bias is the tendency for project teams to treat their project as more distinctive than it actually is. Every team believes their project has special circumstances that make historical comparisons unreliable. Sometimes that is true. More often it is a rationalisation for ignoring the base rates that would make the forecast look worse.

A shared framework is the counter. Risk Companion is built to be multi-framework, so organisations can define a scoring methodology that applies consistently across projects. When the same categories, probability scales, and impact dimensions apply across a portfolio, it becomes harder for a single project team to exempt themselves from the historical record.

The base-rate fallacy sits underneath both of those. Teams fail to use reference class data even when it exists, because the specific details of their situation feel more relevant than the statistical pattern. Flyvbjerg's prescription — and Kahneman's before him — is to weight base rates heavily, then adjust for specific factors second. The Monte Carlo output in Risk Companion is one practical mechanism for doing that: when the P85 figure is significantly higher than the team's point estimate, the question to ask is whether that gap reflects genuine project-specific factors or wishful thinking.

Overconfidence, anchoring, and availability bias

Overconfidence bias is the tendency to have more certainty in one's own estimates than the evidence warrants. It is pervasive across professional domains, and experts are not immune. In some studies they are more overconfident than non-experts, because expertise can narrow the range of scenarios a person is willing to consider.

In project risk management, overconfidence shows up as tight confidence intervals. The team is not just saying the project will cost EUR 10 million; they are saying it is almost certainly going to cost EUR 10 million, give or take ten percent. Flyvbjerg's data suggest the real uncertainty is substantially wider.

Requiring triangular distributions rather than single-point estimates is one practical response. When you have to specify a minimum and maximum alongside a most likely figure, you are forced to put a number on the uncertainty you would prefer to suppress. Risk Companion's Monte Carlo module requires exactly that, and the P85 and P95 outputs make the tail risks visible rather than smoothed away.

Anchoring is the tendency to rely too heavily on the first piece of information received when making subsequent judgments. In a project context, the first cost estimate — often produced early, often casually — tends to anchor all the discussions that follow. Numbers that should move in response to new information stay close to the original figure, because the original figure has set the reference point.

Structured assessment across multiple dimensions disrupts the anchor. Risk Companion requires probability and impact to be assessed separately, across multiple impact perspectives — financial, schedule, quality, HSE, reputational — rather than collapsed into a single score. That structure forces the team to think about different consequences. Current and target assessments are recorded separately, so the question of where the risk sits now and where it is expected to land after measures are applied gets answered independently.

Availability bias is simpler but no less damaging. Teams overestimate the likelihood of risks they can easily recall and underestimate risks that are harder to bring to mind. The recent supply chain disruption gets flagged; the gradual regulatory drift that could affect the project in year three does not, because nobody has a vivid memory of it.

AI-assisted risk identification addresses this directly. Risk Companion's AI suggestions draw on a broad base of risk patterns across project types, so the register starts from more than whatever the team happens to remember in a workshop. The AI presents suggestions and the team decides what to accept. The human judgment stays in the loop, but the starting point is wider than an unaided team would typically produce.

Hindsight bias, escalation of commitment, and what they do together

Hindsight bias — the tendency to see past events as more predictable than they were — causes a specific problem in risk management. It makes teams underestimate uncertainty because, looking back, everything seems like it was going to happen anyway. Risks that were genuinely uncertain at the time look obvious in retrospect, which trains people to think they will be equally obvious in foresight next time. They will not be.

The practical counter is documenting risk assessments at the time they are made, with timestamps, rather than reconstructing them after the fact. Risk Companion's assessment history does that. Every update creates a new record, so the state of the register at any point in time is preserved. If a risk that was scored low actually occurs, the question becomes not "why did we not see that coming" but "what did we know at the time, and was our assessment reasonable given that."

Escalation of commitment is the bias that makes all the others worse. Once a team has invested significantly in a course of action — money, time, reputation — the pressure to continue compounds with every passing quarter. New evidence that the project is in trouble gets filtered, discounted, or reframed rather than acted on, because acting on it means acknowledging that the earlier decision was wrong.

This is not irrationality in the conventional sense. The social cost of reversing a decision is real. But the result is that projects which should be stopped or restructured keep going long past the point where the rational analysis would have called them.

Interrupting escalation of commitment means making the current state of risk visible to people who were not the original decision-makers. A dashboard that shows which measures are overdue, which risks have no active owner, and which risk scores have been static for months while the project has moved on is a basic mechanism for surfacing the information that escalation of commitment suppresses. Risk Companion's Mitigation Status dashboard flags risks without measures, overdue deadlines, and stalled progress so that those patterns can be caught before they become irreversible.

The ten biases as a system

Flyvbjerg's insight is that these biases do not operate independently. Strategic misrepresentation sets up a project with assumptions it cannot meet. Optimism bias fills in the detail. Uniqueness bias makes the team resistant to external challenge. The planning fallacy keeps the schedule tight and overconfidence keeps the confidence intervals narrow. Anchoring keeps everyone close to a number that was always too low. Availability bias leaves whole categories of risk unexamined, and the base-rate fallacy ensures historical data gets discounted. Hindsight bias prevents learning from past projects. Escalation of commitment keeps it all going long after the warning signs appear.

By the time a project is in visible trouble, most of those biases have been operating for months or years. The rework is not just technical. It is political, because the project now has sponsors and stakeholders who have committed to a version of it that was never realistic.

De-biasing has to happen at the front end. The assessment methodology, the ownership structures, the requirement for distributional estimates, the use of reference class data — all of it has to be in place before the first planning meeting.

What structured risk management actually does

None of this is primarily about software. The biases Flyvbjerg identifies are human. Countering them requires processes that create accountability, force honest estimation, and make the current state of risk visible to the people who need to act on it.

Structured risk management software makes those processes harder to avoid. A named owner field is not just a label; it is a social commitment that is recorded and visible to the team. A required minimum and maximum estimate forces someone to put a number on the uncertainty they would prefer to suppress. A P85 output exists independently of the optimism of the team that produced the inputs.

Risk Companion is built around those mechanics. The risk register requires an owner for every risk. The Monte Carlo simulation requires triangular distributions. Current and target assessments are tracked separately, so the gap between where a risk sits and where it is expected to land after measures are applied stays visible. The Mitigation Status dashboard surfaces stalled measures, risks with no active owner, and deadlines that have passed without resolution.

That is de-biasing in practice. The team still decides what risks to accept, what measures to implement, and when to escalate. But the structure makes the biases that distort judgment harder to act on without being noticed.

Flyvbjerg's paper does not offer a software recommendation. It offers a precise diagnosis: the problem is not bad luck. The teams planning projects are systematically biased in ways that are predictable, measurable, and partially correctable with the right structure.

The reference: Flyvbjerg, Bent, 2021, "Top Ten Behavioral Biases in Project Management: An Overview," Project Management Journal, vol. 52, no. 6, pp. 531–546. Available at https://journals.sagepub.com/doi/10.1177/87569728211049046.

Risk Companion's free 14-day trial builds a demo project from your own organisation's profile, so you can see the Monte Carlo P85 output, named ownership, and full assessment history for yourself before you commit to anything. Start your free trial.