When we say that a task will take a certain number of days or weeks, what we really mean is that we expect the task to take this long with its current resource allocation.
We could possibly make it take less time, but to do so would cost more money.
In the project world, spending more money to get something done more quickly is called crashing.
There are an infinite number of ways to crash project tasks, from assigning more staff or purchasing more equipment to contracting work out.
What you are doing when you crash tasks is making a triple constraints trade-off, by adding cost to reduce time.
For that reason, the decision to crash should only take place after you’ve carefully analyzed all the possible alternatives.
The key is to attain a maximum decrease in time for the minimum cost.
Let’s see how.
In the previous example, we wanted to complete the project in 25 (instead of 30) days, and chose to fast-track Task E to make this happen – we converted its relationship with Task D from finish-to-start to start-to-start with a five-day lead.
Before
After
You can see in this example, though, that crashing does not take Task E off the critical path (although crashing it further by adding even more resources might do so).
The Gantt chart also gives us no indication that anything is other than normal – the real impact is felt in the project’s budget.
So what are the risks of crashing?
On the face of it, crashing is a simple enough solution to project problems.
For example, if it takes Bob four hours to complete an activity, it would logically take Bob and Sue two hours to complete the same activity.
If Bob and Sue come at the same hourly rate, then there is no impact on the budget, so what’s the problem?
Unfortunately, adding resources isn’t always the best solution.
For example, new people aren’t going to be as familiar with the tasks at hand, so they will probably be less productive than current team members.
You should also ask, who will guide the new members up the learning curve?
Usually, it will be the most productive members of the team, who could be working themselves to get the task finished more quickly.
Similarly, being available is not the same as being qualified – not even the best bulldozer in the world can write software.
And occasionally, as with some major infrastructure projects, bringing too many under-qualified contractors into finish construction can introduce serious health and safety risks.
There also comes a point when the new resources begin to get in each other’s way and become less efficient – have you heard the phrase too many cooks spoil the broth?
Therefore, the time to stop crashing is when it no longer becomes cost effective.
You should only:
You should also only crash a task until:
There you have it:
Resource-leveling
Fast-tracking
Crashing
More often than not, the best way to achieve schedule efficiency is a combination of all three.
Ultimately, this is nothing more than an exercise in managing your triple constraints.
Ask the question, what is more important: time, cost, or scope?
If the deadline cannot be moved (for example, if your project is an event promised to run on a certain day), you may need to fast-track or crash tasks to guarantee delivery.
If keeping to budget is more important than keeping to schedule, look to more evenly spread your available resources over the life of the project, reducing the need to bring in temporary, expensive fillers.
And if time and cost are absolutely fixed, you may need to reconsider the scope of your project, or accept that quality is likely to suffer.
Did you know that top scheduling professionals can command executive-level salaries and do nothing more than these three: resource-leveling, fast-tracking, and crashing?
So whether you are organizing a small community event or delivering the next Olympic Games, you now have the tools to master all schedule challenges.
Just add experience!