Why Public Rail Projects Take 20 Years — And Why The Schedule Knew First

A construction scheduler with 30 years on transit programs says the causes behind every major rail delay were sitting in the program schedule years before they became headlines — not hidden, just reported in a way nobody was asked to read.

Damon Dewey, principal planner at CPM Pros, a construction scheduling firm, makes that case in an op-ed arguing that the familiar post-mortem findings — late funding, long environmental review, unexpected utilities, poorly integrated contracts, testing overruns — are treated as things that happened to a project when they were actually visible in its schedule data all along.

"Every major rail post-mortem reads the same way," Dewey writes. "Funding arrived later than planned. Environmental review took longer than expected. Utilities turned up where the drawings said they would not. Contracts did not integrate cleanly. Testing and commissioning ran long."

Each finding is true, he concedes. His point is about what the reporting failed to surface.

What does monthly reporting actually show?

Board and funding-partner reports typically carry three items: the revenue service date, a percent-complete figure, and a risk list. The revenue service date holds, Dewey writes — until, suddenly, it doesn't.

Underneath that date, the schedule is often telling a different story month after month:

• Float is consumed on the paths leading to funding milestones
• Utility relocation activities slip in small increments that never individually reach the report
• Integration testing is modeled as a few long bars, so upstream slips disappear into them until the final months, when the date moves all at once

None of this, he argues, requires new software or a new method. It requires asking the schedule different questions.

Report float by funding milestone

Public rail is paced by money as much as by construction. Full Funding Grant Agreements, annual appropriations and local funding commitments all arrive on their own calendars. Yet program reporting rarely tracks schedule float against them.

His fix: each month, report the float remaining on the path to every funding milestone, not just to revenue service. A path losing 10 days a month for six months is telling the board something important long before the service date moves.

"The decision to re-sequence, re-scope or seek bridge funding is cheap at month two and expensive at month 18," Dewey writes.

That's a practical distinction for project controls staff and program managers: the same data, sliced against a different milestone set, changes when the decision window opens.

Model integration testing at real density

On a new line or major upgrade, systems integration testing is where the separate contracts finally have to work together — train control, communications, traction power, stations, fare systems and vehicles. Dewey counts it as hundreds of interdependent steps, each waiting on the readiness of systems built by different contractors.

Program schedules routinely show that work as a handful of bars with comfortable durations. When upstream work slips, those bars absorb it silently. Then the testing period arrives, the real sequence asserts itself, and the opening moves by a season.

"Model testing at the density it actually has, tied to the readiness of every contributing system, and the schedule will warn you a year early instead of a month late," he writes.

Treat reviews and outages as risks, not milestones

Environmental review, historic consultation, track outages and utility agreements are often shown as single milestones with fixed dates. Dewey says that's the wrong frame: they are processes that can reopen, slip or be lost entirely.

The cost of getting this wrong compounds fast. A lost weekend outage can cost a month or more, he notes, because the next available window may be that far away.

His prescription is to show these items as activities with owners, durations and the conditions that could reopen them. "A schedule that shows the National Environmental Policy Act as a dot on a line has not priced reality," he writes.

What practitioners should take from it

Dewey is careful to keep the ask modest. Nothing in his proposal is exotic: it's a monthly schedule review that reads float by milestone, models integration at real density, and treats external processes as risks, reported plainly to the people who fund and govern the program.

For scheduling teams, that means the change lands in how existing critical path method outputs get summarized and escalated, not in new tooling. For boards and oversight bodies, it means the monthly package they receive should carry float-trend data against funding milestones, not a single date and a percent complete.

Dewey's background spans construction scheduling, project controls and forensic schedule analysis on transit, airport, hospital and data center programs. His closing argument cuts at the governance layer as much as the technical one: "Public rail will never be fast, but the 20-year project is not usually a surprise to its own schedule. It is a surprise to everyone who was only ever shown the date."