The product was finished as described in the requirement documents, but generally didn't work 100% like the customer expected.
Yip, generally it's easy to make an estimate for a clear specification. But, customers rarely know what they REALLY want until they see something in production. This is a very common problem. I don't know any easy solution to that: mind-reading machines don't exist.
One partial solution is for the technical analyst to become a domain expert first. But obviously this is often not practical. Further, sometimes the main customer/manager wants something rather odd that is a quirk of their personality. You may build something that fits the domain, but they want to see their domain in peculiar quirky way.
Another partial solution is "RAD": Rapid application development tools. Someone who knows the tool well can usually spit out something pretty quick and change it fairly quick.
However, RAD tools are not known to be very flexible in the longer run, such as when UI styles and expectations change. They achieve RAD in part by marrying business logic to the UI. This marriage makes less "marshaling" code between the database, biz logic, and the UI; BUT also hard-wires it to UI assumptions. Keeping up with the UI Kardashians can be a major PITA. Just when GUI's were maturing, web came along. Just when web was maturing, multi-device-handling needs came along. The current "in" thing is going to be klunky because it's not mature yet.
For now, it looks like we are stuck with some degree of organic meandering to get something the customer is actually happy with; but organic meandering takes more time and money and is hard to estimate up front.