As a long time project manager who now advises others on how best to manage

projects and project portfolios, the term “schedule crashing” still makes me bristle. I
picture a train wreck, not a well-designed product or service that’s delivered on time,
and for good reason. 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. Then, I’ll provide seven
questions that can help you assess whether schedule crashing will really help your
project. Combined, 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

As defined by BusinessDictionary.com, schedule crashing is “Reducing the completion
time of a project by sharply increasing manpower and/or other expenses,” while
the Quality Council of Indiana‘s Certified Six Sigma Black Belt Primer defines it as “…to
apply more resources to complete an activity in a shorter time.” (p.V-46). The Project
Management Body of Knowledge (PMBOK), fourth edition describes schedule crashing as
a type of schedule compression, including overtime and paying for expedited delivery of
goods or services as schedule crashing techniques (PMBOK, p. 156), though I
generally think of overtime as another type of schedule compression – not crashing.
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

Frederick Brooks had much to say about the problems with schedule crashing in, “The
Mythical Man-Month“. In this ground-breaking work about software engineering, Brooks
explains that 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. This phenomena is now referred to as Brook’s Law–
adding resources to a late project actually slows the project down. I personally saw
Brook’s Law in action on a large program led by a prestigious consulting firm where the
client requested that extra resources be added in the final two months of the program;
because the current resources were forced to train new staff instead of complete work,
the program delivered in four more months instead of two.
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 I
ask myself when deciding if crashing is likely to succeed:

o 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 your considering crashing is in the critical path
or will become a critical task activity if it substantially slips, crashing the activity is a waste of
resources.
o 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.
o 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.
o 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.
o Is the project far from completion? Often, people consider crashing when they’re near the end of
a project and its become clear that the team will not meet it’s delivery date. Yet, this may be the
worst time to crash the schedule. Frederick Brooks told the story about his schedule crashing
attempt in “The Mythical Man-Month” where he added resources to one of his projects at the tail
end, which further delayed delivery. In most cases, schedule crashing is only a viable option
when a project is less than half complete.
o 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.
o 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.

o 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.
o 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. I once led a team that increased it’s productivity by
roughly 30% simply by re-sequencing work activities and adding a single team member to speed
up cycle time at a single step in the process.
o Accept the schedule. In some cases, it’s better to offset the downside effects of late delivery
rather than attempt to crash the schedule. In some cases, this amounts to using a beta or
prototype for training rather than a production-ready product.

A Final Caution About Crashing

Because it’s rarely well understand 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, creating much bigger problems for everyone down the road.