For most people, project success is defined simply as delivering what was expected on time and within the project budget. But getting there can sometimes require more than a little fancy footwork. And project managers have several tools to help them get there.
One of these tools is project management crashing. But don’t be fooled by the name. We’re not talking about crashing and burning. Well, that’s a risk, but only if it’s not done correctly.
Project crashing is a legitimate technique used to speed up the completion of a project by reducing the total time needed. It achieves this by adding resources so project tasks can be finished more quickly than planned.
The effect is to compress the project timeframe without risking the quality of the outcome, which allows project managers to navigate new deadline requests.
Not to be confused with fast-tracking
Project crashing is often mixed up with fast-tracking, but important differences exist. Where crashing is about adding resources to maintain schedule, fast-tracking is about using your existing resources. But you’d split or reschedule critical tasks so they could run simultaneously instead of sequentially.
Crashing will always add costs for the extra resources needed to compress the project timeline. And that’ll likely put the project over its original budget.
But there’s a downside to fast-tracking, too. Because it involves using your existing resources, there’s always a risk of spreading your resources too thinly. So, if you want to fast-track, you must be sure you have enough resources to complete the rescheduled tasks without losing quality.
There’s a third way. You could use both techniques together. In other words, you can bring in additional resources to avoid breaking up an existing team, and use crashing there. And you could also reschedule critical tasks to run in parallel and allocate some activities to the extra resources you’ve added to the project. But again, there is a cost implication.
What prompts you to crash a project?
The project management crashing technique is most often used when a customer or project manager wants to speed up a project. It may just be because it’s slipped behind schedule. Or there might be a sudden need to finish faster without changing the project scope or negatively affecting the expected outcome.
There are many reasons you might want to crash a project.
A common characteristic of projects is task dependencies. Sometimes, a team member may be struggling with a task. And it could be a task with a deliverable that’s needed for later tasks, meaning the delay may have a knock-on effect.
Projects also naturally tend to need more time, but sometimes, the original deadline simply can’t change. It could be due to a scheduled product launch and marketing campaign, or the demands of an important customer. It may also be because this is one of a series of projects, and the next one has to kick off the day after project completion.
Members of your project team may be committed to other projects that begin immediately after your project ends. Or the project could have an immovable deadline, with costly penalties in the mix or the possibility of relationship damage.
Good project managers build a little fat into the project duration. They know that there is almost always at least one delay that wasn't or couldn't have been anticipated.
Think about the Covid pandemic in early 2020. Many projects were put at risk then because subcontractors couldn't deliver on time. You might even have a delay caused by a critical team member who’s tied up on other important projects that may have slipped.
The target of nearly all businesses is growth. And with growth comes the need to onboard new tools, resources, or products. That means there’s a ramp-up time. Project crashing can help you compensate for time lost in the training and onboarding processes.
Change has always been a constant in business. And even the best-laid plans can be derailed. Shifts in global demand could disrupt you, such as more intense competition, rapid technological advances, or all of the above.
If, for example, you discover that a competitor is launching a week before you, you may want to crash the project so you can bring your launch date forward by two weeks.
Some projects are designed to incentivize the project team to deliver early. This is sometimes done through substantial cash bonuses for early completion. But you may have had challenges along the way that put your bonuses in danger. That'd be a time to consider using a schedule compression technique like project crashing.
There are times when a project manager suspects inefficiency, redundancy, and waste. Speeding up the project schedule could help you identify and eliminate them. And that might boost your profits, especially if you operate in a sector with tight margins.
Very few projects are entirely stand-alone. Customers often dangle the carrot of a later, much bigger project. In such cases, early delivery can generate goodwill that could impact whether or not you get the later project(s). You may even choose to absorb the additional project costs incurred by crashing.
Not every project has the same value in your organization. And some critical team members might be required on other, more important projects. Crashing can help you get what you need from your resources before they're pulled away from your project.
When not to crash a project
Each of the reasons above can trigger a need for project management crashing. However, it’s probably too late if your project is already in the last third of the project timeline. You’ll need a reasonably long project timeline ahead of you for crashing to pay dividends, and the earlier you do it, the better the outcome will likely be.
There’s another factor, too: cost. Even though crashing will incur additional costs, the key to successful project crashing is getting maximum schedule reduction at minimum additional cost. You should also be ready to pull the plug and stop crashing the minute it’s not cost-effective anymore.
But there are also times when the project is simply not made for crashing. There’s a rather tongue-in-cheek comment about why you can’t crash a pregnancy: it’s because nine women can’t make a baby in one month.
How to do project management crashing
As already mentioned, project crashing is most effective early in a project. And it's usually best done before you're at the halfway mark on the timeline. But despite this, it’s also a last-resort intervention. Plus, you need to have the additional resources available to jump in at short notice and be productive right off the bat.
Working out the critical path
The most important part of project crashing is where exactly you will crash. Wherever it is, it must be in the project's critical path because, without shortening the critical path, you won’t be bringing the project deadline closer.
If you’re unfamiliar with the concept, the simple explanation is that the critical path method helps you identify that string of dependent tasks across your entire project that’ll take the longest. It stands to reason, then, that shortening the timeline of that chain should bring the delivery date forward.
Calculating the crash cost
Project management is all about balancing and optimizing time, cost, and quality in a project. Changes in any one of those three factors will affect the others. It’s a relationship that must be considered when calculating the crash cost.
But in practice, project crashing exercises mostly concern time and cost. When a project customer asks for a project crash, they want to know how much of an increase in speed is possible and at what cost.
Providing the answers is a process known as crash analysis. This is where a project manager looks at the functional relationship between the variables and generates several cost-and-time scenarios to give the customer some options.
Finding the crash limit
According to the Project Management Institute, the crash limit is the point at which no further crashing of activities can be achieved along the critical path. That’s the formal definition. What it means in practice is that it’s pointless to crash tasks that aren’t on the critical path because doing that won’t shorten the project timeline. It also means that there are no more tasks on the critical path that can be rescheduled to run concurrently.
So, if you’ve exhausted the opportunities for the critical path method, you’ve reached your crash limit. It’s that simple. And it’s unlikely that you’ll be able to find any way to compress your project timeline any further than you already have.
This is easy with material resources like money, office space, and equipment. But human resources can get tricky because no two people have the same knowledge, expertise, and experience.
There’s also the little matter of familiarity with the customer, the project team, the tasks and the processes. Onboarding a new team member, even a highly experienced one, takes time, which must also be factored into your crash analysis.
Selling the activity
Given that the whole point of the exercise is to shorten the project schedule, it doesn’t make sense to dilly-dally around making the decision. As the project manager, you must present the scenarios you’ve worked out to the project sponsor, customer, and stakeholders and decide. Fast.
You’re selling your plan to them. It may have been conceived at their request, but they must choose one of the options you’re offering them. And then, they must give you the approval to implement it.
Provided that project crashing succeeds, there is really only one advantage: a shorter project schedule. But it should also lead to a more satisfied customer, which could, in turn, lead to more projects with that customer or referrals to others.
The primary disadvantage of project crashing is increased costs. Your project was conceived to fit into a budget. Project crashing will take you over your project budget, and, for some people, that’ll mean the project failed.
However, if extraneous circumstances are created by one of the ten reasons that may justify the crashing, you could swing that around. It could turn a budgetary failure into a project success.
Another disadvantage of project crashing is increased complexity. Adding resources to a project team can create problems because task responsibilities must be shuffled and shared. That’ll increase project complexity.
Risks you may encounter
In project crashing, there are three primary tools at your disposal: Overtime, more resources, and work-package splitting. Each of those carries risks. Overtime, for example, could overtax your team members and create problems where there shouldn’t be any.
Bringing additional resources onto the project will almost always disrupt the team dynamic, and you’d need to manage that effectively. There’s also the issue of onboarding because, as sais, no matter how skilled the new resources are, they’ll take time to get adequately up-to-speed on the project.
The third significant risk lies in splitting existing work packages into concurrent streams. This has the potential to disrupt the quality of the final project outcome. In all these cases, your resources can become so strained that overall project success is threatened.
Crashing one project can also put a strain on other projects in the organization as resources are redirected. Before you go ahead, all these risks must be assessed, quantified (or at least estimated), understood, and agreed to by project stakeholders and owners.
Keeping track of everything
When you planned your project, you’d have carefully gone through all the eventualities and worked out how they’d play out on the timeline. But when you crash the same project, some of your earlier assumptions could come back to bite you.
The key to effectively managing this is a project-tracking tool. In particular, Motion’s AI-powered intelligent calendar management will allow you to easily adapt your project schedule to the demands of the project-crashing exercise. Make the new assignments, and Motion will take care of the scheduling.
Let Motion do the heavy lifting for you, and grab your 7-day free trial today.