Key Takeaways
- Bent Flyvbjerg's research across 2,062 capital investment projects found average cost overruns of 96 percent for dams, 40 percent for rail, and 24 percent for roads. The figures are too consistent across project types, geographies, and decades to be explained by bad luck or unusual complexity. They are the predictable result of systematic bias.
- The planning fallacy comes from building forecasts upward from the best-case scenario, anchored in the plan itself and disconnected from the distribution of outcomes that similar projects have actually produced. Flyvbjerg's recommended fix is reference class forecasting: anchor the estimate in what projects of this type actually cost, then adjust for project-specific factors second.
- Optimism bias and strategic misrepresentation produce similar outcomes, inflated benefit estimates and suppressed cost figures, but through different mechanisms. One is structural and unconscious, the other is deliberate. Treating them as the same problem leads to the wrong response: cultural interventions address optimism bias, while accountability and audit trails address misrepresentation.
- A single-point risk score collapses a range of possible outcomes into one number, concealing the uncertainty the team would rather not quantify. Requiring minimum, most likely, and maximum estimates forces that uncertainty onto the page, and the P85 output from a Monte Carlo simulation makes the tail risks visible to anyone reviewing the register.
- Escalation of commitment compounds every earlier bias. Once a project is underway, the social and financial pressure to continue filters out new evidence that the project is in trouble, and the longer it runs the harder it becomes to reverse. Interrupting it requires making the current state of risk visible to people who were not the original decision-makers, before the warning signs become irreversible.
Bent Flyvbjerg's research across 2,062 capital investment projects, published in the *Project Management Journal* in 2021, found that dams come in over budget by 96 percent on average, rail projects by 40 percent, and roads by 24 percent. His central finding is that these overruns are predictable, not accidental.
That is a different problem from the one many 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 point to a different cause: projects fail because of the human beings planning them, and the failure is systematic enough to predict in advance.
De-biasing is possible through structured processes, named accountability, and probabilistic analysis that interrupt the cognitive and political patterns that derail projects. The conditions for that to happen need to be deliberately built in.
The first two biases: when distortion is the plan
Strategic misrepresentation is the bias that tends to make people uncomfortable, because it describes 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 person seeking approval knows an honest forecast might not clear the hurdle rate, so the numbers get adjusted, modestly 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, because 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 and a number revised downward before approval leaves a trace.
Optimism bias produces similar outcomes through a structural mechanism. People consistently overestimate the probability that things will go well. Kahneman and Tversky named this the planning fallacy, a concept Kahneman later developed in Thinking, Fast and Slow, and Flyvbjerg finds it across project types, geographies, and decades.
The practical result is that cost estimates lean low, schedules lean tight, and benefit forecasts lean high, produced by people whose reference point is a scenario where things go roughly as planned and who weight that scenario too heavily.
The planning fallacy, uniqueness bias, and the base-rate fallacy
Three closely related biases sit underneath many project forecasting errors, even when the teams involved know about the research.
The planning fallacy comes from building forecasts upward from the best-case scenario, anchored in the plan itself and disconnected from the distribution of outcomes that similar projects have actually produced. A team building a schedule is focused on their plan, and the plan has no delays in it.
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, sampling from the distributions you define, minimum, most likely, and 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, and sometimes that is true. More often it is a rationalisation for ignoring the base rates that would make the forecast look worse.
Consistent frameworks across projects are the practical 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 research suggests experts can be more overconfident than non-experts in some domains, 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 saying the project will cost EUR 10 million and is almost certain of it, give or take ten percent. Flyvbjerg's data suggest the real uncertainty is substantially wider.
Requiring triangular distributions instead of 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 instead of smoothing them 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 and 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 supports probability and impact assessment separately across multiple impact perspectives, financial, schedule, quality, HSE, and reputational, keeping the team focused on different categories of consequence instead of collapsing everything into a single score. 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 give less weight to 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 goes unnoticed, 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, keeping human judgement in the loop while starting from a wider base 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 expect the same clarity in foresight, a false expectation that compounds with every project.
The practical counter is documenting risk assessments at the time they are made, with timestamps, so the record exists without reconstruction after the fact. Risk Companion's assessment history does exactly 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 what the team knew at the time and whether the assessment was reasonable given that information.
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, and reputation, the pressure to continue compounds with every passing quarter. New evidence that the project is in trouble gets filtered, discounted, or reframed, because acting on it means acknowledging that the earlier decision was wrong.
The social cost of reversing a decision weighs heavily on project teams, and that weight keeps projects moving long past the point where the 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 Mitigations 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 work together as a system. Strategic misrepresentation sets up a project with assumptions it cannot meet, optimism bias fills in the detail, and uniqueness bias makes the team resistant to external challenge. The planning fallacy keeps the schedule tight, overconfidence keeps the confidence intervals narrow, and anchoring keeps everyone close to a number that was always too low. Availability bias leaves whole categories of risk unexamined, the base-rate fallacy ensures historical data gets discounted, hindsight bias prevents learning from past projects, and escalation of commitment keeps it all going long after the warning signs appear.
By the time a project is in visible trouble, many of those biases have been operating for months or years. The rework is technical and 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, with the assessment methodology, ownership structures, requirement for distributional estimates, and use of reference class data all 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 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, and 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 keeps the owner field visible and prominent on every risk, the Monte Carlo simulation requires triangular distributions, and 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 Mitigations 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 offers a precise diagnosis: the teams planning projects are systematically biased in ways that are predictable, measurable, and partially correctable with the right structure. The paper makes no software recommendation, but the structural interventions it describes have direct operational equivalents.
If you want to see the Monte Carlo P85 output, named ownership, and full assessment history working together on your own project's risks, start a free 14-day trial of Risk Companion. A demo project built from your own organisation's profile is ready from day one.
Ready to improve your risk management?
See how Risk Companion can help you implement these best practices with powerful, easy-to-use tools. Sign up and we'll prepare a demo project tailored to your company.