What if Enterprise IT built a race car?
scriptrock.com
scriptrock.com
People notice when a car performs badly. Its horrible to drive, and likely will kill people.
Horribly written software, however, can be made to perform well under common usage, even if it fails spectacularly for every single edge case. For most edge case failures, chances are the user is going to be blamed, because most likely, the user doesn't know the correct way to hold the mouse.
And the more endemic problems with horribly written software: maintenance, and difficulty of upgrade, are both easily waved away by those making software decisions from a business perspective. Difficulty of upgrading software is a non-issue (assuming that business data is stored in a db somewhere, sanely), it just becomes a business decision of when to completely replace their current system with the best technology on the market 5 or 10 years from now. And maintenance in the meanwhile is largely a non-issue if you don't plan on steadily upgrading and improving your software, which really, most large places simply don't. The C-level exec isn't the one using the software, and really, as a result, many of them simply don't care.
If you look at it through that light, the IT process the OP describes makes complete sense. Send in an architecture team that proposes the world to the customer, and gets the largest possible contract signed. Send in developers, and minimize cost everywhere, only actually deliver on things you know the C-levels will check, because you know they won't check almost anything, and they certainly won't care about a source code report. Then send in your QA team, to make sure the company who built the software meets bare minimum contractual obligations, and where they haven't, the customer won't notice.
... sigh