Topic 6.10: Crashing
We could possibly make it take less time, but to do so would cost more money.
In project world, spending more money to get something done more quickly is called crashing.
There are an infinite number 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 basic 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 analysed 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.
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.
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 budget, so what’s the problem?
Unfortunately, adding resources isn’t always the best solution.
For example, new resources aren’t going to be 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 themselves be working 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:
Crash activities that are on the critical path (use float first, if it is available)
Crash from the least expensive to most expensive
You should also only crash a task until:
It reaches its maximum time reduction
It causes another path to also become critical, and/or
It becomes more expensive to crash than not to crash.
There you have it:
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 that is 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-levelling, fast-tracking and crashing?
So whether you are organising a small community event or delivering the next Olympic Games, you now have the tools to master all schedule challenges.