I'd guess the usage of [Waits on client to provide specs...] in the software scenario is a bit facetious.
Often clients can't produce specs sufficient to build an application. Some clients may produce 'specs' which are incomprehensible, making them impossible to estimate.
The crude part is, that such projects may still go on, and worse, the client may believe that the application is actually being built to the specs.
Often clients can't produce specs sufficient to build a house/building/pipeline. That's why there is an entire category of firms that exist that are hired by clients to produce these documents.
Guy wants an apartment building, he hires an AE firm and tells them "I want an apartment building" and they say "well what kind of apartment building?" and then goes through the exact same process of defining scope, budget, and schedule that would be done in any other project management field. Lawyers get hired when someone wants to sue someone - "well what do you want to sue them for?" Sourcing managers get hired when someone wants to make something - "well what do we need to buy?"
The fact that the software engineering industry refuses to acknowledge that their industry is not special is a constant source of confusion for anybody who has been doing this in another industry. Why is the software industry special? What makes software so nebulous that scopes cannot be defined and estimates made? The argument that "people don't understand the impact of requests" does not hold water - people don't understand that simply wanting more room in a particular part of their house can cause an entire redesign. That's why you, as the expert, have to explain the impact of their requests clearly rather than just agree to them.
The problem with estimates and scheduling in software engineering isn't a result of work, it is a result of failure by the project management.
You can ask an architect or a builder how much it is going to cost to build your house. They will ask for blueprints and finishes. If the person asking doesn't have specs then the builder or architect will often offer to help them create them... For a price. Most people that want software developed want to know how much it will cost to develop software without having to invest time or money in first developing the specs. The issue is that people who what software developed either don't know too get or don't want to pay for blueprints, then they complain when things go off the rails whether cost, delivery date, or quality... They fail at managing risks themselves (by not minimally getting specs first).
"The problem with estimates and scheduling in software engineering isn't a result of work, it is a result of failure by the project management."
The problem with estimates in software engineering is that few want to pay for them. (Which hinders the formation and demand for the category of firms to produce specs.)
"$300/hr + expenses; hours and expenses determined by necessity to complete work; work as described represents at least 100 hours effort and $x in expenses"
"How much is it going to cost to build my house?"
"Er, I'd rather not commit to a price. We'll figure it out later."