Why Project Plans Fail — And What to Do About It
The evidence is overwhelming: most plans miss their targets. Understanding why is the first step toward building plans that actually work.
The Scale of the Problem
Project failure is not the exception — it is the norm. Decades of research across industries tell a remarkably consistent story: the vast majority of projects do not go according to plan. Understanding the scope of this problem is essential before we can address its causes.
The Standish Group has tracked IT project outcomes since 1994 through their CHAOS report. While their methodology has been subject to academic debate — notably by researchers like Jorgensen and Molokken-Ostvold (2006), who questioned the sampling and definitions — the directional finding is consistent with independent research: most projects deviate significantly from their original plans.
Bent Flyvbjerg, a professor at Oxford and later IT University of Copenhagen, has produced some of the most rigorous research on project overruns. His analysis of over 2,000 projects across 20 countries found that cost overruns are the rule, not the exception. For large infrastructure projects, the average cost overrun was 80%. For IT projects, the average was 27%, with a significant number experiencing overruns of 200% or more.
The Project Management Institute's annual Pulse of the Profession report consistently finds that organizations waste approximately 12% of their project investment due to poor project performance. Scaled to the global economy, this represents hundreds of billions of dollars in wasted resources every year.
These numbers are not an indictment of project managers or organizations. They are a reflection of a planning methodology — deterministic, single-point estimation — that is fundamentally mismatched with the uncertain reality of complex projects.
Root Causes: Why Plans Miss Their Targets
Project failure is not random. It follows predictable patterns rooted in how humans think about the future and how organizations build plans. Understanding these patterns is the key to breaking them.
1. The Planning Fallacy: Hardwired Optimism
Daniel Kahneman and Amos Tversky identified the planning fallacyin 1979: the systematic tendency for people to underestimate the time, costs, and risks of future actions while overestimating the benefits. This is not laziness or incompetence — it is a deeply rooted cognitive bias that affects experts and novices alike.
The planning fallacy operates through what Kahneman calls the "inside view": when estimating a project, people focus on the specific details of the plan in front of them rather than looking at how similar projects have actually performed. They construct a mental narrative of success and estimate based on that narrative, ignoring the base rate of failure for similar projects.
"The prevalent tendency to underweight or ignore distributional information is perhaps the major source of error in forecasting. Planners should therefore make every effort to frame the forecasting problem so as to facilitate utilizing distributional information." — Daniel Kahneman
Crucially, the planning fallacy is resistant to experience. Even people who have seen previous projects overrun their estimates consistently produce optimistic estimates for new projects. Awareness of the bias helps, but only modestly. What works better is changing the estimation process to account for the bias structurally — through techniques like uncertainty-first planning.
2. False Precision: The Illusion of Knowledge
Traditional planning demands precise numbers. How many days will Phase 2 take? What will the budget be? What is the expected revenue in Q3? These questions demand single-point answers, and organizations dutifully provide them: 47 days, $512,000, $1.3 million.
The problem is that these precise numbers are almost certainly wrong. They create an illusion of knowledge and certainty that does not exist. Worse, the precision itself discourages questioning. A budget of "$512,000" sounds like it was carefully calculated. A budget of "$400,000 to $700,000" sounds vague and uncertain — even though it is far more honest and useful.
False precision has a cascading effect. When each line item in a plan is expressed as a single number, the aggregate appears equally precise. A project plan with 50 line items, each estimated to the day, implies a level of schedule knowledge that simply does not exist. The plan looks authoritative and complete, when in reality it is a tower of assumptions stacked on assumptions.
3. Anchoring Bias: The First Number Wins
Anchoring is one of the most powerful cognitive biases documented by behavioral economists. Once a number is established — even an arbitrary one — all subsequent estimates tend to cluster around it. In planning contexts, the first estimate mentioned in a meeting often becomes the plan, regardless of its basis.
This is particularly dangerous in organizations where estimates flow top-down. When a senior leader says "I think we can do this in six months," that becomes the anchor around which the entire team builds their estimates. Engineers who privately believe it will take twelve months adjust their estimates downward, settling on eight or nine months as a "compromise" that is still unrealistic.
Research by Tversky and Kahneman (1974) demonstrated that even random numbers influence estimates. In one classic study, spinning a wheel of fortune before asking participants to estimate the number of African countries in the United Nations significantly influenced their answers. Planning estimates are no less susceptible to these arbitrary anchors.
4. Single-Point Estimates: Collapsing Ranges into Lies
When you estimate that a task will take "3 weeks," what you actually know is probably something like: "It could take 2 weeks if everything goes well, 4 weeks is realistic, and 8 weeks is possible if we hit unexpected technical challenges." But organizational processes force you to collapse this honest range into a single number. That number then becomes a commitment, a baseline, and an accountability tool.
The problem compounds as you aggregate single-point estimates. If your project has 20 tasks, each estimated as a single number, the project estimate is the sum of 20 slightly optimistic numbers. The compound effect makes the overall estimate far more optimistic than any individual estimate. Even if each task estimate has only a 30% chance of being exceeded, the probability that the aggregate is exceeded approaches near certainty.
5. Ignored Dependencies: The System Is Not the Sum of Its Parts
Real projects are systems of interdependent activities, not collections of independent tasks. When Task A runs late, Task B cannot start on time. When the design phase produces something more complex than expected, the development phase takes longer. When the vendor delivers components late, assembly cannot begin.
Traditional planning tools like Gantt charts and critical path analysis do capture some dependencies, but they treat each task duration as fixed. They show you which tasks are dependent but not how variability in one task cascades through the system. This is where Monte Carlo simulation becomes essential: it models dependencies and correlations alongside uncertainty, revealing how the system behaves when things go wrong.
6. Scope Creep: The Plan That Never Stops Growing
Scope creep is often treated as a management failure, but it is more accurately understood as a natural consequence of uncertainty. When you begin a project, you do not fully understand the problem you are solving. As you learn more, the scope naturally evolves. This is not necessarily bad — adapting to new information is rational — but it is catastrophic when the budget and timeline were set based on the original (incomplete) understanding.
Uncertainty-first planning addresses scope creep by building uncertainty about scope into the plan from the start. Instead of assuming the scope is fixed and known, you model a range of possible scope outcomes and plan resources accordingly.
The Cost of Failure
Project failure costs more than money. Understanding the full cost helps justify the investment in better planning methods.
Financial Costs
The direct financial costs of project failure are substantial. According to PMI, organizations waste an average of 12% of their project investment due to poor performance. For a company spending $10 million annually on projects, that is $1.2 million in waste. And this figure captures only the direct costs — it does not include the opportunity cost of capital tied up in failing projects or the revenue lost from delayed market entry.
Flyvbjerg's research on large projects is particularly striking. His analysis found that one in six IT projects experienced a cost overrun of 200% or more, with schedule overruns of nearly 70%. These "black swan" projects — which he calls "fat-tailed" because of their disproportionate frequency compared to what normal distributions would predict — can be existential threats to organizations.
Organizational Costs
Failed projects erode organizational trust and credibility. When a team repeatedly misses its commitments, stakeholders lose confidence. This creates a vicious cycle: leaders add "management reserve" (padding) to every estimate, teams learn that only dramatic overruns get attention, and the planning process becomes a negotiation exercise rather than an analytical one.
The organizational cost also includes the erosion of decision-making quality. When plans are routinely wrong, leaders stop trusting plans altogether and revert to intuition. This is the worst possible outcome — the organization abandons structured planning not because planning is flawed in principle, but because their specific planning methodology is inadequate.
Human Costs
The human costs of project failure are often ignored in academic analyses but are very real. Teams that work on failing projects experience sustained stress, forced overtime, and the demoralization of watching their efforts fall short of unrealistic targets. Over time, this leads to burnout, attrition, and a culture where cynicism replaces engagement.
A 2019 study published in the International Journal of Project Management found that project managers working on challenged projects reported significantly higher levels of stress and lower job satisfaction, with direct effects on retention. The study concluded that more realistic planning would improve both project outcomes and workforce well-being.
How Uncertainty-First Planning Addresses Each Cause
Uncertainty-first planning does not claim to eliminate project failure. But it addresses each root cause directly, producing plans that are more realistic, more robust, and more adaptable to changing conditions.
Against the Planning Fallacy: Replace Intuition with Data
Uncertainty-first planning counters the planning fallacy by requiring range estimates instead of point estimates. When you must specify a best case, worst case, and most likely case for every variable, the process itself forces a more honest assessment. The act of thinking about the worst case surfaces risks that optimistic point estimates suppress.
Additionally, simulation-based approaches incorporate reference class data where available, grounding estimates in historical performance rather than optimistic projection.
Against False Precision: Communicate Probabilities, Not Promises
Instead of committing to "we will deliver on March 15," uncertainty-first planning produces statements like "there is a 70% probability of delivery by March 15, and a 90% probability by April 10." This is not vagueness — it is more informative than a single date. It gives stakeholders the information they need to make decisions about contingency, communication, and resource allocation. See how Incertive produces these probability statements from a plain-language plan description.
Against Anchoring: Start with Ranges, Not Numbers
When the planning process begins with range estimation rather than point estimation, the anchoring effect is reduced. There is no single number to anchor to — the conversation starts with "what is the range?" rather than "what is the number?" This structural change in the process reduces the influence of arbitrary anchors.
Against Single-Point Estimates: Model the Full Distribution
Monte Carlo simulation takes range estimates and produces a complete probability distribution of outcomes. This distribution shows not just the most likely outcome but the entire range of what could happen and with what probability. Decision-makers can then choose the level of confidence they need: if a 70% probability of success is acceptable, the plan looks one way. If they need 95% confidence, it looks different. This is a fundamentally different capability from what tools like Smartsheet provide.
Against Ignored Dependencies: Simulate the System
Monte Carlo simulation naturally models dependencies. When one variable is correlated with another, the simulation captures those interactions across thousands of runs. The result is a realistic picture of how variability in one part of the project cascades through the system. See how operations teams use this to model supply chain uncertainty and capacity decisions.
Practical Steps to Improve Your Planning
You do not need to overhaul your entire planning process overnight. Here are practical steps that any team can implement to start producing more realistic plans.
- Ban single-point estimates. For every significant variable, require a range: best case, worst case, and most likely. Make this a non-negotiable part of your planning template.
- Conduct pre-mortems.Before committing to a plan, ask the team: "Assume this project has failed. What went wrong?" This technique, popularized by Gary Klein, surfaces risks that optimistic planning suppresses.
- Use reference class forecasting. Before estimating from the inside out, look at how similar projects have actually performed. If your last five software projects ran 40% over estimate, your next one probably will too unless you change something fundamental.
- Simulate, do not calculate. Use Monte Carlo simulation to model the combined effect of uncertainty in all your variables. Tools like Incertive make this accessible without requiring a statistics background.
- Report probabilities, not dates.Train your organization to think in probabilities. "80% likely by March 15" is more useful than "March 15" because it makes the uncertainty explicit and lets stakeholders make informed decisions about contingency.
- Track and learn. After each project, compare actual outcomes to your predicted ranges. Were your ranges well-calibrated? Did the actual outcome fall within your predicted distribution? Use this feedback to improve future estimates.
- Build a risk-aware culture. Reward honest estimation over optimistic commitment. When someone provides a wide uncertainty range, they are being more honest and more useful than someone who provides a falsely precise number. Organizational culture must support this shift.
Frequently Asked Questions
What percentage of projects actually fail?
The exact number depends on how you define failure and which industry you examine. The Standish Group CHAOS reports consistently find that around 70% of IT projects do not meet their original scope, timeline, and budget targets. A 2017 study by PMI found that 14% of IT projects fail outright, while a further 31% do not meet their goals. In construction, McKinsey has found that large projects typically run 80% over budget. The common thread across all industries is that the majority of projects do not go according to their original plan.
Is the planning fallacy something I can just train people to avoid?
Unfortunately, no. Research by Kahneman, Tversky, and others has shown that the planning fallacy is resistant to training and experience. Even people who know about the bias and have extensive experience with similar projects continue to produce optimistic estimates. The most effective countermeasure is to change the process rather than the people: use reference class forecasting, require range estimates instead of point estimates, and employ computational simulation to model outcomes.
What is reference class forecasting?
Reference class forecasting is a technique proposed by Daniel Kahneman and Bent Flyvbjerg. Instead of estimating a project from the inside out (bottom-up estimation), you look at how similar projects have actually performed in the past and use that distribution as your starting point. For example, instead of estimating your software project from its work breakdown structure, you look at how long similar software projects actually took and use that range. This approach has been shown to produce significantly more accurate estimates.
Are agile projects less likely to fail than waterfall projects?
Agile methodologies can reduce certain failure modes, particularly those related to building the wrong thing (through iterative delivery and frequent feedback). However, agile does not eliminate the planning fallacy, optimism bias, or the challenges of estimating complex work. Agile projects still frequently miss sprint commitments and release targets. The key advantage of agile is its built-in feedback loops, which allow for course correction. Uncertainty-first planning enhances this further by providing probabilistic forecasts that improve over time.
How can I convince my organization to adopt probabilistic planning?
Start small. Pick one project and run a parallel process: maintain the traditional deterministic plan alongside a probabilistic one. When the deterministic plan misses its targets (as it likely will), show how the probabilistic forecast predicted the actual outcome more accurately. This evidence is far more convincing than theoretical arguments. Additionally, frame the conversation around better decisions rather than better estimates. Stakeholders care about making good decisions; probabilistic planning gives them better information to do so.
Does uncertainty-first planning take more time than traditional planning?
Initially, yes, because it requires thinking carefully about uncertainty ranges rather than committing to single numbers. However, this time is invested upfront rather than spent later on re-planning, scope negotiations, and crisis management when the original plan fails. With tools like Incertive, the computational aspects are automated, so the additional time is primarily in honest estimation. Most teams find that after one or two projects, uncertainty-first planning actually saves time overall.
What is the single biggest reason projects fail?
While there is no single cause, the most consistent finding across research is that projects fail because they are planned around assumptions that turn out to be wrong, without adequate contingency for those assumptions being wrong. This manifests as unrealistic schedules, insufficient budgets, underestimated complexity, and unidentified dependencies. All of these are symptoms of the same root cause: treating uncertain estimates as certain commitments.
Can small projects benefit from uncertainty-first planning, or is it only for large initiatives?
Projects of any size benefit from honest uncertainty estimation. For a small project, the analysis might be as simple as asking "what is the best and worst case for each task?" and using a tool to calculate the probability distribution of the total timeline. The formality of the approach should scale with the stakes and complexity, but the core principle, acknowledging and modeling uncertainty, is valuable at every scale.
Stop Planning to Fail
Incertive shows you the real probability of success for your plan — and how to improve it.
Get Your Go/No-Go Answer