A couple of rambling thoughts on the subject:

All the analogies above definitely help (I'm especially partial to the "piano down a narrow staircase" analogy). Analogies can definitely be used to get a point across in terms non-devs can understand, BUT:

There's one glaring problem here - your PM's don't listen to the developers. Either they don't like what they devs have to say (possible), or they don't trust the developers (also possible), or some combination of the above.

What I've done in the past:

• Take the project, break it into every conceivable task you can think of - a spreadsheet is handy here - one sheet for each major task, with a sheet summarizing everything.
• Each sheet should contain estimates on how long to complete the task - the rougher the spec, the rougher the estimate (e.g. be defensive in your estimates).
• As much as I hate to admit it, MS Project becomes handy here - create GANTT charts detailing each task - milestones, dependencies, etc. For each task, assign people as you can, the software will re-schedule as needed.
• Providing management with a project that forces them to acknowledge that dumping more people into the mix (don't forget to add time for them to come up to speed!) will display the stark truth.

I know this sounds like a lot, but here's an example - A few months ago, we specced a 1500+ hour project - the above estimates & timeline took about a week, and bought us a tremendous amount of leverage in scheduling the deadlines for it. We would have been dead in the water without it.

The end result? The more you continue to be right, the more trust you earn. Do the legwork necessary to back up your arguments, and you will reap the rewards down the line.