Ask if they have a security policy. If not, find out if anyone would be responsible for creating one. If not... consider proposing a policy, something like this, but tweak it... it's got some problems : http://www.sans.org/security-resources/policies/Password_Policy.pdf
Throw in a caveat that when the policy is in conflict with an existing policy, such as PCI, the stronger policy wins.
Add a review clause (e.g., annually) a questions-directed-to notice, an exception process, and versioning with a date. If anyone has questions, suggest they attend your annual meeting.
Introduce it with an announcement and review period, e.g., 3 months. Allow for feedback. Hold your first meeting. Hand it to management and hopefully have it declared a policy.
Then develop a process for your team to manage passwords. Suggest the process as a guideline for other teams to create a policy-compliant process.
Once in place, consider tools to audit password strength.
edit: btw, I agree with @webtoe on this one. This is an area IMHO where the old password policies like the one at SANS need tweaking. E.g., 8 characters, mixed case, alphanumeric, special characters, no dictionary words, blindly requiring 30 day password change policies, forbidding ssh-to-root, demanding no writing of passwords down, etc, is just asking for trouble. OTOH, if you give too much flexibility, people will get sloppy. Every aspect of password management needs a rationale and should be able to be challenged.
One of the stupidest password policies I encountered required an automated scan using a tool which would check for password strength. My automation IDs for SSH got hit repeatedly because password authentication was disabled, only public/private key was permitted. Unfortunately this meant that I had to create a cron job to create a random password every 90 days. It wouldn't communicate it, but the policy effectively reduced the security of the solution.