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:
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.
Fortunately, there are alternatives to schedule crashing that may be more appropriate than the crash itself.
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.