Microsoft Project 2010 : Linking Tasks (part 3) - Using the Start-to-Start Relationship,Using the Finish-to-Finish Relationship

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 type is most helpful when scheduling from the finish date rather than form the start date.

Here are some 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 having 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 4 illustrates a project where the framing materials (lumber) are to be purchased just in time for framing the walls. The Purchase Lumber task is scheduled to finish just as the Frame Walls task begins. Lumber Purchase and Delivery is dependent on Frame Walls, because you are scheduling the purchasing to be finished just in time for the framing, making Frame Walls its predecessor. If the framing is delayed (for weather, availability of workers, or another reason), the delivery of lumber 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. In actual practice, it is very rare to see the Start-to-Finish link type used in anything but a project that is scheduled from the end date.

Figure 4. Use a Start-to-Finish dependency link for circumstances where you want the successor task to finish just in time for the predecessor to start.

Now, say for example, preparing the foundation has a longer duration than in the original schedule, and that delays the scheduled start for Frame Walls. Automatically, Project delays the dependent task Lumber Purchase and Delivery just enough so that it will still be finished just in time for the new start date of Frame Walls. That is the difference between setting up the dependency link like the illustration in Figure 4 and using a Finish-to-Start dependency relationship. If the predecessor is delayed, the successor is delayed. Otherwise, the Lumber Purchase and Delivery task would have occurred as planned, and you would have a huge pile of lumber sitting around your work site, waiting for the Frame Walls task to begin, rather than have the lumber purchased just in time for the walls to be framed.

Choosing the Dependent Tasks

Deciding which of two tasks is the dependent task (the successor) and which is the predecessor is often obvious. 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 the other task its predecessor. Other times, however, it is not so simple.

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

Katy is an on-the-job trainee for a residential construction project. She is responsible for making sure that lumber and materials are on hand when the foundation is finished and it is time to frame the walls of the new house. Katy must watch the progress on finishing the foundation and call the lumberyard four days before the foundation is finished to schedule the delivery of the lumber. Katy’s instructions are to avoid ordering the lumber any earlier than necessary because that would mean paying interest on borrowed money for a longer period of time.

When it is just about time to call the lumberyard, Katy learns that the carpenters are being diverted to another project that has a higher priority, and the framing has been put on hold for a week. Katy’s common sense tells her that the lumber 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 the framing. Although her instructions were to order the lumber four days before the foundation is finished, these instructions assumed that there would be no gap between working on the foundation and the framing. Because there was a gap, Katy was correct to link her task (ordering lumber) with the framing task.

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

The decision about which task should be the predecessor and which task should be the dependent, or successor, might depend 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 for which the schedule for one task is out of your control, you might want to arbitrarily make the more flexible scheduled task the dependent task—regardless of which task actually must come first in time (like Katy did in the previous example).

Allowing for Delays and Overlaps

Sometimes you might need to schedule a delay 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 lag time in a task scheduling, and you could add a one-day lag to the Finish-to-Start link between the Apply the Primer and Apply Paint tasks. The successor task’s start would lag behind the predecessor’s finish in the manner you define.

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 Clean-Up crew can begin the Clean-Up task when the painters are close to finishing the Apply Paint task. The successor task’s start would lead to the predecessor’s finish.

Figure 5 shows the painting example again. The first set of tasks has no lead or lag defined, whereas the revised schedule has lead and lag time added to the links. There is a lag added to the link between the primer and paint, because you have to wait for the primer to dry. But there is a lead time between the Apply Paint and the Clean Up task, because you can begin cleaning up before the paint is dry. 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 5. Lag and lead times enable you to create a more realistic schedule, and often enable you to finish earlier than expected.

Lags and leads can be defined in ordinary duration units or in elapsed duration units. If you want Microsoft Project to schedule the lag during working time on the calendar, you use ordinary duration units. If Project can use non-working time also for scheduling the lag, you use elapsed duration units. For example, assume the Apply Primer task finishes on a Friday, the last day of the working week. If the one-day lag for the Apply Paint task was defined as one ordinary day (typically eight hours of working time on a standard calendar), Project would let one day of working time pass before scheduling the start of the Apply Paint task. Because the next working day after Friday is Monday, the successor task would be scheduled for Tuesday. But if the lag was defined as one elapsed day (that is, 24 hours of continuous time), Project would use the weekend days for the lag and the paint would be scheduled for Monday.