# 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.

• Can you reformulate the question to describe the actual problem you're facing, or is this just intended as an abstract question? – Todd A. Jacobs Jul 17 '12 at 12:12
• No actual problem. – David Espina Jul 17 '12 at 12:51
• It is not an abstract question. It is looking for a fact based answer/a specific method or set of methods. It is definitely in the realm of project management knowledge and is something that other practitioners would find useful. – Mark Phillips Jul 18 '12 at 4:44
• David, what ratio are you thinking of - compression cost vs ROI, or ?? – Trevor K. Nelson Jul 20 '12 at 22:17
• I'm not sure. This was referenced in Glen Alleman's Project Breathalyzer's critical project questions. Literally, that was the first time I have heard of it. I understand schedule compression but I am not sure the variables for the ratio. – David Espina Jul 21 '12 at 12:11

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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
• Hi Glen, great answer! I was wondering if you could clarify your last point. If the PM is the person who needs to get to the airport and who knows the deadline (flight leaves at 3:20pm), would a good analogy for the subject matter experts be city residents who have experienced the variations in commute times to the specific airport in their city? In other words, if you came to Portland and had never been here before, would I be your subject matter expert in this case? Thank you! – jmort253 Aug 3 '12 at 1:20
• @Jmort - Yes good analogy. This is the transition to the Reference Class Forecasting process. "Go find people who have done this work before and ask them." Or better yet, go look at how long it took to do the work from the "past performance" for the same or similar "class" of work, and use that as the starting point. – Glen Alleman Dec 30 '12 at 20:28
• Hi Glen, thanks for the follow up! So it sounds like you wouldn't just rely on my "gut advice" on the times it took me to get to the airport; instead, it sounds like you'd want real, factual data to build a model. :) ..... As an aside, I merged your new account and your old one so you can do more stuff on the site, like commenting on posts, upvoting, posting in our meta site, etc. If you register, you'll retain your reputation score and account. Hope this helps, and welcome back! :) – jmort253 Dec 30 '12 at 23:48

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.