> consider whether the reliance on comprehensive digital modelling might be in any way to blame for the delays?
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.