If project timelines and budgets are not credible, it has very real implications for the viability of future infrastructure projects. It becomes much harder to justify future spending if you can't trust your models.
Already (before than pandemic hit) the blow-outs on Crossrail were putting the north-south "Crossrail 2" line in doubt. Originally it was hoped this would get started in 2023, but I doubt there's any chance it will start before well into the 2030s now.
Don't be surprised that $20B transportation projects are being reconsidered.
[0]: https://www.theguardian.com/business/2021/mar/22/a-year-of-c...
(Not just flights - everything except essential goods including via trains, ships and lorries. Certainly all people should have been disallowed entry.)
Although I do believe there is a great future for public transit in coordination with lighter ‘last mile’ solutions simply because cars are way too bulky for cities.
Seattle had the same hand wringing around our newish rail line back in the early 2000s, now no one even knows it was late.
Also - Now that Seattle is around 85% vaccinated, offices are re-opening and the trains are full again. London is being more conservative in their approach to reopening, but they are merely months behind.
But just “full to capacity, standing room only” full, not ”full to beyond capacity, have to push and squeeze your way in before the doors close” like before the pandemic!
I remember someone commenting that given the choice, it's better to delay shipping video games if you need to fix things. This is because not long after release no one will remember it being late, but everyone will remember (hearing that) it being a pile of garbage.
Reputations are often very hard to shake.
You can ship a game with lots of bugs and missing content, as long as the price is set in consequence.
The soon to be classic example is cyberpunk. Funny this actually happened to them before with the first Witcher game, originally very buggy and had a re-release that patched it, but they were a smaller studio then and their reputation effectively unknown.
It's an incredible progress for game developers that they can ship a buggy/incomplete game and improve it over the next year. (And you can write an announcement with every update to drive sales!)
- Someone.
Maybe. 3D models have been used to design and plan projects for over 20 years now (I've been in the industry in Aus for >15 years), and so the bulk of the models are not at fault here (because if these design models were the delay, the construction would also be delayed, but the article suggests it wasn't). But when you want to go to the next level (digital twin), and start modelling every individual light-bulb, tracking it and making it function as part of a "smart system", then things will take a lot longer.
But actually, the article says;
> Despite the huge amount of construction work that has already been completed, many aspects of Crossrail do not yet have an agreed-upon final design. That’s because the complexity and uncertainty involved in building large underground structures means that detailed “fit out” designs are begun only after it’s fairly clear how the space will look.
This boggles my mind. I don't see how it couldn't all be completed at the start. The physical design should have a few flexibilities baked in, so that if the tunnel ends up a meter out of place, or the rail centerline is 200mm off target, the design should be able to absorb it with minimal re-work.
But regardless of the physical layout, they could have mocked up a model beforehand that contains all the necessary "virtual" components. They would have known what rooms/etc were required, roughly how many entities were needed per space (eg, 4 chairs, 1 table, all with data tags). Then when you have a better idea on the physical layout, you can arrange the virtual components properly.
So yes it's possible that trying to be too fancy was a major factor in the delays. I haven't worked in a professional software engineering environment, but I get the impression that at a high-level, construction engineering has similar traps and pitfalls. Just like when coding, engineers/modellers do come across problems with their initial design, and then have to face the choice of implementing significant work-arounds, or "refactor" to something different.
Information systems exist but seem to have shocking data models designed by committees. Existing software and experience is then transposed on top of this information system. But the engineers don't have expertise in data and are using software from another age that makes "drawings". Adding a live "as built" component to that is just asking for trouble.
The story might be different elsewhere, but here it is draftsman that make the 3d models and all the associated data, and to do get a job in the industry only requires 1 year of vocational education. To put it bluntly, these aren't the smartest people.