Microsoft Project uses the term “links” to describe the dependencies that are created to specify the order that tasks can take place. Links define which tasks can take place in parallel (concurrently) and which must take place in series (sequentially). Though Microsoft Project uses the term link, the more commonly used terms in the scheduling community (outside of Microsoft Project) is relationship or dependency.
When we talk about links, we are always talking about the links between two tasks, or between tasks and milestones.
The first task is called the predecessor and the second task is called the successor.
Link Categories
There are four main categories of links that must be considered.
For example: You must build a unit before it can be tested. The Test Unit task requires an input of the unit before it can start. The unit is the output of the Build Unit task.
Discretionary links, are links that are defined based on best practices or a preferred way of doing the work. They are not driven by input requirements.
For example: If you are building a house, you may have a task that is Painting the exterior of the house, and another task that is Landscaping.
It is not mandatory that the painting be completed prior to the landscaping, but it would be better not to have painters traipsing through when the landscaping is going on. So you might create a discretionary link between the two tasks.
Discretionary links should typically be used very sparingly and must be well documented. There may be reasons to revisit and change them if schedule challenges occur. If your schedule starts running late, you may need to find a way to perform those 2 tasks in parallel.
External links are links to tasks outside the scope of the project. These are typically modeled with a milestone that represents the receipt of the item that is coming from outside of your project which is then linked to a task in your project. You will typically assign a Start No Earlier Than (SNET) Date Constraint on the milestone that represents the date you expect to receive the item.
For example: If you are receiving a battery from an outside vendor, that would be represented as an external link, with a milestone in your schedule assigned a SNET date equal to the promised date from the vendor.
External links should be monitored carefully to identify any potential impacts coming from external sources. You must make sure that you get status on that delivery in case something changes.
Internal links are defined between two project activities, in which the Integrated Product Team (IPT) has complete control over the project activities.
Link Types
There are three types of links commonly used in modeling: Finish to Start (FS), Start to Start (SS), and Finish to Finish (FF).
Both SS and FF links model parallel work. There is some portion of the two tasks that can take place at the same time.
For Finish to Start (FS), the predecessor must finish before the successor starts. Or you can think of it as the successor cannot start until the predecessor finishes. This means that the earliest the successor can start is immediately following when the predecessor finishes.
FS is the most common link type you will use, with typically more than 90% of your links in a detailed schedule set to this type. Many schedules use only FS. This is the default in Microsoft Project.
There is also a fourth kind of link which is not commonly used called Start to Finish (SF). This link type is not recommended for use – there are better ways to model this dependency.
When linking tasks, you should only create links between detailed tasks and milestones. Although Microsoft Project allows it, you should NOT create links to or from Summary tasks.
Lags
Lags are used to delay the start or finish of the successor task. Links are assigned to the link.
You should typically only use a lag in a SS or FF link. In SS the lag delays the start of the successor. In FF it delays the finish of the successor.
Lags should represent effort. The lag is the portion of the tasks that cannot take place at the same time.
In SS, the lag represents the portion of the predecessor that must take place before the successor can start. In FF, the lag represents the portion of the successor that cannot finish until the entire predecessor is complete.
Because lags should represent effort, FS dependencies should typically NOT have lags.
FS links should typically NOT have lags. Typically, people put lags on FS links for one of 2 reasons:
1. To represent what they consider an insignificant effort. So for example, we have a task Pour Concrete and we know that we can’t start framing the walls until the concrete has had 10 days to cure. Often people will put a lag in for the cure time.
However, the lag represents something happening, even if it seems unimportant. Add a task to provide visibility so that anyone who looks at your schedule knows what is happening during that time.
In this example, we have been told that the Wind Tunnel will not be available for testing until 6/12. Based on the completion of the predecessor, the Test in Wind Tunnel task may begin on 6/6. Often people will put in a lag on the FS link to drive the start of the successor to 6/12.
The problem is that if the predecessor is delayed, the lag remains and no matter when the predecessor finishes, the successor will not start until 6 days later.
A better way to model this is to assign a Start No Earlier Than (SNET) Date Constraint. Then if the task slips, both the SNET and the link are honored, but because there is no arbitrary lag assigned, the task will be scheduled to start as early as it can be, based on true conditions.
- SS and FF links should typically have lags.
- FS links should typically not have lags.
- Do NOT link summary tasks.