When IT Projects Go Wild: What We Need to Know
Happy Tuesday, Transformation Friends. Another week, another opportunity to go Beyond the Status Quo.
Today, we explore this question: Why do so many government IT projects spiral out of control?
A new paper by Bent Flyvbjerg and colleagues takes a close look at cost risk across 23 different project types, and the results are striking and offer a lot of insight. Their study shows that IT stands apart: unpredictable, with risk patterns so uneven that traditional forecasting cannot be trusted. The research compares IT with fields like nuclear power, transport, and energy, and still finds IT uniquely risky, which is an unsettling conclusion for those responsible for large IT transformations.
Today, IT investments are ingrained in every service we deliver. When costs spiral, budgets suffer, but worse: so does public trust and service reliability. The evidence suggests that IT is not just another category of capital project. Rather, it's a special risk class that demands a different mindset and different tools. This raises important questions about how leaders approach planning, oversight, and delivery.
Today, we'll start with a summary of this research, then look at what it means for us by extracting some lessons based on Flyvbjerg's findings. Finally, we'll share some prompts to spark reflection on how this connects to your own work.
The full article is here:
Flyvbjerg, B., Budzier, A., Aaen, J., Keil, M., & Zottoli, M. (2025). The Uniqueness of IT Cost Risk: A Cross-Group Comparison of 23 Project Types. Project Management Journal, 0(0). https://doi.org/10.1177/87569728251340590
Grab your morning coffee, and let’s get started.
What the Research Found
The study analyzed 11,011 projects across 23 categories, ranging from IT and nuclear power to roads and wind farms. The focus was on cost risk, measured as the ratio of actual to estimated costs at the point of final investment decision. I've put the data I'm about to discuss at the end of this section so you can have a look and follow along.
IT projects stood out as uniquely risky.
At first glance, the picture for IT looks surprisingly good. Out of the 5,360 IT projects in the dataset, only about 41% went over budget. That actually places IT among the best performers. For contrast, every Olympic Games project studied has gone over budget, and 97% of nuclear power projects did too.
Even when looking at projects that ran more than 50% over budget, IT still sits near the middle of the pack at 18%. On these basic measures, IT does not appear to be the problem child many expect.
The trouble emerges when looking at what happens once IT projects cross the 50% overrun threshold. For these projects, the average cost overrun is an astonishing 453%. This is worse than any other project type and, aside from nuclear storage, far worse than the rest.
Put simply: when IT projects go over budget, they go dramatically over.
The trouble continues...
The researchers also show that cost overruns follow a power‑law curve. For those interested in the technical details, they use a Pareto Type I distribution, defined by a “tail shape” parameter (alpha). IT projects have an unusually heavy tail: their alpha is 0.92, making them the only project type below 1. This matters because a value under 1 means averages and variances do not converge (they can't be calculated). In practice, there is no stable “typical” outcome. Instead, rare but extreme blowouts dominate the results and overwhelm the overall picture.
It's what they call “wild risk.”
This makes IT projects fundamentally different from bridges, roads, or even nuclear plants, where averages can provide some guidance. The research tells us that for IT projects, traditional forecasting breaks down, and leaders must plan for the possibility that these extreme events will bend the cost curve far out of shape.
The paper also explores why this might be the case, suggesting four familiar explanations for IT risk:
Immaturity: IT is a relatively young field compared to engineering disciplines like construction, with weaker standards, less professionalization, and fewer established practices.
Intangibility: Software has no physical presence, making progress harder to see, communication more difficult, and scope creep easier to accept.
Unclear goals: Objectives in IT projects often shift or are poorly defined, leading to volatility, drift, and escalation.
Stakeholder resistance: IT alters established ways of working and power dynamics, creating pushback that adds complexity and delay.
While these remain plausible explanations, the data point to added drivers: a heavy reliance on bespoke builds instead of modular components, and decision-making that is rushed, leaving projects underprepared.
Implications
The lesson is clear: large IT initiatives need to be treated as their own category of risk because extreme events drive the overall budget picture. Average-based forecasting and thin risk registers do not capture reality. A better approach is to use high-percentile budgeting and to set limits on exposure at the portfolio level.
Decision-making and Optimism Bias
Business cases built on averages are misleading. Approvals should be based on percentile forecasts that account for extreme outcomes. This is where reference-class forecasting and the outside view become essential. By comparing proposed projects with a broad dataset of similar initiatives, leaders can ground expectations in real-world outcomes rather than optimistic assumptions.
This connects directly to optimism bias: the tendency for leaders and teams to assume things will go better than they actually do. In IT, this often means underestimating costs, overestimating delivery speed, or ignoring early signs of trouble. Optimism bias is especially dangerous when combined with fat-tailed risk: even small misjudgments can leave organizations exposed to rare but extreme overruns.
Business cases, budgets, and schedules must therefore be stress-tested against outside evidence. Embedding reference-class forecasting and the outside view into gating and oversight processes reduces the gap between what leaders hope will happen and what actually unfolds. Where possible, we should also favour configurable off-the-shelf products or platform components rather than bespoke builds, aligning with the Treasury Board’s Policy on Service and Digital and departmental gating practices for major projects.
Service delivery
Systems should be designed to degrade gracefully and delivered in modular stages. The research highlights a barbell effect: many IT projects meet their budget, but a significant minority collapse with extreme overruns. Leaders cannot assume a single failure will be rare or containable. By staging releases, using feature flags, and designing for modularity, we can reduce the risk of a total shutdown when one part goes wrong. This ensures that even if a module slips, core services remain available and public trust is protected.
Budgeting
Reserves need to be ready at the portfolio level, not only at the project level. For projects that start moving into the extreme tail, pre‑defined kill‑switches and pivot options should be in place. Metrics such as change‑request velocity, the number of integration dependencies, and the share of bespoke code can serve as early warnings for governance. Budgets and stage‑gates should be built around P80–P95 cost forecasts. Tracking and reporting exposure at the portfolio level makes it possible to see the bigger picture and prepare for rare but damaging overruns.
Reducing bespoke design
Departments should favour platforms, commercial off‑the‑shelf products, and APIs to reduce the complexity that drives extreme outcomes. Measuring the share of configurable versus bespoke scope as a key performance indicator provides leaders with a clear picture of where their exposure lies.
Flyvbjerg’s broader work, including How Big Things Get Done, reinforces the same point. He argues that the best way to reduce risk is to treat projects like building with Lego: using repeatable, modular blocks that can be assembled in reliable ways. When organizations insist on unique, one‑off designs, they expose themselves to greater uncertainty, slower delivery, and larger cost blowouts. The goal should not be to chase uniqueness, but to build on proven, standardized components wherever possible. This mindset makes IT projects more predictable and keeps them within manageable levels of risk.
Monitoring and governance
Early‑warning metrics such as change‑request velocity, dependency counts, defect discovery rates, and interface churn should be monitored closely to detect risks before they escalate. Kill‑switches and de‑scope paths should be pre-authorized so that projects can pivot quickly if warning signs mount. Independent “think‑slow” reviews provide an additional check on momentum that can otherwise carry troubled projects too far.
Workforce and procurement
Contracts should be built around modularity and standard interfaces. Vendors should be incentivized to reduce integration complexity. Avoid monolithic statements of work that lock in bespoke design. Integration architects, platform engineers, and commercial specialists are all needed to enforce modular procurement and reduce complexity. Investing in these capabilities strengthens the foundation for managing IT as a distinct risk class.
What To Do
Asking the right questions is one of the most practical tools we have to spot risks early and decide how to respond. Here are five areas to probe to help reduce exposure and improve outcomes.
Where do we see “bespoke by default,” and how could we modularise without losing mission fit?
Leaders should ask whether solutions are being custom-built when existing platforms or components might work. Explore how modularisation can preserve mission needs while cutting down on unnecessary complexity and risk.
What tail-specific indicators should we adopt to trigger gatekeepers early?
Metrics like change‑request velocity, the number of integration dependencies, and the share of bespoke code can warn when projects are drifting into the extreme tail. These signals should trigger earlier reviews before overruns take hold.
How should we rebalance contingencies between project and portfolio levels for fat-tailed IT risk?
Reserves may be more effective at the portfolio level, where extreme risks can be absorbed across projects. Leaders should consider whether current contingency practices reflect the reality of fat-tailed risk.
Which procurement levers best reduce integration interdependencies and scope volatility?
Breaking contracts into smaller, modular packages, building in incentives for simpler integration, and avoiding monolithic statements of work are practical ways to reduce volatility and complexity.
When should we pivot from build to buy to reduce exposure to extreme risk?
Consider thresholds where bespoke development becomes too risky, and where configurable off-the-shelf or platform solutions can achieve the same outcomes with less exposure.
Wrap up
Flyvbjerg’s research shows why IT projects stand apart and why we need a different toolkit to manage them. The main ideas are straightforward: recognize IT as its own risk class, use the outside view to check optimism bias, and rely on modular, proven components instead of chasing uniqueness.
As you think this through, here are three questions to reflect on:
Are we managing IT initiatives as if they are uniquely risky, or as if they are just like other major projects?
What would it take to embed tail-aware budgeting and governance practices into our institutions?
How can we shift from bespoke builds toward modular approaches that better manage risk?
Until next time, stay curious and I’ll see you Beyond the Status Quo.