Understanding Dependency Links

Usually some tasks in a project cannot start until one or more other tasks have finished. One common reason for this requirement is that a task might need to use the output generated by another task. For example, in building a house, the foundation must be laid before you can frame the walls. Therefore, the start of the task Frame the Walls is determined by, and should be linked to, the finish of the task Lay the Foundation. The link expresses the dependency of the framing schedule on the schedule for the foundation.

An inexperienced scheduler in this building project might just list the tasks in Excel and type in start and finish dates for all the tasks. But what if the scheduler later finds out that for some reason the Lay the Foundation task will be delayed? The scheduler would then have to go through the entire project, typing in later start and finish dates for all the tasks that will be affected by the delay. However, if the tasks are typed into Microsoft Project and dependency links are defined, the scheduler can simply enter a delayed start date for Lay the Foundation, and Project will calculate new start and finish dates for all the tasks that are dependent, directly or indirectly, on that task. The reason you take the time to define links between tasks is so that Project can recalculate the schedule for you quickly when there is a change in the schedule that affects the scheduling of other tasks.

Defining Dependency Links

When tasks are linked to show a dependency relationship, the dependent task is called the successor task and the task on which its schedule depends is called its predecessor . These names were adopted a long time ago, when the only scheduling links envisioned had dependent tasks coming after the tasks they depend on, and they serve well for describing the vast majority of linked tasks. You will soon see that more sophisticated linking can create a situation where they simply aren't appropriate.

To illustrate the usage of the terms predecessor and successor, suppose you need to schedule the application of two coats of paint to the exterior walls of a small structure. There will be four tasks involved: Prepare Surfaces, Apply First Coat, Apply Final Coat, and Clean Up. The start of Apply First Coat depends on the finish of Prepare Surfaces; therefore, Prepare Surfaces is the predecessor to Apply First Coat. Similarly, Apply First Coat is the predecessor to Apply Final Coat, and Apply Final Coat is the predecessor to Clean Up. The start date for the successor task should be linked to the finish date for the predecessor. As illustrated in Figure 6.1, Project draws a small arrow from the finish of each predecessor task to the start of its successor task.

Figure 6.1. When you link a dependent task, its schedule depends on the schedule of its predecessor.

When you refer to a dependency link, the linked date of the predecessor task (either its start or its finish) is named first, and the linked date of the successor task is named last. In the painting example in Figure 6.1, the dependency relationships are called Finish-to-Start links because the predecessor's finish determines the successor's start. Finish-to-Start is the most common type of link, but there are also three other types you can use: Finish-to-Finish, Start-to-Start, and Start-to-Finish. The section "Defining the Types of Dependency Link Relationships," later in this chapter, describes the use of all types of links.

By establishing the link in the painting example, you instruct Project to set the start date for Apply Final Coat based on the scheduled finish date for Apply First Coat. Any change that alters the calculated finish date for the predecessor causes Project to also reschedule the start date for the dependent or successor task. In Figure 6.1 the Apply First Coat task in the revised schedule on row 8 has been given a longer duration than it had in the original schedule, on row 3. Accordingly, the Apply Final Coat task on row 9 is scheduled to start and finish later than it was on row 4, reflecting the longer duration of its predecessor. If you define task links, Project automatically reschedules dependent tasks when the schedule for the predecessor changes.

CAUTION

Do not link two unrelated tasks just to level out the workload for a resource who is assigned to work on both tasks. It is true that the link forces Project to schedule the tasks one after the other, thus allowing the worker to complete one task before starting the next . But what if the worker is later removed from working on one of the tasks? There is no way to tell that the link no longer serves a purpose and can be removed (unless you just happen to remember it), and you will be left with an unnecessary delay that could delay the finish of your project. The preferred way to deal with this problem is to delay one of the tasks by using the Leveling Delay field.

For the steps to follow in using leveling delays, see "Resolving Overallocations by Delaying Assignments," p. 440 .

Choosing the Dependent Task

Deciding which of two tasks is the dependent task and which is the predecessor is often self-evident. In many cases, as with the building example used earlier, the dependent task requires the output of another task; in such a case, you make that other task its predecessor. Other times, however, it's not so simple.

Consider the following case, in which a person, not a computer, is doing the scheduling:

Elaine is an on-the-job trainee for a residential construction project, and she is responsible for making sure that lumber and materials are on hand when the foundation is finished and it's time to frame the walls of the new house. Elaine is to watch the progress on finishing the foundation and call the lumberyard four days before the foundation is finished to schedule the materials' delivery. Elaine's instructions are to avoid ordering the materials any earlier than necessary because that would mean paying interest on borrowed money for a longer period of time. Although the term just-in-time scheduling wasn't used in Elaine's instructions, this is, in fact, an example of that management principle.

When it's just about time to call the lumberyard, Elaine learns that the carpenters are being diverted to another project that has a higher priority, and the framing phase of the project has been put on hold for a week. Elaine's common sense tells her that the materials' order is really linked to the start of the framing, not to the finish of the foundation, and she delays placing the delivery order until two days before the new start date for framing.

If you were scheduling this example in Microsoft Project, you would want to give Project enough information to be able to do what Elaine did ”delay the start of the delivery task if the framing task is delayed. To do that, you need to treat the delivery of materials as a task that is dependent on the start of the framing task.

This type of linking was not envisioned when the terms predecessor and successor became popular. Recall that the term successor was coined to refer to the dependent task. In this example, where the delivery task's schedule depends on the framing task's schedule, we have to call the delivery task the successor and the framing task the predecessor, even though the successor in this case is to take place a day or so before its predecessor. This usage flies in the face of our everyday use of the terms predecessor and successor. (We really should call them something like driver task and dependent task instead of predecessor and successor.) However, it's just the result of keeping old labels for more modern methods .

The decision about which task should be the predecessor and which the dependent, or successor, task might hinge on which task you have more control over. If you have equal scheduling control over both tasks, make the task that must come first the predecessor and let the later task be the dependent successor. In cases in which the schedule for one task is out of your control, you might want to arbitrarily make the more flexibly scheduled task the dependent task ”regardless of which task actually must come first in time.

For example, suppose an office building project will have a world-famous artist paint a mural in the entrance to the building. The artist is available only at certain times, and a change in the artist's availability would mean a change in the schedule. The artist's task will probably be defined as the driver (the predecessor) for other tasks that are more flexible ”tasks such as having scaffolding erected for the artist to use and maybe even when to start construction. On the other hand, if the mural were to be painted by a talented local artist who is anxious to get the work, you would probably let earlier steps in construction drive the schedule for painting the mural.

When one of two linked tasks is a support function that merely facilitates the other task (such as ordering lumber and materials for framing, erecting scaffolding for painting a mural), you will usually want to make the main task the predecessor and the support function the dependent task.

Allowing for Delays and Overlaps

Sometimes you might need to schedule a delay as part of the linkage between the predecessor and the successor tasks. For instance, in the painting example, you need to allow time for the first coat of paint to dry before you apply the final coat. This kind of delay is known as a lag or as lag time in task scheduling, and you could add a one-day lag to the Finish-to-Start link between the Apply First Coat and Apply Final Coat tasks. The successor task's start would lag behind the predecessor's finish.

Other times you might want to allow the dependent task to overlap or start before the predecessor task is finished. You add lead time to a link when you want the linked date for the successor task to anticipate the linked date of its predecessor. For example, the cleanup crew can begin the Clean Up task when the painters are close to finishing the Apply Final Coat task. The successor task's start would lead to the predecessor's finish.

Figure 6.2 shows the painting example again. The first set of tasks has no lead or lag defined; the revised schedule has lead and lag time added to the links. There is a lag added to the link between the first and final coats of paint, and there is lead time between the Apply Final Coat and the Clean Up task. The lag adds to the overall duration of the painting project, but the lead allows the project to finish faster than it would otherwise .

Figure 6.2. You can use lag time to delay the successor task. Lead time allows tasks to overlap, meaning that the project can finish earlier than would be possible otherwise.

TIP

Identifying task relationships where overlaps such as lead time are possible is one of the best ways to shorten the overall time it takes to finish a project.

For more information on compressing, or crashing, a schedule, see "Shortening the Critical Path," p. 480 .

Lags and leads can be defined in ordinary duration units or in elapsed duration units. If you want Project to schedule the lag during working time on the calendar, you use ordinary duration units. If Project can use nonworking time also for scheduling the lag, you use elapsed duration units. For example, what if the Apply First Coat task were to finish on a Friday, the last working day of the week? If the one-day lag for the Apply Final Coat task were defined as one ordinary day (typically 8 hours of working time, on a standard calendar), Project would let one day of working time pass before scheduling the start of the Apply Final Coat task. The next working day after Friday is Monday; therefore, the successor task would be scheduled for Tuesday. But if the lag were defined as one elapsed day (that is, 24 hours of continuous time), Project would use the weekend days for the lag and the final coat could begin on Monday.

For more information about using elapsed duration, see "Defining Elapsed Duration," p. 135 .

Although you usually define lags and leads in fixed time units (such as 4 hours or two elapsed days), Project also allows you to define lags and leads as a percentage of the duration of the predecessor. With the percentage format, Project makes the length of the lag or lead a multiple of the length of the predecessor task. Using the different methods of entering leads and lags is discussed in the section "Entering Leads and Lags," later in this chapter.

Defining the Types of Dependency Link Relationships

You can create four types of dependency relationships, depending on whether you use the start dates or finish dates when linking tasks. The name for each dependency type includes a reference to the linked date for the predecessor (either its start date or its finish date), followed by a reference to the linked date for the dependent task (either its start or finish date). Therefore, a Finish-to-Start relationship signifies that the finish date of the predecessor task is used to schedule the start date of the dependent task. The predecessor is referenced first, and then the dependent or successor task is referenced.

Project usually uses two-letter code abbreviations for the four dependency types, as shown in Table 6.1. The first letter in the code refers to the predecessor's start or finish, and the second letter refers to the dependent task. Thus, the code for Finish-to-Start is FS. The following subsections describe the different dependency types.

Table 6.1. The Linking Relationships in Microsoft Project

Code	Dependency Type	Meaning
FS	Finish-to-Start	Predecessor's finish determines successor's start.
SS	Start-to-Start	Predecessor's start determines successor's start.
FF	Finish-to-Finish	Predecessor's finish determines successor's finish.
SF	Start-to-Finish	Predecessor's start determines successor's finish.

Using the Finish-to-Start Relationship

In the Finish-to-Start relationship, the finish date of the predecessor determines the start date of the successor task. For example, framing the walls of a new house should be scheduled to start after the foundation is prepared. The links in the painting example in Figures 6.1 and 6.2 are all Finish-to-Start links. The linking arrow in the Gantt Chart is drawn from the finish of the predecessor task to the start of the dependent task. This is the most common dependency type and is the default relationship created via the Edit, Link Tasks command.

Using the Start-to-Start Relationship

In the Start-to-Start relationship, the start date of the predecessor task determines the start date of the successor task. You can schedule the two tasks to start at or near the same time by using this type of relationship. The two tasks are scheduled to run in parallel.

NOTE

A lag often is associated with Start-to-Start links. The start of the dependent task is delayed until some time after the predecessor task is underway.

For example, suppose an organization leases new office space and plans to move to the new space when remodeling is completed. As part of the move from one office to another, several tasks need to be accomplished ”packing boxes, disconnecting desktop computers, disassembling furniture, and loading the boxes and furniture into the moving van. Because the movers can start loading the vans almost immediately after the packing task starts, the start of the Load Vans task can be linked to the start of the Pack Boxes & Disassemble Furniture task, with a small amount of delay or lag time (see the tasks in Scenario A in Figure 6.3). Pack Boxes & Disassemble Furniture is the predecessor task; Load Vans is the successor task. The arrow is drawn from the start of the predecessor to the start of the dependent task.

Figure 6.3. You can link the start of the Load Vans task to the start of the Pack Boxes & Disassemble Furniture task, with a two-hour lag. Alternatively, you can link the Pack Boxes & Disassemble Furniture task to the Load Vans task, with a two- hour lead.

If the availability of the loading vans drives this operation, you could make the Pack Boxes & Disassemble Furniture task dependent on Load Vans, with a small amount of lead time. The linking shown in the Scenario B taskbars in Figure 6.3 illustrates this alternative. The start of the Pack & Disassemble Furniture task is linked to the start of the Load Vans task, with a two-hour lead, to ensure that packing starts shortly before the loaders are ready to start.

Using the Finish-to-Finish Relationship

In the Start-to-Start relationship, the start date of the predecessor to the Finish-to-Finish relationship, the finish date of the predecessor determines the scheduled finish date of the successor task; you schedule two tasks to finish at or about the same time. For example, in remodeling a kitchen, the acquisition of the kitchen appliances should be completed by the time the cabinetmakers finish installing the kitchen cabinets, so the cabinetmakers can install the appliances in and around the new cabinets (see Figure 6.4).

Figure 6.4. The kitchen appliances should all be purchased by the time the kitchen cabinets are completed; this is a Finish-to-Finish relationship.

NOTE

The link types Start-to-Start and Finish-to-Finish with leads and lags can be used to schedule tasks to overlap and are standard techniques for fast-tracking a project ”that is, compressing the overall duration of the project by overlapping tasks.

Using the Start-to-Finish Relationship

In the Start-to-Finish relationship, the start date of the predecessor task determines the scheduled finish date of the successor. With this type of relationship you schedule a task to finish just in time to start a more important task that it supports. This is the link type you would use in the example about helping Elaine schedule the delivery of framing materials. Here are some more examples that illustrate the Start-to-Finish relationship:

• When scheduling the delivery of merchandise to a new store, the grand opening date determines when the deliveries must be scheduled. A delay in construction that pushes back the grand opening leads to calls to the merchandise suppliers to delay their deliveries.

• Just-in-time scheduling in manufacturing is a policy that strives to stock raw materials just in time for the manufacturing process to begin. This policy saves money by not tying up cash in materials' inventories any longer than necessary.

Figure 6.5 illustrates Elaine's project, where the framing materials are to be purchased just in time for framing the walls. In the first set of tasks (the original schedule), the Purchase Materials task is scheduled to finish just as the Frame Walls task begins. Purchase Materials is dependent on Frame Walls, making Frame Walls its predecessor. If the framing is delayed, the purchase of materials will be delayed, too. The link is a Start-to-Finish link, and the arrow is drawn from the start of the predecessor to the finish of the dependent task.

Figure 6.5. The Purchase Materials task must be completed in time for the Frame Walls task to begin, making its schedule dependent on the schedule for Frame Walls.

In the revised schedule in Figure 6.5, the Prepare Foundation task has a longer duration than in the original schedule, and that delays the scheduled start for Frame Walls. Automatically, Project delays the dependent task Purchase Materials just enough so that it will still be finished just in time for the new start date of Frame Walls.

Linking Summary Tasks

Standard practice is to link subtasks ”the working tasks in the project ”and not to link summary tasks. However, summary tasks can be linked to each other or to subtasks under other summary tasks. A summary task is already implicitly linked to its own subtasks ; therefore, Project won't let you establish an explicit link between a subtask and its summary task.

If the summary task is linked to a predecessor, the predecessor relationship dictates when the summary task (and therefore its subtasks) can begin. Likewise, as you will see later in this chapter, if the summary task has a date constraint, its subtasks are effectively constrained to that date also. If the summary task has no links or date constraints, its start and finish dates are derived from the earliest start and the latest finish of any of its subtasks.

Linking summary tasks is generally not considered to be good practice. Summary tasks do not define the activities where work gets done ”and links should generally reflect the scheduling requirements of the tasks where work is done.

If a summary task represents a discrete, self-contained group of tasks, and no subtask of the would-be dependent summary task needs to be linked to the predecessor summary task, it may be useful. In that case, linking the phases has the advantage that you can change the subtasks within each of the two phases without worrying about redefining the link between the phases.

NOTE

If you select all tasks and let Microsoft Project link the tasks in an outlined project, Project links all tasks at the first outline level to each other, whether they are summary tasks or not. It then links the next level of subtasks within any summary tasks to each other, and so forth, until all outline levels in all summary tasks are linked at their own levels. All links are the default Finish-to-Start link type.

If you create a task link that involves a summary task as the dependent or successor task, you can use only the link types Finish-to-Start and Start-to-Start. Project does not let you establish the other link types (those where the summary task's finish date is linked). However, if the link involves a summary task as the predecessor to a nonsummary task, you can use any of the four possible link types. These rules apply the same in both fixed start-date and fixed finish-date projects.

CAUTION

Be sure you establish no links between subtasks under the same summary task that try to schedule one of the subtasks to start before the first subtask in the summary group. For example, suppose Subtask A starts when the summary task starts. If you link another subtask in the same group to Subtask A with a Start-to-Start link and add lead time to the link, you would be telling Project to start the second subtask before the summary task begins. Project would ignore the lead time and schedule both tasks to start at the same time.