A negative comparison often seems to be made between software engineering and construction, but it seems to me that the latter is a unique subfield of engineering, where you have an unusually large number of projects with a roughly homogenous set of constraints and variables. This has allowed those constraints and variables to be studied, understood and mastered to produce a discipline that more closely resembles mass-production. And in those subfields of software that also involve more homogenous constraints, such as the production of standard commercial websites, you do see a more controlled and templated approach, using tools like Wordpress.
It follows this trend I've seen across the board in business throughout my career, of mistaking the last hair on the last yak for the entire job. The classic example is documentation. "Hey the electrical drawings are due on Thursday the Aprilteenth, can you have them ready by then?" Oh sure, that's two months away, that's plenty of time to bang out some drawings, right? But wait! The drawings depend on the functional specification. And the functional specification depends on the functional description. And the functional description is blocked on some TQs from the client. And you're still expected to produce these drawings by Thursday Aprilteenth when realistically you're not going to see even a first draft of the functional specification until the Wtf'th of August. But now it's your fault that the drawings are late because you weren't paying attention and you agreed to a due date that didn't depend on your dependencies.
I take this one particularly personally because I'm in industrial automation and, almost by definition, we get the last bite of the pie on every single project. Sure, there are some things we can start early but on the project-specific parts, generally we're waiting for everyone else to do their job before we get priority.
"Can you help us with the motion control software for AwesomeBot?"
Sure, no worries!
"Just remember we need AwesomeBot running by Thursday."
Hey cool, you present me with an AwesomeBot-shaped shell and I'll fill it with closed-loop-ey goodness.
"It's Friday, why isn't AwesomeBot doing somersaults like you told us it would?"
Uh well, AwesomeBot is lying disassembled on the mechanical workbench and half the laser cut sheet metal hasn't arrived.
"But you told us Thursday! Okay, we'll finish putting AwesomeBot together and let you know when it's done."
<fast forward 17 months>
"Hi remember us? We're AwesomeBot inc."
Oh hey how's it going with that?
"We've got AwesomeBot fully assembled and we're ready to go! Can you come down tomorrow and install the software on it so it does everything we ever dreamed of including anything we might have imagined it might do in the 17 months since we last saw you?"
Uhhhh... so how's testing going, have you switched it on yet?
"No, why would we do that? We were only waiting for you!"
We are very deliberate about setting deliverable dates in time after the required inputs by others are available, and when inevitably they are not, we have a spreadsheet sent to the customer every 2 weeks which shows what information we are missing and the delay that is causing to our progress. As we are liable for damages if we delay the project it is necessary for us to have the proof that we did not cause the project to be behind schedule. This often means having these difficult conversations only a month in to a year long project when vendor drawings we were promised are not delivered.
This is a great approach if you can stay that organised. It reminds me of one of my fundamental rules of business - the two benchmarks you're compared to are the previous entry in the Gantt chart and your counterpart in the client organisation. If you can stay ahead of both of those, you're golden!