
A contractor, a rail project owner and a delivery authority walk into a (we)b(in)ar: Part II
Part two of our rail webinar highlights. An owner (Wes Cadby, Transpennine Route Upgrade), a Tier 1 contractor (Paul Bradley, John Holland) and a government delivery authority (Paul Reichl, VIDA) get concrete on AI-led assurance: the demonstrable value, how AI works across a multi-party alliance, the generative tools changing the day-to-day, and their advice for anyone still on the fence.
Earlier this summer we ran a webinar that brought together three people tackling the same problem - rail programmes that overrun on cost and schedule - from three very different vantage points. Wes Cadby leads risk on the £14bn Transpennine Route Upgrade, Paul Bradley runs planning at John Holland, a Tier 1 contractor. And Paul Reichl works at Victoria's Infrastructure Delivery Authority, the government body overseeing a A$120bn 'Big Build' of more than 200 road and rail projects. Our CEO, Dev Amratia, put the same questions to all three.
In my first post covering the highlights of this (awesome) webinar, we covered the early ground: what made staying on top of delivery risk so hard before AI, the moment each of our speakers saw it prove its worth, and what it actually took to win their teams over. This time we get more concrete (in some cases literally): the value Paul, Paul and Wes have got from AI, how AI plays inside a multi-party alliance, and the newer generative tools starting to change their day-to-day working lives.
What getting value from AI actually looks like
Dev asked each of our speakers to bring the value of AI to life with a real story - check it out:
For Wes Cadby, the value of AI shows up ahead of possessions - the windows when the railway is closed so work can happen. Miss one and the whole programme slips:
Because we have so much possession access over a significant amount of time, if we miss any of those accesses, it essentially shifts our programme to the right… it can be two and a half million pounds...per possession [missed].
On a programme worth over £10bn, hitting those access windows is what the programme depends on, and Wes's point is that AI-supplemented risk analysis gives his team the confidence, well in advance, that the early enabling works will land on time. The saving isn't hypothetical: every possession they don't miss is £2.5–5m of taxpayers' money not spent clawing the programme back on track.
Paul Reichl reached, quite literally, for concrete:
We were able to ask Barry to surface how many concrete pours are scheduled in the next month and the likelihood of happening on the dates that were there sort of scheduled for. And it was able to surface that in no time.
What struck him wasn't just the speed, but who AI opens the schedule up to. He could see the same tool being useful to a comms team who need to tell the public what's happening but would never normally interrogate a project schedule. Being able to ask a plain question and get a plain answer turns the plan into something the whole programme can draw on, not just the planners.
Paul Bradley's example was a bottleneck his team already half-knew about:
There was a case at our Melton grade separation where there was a critical path bottleneck. There was some sequencing with the retaining wall and the platform. And it was showing a resource clash. Everyone kind of knew it. But it brought the conversation out, and they resolved that as a result. Fixed the programme and kind of de-risked that.
The clash wasn't a secret (people had a gut feeling about it) but the analysis surfaced it in a way that got the conversation going and got it fixed. As Bradley put it elsewhere, AI tools can give people permission to act on what they already suspect, by showing everyone they're on the same page.
AI-enabled alliances?
Next Dev turned to the topic of delivering through alliances with multiple stakeholders, all with their own priorities. He asked Wes (and Paul Reichl) whether AI-derived insights struggled to get cut-through due to the dynamics of these commonly used delivery vehicles.
Wes oversees a programme split across multiple alliances at very different stages - some with early, assumption-heavy schedules, others already building week in, week out. The hard part is getting one trustworthy picture out of all that variety:
I think what [AI has] allowed us to do is to take various different maturity of outputs at exactly the same time, put them all into one place and get a, a meaningful enterprise or programme-wide output… at the flick of a button.
The payoff, in his words, is being able to look forwards rather than back - assembling a consistent, current, programme-wide view in minutes rather than the weeks of effort it would otherwise take.
He was also clear that how you manage the tooling matters. His risk team are the custodians, but the whole programme can use it:
As long as it doesn't feel like AI is being done to people, that actually here's a tool that can help you drive your conversations in a certain way that removes any typical owner-supplier tensions that might have existed previously.
Paul Reichl, from the delivery authority side, picked up a related thread when the conversation turned to how government and funders receive risk messaging. His point was about being an informed client:
When you're an informed client, you're able to make better decisions and I think it gives you some of that capability to be more informed, and that provides assurance to a whole lot of other people… rather than it's just expert judgment.
Between them, Wes and Paul describe the same shift from their different roles: when risk information is backed by data and shared openly, rather than handed down or negotiated, it stops being a source of friction between parties and starts being something they can all work from.
The generative tools changing working lives
Next, Dev asked the speakers what they thought of nPlan's newer generative capabilities and how they're starting to change how teams work.
Paul Bradley's team is trialling Schedule Studio to speed up the slow part of a tender:
The sooner the programme is available for some iteration through that process, the better… we might have a large complex programme, but it might have a simple RC framed multi-story car park. There might be parts of it that we can, we can just speed up.
The idea is to get a programme ready for probabilistic analysis sooner, even if only the simpler parts are automated first, so the answers come back faster when time is tight.
Paul Reichl was most excited by what the conversational tools open up:
The ability for non-schedulers and planners to ask lots of questions… you can ask questions from a range of different perspectives is really where I can see lots of value.
In a government setting, where you're answering to many stakeholders, being able to interrogate the schedule from each of their angles - quickly, without diving into the detail - is genuinely useful. He's also watching the photo-based trial with interest: upload a picture of a site and get an estimate of where it is against programme, something he can see comms teams and other non-traditional users getting real value from.
Advice for anyone on the fence
Finally, the quick-fire round: what would you say to someone still deciding whether to take the plunge?
Wes Cadby kept it simple:
Start small, build trust… do not see any AI capability as a replacement to existing processes, but more a way to drive a different conversation during those sessions.
His warning is that you don't win people over by announcing you've got an AI tool. You win them over slowly, by running it alongside what they already trust and letting it earn its place - and, for the risk function especially, by keeping people in the room talking about risk rather than replacing them.
Paul Reichl's advice was to put it under real scrutiny:
Run a pilot, compare the insights with your existing processes… let people throw stones at it, then hopefully you know, when it sort of agrees with them most of the time, that's what they'll actually…want.
Confidence, he argues, is built by letting sceptics test the thing against what they already know. When it keeps agreeing with their judgement, they start to trust it, and then it can do its real job, distilling a mass of detail into something a whole team can quickly grasp.
Paul Bradley's was the bluntest:
It's not an if, it's a when. So I'd say if you're thinking about it, get on with it… the cost to us of running a trial for one year, if it saves one mistake, it's paid for itself.
His logic is hard to argue with: given how much money moves through a major programme daily, avoiding a single one-day problem very nearly covers a year's trial. There's no need to place blind trust in any tool that comes along - but, given where this is all heading, no reason to wait either.
Watch the full webinar
As I said at the end of my last highlights post, this webinar was one of the best we've ever run - in terms of showcasing a range of perspectives and generating some incredible quotes about how AI is changing the way big things get built. If you'd like to watch the whole thing, end-to-end, you can do so here.

What I wish I knew about ML infrastructure when I was a researcher
Join Carlos Ledezma, Product Manager at nPlan, on an exciting journey to optimize your Machine Learning projects. Learn how Docker can revolutionize your ML infrastructure, making code portable, reproducible, and easily deployable. Explore practical examples and expert insights to unlock the full potential of Docker in ML engineering. Dive into this blog now to elevate your career in Machine Learning!






