Why Traditional Engineering Forecasts Fail in Complex Projects — and How AI Helps

Why Traditional Engineering Forecasts Fail in Complex Projects  and How AI Helps

Engineering forecasts play a central role in how complex projects are governed. Whether in energy, transport, aerospace, or infrastructure, forecasts influence investment decisions, resource allocation, and risk mitigation strategies. Yet many engineers will recognize a familiar pattern: forecasts that appear robust during planning gradually lose credibility once execution begins.

This is not primarily a failure of competence or effort. It is a consequence of how traditional forecasting methods interact with complexity.

The challenge of forecasting in complex engineering systems

Most engineering forecasts are built on deterministic foundations. Schedules, cost models, and performance baselines are typically constructed using structured logic, defined dependencies, and assumed execution stability. These approaches work reasonably well in controlled or repeatable environments.

However, large engineering programs rarely behave linearly or stably. As projects scale up, several characteristics emerge:

  • High interdependence between engineering disciplines
  • Frequent resequencing due to late information or design evolution
  • Resource constraints interacting with physical and contractual interfaces
  • Local changes propagating across the system in non-obvious ways

Traditional forecasting methods tend to assume that once a baseline is established, deviations are exceptions rather than the norm. Change becomes the dominant condition.

Why forecasts degrade during execution

A common issue in complex projects is that forecasts remain technically correct while becoming practically misleading.

Performance indicators such as schedule variance, cost variance, or trend-based extrapolations are often calculated accurately. The problem is that they are anchored to a structural assumption of stability that no longer exists.

Engineers may observe symptoms such as repeated movement of the critical path, erosion of float across near-critical activities, recovery actions that solve one problem while creating another, and forecasts that are revised frequently but still fail to converge.

 

These are not data problems. They are system behavior problems.

Traditional methods are not designed to sense volatility, interaction effects, or emerging patterns across thousands of activities and updates. As a result, forecasts tend to lag reality rather than anticipate it.

What AI changes from an engineering perspective

Artificial intelligence is often discussed in terms of automation or prediction accuracy. In complex engineering environments, its real value lies elsewhere.

AI is particularly effective at identifying patterns of instability across large, evolving systems. Rather than replacing engineering judgement, it augments it by revealing behaviors that are difficult to quantify consistently using manual or rule-based approaches.

Examples of what AI can help detect include:

  • Repeating combinations of activity slippage that historically led to delay escalation
  • Early signals that recovery actions are increasing system stress rather than reducing it
  • Relationships between design churn, resequencing frequency, and forecast failure
  • The growth of near-critical activity sets that precede major program disruption

Importantly, these insights emerge from learning across historical execution data, not from redefining engineering logic. The underlying schedule and cost structures remain engineering led.

Lessons from applied use in complex programs

In applied project environments, AI performs best when used as an early warning and sensing layer, not as a black box forecasting engine.

Successful implementations tend to share common principles:

  • AI outputs are reviewed alongside traditional metrics, not instead of them
  • Models are trained to recognize execution patterns, not to generate deterministic dates
  • Engineers remain responsible for decisions; AI highlights where attention is needed
  • Transparency and explain ability are prioritized over theoretical accuracy

When used in this way, AI helps engineers ask better questions earlier. Instead of asking “are we late?”, teams can ask “is the system becoming unstable?” or “which interactions are most likely to undermine recovery plans?”

This shift is subtle but powerful.

Implications for engineering governance

The introduction of AI into forecasting has implications beyond tools and analytics. It challenges how engineering teams think about control, assurance, and decision-making.

Rather than treating forecasts as static outputs, they become dynamic indicators of system health. Governance discussions shift from defending numbers to understanding behavior. This aligns well with how experienced engineers already think, but often lack the data support to demonstrate.

Crucially, AI does not remove the need for engineering judgement. It increases its importance. Engineers must interpret signals, contextualize insights, and decide how to intervene in complex systems responsibly.

Looking ahead

As engineering projects continue to increase in scale and complexity, the limitations of traditional forecasting approaches will become more visible. AI offers a practical way to extend existing engineering methods, not by replacing them, but by adding structural awareness to how forecasts are interpreted and used.

The organizations that gain the most value will be those that treat AI as an engineering support capability rather than a reporting shortcut.

I would be interested to hear how other engineers are experiencing forecasting challenges in complex projects, and whether AI or advanced analytics are being explored as part of their engineering control approach.

This article builds on broader practitioner discussions around forecasting and AI that I have shared with different professional communities.

Parents
  • It's an interesting idea, however I suspect that there will be a lot of human factors hidden within the available (or not) data about how and why issues occur and how they propagate through the system.

    In many sense it's the same issues seen in health and safety and accident investigations where blame is apportioned based on the type of investigator stop rules [Rasmussen, Cognitive systems engineering, ch 6, p138ff - Lawyers look for 'blame', Medics look for injuries, Engineers look for faulty components, etc.].

    Managers are not paid to flag up problems to senior execs until it's too late. All those 'it was all greens, until it wasn't' problems [see Seddon J, "I want you to Cheat"] where the conventional aim is to be the second (not the first) to report delays, so that your delay can ride on the coat tails of others (or be hidden by the delays of others).

    AI summarises data, whether good or bad data, and most projects are one off specials with their own unique problems (otherwise they'd already have been completed and actioned at lower levels), so it become hard to find common factors that can be applied forward. 

    A lot of 'good planning' is the avoidance of 'speedy capitalism' [again, see Rasmussen, accident trajectory diagram (fig 6.3, p149): failed plans are accidents!]

    AI is definitely worth investigating, starting with previous investigations about why planning 'always' fails when it contacts the enemy of 'reality' Wink  [Who are the system owners, and do they actually want to stop such failures..? - link back to Rasmussen's 'blame']

  • Thank you for the thoughtful response, I agree with much of this, particularly the Rasmussen framing and the parallels with accident investigation and H&S. Forecast failure is rarely technical; it is usually the result of human, organisational, and incentive-driven behaviours, including the “all greens until it wasn’t” dynamic you describe.

    I don’t see AI as removing bias or replacing judgement. It reflects the system as it is which is precisely why it must be interpreted through a cognitive-systems lens. Its value is less in explaining why people hide issues, and more in surfacing early patterns of instability (e.g. critical path churn, float erosion, resequencing) that often precede those behaviours and become normalised over time.

    In that sense, AI is best seen as a disturbance detector, not a decision-maker,  a way to make latent degradation visible earlier, before organizations fully migrate into Rasmussen’s “acceptable failure” zone. Whether that leads to better outcomes, as you rightly note, ultimately depends on whether system owners genuinely want to act on what is revealed.

    Appreciate the depth of the your critique, it strengthens the discussion.

  • I'd just add that in my neck of the woods, small projects, proportionally, tend to get underestimated just as much as large ones - it's just that the numbers are each smaller in absolute terms so don't hit the headlines anything like as easily.

    The cynical side of me might even postulate that there's little incentive in producing an accurate initial estimates - as to do so would typically produce such large numbers that the powers that be would inevitably say it was far too expensive and the project proper would never get off the ground and you'd be out of a job. Put in a smaller initial estimate and things get started, you keep your job, then too much has already been spent to throw it all away and the project eventually gets finished at pretty much what it was always going to cost in reality anyway.

      - Andy.

  • a smaller initial estimate and things get started,

    Add in a little bit of deflective blame then claim the heroic recovery. Ideal programme management [C3] competence!

  • Thanks Andy — that’s a fair and important observation, and I agree that this behaviour is not limited to large projects. Smaller projects are often underestimated just as systematically; the difference, as you note, is that the absolute numbers are smaller and therefore attract less scrutiny.

    Your point about incentives is particularly relevant. In many organisations, early estimates are shaped as much by governance and approval dynamics as by technical uncertainty. When realistic estimates are perceived as “unacceptable”, optimism bias (or strategic understatement) becomes a survival mechanism rather than a technical failure.

    This is precisely where traditional forecasting approaches struggle. They tend to assume that early estimates are neutral technical artefacts, whereas in practice they are influenced by behavioural, organisational, and structural pressures — regardless of project size.

    My argument is not that AI magically removes these incentives, but that it can expose their consequences. By learning from execution-phase volatility, rework patterns, and schedule instability — rather than relying solely on initial estimates — forecasting can become less dependent on the optimism embedded at project start and more grounded in observed delivery behaviour.

    In that sense, the issue you highlight strengthens the case for moving beyond static, front-end estimates toward adaptive, evidence-based forecasting throughout the project lifecycle.

  • All very true points on all sides, I was going to make a similar point to Andy, and it's not being cynical - if projects are estimated on the worst case basis they don't get approval. That is realpolitik. (e,g, London Crossrail would never have got approval for the cost and timescale that many knew from the start would actually be involved.) Given three competing contractors, the one that tenders with the "politically correct" timescales will win the work. That's not to say that those timescales were incorrectly estimated, just that the ones that won the work will be the minimum estimates. So at that stage in the work sadly I suspect there would be little real impact of improving the estimates - my experience of project tendering (from small to very large) is that actually an experienced team is really pretty good at estimating the worst case and best case timescales and costs. Not to say AI couldn't potentially slightly improve it, but given the number of unknowns at that stage the impact will probably be slight. And in any case people will still choose the AI model that gives the "right" answer!

    BUT where I think there could be room for great improvement is improving the estimates during project progression, and to assist in modelling different scenarios, the point where project planners currently get very stressed trying to cope with the huge numbers of variations and possibilities. Once a project is launched it easier to be honest about what is likely to happen, and also decision makers need the best possible estimates for managing different scenarios. There will be a "garbage in, garbage out" problem - AI or anything else can only process the information it is given, and for innovation projects you are going to come back to either a human estimating timescales / costs for a particular tasks, or AI trying to correlate that task against other innovation tasks which by the definition of innovation will be problematic.

    So overall, don't assume that project decision makers want better data to support their decisions, often what they want is data that gives them the answers they want to hear. ("Keep sacking project managers until you find one that says the project can be delivered next week.") And again this is not cynicism, it's the stated mantra of many management textbooks and business leaders: to say that a delivery date or cost is impossible to achieve is a sign of lack of imagination or a lack of determination to work hard enough. So what these types of AI tools could potentially achieve, which is really difficult for humans on large projects, is to look at all the options and determine which parts of the project can be dropped, scaled down, rescoped etc, and what the consequences would be, so that in that type of environment clear and reasonable options can be given with the consequences fully understood.

    On that last point:

    In that sense, the issue you highlight strengthens the case for moving beyond static, front-end estimates toward adaptive, evidence-based forecasting throughout the project lifecycle.

    Actually, all projects I've ever worked on (of whatever scale) have always worked like that. They have to. The sad sight is seeing a project manager desperately trying to align the real world with a project plan that by day 2 was already hopelessly out of date. Experienced project managers know that the forecast should be considered not so much a code, more as guidelines. However as above it is certainly interesting to think how AI could make that chaotic situation far more manageable. And by coming up with credible options for ways forward which all - or at least most - can buy into, may help get away from the daft situation where everyone up to governmental level pretends that a project is going to deliver to the proposed timescales when it's clear that it's still abuilding site. (Our office directly overlooks the Paddington Elizabeth line station. We had exactly that situation where we were being told, as assessment signatories, that it was going to open in three months time, whilst we were literally looking at a hole in the ground!)

    Interesting discussion, thanks for starting it.

Reply
  • All very true points on all sides, I was going to make a similar point to Andy, and it's not being cynical - if projects are estimated on the worst case basis they don't get approval. That is realpolitik. (e,g, London Crossrail would never have got approval for the cost and timescale that many knew from the start would actually be involved.) Given three competing contractors, the one that tenders with the "politically correct" timescales will win the work. That's not to say that those timescales were incorrectly estimated, just that the ones that won the work will be the minimum estimates. So at that stage in the work sadly I suspect there would be little real impact of improving the estimates - my experience of project tendering (from small to very large) is that actually an experienced team is really pretty good at estimating the worst case and best case timescales and costs. Not to say AI couldn't potentially slightly improve it, but given the number of unknowns at that stage the impact will probably be slight. And in any case people will still choose the AI model that gives the "right" answer!

    BUT where I think there could be room for great improvement is improving the estimates during project progression, and to assist in modelling different scenarios, the point where project planners currently get very stressed trying to cope with the huge numbers of variations and possibilities. Once a project is launched it easier to be honest about what is likely to happen, and also decision makers need the best possible estimates for managing different scenarios. There will be a "garbage in, garbage out" problem - AI or anything else can only process the information it is given, and for innovation projects you are going to come back to either a human estimating timescales / costs for a particular tasks, or AI trying to correlate that task against other innovation tasks which by the definition of innovation will be problematic.

    So overall, don't assume that project decision makers want better data to support their decisions, often what they want is data that gives them the answers they want to hear. ("Keep sacking project managers until you find one that says the project can be delivered next week.") And again this is not cynicism, it's the stated mantra of many management textbooks and business leaders: to say that a delivery date or cost is impossible to achieve is a sign of lack of imagination or a lack of determination to work hard enough. So what these types of AI tools could potentially achieve, which is really difficult for humans on large projects, is to look at all the options and determine which parts of the project can be dropped, scaled down, rescoped etc, and what the consequences would be, so that in that type of environment clear and reasonable options can be given with the consequences fully understood.

    On that last point:

    In that sense, the issue you highlight strengthens the case for moving beyond static, front-end estimates toward adaptive, evidence-based forecasting throughout the project lifecycle.

    Actually, all projects I've ever worked on (of whatever scale) have always worked like that. They have to. The sad sight is seeing a project manager desperately trying to align the real world with a project plan that by day 2 was already hopelessly out of date. Experienced project managers know that the forecast should be considered not so much a code, more as guidelines. However as above it is certainly interesting to think how AI could make that chaotic situation far more manageable. And by coming up with credible options for ways forward which all - or at least most - can buy into, may help get away from the daft situation where everyone up to governmental level pretends that a project is going to deliver to the proposed timescales when it's clear that it's still abuilding site. (Our office directly overlooks the Paddington Elizabeth line station. We had exactly that situation where we were being told, as assessment signatories, that it was going to open in three months time, whilst we were literally looking at a hole in the ground!)

    Interesting discussion, thanks for starting it.

Children
  • Thank you for such a thoughtful and experience-grounded response — I broadly agree with much of what you’ve said.

    On front-end estimating and tendering realism: you are absolutely right. In competitive environments, projects are rarely approved on worst-case estimates, and contractors rarely win work by submitting them. That is not cynicism; it is commercial reality. I have seen the same behaviour across small projects and multi-billion programmes — including well-known cases such as London Crossrail. In that context, AI is not a magic solution that suddenly produces politically acceptable “truth” at the approval gate, nor would organisations necessarily choose to act on it even if it did.

    Where I see AI’s value — and where my argument is deliberately focused — is not in replacing experienced estimators at the bid stage, nor in eliminating uncertainty where uncertainty is intrinsic. As you note, experienced teams are already very good at defining plausible best- and worst-case bounds early on.

    The real opportunity is post-launch, once the project is committed and the cost of self-deception becomes material. At that point, planners and project managers are no longer dealing with a single estimate, but with:

    • constant scope churn,
    • recovery resequencing,
    • partial information,
    • and hundreds of interacting decisions that humans struggle to reason about consistently over time.

    This is where traditional forecasting often collapses under its own complexity — not because people are incompetent, but because the system is too dynamic. AI does not remove “garbage in, garbage out”, but it can surface structural signals that are otherwise invisible: volatility in the critical path, repeated erosion of near-critical float, or patterns where certain recovery strategies reliably worsen downstream outcomes.

    I also agree strongly with your final point: decision-makers do not always want “better data”; they often want defensible options. In my experience, one of the most promising applications of AI is not predicting a single “correct” finish date, but rapidly evaluating what can be dropped, deferred, resequenced or de-scoped, and showing the consequences transparently. That is extremely difficult to do manually on large, fast-moving projects — and it is exactly the space where AI can support, rather than undermine, experienced professional judgement.

    So I don’t see this as AI versus experienced project managers. I see it as a way to make the unavoidable chaos you describe more navigable, and to help teams move away from the ritual of pretending a plan is still valid when everyone knows it is not.

    Really appreciate the discussion — this is precisely the kind of grounded debate the topic needs.