What Is Crashing in Project Management? The Ultimate Guide

Changes and hiccups are an inevitable part of project management, and they can sometimes cause your project to take much longer than expected. 

But, what happens when issues occur, but the final project deadline can’t be pushed back? Or if the stakeholders suddenly request that you finish the project sooner than originally planned?

In this case, compressing your schedule might be your only option.

Crashing and fast tracking are two commonly used schedule compression techniques. 

This guide will focus on crashing in project management, and it will walk you through the following:

• The definition of crashing,
• The difference between crashing and fast tracking,
• Examples of what crashing looks like in practice,
• Common reasons for crashing a project, and
• Steps you ought to take to make sure your project crashing goes smoothly.

What is crashing in project management?

Crashing a project means speeding up the project by employing additional resources, in cases where the project scope and the project deadline cannot be changed.

In PMI’s PMBOK Guide — 7th Edition, crashing is defined as “a method used to shorten the schedule duration for the least incremental cost by adding resources.”

You can think of it as cramming for an exam — the exam date and the amount of learning material won’t change, so you have to utilize all the resources and brainpower at your disposal to finish studying in time for the exam, while the clock is ticking.

Now, crashing is a highly useful and important project management tool — but it should be used sparingly.

Since crashing a project entails a large budget increase for employing additional resources, it should only be used as a last resort when:

• It’s impossible to delay the project deadline,
• It’s impossible to reduce the scope of the project, or
• When the cost of missing the deadline is greater than the cost of crashing the project.

That said, the best, and most effective time to begin crashing a project is as soon as the need for it is identified. 

According to research published by the International Digital Organization for Scientific Research, crashing can increase the quality of work and reduce the duration of the project by as much as a third. 

But, to be successful, “project crashing should be calibrated, decided upon, and applied at the very start of a project for effective results.”

Crashing vs. fast tracking in project management

Crashing and fast tracking are two commonly confused techniques for speeding up the project timeline.

Crashing, as we said, involves adding more resources (most often more manpower) to the project to make up for lost time and finish the project by the agreed deadline. As a result, crashing is expensive and should, therefore, be used only after careful deliberation.

Fast tracking refers to cutting the time needed to finish the project by taking two or more tasks that were meant to be performed separately, one after the other, and doing them at the same time.

Fast tracking is a much cheaper choice than crashing a project — but it’s not always possible to pull off as some tasks can only be done after others have already been completed. 

In cases where fast tracking is possible, project managers might choose to do it first, or even try suggesting a reduction of scope, before resorting to crashing.

Example of crashing in project management

Contrary to popular belief, crashing is actually a very straightforward concept — pay more to get things done faster.

Let’s make things simple with an example from day-to-day life. 

Imagine you’re moving to a new apartment and you have to get all your things out of your old apartment in two days because that’s when the new tenant is moving in. 

The deadline is non-negotiable, you have a lot of work to do, and you can’t do it in time with the resources you currently have at your disposal. 

Your only option is to speed up the process by either calling friends to help you out or hiring a moving company, both of which will cost you money (either a round of drinks or a movers’ fee). 

Your job as this project’s manager is to determine:

• Whether taking action to speed up the moving process is necessary, 
• Whether you have the funds to support these options, and if you do,
• Which of the two options will give you the results you want for a lower price.

5 Common reasons for project crashing

There are many reasons a project manager might choose crashing as the best course of action.

Surprisingly, not all of them have to do with getting the project back on track. 

Here are the 5 most common reasons project managers choose to crash projects.

Reason #1: Major delays

Delays at one or more critical project stages are probably the most common reason for crashing a project. 

Regardless of all the planning and risk management project managers do, sometimes, issues arise due to elements that are out of their control. 

Perhaps the weather is causing unforeseen problems, or important goods or resources got held up at customs. Whatever it may be, with an immovable deadline looming ahead, crashing is sometimes the only viable course of action.

Keep in mind that, while crashing is an extremely effective technique, it’s best to never have to use it in the first place.

It’s true that, sometimes, unavoidable circumstances can force your hand. However, with proper planning, good project management skills, and reliable project management software to back you up, you should be able to carry your projects to completion without ever having to think about crashing.

Common issues like inadequate work distribution, overlapping deadlines, and misalignment among teams can be easily avoided with the help of digital project management tools like Plaky that allow you to keep track of progress and stay on top of all your teams in one place.

Reason #2: Unrealistic deadlines

It’s never easy to determine how long a project will take, and project managers do make mistakes. 

It might be that the project manager assumed that the project would take 6 months to complete, when, in fact, 9 months would be more realistic. Or perhaps it’s not their fault, and it’s the stakeholders who are pushing for the project to be finished sooner rather than later.

Another possible reason is the appearance of an emergency project that can’t be delayed.Whatever the case may be, unrealistic deadlines create a host of issues in project management, but even more so when the deadlines are set in stone. In cases like these, project crashing is often the only solution.

Reason #3: Staff reassignment

In cases where a company is working on several separate projects at the same time, or several smaller projects as part of a larger program, the available staff can sometimes be called to help out other teams, leaving their own team short of people.

Even more commonly, people can get sick or quit mid-project. 

These kinds of staff shortages can cause delays left and right. As a result, additional qualified people must be called in to make up for the losses.

Reason #4: Change in priorities

It’s not uncommon for project managers to work on several projects at a time. Sometimes, an important new project will crop up that takes priority over all others. 

In these cases, project managers might choose to crash a project to make sure they finish it as soon as possible, so they can dedicate their full attention to the shiny new project — or they might be ordered to do so. Regardless, a priority change is a relatively common reason for project crashing.

Reason #5: New resources become available

Companies often have training or internship programs where new recruits come to learn about the work through hands-on experience.

Programs such as these are an amazing opportunity for project managers to get more hands on deck without incurring high costs. 

Project managers might sometimes choose to utilize these resources even if their project is not in immediate danger of missing the deadline — simply because it provides a good opportunity to get ahead on their project.

5 Simple steps for crashing a project

Say you’ve thoroughly analyzed your project, and you’ve determined that crashing is the best course of action — how would you go about it?

Before crashing your project, it’s important to conduct a crash analysis.

In this section, we’ll explain the 5 crucial steps of crash analysis you have to go through to make your crashing successful:

• Define the Critical Path,
• Identify activities that can be crashed,
• Identify crash limits,
• Calculate crash costs and benefits, and
• Get approval from stakeholders.

Step #1: Define the Critical Path

The Critical Path is the longest string of dependent activities in a project. 

A project typically has one Critical Path and several other Non-Critical Paths. While each path is constructed from dependent activities, the paths themselves are independent of each other and can, therefore, be performed in parallel.

In the image above, the C-string of activities is the Critical Path because it takes the longest to complete. With this in mind, we can say that the duration of the Critical Path equals the overall estimated duration of the entire project.

When crashing a project, you should first determine the project’s Critical Path. The only activities that should be crashed are those within the Critical Path, as the Non-Critical Path activities will have no bearing on the overall duration of the project.

Step #2: Identify activities that can be crashed

Some activities simply cannot be crashed, even though they are part of the Critical Path. 

For example, if you’re working on a construction project, one of the first things you need to do is acquire a building permit. Since you can’t begin the work without this document, it’s likely that acquiring the permit will be one of the activities belonging to the Critical Path. 

However, this isn’t something that you, as a project manager, have any influence over. Therefore, acquiring a building permit is a Critical Path activity that cannot be crashed.

So, once you know what your Critical Path is, the next step is to meet with all your team leaders and determine which of the activities within the Critical Path can be crashed.

Step #3: Identify crash limits

Every activity has a crash limit — a point beyond which it can’t be crashed any further. 

By determining the crash limits within the Critical Path, you can calculate the maximum amount of time you can save by using the crashing technique.

Step #4: Calculate crash costs and benefits

Not all activities can be crashed, and not all those that can be crashed should be crashed.

Since crashing is a technique that helps you perform more work over a shorter period of time, and it requires large budget increases, it’s best to first calculate crash costs and determine the cost-to-benefit ratios. 

By doing this, you can surmise which of the activities will give you the greatest benefits for the lowest possible price. And, you can then crash only as many activities as necessary to be able to finish the project by the agreed deadline.

Step #5: Get approval from stakeholders

No amount of crashing can be performed before acquiring stakeholder approval. 

With all the information gathered from the previous 4 steps, you can confidently recalculate the project budget and timeline — and then:

• Present the most reasonable option to the stakeholders, 
• Collect their signatures, and 
• Begin the crash without further delays.

Conclusion: Project crashing is useful but expensive — so use it wisely

Crashing is an excellent project management tool that can sometimes save a project from the brink of failure. 

However, not every project can be crashed, and not every project should be crashed. So, before opting for this technique that might drain your stakeholders’ wallets, you can try fast tracking some activities first or convincing your stakeholders to accept a scope reduction.

If both of these options fail or prove impossible, and the stakeholders decide that finishing the project under their terms is worth the further investment, then crashing is the best way to move forward.

📖 Scehdule compression techniques offer ways to save projects that are falling behind schedule, but they’re far from the perfect solution. To learn more about how to properly manage projects and what you can do to prevent them from lagging in the first place, explore our Project Management Glossary of Terms and find out more about project management.

References

• Nwekpa et al. (2019). Project Crashing and its Implications on Quality of Work in Construction Firms: A Demonstration. IDOSR Journal of Current Issues in Arts and Humanities, 5(1), 47-56. https://www.idosr.org/wp-content/uploads/2019/07/IDOSR-JCIAH-5147-56-2019.-LU.pdf
• Project Management Institute. (2021). A Guide to the Project Management Body of Knowledge (PMBOK® Guide)–Seventh Edition (English Edition). Project Management Institute. https://www.goodreads.com/book/show/59241806-pmp-exam-flashcards-pmbok-guide-7th-edition 
• Kelly, É. V. (2009). Crash with confidence. Paper presented at PMI® Global Congress 2009—North America, Orlando, FL. Newtown Square, PA: Project Management Institute.