Removing Start-to-Finish Relationships from Mid-point Scheduling

Mid-point or block scheduling involves a sequence of tasks, the scheduling of which is dependent upon the start of a target task embedded within the sequence. In practice, as the sequence is moved forward or backward within the schedule, start-to-finish (SF) task relationships are used to drag the predecessors of the target task along with the target task. Here is an example.

Figure 1. Example of mid-point or block scheduling with SF relationships.

 

The start of the target task, “Move to new office,” depends upon the completion of the preparation task. If preparation completion is delayed, the entire move sequence is delayed.

Figure 2. Example with start of target task delayed.

 

If preparation completion is accelerated, the start of the sequence is accelerated. In this case, it is accelerated to a date before the start of the project. Project issues a warning. We would need to compress the predecessor tasks in order to take advantage of the accelerated move date.

 

Figure 3. Example with start of target task accelerated, along with a warning.

 

However, if we baseline and track the schedule, it does not behave as we might expect. Let’s assume that by the end of the fourth time period, the preparation task is completed as expected, but the box distribution task did not start on time.  Project’s calculations are correct. Having more than zero days of lag between the start of the packing task and the finish of the distribution task does not invalidate the SF relationship. As a consequence, the move task is not delayed.

Figure 4. Baselined example with tracking.

 

What’s Wrong?

There are several issues regarding the use of SF relationships in the example.

First, while Project computed float correctly relative to using SF relationships, the float calculations are counter-intuitive. If the box distribution or packing tasks are delayed, the move task should be delayed. However, the schedule indicates that these preceding tasks have float. See Figures 1-3.

Second, schedule perturbations may cause the tasks with SF relationships to track in a counter-intuitive manner, as shown in Figure 4.

And lastly, in general, the DCMA scheduling guideline admonishes against the use of SF relationships (see paragraph 4.4), negative lag (see paragraph 4.2), and unbound tasks (see paragraph 4.1).  The arithmetic equivalents of the SF relationships used in this example are finish-to-start (FS) relationships with negative lag. Further, the start of the first task in the sequence is unbound. While the finish of the box distribution task is preceded by the start of the packing task, the start of the distribution task does not have a predecessor.

Even with these issues, it is difficult to dissuade a scheduler from using SF relationships in mid-point scheduling. After all, the dates and behavior of the initial schedule appear to be correct.

 

An Alternative

Here is an alternative that does not use SF relationships. The sequence is clearly defined as a series of FS relationships. The start of the sequence is linked to the start of the project. The two predecessor tasks in the sequence are scheduled as late as possible using the tasks’ late start and finish times. This corrects the float calculations and shows the two predecessors as being critical.

Figure 5. An alternative.

 

If preparation completion is delayed, the sequence is delayed accordingly.

Figure 6. Alternative with delayed move availability date.

 

If the preparation completion is accelerated, the sequence is not scheduled before the beginning of the project. In this case, it is the combined length of the predecessors in the sequence, not the finish of the preparation task, that drives the move date. This forces us to recognize that one or both of the predecessor tasks must be compressed in order to accelerate the move date. The preparation task is no longer critical.

Figure 7. Alternative with accelerated move availability date.

 

Tracking with the alternative clearly shows that a delay in starting the box distribution task will delay the start of the move.

Figure 8. Baselined alternative with tracking.

 

What do you think?

Have you seen or used mid-point scheduling in practice?  Would you prefer using the alternative?  Please share your thoughts in the comments below.

 

Next Webinar

Manually Entering Task Progress in Microsoft Project

Written by Robin Nicklas
Robin Nicklas is a project management consultant and educator. Since 2001, he has trained project managers in the aerospace, financial, telecommunications, government, and software sectors. Prior to teaching, he spent twenty years in information systems and technology, twelve of which he managed software development at large information service companies. Since 2003, he has taught graduate and undergraduate courses in project management at the University of Washington in Seattle, as well as MS Project courses at Bellevue College Continuing Education since 2011. Robin is a former president of the PMI Puget Sound Chapter in Seattle and a certified PMP. He can be contacted through his website, robinnicklas.com.
Share This Post
Have your say!
00
4 Comments
  1. I was shown a similar example of when you might use an SF relationship, and your explanation shows perfectly that the SF is not the best approach.

    So are there any cases when you might use SF when scheduling?

  2. Paul,

    Good question!

    In one of the early precedence diagramming articles, Crandall (1973) deliberately ignores SF relationships, having not found them of value.

    Moder, Phillips and Davis (1983, pp. 38-42, 94-96) offer this example of a SF relationship, restated here as:

    Assume two tasks, “Design Powertrain” (8 weeks) and “Design Chassis” (6 weeks), with a logical constraint that the last 4 weeks of design chassis work depends upon the completion of the first 5 weeks of design powertrain work. That is, 5 weeks after the start of the design powertrain work, 4 weeks are required to finish design chassis work. The finish of the chassis work must lag 9 weeks (5 + 4 weeks) after the start of the powertrain work.

    In the example, note that the start of Design Powertrain clearly precedes the start of Design Chassis and that the lag is positive.

    Lu and Lam (2009) demonstrate how non-FS relationships can be restated with FS relationships. In the example just mentioned, both tasks would be partitioned into two parts: Design Powertrain A (5 weeks), Design Powertrain B (3 weeks), Design Chassis A (2 weeks) and Design Chassis B (4 weeks). Three FS relationships are needed: Design Powertrain A precedes Design Powertrain B and Design Chassis B; and, Design Chassis A precedes Design Chassis B. Further, Design Chassis A must be scheduled as late as possible to avoid splitting the Design Chassis work. While the restatement is more complicated, it clearly shows that Design Powertrain A is driving Design Chassis B.

    In my experience, most of the SF relationships encountered in the field are equivalent to FS relationships with negative lag, which renders the schedule nonsensical. If task A starts at time 1 and task B starts at time 0 and both tasks are 1 week long, I could link this as A precedes B with a SF relationship and 0 weeks of lag. But, this is equivalent to A precedes B with a FS relationship and negative 2 weeks of lag. Or, I could show that B precedes A with a FS relationship and 0 weeks of lag. Which is it?

    While this response may not answer your question directly, it does open up the rabbit hole . . .

    References:

    Crandall, Keith C. (1973). Project planning with precedence lead/lag factors. Project Management Quarterly, 5(3), 18–27.

    Moder, Joseph J., Phillips, Cecil R., and Davis, Edward, W. (1983). Project Management with CPM, PERT and Precedence Diagramming, 3rd edition. Van Nostrand Reinhold.

    Lu, Ming and Lan, Hoi-Ching Lam. (2009). Transform Schemes Applied on Non-Finish-to-Start Logical Relationships in Project Network Diagrams. Journal of Construction Engineering and Management, 135(9), 863-873.

  3. Schedules with SFs can’t be trusted but I use SFs two ways:
    1. For quick work-back “sketches” to determine dates and durations. (Add SF tasks until the block works, i.e. starts where you want, etc. Those will be your projected dates. Then convert the block to FS: just copy task names and durations into a new block with FS relationships and then zap the old SF block.)
    2. For real-time meeting updates when I have the projector and don’t want people to waste their time watching me futz with some hard FS problem. Convert it to FS later.

  4. Joseph,

    Excellent suggestions!

    There are plenty of features in MS Project that facilitate “off the cuff” or “what if” calculations, but we would never include them in a final schedule.

    Cleaning up afterwards takes discipline, but it sounds as if that is part of your routine.

    Thanks.

    -Robin

Leave a Reply