From the dev perspective this is the problem. There are few workflows that can be described to the developer, who then develops it and throws it over a wall, and it's successful. All of the successful project's I've been part of have been iterative.
Best is when I'm an actual user of a system I'm developing, eating my own dog food as I go, being the user who is feeling the pain. That was the case for much of my career.
Next best is having to handle the user tickets for the system you wrote, which is what I frequently do now. Every ticket is an opportunity to patch and fix and refactor to remove the need for the next such ticket.
I don't think I've ever written a non-trivial program, however thoroughly planned and specified, that was fit to purpose before it was used, and heavily.
Development contracts should be written with this in mind. They either need to extend well into the "post development" phase, or include staffing or training as needed to continue development far past release if not for the life of the software.