What should be in your policy. Your policy should specify several things:
Minimum password length/strength. For instance, requiring that the password be at least 8 characters or longer makes sense.
Password selection methods. Advise people on good ways to select a password. People aren't very good at choosing strong passwords, so your password policy should provide guidance about how to do this. The best solution might be to provide them with a tool to automatically generate a random password for them. Alternatively, you could suggest how people can choose a strong password on their own (e.g., pick a short phrase that will be memorable to them and that no one else is likely to use).
Password handling. You should tell people to never share their password with anyone else. You should promise them that sysadmins will never ask them for their password. You should prohibit sysadmins and other staff from ever asking anyone for their password. You should specify the penalty for violations.
Cleartext passwords. I recommend that your policy prohibit transmission of passwords in cleartext over the network: in other words, it should require that internal services and applications be designed to avoid transmitting passwords in cleartext over the network, and it should prohibit services and applications (e.g., telnet, non-anonymous ftp) that transmit user passwords unencrypted over the network. Your policy might specify a phase-in period and a process for getting approval for exceptions, if necessary.
What should not be in your policy. You should not require users to change their passwords every 90 days. This is a lousy idea. It is horrible for usability. And, it does not improve security: it's one of those things that superficially sounds good to non-experts, but does not actually add any significant benefits that I know of. In particular, it does not really help defend against any realistic threat model I'm familiar with. If you're lucky, it may cause people to choose a predictable sequence of passwords (e.g.,
xlkjsadf3, etc.). If you're less lucky, it may make security worse, by forcing people to write down their password somewhere (a yellow sticky note attached to their monitor is the traditional method).
Possibilities to consider. Depending upon your circumstances, you might also consider the following:
Non-password authentication. Passwords are not the end-all, be-all of user authentication. For high-risk activities (e.g., sysadmins with root/administrator access to critical machines), you might consider requiring other forms of authentication, such as RSA SecurID cards. They are generally more secure than passwords.
Password escrow. There are some cases where you might want to require employees to escrow a copy of a password with the company. A typical case is where the employee signs up for some external service (e.g., Amazon EC2) and has to specify a username and password for the account with that service, and where the external service does not provide any way to link more than one username with the service, and where the external service is relied upon or used by multiple folks in the company. In that case, if the employee who created the account leaves the company, you may lose access to the account on the external service. One solution is to ask the employee to escrow the password they created for that account with the company: e.g., put it in an envelope, seal the envelope, sign over the flap, and place it in a locked safe controlled by their boss or some other employee.