Lead, Lag, and Constraints

Even if lead and lag are easy to understand, they often generate confusion, especially among the novice project managers.

What is lag?

“Lag” refers to the amount of time that is added between a predecessor task and its successor. It can be applied to all dependent tasks regardless of their dependency type (FS, FF, SS, SF). Lag is always associated with delay.

Normally, any lag that is added between tasks on the critical path will delay your project. This is usually something you don’t want to. So basically you want to add lag either when you don’t have a choice or when you have a clear goal in mind. Let’s have a look at an example:

In the example above we have a finish to start a relationship between “Generate report” task and “Create wireframe” task. This means that Paul can’t start creating the wireframes until Florie finishes the report. But Paul is only available for work starting February 22nd. This is why we are forced to add a 2-day lag after Florie has finished the report.

What is lead?

If lag is associated with delay, “lead” is the amount of time by which a successor task can be advanced with regard to its predecessor.

If adding lag will result in delaying a project, adding lead to dependent tasks on critical path may reduce the time required to complete the project. Lead can be applied to the FS dependency. In this case, the dependency has to be “flexible”. Even if the 2 tasks are dependent, the predecessor doesn’t have to finish before the successor can start.

In the example, “Create web page design” task depends on “Generate wireframes” task. There’s an FS dependency between them. But in order to start working, Paul doesn’t have to wait until all the wireframes are created, he can start doing his job as soon as Florie has created 3-4 wireframes.  In theory, by doing so, the lifetime of the project might be shortened by one day.

The 8 types of constraints

In a Gantt Chart, a “constraint” represents a restriction that is applied to the start or end date of a task. They are helpful because they offer various degrees of flexibility when scheduling. In the meantime, you have to understand that when used in conjunction with dependencies, several scheduling conflicts might appear.
Let’s now take a look at each type and see what they do and when you should use them.

1. As soon as possible – when you apply this constraint to an unlinked task, the start date of that task will be the same as the start date of the project. When this is applied to a dependent task, that task will start as soon as the dependency of its predecessor allow.

2. As late as possible – this is a flexible constraint which when applied to an unlinked task, will match its end date to the finish date of the entire project. If this is applied to a dependent task, the task will be scheduled to finish when its successor task has to start.

The next 6 constraints follow the same rules, regardless of the type of task (unlinked or dependent).

3. Start no earlier than – the task can start on or after the specified date

4. Start no later than – the tasks can start on or before the specified date

5. Finish no earlier than – the task has to finish on or after the specified date

6. Finish no later than – the task has to finish on or before a specified date

7. Must start on – the task has to start on the specified date

8. Must finish on – the task has to finish on the specified date

Constraints 1-2 are considered flexible (they don’t tie a task to a specific date), 3-6 are semi-flexible (they include either a start or finish date but are not limited to these) and 7-8 are inflexible (because they have specific start or finish dates).

The relationship between constraints and dependencies

The first thing you should know is that the majority of project management software consider constraints more important than dependencies. This means than if a scheduling conflict appears, the constraint rule has priority and will “override” the logic of the dependency. To better understand this let’s have a look at an example:

Here’s a common finish-to-start dependency between the predecessor task “Project design report” and successor “Create web page design”. The first task takes 3 days to complete. The second one also 3 days.  A manager decides the design must be ready on Friday. What you have to do now is add an MFO (must finish on) constraint to the “Create web page design task”. But when you do this through a scheduling conflict appears: the FS dependency says that task “Create web page design” cannot start before task “Project design report” ends. However, because it has to finish on 23rd, it has to start on 21st (which is 1 day before its predecessor ends).

The software considers the constraint more important, hence the FS dependency logic is overridden. To be easily spotted by the project manager, this “abnormality” is often marked visually. For example, the dependency arrow has a different color. The project manager has to find a solution. In this case, he has to look for additional resources to finish one or both tasks in less time.

If the software allows, attach a note to each constraint. After 3 or 4 months you might forget why you had to include them in your schedule.

Found this article useful? Please spread the knowledge and share it with your teammates and followers.