Educate them on what you need from the software—meaningful, persistent, and unique object names; access to object attributes, methods, and properties; standard classes at best or standard implementations of custom classes at worst; a stable and repeatable test data environment. Explain the implications for automation when these are missing. Discuss whether these issues exist in the application and what the effort and schedule will be to remedy them.
Overcome resistance to investing development resources in enabling automation by pointing out that the rigor and conventions required for automation also make the code more maintainable and transferable over the long term.
Be prepared to pull the plug on automation if you identify significant issues but no solutions are forthcoming. There is no reward for hard work if it doesn't get you anywhere. As they say, discretion is the better part of valor. If the application is a loser, face it and deal with it. Let management know that automation is not feasible and either look for another application to automate or wait until the changes you need can be made.
On the bright side, my experience shows that the more developers understand about automation, the more testable the applications they build and the more willing they are to cooperate. Even doing it the good way doesn't mean the outcome is guaranteed, but it will save you a lot of time and grief because you will find out sooner rather than later whether your relationship with development will survive automation.
What has your experience been? Share your comments below.