In addition to creating schedule logic the way people ordinarily perform their business activities, it’s important from a scheduling logic perspective to also include at least one Finish-To-Start successor to each detail level task in a Microsoft Project schedule model. To illustrate this, I’m going to use a wildly exaggerated example.
Consider a program that has tasks as shown in Figure 1. Task A represents an integration activity; Task B represents a testing activity that may commence sometime after the start of integration. Task B is scheduled to start on Friday of Week 1 in the program. The Finish Up Task item represents the writing of a test report that can’t start until the testing is complete. In this article, we’re going to focus on the relationship between Tasks A and B (integration and test).
Figure 1: A sample project.
A Start to Start Relationship
The owner of Task B believes she’ll have no drivers other than she may start when Task A claims he’s 25 percent complete. The scenario is worsened if Task B starts a fixed number of days after Task A starts such as 2SS+2days. The owner of Task A believes she’s not a program driver.
Once execution of Task A begins, the owner of Task A encounters a problem and believes his new task duration is 20 days (instead of eight days). Notice how the lack of a finish to start successor on “Task A” fails to correctly push the Project Complete milestone to a correct date in Figure 2.
Figure 2: The duration of Task A increases.
Although the increase in duration of Task A drives the start of Task B to a later date (Wednesday of Week 2), the Project Complete milestone is incorrect because it shows Wednesday of Week 4 instead of Thursday of Week 5. The lag on the predecessor for Task B does move Task B to the right if its predecessor runs longer than anticipated. If the lag on the predecessor to Task B were a fixed amount, say 2SS+2days, then Project Complete milestone would not have moved at all, as shown in Figure 3.
Figure 3: Task B with a fixed duration lag.
The problem is exacerbated if Task B has already started and the owner of Task A realizes his trouble later in the execution process (Figure 4). Essentially this situation becomes identical to a fixed lag on Task B since the existence of progress on Task B freezes its location.
Figure 4: A Task A problem is found after the start of Task B.
The proper way to link this schedule is with a Finish-to-Start successor on Task A linking it to either the Project Complete milestone or the Finish Up Tasks (Figure 5). The original Start-To-Start relationship between Tasks A and B remains along with the new successor.
Figure 5. Changing successors on Task A.
The idea is that sooner or later, Task A could run so long that it will impact someone. Now, if “Task A” doesn’t get completed in a timely manner, the Project Complete milestone will push out accordingly.
An argument is that if Task A increases in duration, Task B must also increase in duration: Test may start when integration is 25 percent complete, and testing will finish five days after the completion of integration. The task to test (Task B) becomes a “hammock task” with dates automatically driven by changes to Task A. I’ll give you the steps for creating a hammock task in a future article.
Since Microsoft Project doesn’t allow a single task to drive both the start and finish of the same successor activity, two faux milestones are added after Task A, indicating the start of Task B (test) and the expected completion of Task B. These are identified in Figure 6 as the two MS (milestone) tasks. To make the completion of Task B contingent on the duration of Task A, create a hammock task driven by the two milestones. The Hammock task (Task B) is created from the milestones to account for the lag in start and completion. The start and complete criteria for Task B are totally within the control of the user who specifies this information using the two milestones. Using the hammock task scenario, the new schedule appears in Figure 6.
Figure 6: The use of the a hammock task for Task B.
When the duration of Task A increases, the duration of Task B will follow suit without user intervention (Figure 7).
Figure 7: Task A dates drive hammock task B dates.
The finish date for Task B will still change even if Tasks A and B are in process.
A Finish to Finish Relationship
Consider a Task B that may start at any time, but must finish concurrently with Task A plus two days (Figure 8).
Figure 8: Task B with a finish-to-finish predecessor.
If the owner of “Task B” decides an additional 10 days will be needed (making the duration of “Task B” 16 days), this drives the start date of Task B to the left. This doesn’t appear to be a problem, unless this drives the start of “Task B” to before today. However, there will come a time when the duration of Task B becomes so long that it may start prior to the start of its predecessor (Task A). Of course, this isn’t logical. A successor activity generally doesn’t start prior to the commencement of the predecessor. In this example, Task B (Test) could certainly not start prior to Task A (Integration) without changing the meaning of the terms. If there’s no predecessor to drive the start of Task B, why not simply start it on day one of the project? Answering that question will establish a start constraint for Task B. Some task must drive the start of Task B. Determining that task will create the needed finish-to-start predecessor to start Task B; and a hammock task can be created just like above.
More than likely, the logic behind a finish-to-finish predecessor is that tasks will run in parallel: Testing will be done about two days after completion of integration. This drives the finish date of Task B and the project completion date in the example. We’re handed the reciprocal problem — what will drive the start date?
When considering business rules, task relationship may be start-to-start or finish-to-finish. To preserve schedule logic, you also need to drive detail tasks with a Finish-To-Start successor.
