No. Every action on a network must be directly attributable to exactly one real person. Every person should have permissions to the data/systems they need under their own account. If that includes subordinates' email inboxes and home directories, so be it.

In some cases it may be necessary to see the application from another user's perspective. In this case you build a function analogous to "sudo -i -u user" which lets the privileged employee use his own account to get a session under another user's account, while generating an audit trail.

However this is usually not the right answer. Google Apps does not provide an "impersonate" function, but API endpoints which let you dump all mail to your own archiving system (where your company can search it for investigations, legal discovery, etc.) This is more efficient anyway, and doesn't require the disclosure of user passwords.

You can also do this crudely by resetting the password in the database, gathering whatever you need to, and then changing the password back by replacing the old hash directly in the database. Then at least the impersonation is evident in your MySQL logs.

If there is an Excel sheet of passwords shared among managers, and someone does something nasty from an account whose password is on that sheet, good luck figuring out whether the perpetrator is the account owner, one of the n managers with access to the passwords list, or someone else entirely.

Context independent, having a store of usernames/ids/emails and plaintext passwords is Bad because it can be cross referenced with a store that actually matters.