Schedule Compression in Project Management
27 September 2019
27 September 2019,
 0

Schedule Compression: Nearly every experienced project manager has been through it. He/she inherits a project with a difficult or near-impossible schedule and the order comes down to deliver on time. When you mention how far the project is behind, you’re simply told to “crash the schedule”, or “make it happen.”

While schedule crashing sounds so easy in theory, in practice schedule crashing is a very risky undertaking that requires some serious evaluation to determine whether crashing will actually help or hurt.

In this article, I’ll explain the underlying premise behind schedule crashing and describe some of the typical risks involved in a schedule crashing effort. The schedule crashing assessment and the risks can be brought to executive management when you advise them about how best to proceed with your project.

Schedule Crashing Defined
The Project Management Body of Knowledge (PMBOK) guide sixth edition describes schedule crashing as a type of schedule compression technique used to shorten the schedule duration for the least incremental cost by adding resources. Examples of crashing include approving overtime, bringing in additional resources or paying to expedite delivery to activities on the critical path.

From a scheduling perspective, schedule crashing assumes that a straight mathematical formula exists between the number of laborers, the number of hours required to complete the task, and the calendar time required to complete the task. Said simply, if a 40-hour task takes one person five days to complete (40 hours/one person * 8 hours/day=5 days), then according to schedule crashing, assigning five resources would take one day (40 hours/5 people*8 hours/day=1day).

The Risks of Crashing
There are many factors that might make schedule crashing impractical, including the dependency of many work activities on their preceding activities and the increased cost of communication. Additional risks of crashing include increased project cost if they crashing attempt fails, delayed delivery if the crash adversely impacts team performance, additional conflict as new team members are folded into the current team to share responsibility, risks to product quality from uneven or poorly coordinated work, and safety risks from the addition of inexperienced resources.

In short, schedule crashing at its most extreme can be fraught with risks. Managers at all levels should be very cautious before recommending or pursuing a crashing strategy.

Making the Call to Crash
So, how can a project manager decide if crashing will help? Here are seven questions that should be asked when deciding if crashing is likely to succeed:

  1. Is the task (or group of tasks) in the critical path? Tasks in the critical path are affecting the overall duration and the delivery date of your project, while tasks outside of the critical path are not affecting your delivery date. Unless the task you are considering to crash is in the critical path or will become a critical task activity if it substantially slips, crashing the activity is a waste of resources.
  2. Is the task (or group of tasks) long? If the task is short and does not repeat over the course of the project, then it’s unlikely you’ll gain any benefit from crashing the activity. A long task or task group, however, is far more likely to benefit from the addition of a new resource, as can tasks that require similar skills.
  3. Are appropriate resources available? Crashing is rarely useful when qualified resources are not available. Is there a qualified person on the bench who can be added to the project team to perform the work? If not, can someone be brought in quickly who has the needed skills? Recruiting skilled resources is a costly and time-consuming activity, so by the time the resource(s) are added to your team, the task may be complete and your recruiting efforts wasted.
  4. Is ramp-up time short? Some types of projects require a great deal of project-specific or industry-specific knowledge and it takes time to transfer that knowledge from the project team to the new team members. If the ramp-up time is too long, then it may not make sense to crash the schedule.
  5. Is the project far from completion? Often, people consider crashing when they’re near the end of a project and it becomes clear that the team will not meet the delivery date. Yet, this may be the worst time to crash the schedule. In most cases, schedule crashing is only a viable option when a project is less than half complete.
  6. Is the work modular? On many projects, the work being delivered is modular in nature. For example, in automotive engineering, it’s possible for one part of the team to design the wiring for a new vehicle model while another part of the team designs the audio system that relies upon electricity, as long as points of integration and dependencies are defined early. Through fast-tracking, or completing these tasks in parallel, it becomes beneficial to also add resources, crashing the schedule.
  7. Will another pair of hands really help? All of us have heard that “too many cooks can spoil the broth,” but this also applies to engineering, software development and construction. Consider where the new resources would sit, how would they integrate with the current team, would their introduction cause an unnatural sharing of roles?

If you’ve answered these questions and responded “yes” to at least five of the seven questions, then you have a reasonably good project-crashing opportunity; a “yes” to three or four is of marginal benefit, while a “yes” to only one or two is almost certain to end for the worse.

Alternatives to the Crash

Fortunately, there are alternatives to schedule crashing that may be more appropriate than the crash itself.

  1. Increase hours of current resources. For a limited time period and within reason, asking current team members to work overtime can help you reach your delivery date more quickly than schedule crashing. When considering overtime, it’s important to remember the caveats, “a limited time period” and “within reason”. Asking resources to work 50-60 hours a week for six months is unreasonable, as is asking resources to work 70 hours per week for a month for all but the most critical projects.
  2. Increase efficiency of the current team. Though it’s surprisingly rare on projects, examining current work processes and adding new time-saving tools can improve the productivity of a team by 10% to 50% or more if a project is long.
  3. Accept the schedule. In some cases, it’s better to offset the downside effects of late delivery rather than attempt to crash the schedule.

A Final Caution about Crashing

Because it’s rarely well understood by anyone other than project managers, schedule crashing is often recommended by co-workers who really don’t understand the implications of the decision. While they see an opportunity to buy time, they almost never see the inherent risks.

As a result, it’s critical that project managers not only assess the likelihood of success when considering crashing as an option, they also educate their stakeholders, their sponsor and other decision-makers about the risks of a schedule-crashing approach. Doing anything less perpetuates the myth that crashing is a panacea that cures all that ails a late project, potentially creating much bigger problems for everyone down the road.

Comments are closed.