Most engineering disciplines spend a lot of time for creating designs and blue prints before proceeding with the implementation phase. The mistake is assuming that software requires that too. It requires a little bit of thinking for sure. But fundamentally, the ultimate blueprint for software is executable. Your blueprint isn't finished until it runs. The process of producing the working blueprint is the whole point of a software project. You produce an executable specification in some programming language. The process of translating that to a working system (aka. compiling) is automated and does not require any human input typically. So, you do that very often starting on day 0 of the project. Until you are satisfied with the results. And why stop there? Many software products continue after their first release.
If you are building a nuclear plant (or any similarly large civil engineering project), producing the blueprints takes many years. In fact, nuclear plants are infamous for lengthy delays during that phase. Almost like a big software project. Unexpected things happen. Which then require changes to the blue prints. And until you have those, you're haggling with authorities and other stakeholders over permits, requirements, safety, and what not. It's fundamentally an iterative process that doesn't respect deadlines. Like software. Of course building the thing is also not without challenges but there's typically no room for a lot of improvisation during that phase. So, it's relatively easy and more predictable.
You can't really plan a hardware projects until after you have the blueprints. Hardware is just like software in that sense. The difference is that with software you are done once you have those. Planning the deployment (or customer implementation as it is sometimes referred to) is relatively straightforward: take the thing, install it, and run it.