Glossary
Fast Tracking
overlapping, parallelisation, overlapping activities
Fast tracking shortens the project duration by running activities that were planned in sequence fully or partly in parallel. It needs no additional staff but increases the risk of rework and the costs that come with it. Example: two activities of 10 days each that overlap by 4 days finish after 16 days instead of 20.
Fast tracking works on the logic of the schedule: a successor starts before its predecessor is fully complete. "Concept finished, then implementation" becomes "implementation starts as soon as 60 percent of the concept is stable". The schedule gets denser, the amount of work stays the same.
Which activities are suitable for fast tracking?
What matters is the type of dependency:
- Mandatory dependencies follow from the matter itself, such as pouring concrete and letting it cure before building on top. They cannot be parallelised.
- Discretionary dependencies arise from habit, caution or internal convention. This is exactly where fast tracking applies.
The activity also has to lie on the critical path. Overlapping two activities that have float leaves the project end where it was.
Example: how much time does fast tracking save?
A software team plans concept (10 days) and implementation (10 days) as a finish-to-start sequence. Implementation is to start as soon as the data model is stable, after 6 days of concept work:
| Concept | Implementation | Project end | |
|---|---|---|---|
| Without fast tracking | day 0 to 10 | day 10 to 20 | day 20 |
| With 4 days of overlap | day 0 to 10 | day 6 to 16 | day 16 |
The project finishes 4 days earlier, the work stays at 20 person-days. Two limits belong in every calculation:
- Rework: if the concept changes after day 6 so that 2 days of implementation have to be redone, the gain shrinks to 2 days.
- Parallel paths: if a parallel path has only 2 days of float, it turns critical after 2 days of shortening. The project end then moves forward by 2 days, not 4.
What is the difference between fast tracking and crashing?
Both techniques shorten the critical path, but they pay in different currencies:
| Fast tracking | Crashing | |
|---|---|---|
| Lever | schedule logic: activities overlap | resources: more staff, overtime, external help |
| Cost | no extra staff, rework costs possible | extra cost per day gained |
| Main risk | rework when requirements change | onboarding and coordination eat up the gain (see Brooks's law) |
| Precondition | discretionary dependency | the activity actually gets faster with more resources |
In practice, check fast tracking first because it needs no extra staff, then crash the activities with the lowest cost per day saved.
When does fast tracking not pay off?
- Unstable requirements: if you expect many changes to the predecessor, rework eats up the time gained.
- Same people on both activities: if concept and implementation rely on the same team, you get overload instead of real parallel work.
- Approvals and sign-offs: if implementation starts before a contractually required approval, you carry the risk alone.
How do you fast track in Merlin Project?
In Merlin Project you enter an overlap as a negative lead/lag on the dependency. Click the dependency arrow in the Gantt chart and enter the value in the Lead/Lag field in the Inspector: on an End to Start dependency, a lead/lag of −4 days lets the successor start four days before the predecessor ends. A positive value does the opposite and creates waiting time.
Alternatively, switch the dependency to Start to Start, either in the Type field in the Inspector or via Structure › Link › Start to Start. With a lead/lag of 6 days, the implementation from the example then starts 6 days after the concept. Turn on the critical path with View › Show Critical Path or the Critical Path icon in the toolbar to see whether the overlap actually pulls the project end forward or whether another path becomes critical.
How to use fast tracking together with contouring is shown in the article fast tracking, crashing and contouring in practice.
