I've used this analogy... a lot of software projects start because the person who needs some software knows the equivalent of a "handyman", and they hire this person to build them the software equivalent of a garden shed. It's a small, useful little application that does its job very well.
The customer then goes back to the handyman, happy with their work, and asks them to change the software to do one more thing. A lot of times, this new feature doesn't have much to do with the original request, so it's almost like they're asking you to build another room on the back of the garden shed with a separate entrance.
Then they want to put a light inside the shed, so they have the handyman back, and he runs a single circuit from the main panel in the house, installs a pull chain light switch in the ceiling of each room and connects them to the circuit.
The customer then decides they want to run some power tools, but it keeps blowing the circuit breaker, so they call the person back and he actually has to rip out the single circuit he ran to the main panel, and install a larger conductor and a sub-panel in the shed. He had to run the wire twice, and pay for two electrical permits, etc. This is inefficient.
Then the client asks for something absurd: can you turn my garden shed into a garage? I don't want you to re-do anything you've done... I just want you to make it bigger so I can park my car in there. Then, in a lot of cases, the handyman thinks "the customer is always right" and proceeds to build additions onto 3 sides of the shed to make it bigger, knocks down the wall between the partitions, etc. Of course, the roof ends up sagging because it isn't constructed right, etc.
So the client isn't that impressed anymore, but they still want more. They ask the handyman back over and over to just add one more room, or change this existing room to do this, etc. You end up with something that looks like The Burrow and is about as architecturally sound.
Now most people aren't silly enough to try this in the construction world, but it happens all the time in the software world, because people don't make these connections:
A person qualified to build a really nice garden shed is not necessarily qualified to build a house.
If you knew ahead of time that you were going to build a house in stages, but it was only going to start as a garden shed, you'd do things differently and the garden shed would cost a lot more (you'd pour a really thick pad, make sure you ran a conductor big enough for the full load of a finished house, etc.).
In a lot of cases, upgrading from one stage to another involves undoing a lot of the work that was previously done, making it more expensive than it seems like it should be.
In the world of construction, we can give the customer a good idea what the result will look like during the design stage, but we don't have that ability in the software world. If you got it to that point, you've basically written a significant portion of the software.
The Agile Manifesto is a result of acknowledging that the software/construction analogy is broken. Things like automated unit tests and iterative release cycles have no parallel in construction. These things take advantage of the near zero cost of going from design to prototype (we call it compiling or building).