I think Alexander's ideas and patterns are very lean processes instead. He see what's the terrain like, what's the use like, builds a bit, and reevaluates along the way. He even explicitly have drawings rendered 'for regulation' but changes it after it's built.
Context: I'm assuming Alexander here refers to Christopher Alexander. He has authored books related to identifying architecture patterns with 'liveness' in them, from the very small to the big scale. I think a lot of his ideas can be applied to software too and even really matches up with Extreme Programming. I recommend reading The Nature of Order for the fundamentals of his ideas and how it fits with the world. I'll refer to him as CA in this comment.
I think it's the overspecialisation of roles and the 'waterfall' aspect of the engineering that normalises this. The architect don't (or can't) verify whether their designs work along the way. CA once described a story where he needs a constant feedback with the soil engineer for the start of the project but his request is denied by the client. The client wants the engineer to start and finish his survey first and then for CA to receive the reports only. CA ended up declining to work with the client due to that. As with Software Engineering/Development, there are questions that only surfaces when we do a part of the building, and can't be predicted. This is why the continuous feedback is important. I'm not sure whether the architect in your case _can_ come back to the site and direct the constructors against the drawings, even if the later directions are more suitable to build.
It's a bit weird that now we're taking missed plans as the default, when the Empire State Building (and NYC skyscrapers of the time) ran ahead of their schedule, with Lean principles by focusing on constraints and workflow instead of planning the minute details: https://chrisgagne.com/1255/mary-poppendiecks-the-tyranny-of...
I'm afraid that a lot of churn in Software Development also comes from a similar overspecialisation, overplanning, and the wrong kind of feedback loops. 30% of costs wasted seems like the better end for software. The difference is that building physical buildings has happened for thousands of years and there is a lot of history to compare with the current day. Software has at most 100 years of history, and currently it's still very much the wild west and every team is trying to stumble upon a process that is sustainable. This doesn't even count that a lot of developers see themselves and the job differently, and the organization also sees the Tech/Engineering team differently.
This comment is more of a rambling than a coherent thought, but I thought I'd get it out there. I'm sure I'm not the only one feeling like the current Software Development process is a mess. There has been good efforts (Extreme Programming and agile, not branded Agile) and current good effort (Basecamp's evangelism of their work process and the Shape Up book) to carve a sane way, but it needs to be the normal practice instead of the contrarian view/practice.