Q:

How Do You Calculate Schedule Compression Ratio?

Schedule Compression Ratio

How do you calculate schedule compression ratio?  
When and why would you do it? What does it tell you? What benefit does this bring to a project manager?
Are there heuristics with the the ratio that are to be generally followed?

Since there is a bounty on this question, answers should cover all 3 bulleted questions and provide a thorough explanation.

A:

Think of schedule compression as the elasticity of the work. If you have zero compression opportunities, you have no slack in the schedule. Anything along the critical path slips to the right, all the activities along that path slip to the right.
What the manager needs to know about schedule compression when asked What is your schedule compression is how much slack do you have?
This means, how much can work slip to the right before you start bumping up against the delivery date?
There are several things to realize

Schedules with no slack or zero compression, are going to be late on day one. No task duration can be credible without schedule margin, since all duration numbers are random variables.
Knowing where in the you can slip and by how much and where you can't is not a "numbers" game, it is a hands on management process. The PM has to "know" where this will take place and what to do about it if it were ever to come true. This is the "get to GREEN" discussion.
Having specific ratios alone is not too meaningful, since all margin is dependent on the specifics of the project. Three weeks may be a huge amount of margin on a one year schedule and on another three weeks margin is the same as being late.
You must always have schedule margin. In the presence of random values for duration, effort, cost, and technical performance, naturally occurring variances are - just natural. It's like commuting to work on the freeway, no matter what your navigation computer says, it NEVER takes exactly that long. You always need a buffer, a margin for variance.
The best heuristics are the experience of those planning the project. Past Performance is a good heuristic. "How long did it take the last 4 times we did this, or something close to this?" Reference Class Forecasting is another approach, where you build "models" of the thing you're trying to estimate. But estimating itself is a probability and statistics discipline, so just making guesses is probably not going to be too useful. 
McConnell speaks to estimating so does Mike Cohn (but be careful about the overly simplified distribution curves, real curves are never symmetric). The work at USC on COCOMO II is also a very good place for software estimating models (Center for Systems and Software Engineering). These type models are used in places where being late and over budget is not allowed - Defense Department procurement. 
So in the end think about that commute to the airport, how do you know how much time to allow for a one hour drive? In LA (60 minutes), in Denver, CO (45 minutes) in Gunnison, Colorado (5 minutes). It depends. This is the role of subject matter experts and estimating processes.

A:

How do you calculate schedule compression ratio?
From McConnell's book, Rapid Development, he describes compression ratios from researches involving hundreds to thousands of projects. So I think you can't just calculate the compression ratio of one or two projects, as you can't know how much the project would cost without the compression.
Another method that he cites, is to make a specific research with the same problem, and give different priorities to five teams, and compare them, but again, it's just for research purposes. Maybe a more useful method that you can apply is to gather your company's historical data and match projects of about the same size and compare their schedules length.
When and why would you do it? What does it tell you? What benefit does this bring to a project manager?
I would do it to verify the effectiveness of new process or tools that are not well known or don't have enough data to prove its effectiveness, mainly with the "silver bullet branded" ones. The benefit is that you can assert by yourself if the new process/tool really fits well in your project, or if it does't justify its costs and should be avoided in future projects of the same kind.
Are there heuristics with the the ratio that are to be generally followed?
Yes. Compression ratio is not an exact number, you can't say that a practice will compress your schedule by 18.32%. It may have compressed 18% in one project, 5% in another and none at all in another one. Again, based on McConnell's book, mainly in the Best Practices chapter, he describes compression ratios (potential reduction from nominal schedule) as possibly:

None (0%)
Fair (0%-10%)
Good (10%-20%)
Very Good (20%-30%)
Excellent (30%+)

So, it's better you classify the ratio by these heuristic statements, rather than by numbers, as it shows the inexactness of the ratio.

