Topic 6.8: Fast-tracking
You fast-track a project by scheduling tasks that were originally scheduled to run one after the other (consecutively) to instead run closer together or at the same time (concurrently).
Although they might not appreciate this as such, the folks who drive to work while simultaneously drinking coffee, shaving, reading the newspaper and texting a friend are fast-tracking their morning tasks.
And as in this irritating and slightly scary example, fast-tracking comes with more than its share of risks.
To continue our Gantt chart example, let’s say that after having completed our project schedule, the client comes to us and says they actually need the output delivered in 25 days – not 30.
One way – but not the only way – we can respond to this challenge is by bringing forward the start date of every task that is scheduled to finish beyond day 25.
In our example, this is Task E and Task G.
Let’s look carefully at what has just happened.
First of all, by using up all of the 5 days of float on Task C, we sent the path A-B-C critical.
But hang on, didn’t Task B have 5 days of float as well?
In our original chart, yes it did; however, in reality that float was available to either task B or C, not both.
To illustrate, if Task B was delayed by one day and, as a result, used up one day of its float, then because Task C cannot start until Task B is finished, its early start date would also be pushed out by one day.
Remember how we saw this happen when we pushed out Task F in the last topic and Task G moved with it?
In fact, you can see the same effect happening again with Task G.
In order to give ourselves the nine days necessary to complete the task, we now need to begin on Day 16.
This runs it right up against its predecessor Task F, sending that path critical as well.
Maybe we should push the start of Task F back to use some of its available float…
By making better use of the available float, we have managed to remove these tasks from the critical path!
So there is a very important lesson to be learned here: whenever a task is brought forward or delayed and uses up its float, the float available to other dependent tasks downstream will also be consumed.
That is why what looks like quite a comfortable project schedule can suddenly become highly vulnerable to shock.
Therefore keep in mind that when tasks take longer than we originally estimated (or, as we say in project management, the tasks on your schedule slip) – the consequences can be exponentially felt.
A final observation
You might also have noticed that the relationship between Task D and Task E has changed.
What was previously a classic finish-to-start dependency is now start-to-start with a five-day lag.
Now our assumption here is that it is perfectly possible to begin Task E before Task D is finished; we were just choosing to wait in our original plan.
Obviously you should validate this assumption by consulting with the relevant stakeholders.
Even so, by converting our D-to-E dependency from FS to SS, we are putting even more pressure on the team responsible for Task D to make sure they get things right.
Ultimately, in as much as increasing the time available to complete tasks theoretically improves the quality of outcomes (as per our theory of triple constraints), at the end of the day, fast-tracking adds risk to reduce time.
Therefore like crashing, which we will discuss shortly, fast-tracking is often used outside of planning and in the project delivery phase as a response to tasks taking longer than originally estimated.
However, as with resource levelling, not all tasks are equally amenable to fast-tracking.
In the next topic, we will look at how to apply your expert judgement to this end.