Key Takeaways
- Research shows that large capital projects come in up to 80 percent over budget, and most of those overruns are rooted in decisions made, or not made, in the concept and design phase.
- A risk register where every risk sits in the amber band with no probability score and no named owner is not a management tool. It is a gateway document that nobody will act on.
- Scope creep in infrastructure is rarely a construction problem. It almost always starts with ambiguity that was cheap to resolve in the concept phase and expensive to fix after design has started.
- Contingency built from Monte Carlo simulation of your risk register gives you a figure you can defend to the board. A flat 10 percent added on top of a cost estimate is guesswork with a respectable label.
- The projects that consistently deliver within budget are not lucky. They are the ones where the risk register shaped the contingency budget, influenced procurement strategy, and triggered design changes before those changes became expensive.
The overrun was visible before construction started
Large infrastructure projects fail on schedule and on budget at a rate that would be unacceptable in almost any other industry. McKinsey research found that large capital projects typically come in up to 80 percent over budget and 20 percent behind schedule. Bent Flyvbjerg's research on megaprojects, conducted at Oxford, puts the figure even higher: nine out of ten major infrastructure projects experience cost overruns, and the average overrun for rail projects exceeds 40 percent.
Infrastructure project risk management is the field that exists to close that gap. But most of the literature, and most of the practice, focuses on the wrong part of the timeline.
When a tunnel hits unexpected geology, when a procurement contract comes in 30 percent above estimate, when a local authority blocks a planning application two years into a project, those are execution problems. But the roots of each one are almost always visible much earlier, in the concept phase, the feasibility study, the design brief. The battle is won or lost before a spade hits the ground.
Early-phase risk assessment is the single highest-leverage activity available to a project team, not a checkbox on a gateway document.
If you get it right, you enter construction with realistic budgets, identified risks, and contingency figures you can defend. If you get it wrong, you spend the next three years firefighting problems that were entirely foreseeable.
What actually goes wrong in the early phase
Ask any experienced project director where the overruns really start, and the answers cluster around three patterns.
Scope that was never properly defined. The project brief describes an outcome, not the work. Everyone interprets it differently. Design teams proceed on assumptions. By the time the scope is formally defined (often at tender stage) months of rework are already baked in. Scope creep in infrastructure is rarely a construction problem. It almost always starts with ambiguity that nobody resolved when resolving it was still cheap.
Risks identified but never quantified. Early-phase risk registers in infrastructure tend to be long and impressive: thirty, forty, fifty risks, every one of them marked amber, with no probability scores, no financial exposure attached, and no owner accountable for tracking them. The register exists to satisfy a gateway review rather than to guide decisions. When those risks materialise on site (and several of them always do), the team treats them as surprises, when in fact they were known unknowns that nobody turned into numbers.
Stakeholders mapped too late. Consider a highway project that spends eighteen months in detailed design before a heritage assessment reveals that a proposed junction cuts through the boundary of a protected site. The redesign costs €14 million and delays the programme by eleven months. The heritage constraint was discoverable from public records on day one. Stakeholder and constraint mapping that happens after design has started is damage control rather than risk management
Each of these patterns shares the same root cause: risk thinking treated as a formality rather than a genuine analytical discipline.
Why early-phase decisions are structurally different
There is a concept in project management called the "influence curve", the idea that your ability to affect project outcomes decreases sharply as the project progresses, while the cost of making changes increases. In infrastructure, that curve is steeper than almost anywhere else.
A change made in the concept phase costs almost nothing, while the same change made during detailed design costs ten times more and during construction can cost a hundred times more. This is not a theory, it is consistent with what project teams report, and it is why capital project risk in the early phase deserves a level of rigour that most organisations do not apply.
The uncomfortable implication is that the teams that spend the most time on early-phase risk analysis tend to have the least dramatic construction phases. Not because they are luckier. Because they used the window when intervention was still affordable.
What does rigorous early-phase risk management actually look like? Four things stand out.
Structured risk identification, not a brainstorm. Most early-phase risk workshops produce a list of risks that reflects whoever was loudest in the room. Structured risk identification means working systematically through categories (ground conditions, regulatory, procurement, stakeholder, environmental, financial) and using tools that prompt the team to think about causes and consequences, not just events. Bow-tie analysis is particularly useful here: it forces teams to think about what triggers a risk and what happens downstream if it occurs, which is a very different discipline from simply listing "ground conditions risk" on a register.
Probability and impact scored, not assumed. An unscored risk is an unmanaged risk. Scoring probability and impact on a 1-5 scale is imprecise, and we should be honest about that — but it is dramatically better than no score at all. It forces a conversation, surfaces disagreement, and creates a ranked list that tells you where to focus attention and contingency budget. A risk register where every risk sits in the amber band is not a ranking tool. It is a comfort blanket.
Owners assigned before the register is shared. Every risk needs a named person accountable for tracking it, updating it, and ensuring measures are in place. Not a department or a project team but a named individual. In our experience, the single most common failure mode in infrastructure risk management is a well-populated risk register where nobody knows who is actually responsible for any of it.
Contingency built from the risk register, not added on top of it. The standard practice of adding a 10 or 15 percent contingency to a capital cost estimate is not risk management. It is guesswork with a respectable label. Running probabilistic risk analysis, e.g. Monte Carlo simulations that model your risk register across thousands of scenarios, gives you a contingency figure with a confidence interval attached. You can tell the board: 'There is an 80 percent probability that project cost will fall within this range.' That is a defensible number, which a flat percentage added on top of an estimate is not.
The risks that kill infrastructure projects early
Not all early-phase risks are equal. The ones that cause the most damage share a common characteristic: they are systemic, not event-specific. They do not show up as a single line in a risk register. They infect the whole project.
Optimism bias. Flyvbjerg's earlier cited research across hundreds of megaprojects found consistent evidence of optimism bias in early estimates, with project teams systematically underestimating cost and duration because incentive structures reward winning approval rather than accurate forecasting. The solution is not to tell teams to be more pessimistic but to use reference class forecasting: comparing your project to the actual outcomes of comparable completed projects and adjusting from there. Most infrastructure teams build estimates from first principles and anchor to the brief instead.
Strategic misrepresentation. Related to optimism bias but distinct, strategic misrepresentation is the deliberate understatement of cost and duration to secure funding approval. It is a governance failure rather than a risk management failure, but it creates exactly the same outcome: a project that enters construction with a budget that was never realistic.
Incomplete risk transfer assumptions. Early-phase financial models often assume a level of risk transfer to contractors that does not survive contact with actual procurement. Alliance contracts, target-cost arrangements, and NEC-form contracts share risk in ways that are not straightforward to model. Teams that model early-phase cost as if full risk transfer will occur routinely discover at tender that it does not.
Regulatory and planning uncertainty. Infrastructure projects almost always require permits, consents, or regulatory approvals from multiple bodies. The timing and conditions attached to those approvals are genuine risks, and they are frequently underestimated in early schedules. A single planning condition (a species survey, a heritage impact assessment, or a noise study) can add six months to a programme, which means those risks need to be on the register early with probability scores and programme contingency attached.
How to build an early-phase risk process that actually works
The gap between good and bad infrastructure risk management in the early phase is not a gap in knowledge. Most project teams know what they should do. The gap is in execution, specifically in making the process structured enough to be consistent, and light enough to actually happen.
A few principles that make the difference in practice.
Start the risk register on day one. Not at the first gateway review. Not when the project director asks for it. Day one. The register should be a live document from project inception, not a deliverable assembled before a milestone. Early risks are often the most important ones, and they get missed when the register is built in a hurry before a review.
Run a structured risk session with the full project team. Risk identification in silos produces siloed risk registers. The geotechnical risk that the engineers see and the stakeholder risk that the project manager sees rarely end up in the same conversation unless someone deliberately creates one. A structured risk workshop, even 90 minutes with the core team, surfaces connections that individual contributions miss.
Assign measures before the register leaves the room. Every risk should leave the workshop with at least one measure attached, an owner named, and a due date set. A risk without a measure is a risk with no response plan. In the context of a £50 million infrastructure project, that is a liability and not an oversight.
Revisit the register at every major design decision point. Risk registers that are built once and reviewed quarterly are already out of date. In the early phase, design decisions happen weekly. Each one resolves some risks and creates new ones. The register should be reviewed whenever a significant design or scope decision is made, not just on a calendar schedule.
Use your risk data to stress-test the budget. If your risk register has probability and impact scores, you have the raw material for a probabilistic cost analysis. Monte Carlo simulations run your register through thousands of scenarios and return a distribution of possible outcomes. The output is a contingency budget you can explain: "our P80 cost is €X, driven primarily by ground condition uncertainty and procurement risk", rather than a percentage that nobody can justify.
Risk Companion's risk register gives every risk an owner, a score, and a clear next step from day one. The Monte Carlo simulation capability runs your early-phase register through thousands of scenarios, so the contingency figure you present to the board reflects your actual risk profile. And bow-tie diagrams make cause-consequence relationships visible to the whole project team, not just the risk manager.
(One honest caveat: software does not fix a governance culture that treats risk management as a formality. If the project director does not take the risk register seriously, no tool will change that. But if the intent is there, a structured tool makes the process faster, more consistent, and far less dependent on individual expertise.)
The question most project teams never ask
If your early-phase risk register disappeared tomorrow, would anything about your project actually change? If the answer is no, the process has already failed regardless of how complete the register looks, because a register that is a document rather than a decision-making tool is not managing risk.
The projects that consistently deliver within budget and on programme are not the ones with the longest risk registers. They are the ones where the risk register shaped the contingency budget, influenced the procurement strategy, and triggered design changes before those changes became expensive. Early-phase risk management done well is invisible by the time construction starts. You simply have a project that behaves like it was planned properly. Because it was.
If you are building or refreshing the risk process for a capital project and want to see how Risk Companion supports structured risk thinking from project inception, you can sign up for a free 14 day trial.
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.