Art of Microsoft Project Scheduling: Driving Task Dependencies with Percentages

Not all project tasks are performed sequentially; some are sequential, some are parallel, some have lag times, some have lead times (another term for negative lag), and some require a combination of these. The right logical dependency to establish between any two project tasks will depend upon the situation.

If you want to establish a task dependency to represent a situation where a second (successor) task should begin when the first (predecessor) task has a predefined percentage of progress, you can use a combination of ‘Start-to-Start’ with a percentage lag time.

Let’s pretend that we have a situation in which two tasks will be performed by two people (George and Ringo), and Ringo should begin the second task when George has completed 25% of the first task.

You might already guess that a ‘Start-to-Start’ dependency can be established between the two tasks with a lag built into the dependency causing the second task to have a delayed start date. The commonly-known method of introducing lag time into a task dependency involves entering a fixed number of days of lag time (25% of a 4-day duration is 1 day of lag time)…

…and when the predecessor task is 25% complete, then the successor task should begin:

However, if the duration of the predecessor task (‘Install Ice Cream Equipment’) changes, the lag time remains fixed (25% of an 8-day duration should be 2 days of lag time… not 1 day):

If you change the lag time to a percentage, rather than a fixed number of days…

…and if the duration of the predecessor task (‘Install Ice Cream Equipment’) changes, the lag time adjusts automatically (25% of a 8-day duration yields a 2-day lag time):

Therefore, when the predecessor task is 25% complete, the successor task should still begin as desired:

Important Note: the duration of the predecessor task will need to be updated regularly to reflect current conditions (as should be done anyway… regardless of the situation). If the predecessor task is not updated to reflect any duration changes, then the successor task may not be scheduled to begin when desired, since the percentage of lag is calculated from the duration of the predecessor task.

Good luck!