Priority fast-tracking

Most of the time, the risks involved in fast-tracking – or overlapping – tasks are small.

Beginning work on a building’s foundation before the detailed design is complete is common in the construction industry. 

After all, the foundation is unlikely to change when the architect is down to deciding which windows and kitchen cabinets to use.

To make the most of fast-tracking, look at the longest tasks on the critical path first. 

These provide the largest potential decrease in duration with the smallest number of risks to manage. 

Moreover, by fast-tracking only a few long tasks, you have fewer actual changes to make, and fewer impacts on the subsequent activities.

You should then look at all your finish-to-start dependencies and see if these can be changed to start-to-start. 

If they can be changed, ask how much lead (or lag) time is required between starts.

You can even schedule tasks concurrently as long as they use different resources and the risks are acceptable.

Remember, too, that there may be a large number of tasks in your project that have no dependencies. 

If that is the case, you should be able to perform these tasks concurrently, in any order and at any time – unless, of course, there is a dependency hidden there that we do not yet understand (as in the earlier case of our excavator)!

---

Five dependency constraints

Because fast-tracking seems so simple, you might be tempted to start fast-tracking tasks left and right. 

This is why it is useful to understand the dependency hierarchy and how to apply it when fast-tracking.

Logical dependencies

Logical dependencies occur when the laws of nature or logic stipulate how two activities are sequenced. 

For example, have you heard the saying you can’t make an omelet without breaking a few eggs? 

Well in project management, the task ‘cook omelet’ logically depends on the task ‘break eggs’ occurring first. 

Similarly, putting the roof on a house before you build the walls is impossible. 

Therefore, the task ‘build walls’ must logically precede the ‘build roof’ task in a construction project.

Logical dependencies are inviolate and cannot be fast-tracked.

Mandatory dependencies

Mandatory dependencies are the legal, contractual, or business process requirements that link two or more WBS tasks. 

For example, an organization may stipulate that all contractors must be engaged through a formal tender process. 

Therefore, the task ‘engage contractor’ would need to be preceded by the group of tasks defined by the organization’s procurement policy.

Now, although it is technically possible to work around or avoid mandatory dependencies, to do so might seriously jeopardize the quality of project outcomes. 

Therefore, if the delivery of your project has reached the point where you are considering side-stepping mandatory requirements, then you should reconsider whether the project is even possible anymore.

External dependencies

External dependencies occur when a project depends on inputs from a source it does not control. 

For example, the testing activity in a software project can depend on hardware delivery from an external source, or government environmental hearings may need to be held before site preparation can begin on a construction project.

Because, by definition, they are out of your control, you should allow for the risk that these inputs may not be delivered perfectly on time, on-budget, or to the agreed scope.

Internal dependencies

Internal dependencies refer to the people, materials, or other resource constraints placed on project activities. 

So, whereas it may be logically possible to conduct a stakeholder workshop next Monday, your expert facilitator might only be available on Wednesdays. 

Therefore, the WBS task ‘conduct workshop’ depends on the required resource – the facilitator – and must be appropriately delayed.

We saw an example of this in the resource leveling presentation, where we learned of and created a resource dependency where one didn’t exist previously.

Internal dependencies do have a level of flexibility – to solve a resource constraint, you can spend more money to acquire more resources. 

However, your ability to spend more money may be constrained, so adding time or reducing scope may be alternative strategies.

Discretionary dependencies

Discretionary dependencies reflect the preferences of the project team or organization. 

It may be that you have experience in similar projects that shows that it is better to start painting the exterior of a house before the interior. 

That way, in bad weather, you can move inside temporarily until the weather clears, without any slippage to your schedule.

No logical, mandatory, external, or internal demand says here Task A depends upon Task B. 

Therefore, when looking for opportunities to fast-track tasks, we usually head first to discretionary dependencies and then work our way up the hierarchy.