Written by Jeff Graham, Enterprise Account Executive, ALICE Technologies
The Eglinton Crosstown took 15 years to build, ran billions over budget, and became a byword for everything that can go wrong on a transit project. Adding insult to injury, a UK construction channel made a YouTube video about it titled "Canada's Guide on How Not to Build a Railway"—it has 1.8 million views.
Then there's Finch West, which opened four years late. And current reporting says the Yonge North subway extension is slipping into the mid-2030s, dragging the Ontario Line with it.
A lot of that is genuinely bad, and Eglinton in particular earned a lot of the criticism it got. But if you've spent enough time around large project schedules you'll know the picture is more complicated than a delay story makes it look.
A subway extension like Yonge North means boring kilometres of tunnel under a live city. Billion-dollar procurements with long-lead equipment. A dozen agencies and contractors who all have to move in sequence, where one party's slip becomes everyone's slip. Most of what moves a date on a job like this sits outside any single team's control, and the Toronto Star only ever shows up for the bad version of the story.
So this isn't a blog about anyone doing it wrong—the work is genuinely hard. Instead, I want to focus on the part of megaprojects I think we still handle worse than we should: the schedule itself, and specifically what happens to it the day reality moves.
The job nobody sees
Before I get to the schedule, it's worth mentioning what the people running these programs are actually holding.
A scheduler on a project like this is carrying tens of thousands of activities, dozens of contractors, fixed milestone dates written into contracts, and a critical path that shifts every time a single input moves. The owner's team is balancing a public budget, political timelines, community disruption, and the simple fact that they answer to everyone and control almost nothing directly. The contractor is managing the same uncertainty from the other side of the table, where every slip carries cost exposure they can't fully see coming. And all of them are doing it with tools that were built to record a plan, not to rethink one.
A decade-long build that slips is a real miss, and pretending otherwise insults everyone who was counting on the date. But most of what moved these dates was hard in ways that had nothing to do with competence, and the same teams absorbed a hundred problems that never became headlines because they got solved.
That's the part I think gets lost. So the question worth asking isn't "why can't they hit the date" — it's "what could give people doing work this hard a little more room."
The recovery plan gets built last, by hand, under pressure
There's a pattern on almost every large program. The schedule is built carefully up front. It gets risk-analyzed, often with a Monte Carlo tool that returns a probability distribution: an 80% confidence date, a P50 and a P90, a tornado chart of the risks driving the spread. These tools are useful because they tell the team how exposed the project is.
But then a long-lead item slips, or a permit lands late, or a tie-in window gets compressed, and the date moves. At that point the risk model has done its job and stepped off the field. It told them the slip was possible. What it didn't tell them was what to do about it.
So the planner builds the recovery plan by hand—opening P6 and reworking the logic: What if we add resources here? Resequence those two areas? Shift the order of work where it isn't fixed? Each option takes hours, sometimes days, to model, and realistically they get through only three or four before a decision is due. The recovery strategy comes together weeks after the date has already moved—under the exact time pressure that makes good decisions hardest.
I recently spoke with a planner who put it plainly. His risk tool gave him probability outputs, but when he brought those to the project team and the client, no one could act on them because a distribution isn't a plan. So he fell back to modelling acceleration scenarios by hand. The risk analysis and the recovery work lived in two different worlds, and the only bridge between them was him. Working manually. After the fact.
A schedule that can answer back
The idea I keep coming back to: the schedule should be something you can ask questions of, not just a record you maintain.
Right now, for most teams, the schedule is like a drawing. It shows the plan, but it can't tell you what else was possible, or what to do when the plan breaks. The shift that matters is turning the schedule into a constraint model—one that knows the rules behind the plan: which activities depend on which, what resources you actually have, which sequences are physically possible, and where the hard constraints sit that genuinely cannot move—things like density, physics, a shutdown window, or a permit date.
If the schedule knows its own rules, you can ask it things you can't ask a Gantt chart. Things like: if we need to pull the end date in, what are our options—and what does each one cost? Instead of hand-building three scenarios, you give the model room to move within the rules and let it return every viable schedule that fits—not one answer, but a set of feasible plans, each with its own completion date and cost. Then you choose the trade-off you can live with, rather than the first thing you had time to model.
This is the part of the problem we work on at ALICE, and the numbers are real. One team came to us with a project running 121 days late. The questions weren't abstract: how much can we claw back, and what does it cost us each way? The scenarios came back as concrete, sequenced schedules. One pulled 30 days of recovery, landing at 91 days residual. A second pulled 56, landing at 65. And a third faced the case every project leader eventually hits—when full recovery isn't feasible, hold the line and minimize the cost of the delay instead. Three real plans, three honest trade-offs, in an afternoon.
The best version of this isn't reactive at all. You run your normal risk analysis, take the handful of risks most likely to actually bite, and pre-build a recovery plan for each one—before a shovel hits the ground. Then, when a risk occurs, you're not starting from a blank file under pressure: you already have the plan modelled and ready, and the conversation shifts from 'how bad is this?' to 'which of these paths do we run?' And because it started as your real schedule, the option you choose goes straight back into P6 as a plan your team can actually execute—not an answer trapped in a separate tool nobody trusts.
The projects don't get easier
None of this makes a tunnel dig faster, and no scheduling approach on its own decides how a project like Eglinton or Finch West plays out. The constraints are real, the interfaces are real, and a lot of what moves these dates will always sit outside any one team's hands.
But there's a difference between finding out about a slip from the schedule — weeks late, with no plan in hand — and finding out from the model first, with viable recovery paths already on the table. For an owner, that's the difference between absorbing a delay and steering it. For a contractor, it's the difference between defending a slip and managing one. For the people doing this genuinely hard work, it's a little more room to make the next call from a position of choice rather than scramble. On projects this complex, I think that's where the real opportunity is.
You can read the article as published on Jeff's LinkedIn blog post here.