I've been a developer working for large corporations for the past 4 who are more concerned with "fast" delivery than "correct" delivery. As a result of that, the concept of Unit Testing is somewhat foreign in the environment (I think we have somewhere around 40% test coverage, our unit test suite takes ~40 minutes to run on a dev machine, and new unit tests rarely get written). Unit tests aren't "valuable" to the customer, so they are pushed out in favor of "value" code (features) and the reliance on manual QA testers to catch defects (which doesn't happen).
Imagine you were hired as a consultant to come in here and fix our process. How would you sell TDD to the bosses/managers who only see it as extra work for the same value? I'll admit I'm a little fuzzy on the benefits as well. I'm slightly ashamed to admit that even on my side projects I'm like "I'm totally gonna do TDD you guys!" but that rapidly falls by the wayside.
#2 Inadequate unit testing almost always correlates to greater defects in the support/maintenance cycle. So I would recommend gathering some data around it: for e.g., number of open support tickets, hours spent fixing such defects, regression testing etc etc. This must translate to either $$ or Hours "wasted" or additional head-count (required to deal with tickets).
#3 Identify a small but meaningful project to pilot out the TDD process. You will eventually have to develop your flavor of TDD within the constraints of your organization (people, tools, process...)
#4 Run the process for a few months and then compile the "before and after" data. Be prepared for disappointment. Process improvements are not always quick or visible at the surface.
#5 Management avoids things they don't fully understand. Most managers hear "better unit testing" and hear "more time and effort". Instead, they should hear "lower downstream issues, lower support costs, better builds, happier users".
So, can you help them understand the issue better? Just make sure YOU understand why unit testing matters to your company.