Lead, lag and constraints
Even if lead and lag are easy to understand concepts in project management, 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, and it can be applied to all dependent tasks regardless of their dependency type (FS, FF, SS, SF). In this regard, lag is always associated with delay.
Normally, any lag that is added between tasks on the critical path will delay your project, which 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 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 because Paul is only available for work starting February 22nd, 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 though, the dependency has to be “flexible”, which means that even if the 2 tasks are dependent, the predecessor doesn’t necessarily have to finish before the successor can start.
In the example above, “Create web page design” task depends on “Generate wireframes” task, and there’s a 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, but 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:
In this situation we have a common finish-to-start dependency between the predecessor task “Project design report” and succesor “Create web page design”. The first task takes 3 days to complete, the second one also 3 days. A manager decides though that the design must be ready on Friday. What you have to do now is add a MFO (must finish on) constraint to the “Create web page design task”. But when you do this though a scheduling conflict appears: the FS dependency says that task “Create web page design” cannot start before task “Project design report” ends, but in the meantime because it has to finish on 23d (and it takes 3 days to complete) it has to start on 21st (which is 1 day before its predecessor ends). The software consider the constraint more important, hence the FS dependency logic is overridden. In order to be easily spotted by the project manager, in most programs this “abnormality” is marked visually (for example, the dependency arrow has a different color), and 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 you to do this, it’s a good practice to attach a note to each constraint you add to the tasks, because after 3 or 4 months into the project you might forget why you had to include them in your schedule.