Ms. Laurianne, when we deliver documents which EXPLICITLY define data/database design standards & expectations from the request for quote to final acceptance -- the entire lifecycle of the project -- & have built a validation tool to ensure those standards are met, the problem then lies COMPLETELY with the outsource vendor. In effect, the vendor is telling US what standards s/he is going to comply with & which we may not-so-politely stuff in our ears -- regardless, the vendor expects to be paid for an unfinished, non-compliant deliverable. We refuse to accept the product, the vendor begins whining, & the real fun begins.
My point: In the couple of years my company has been outsourcing application development projects, it has been the outsource vendor as the source of 90% of insufficient communication, conflict, & tension. The implementation time required to get the outsource project functional has increased from 6 to 10 hours to 2 to 6 weeks -- a good bit of the added time showing the vendor where IF our standards had been complied with in the first place, the issues encountered would never occurred. The vendors know LONG before implementation -- because we provide the findings reports from our validation tool -- their deliverable is out of compliance; there's no last minute 'gotcha!'.
They don't want to comply with data/database design standards because the coding tools they use are constructed for optimized CODE. From that code, a database is, basically, reverse-engineered. They're coders -- that's what they do & they're good at it. I remember back in the Dark Ages when coders did everything from gather the requirements to write the programs to design the databases to implement the whole kit-&-kaboodle. I remember because I was one.
Coders are a lot like race horses: They're blindered so they can only see what's directly ahead of them. That's what makes a good coder. See problem, fix problem, next problem.
Architects have to see the entire race track -- taking the analogy further. As a matter of fact, we also have to see the stands, offices, parking lots, etc. We HAVE to keep a handle on how the "everything" fits together. Design standards enable us to do that more effectively & efficiently.
The other 10% of all project issues usually belongs to users changing their minds after development has begun. But that is an entirely different herd of ponies.