I received the following question from one the participants in the global webinar on dependencies, leads and lags.
*********
Good Morning Satya,
Thanks for the presentation yesterday. I was looking for a more simplistic manner to present to new superintendents and APMs this subject. I like the way you laid out the predecessor column and successor column and think that is a great way to simplify it for others.
I filled out the survey information and made the following comment at the end of the survey:
I posted a question that was never asked - not sure why. The topic was rather elementary and was expecting to be able to resolve issues we have with entering Actual Start dates that contradict the dependency entered - increasing the duration of the task due to an early start yet maintaining the logic which many times no longer applies. The fix for this is to actually modify the task dependency to accurately reflect how it was started in relationship to the predecessor.
At some point MS Project (I believe it was with the 2007 release but may have been before that) changed the way task dependencies were handled when updating the project schedule. The process used to hold logic until an Actual Start date was entered and then it reverted to calculating the task finish date by adding the duration to the Actual Start date entered. Now Project maintains the task dependency even if the Actual Start did not follow the logic created. Using your examples:
Task A – 4d
Task B – 4d – Task A FS
Task B Actual Start on day 3 in lieu of day 5
Task B duration now becomes 6d long
Our company is a multi-family general contractor in central Florida. We build large apartment complexes, senior care, hotels, timeshares (which are few and far between these days), etc. Our schedules deal with larger groups of units and we use a lot of leads and lags to overlap trades. I was hoping this issue would have been discussed and I guess I was wondering if there is a specific way to create schedules that alleviate or minimize the impact of this condition. My fix is to adjust the logic to accurately reflect the date we want the subcontractor to complete the scope. It is hard to get PMs and APMs to actually focus enough when updating to pay attention to this issue. As a result, I lean heavily on SS+ relationships. Could you convey your view on this please.
Also, on the topic of SF dependency, I look at that logic differently. I use it to create a Start and Finish date for a scope of work that needs to complete prior to a scope that has a fixed date (either by dependency or constraint though I rarely use constraints in my schedules). An example would be normal weight concrete (though we refer to it as “lightweight concrete” in our schedules) at corridors and patios which is usually a long lead item requiring it to be scheduled 6-8weeks prior. There is a scope of work that needs to be completed prior to this work (engineering inspection, plywood & gypsum sheathing, door pans). The predecessor work may need to be completed out of sequence with the normal framing scope to accommodate the long lead task. Comments?
Thanks again for taking the time to present and for your time with these questions.
DAVID HAMMOND | Scheduling Manager
18 Years of Service
WINTER PARK CONSTRUCTION
WWW.WPC.COM
221 Circle Drive | Maitland, FL 32751
*********
This question was repeated by others who use my MS Project courses and some who had joined the webinar. Hence, I decided to put it as a post. There is another question on SF dependency, which I’ve already explained in the webinar. Now, let’s see the first question and how changing dependency changes the duration “visibly” to additional days!
The Situation
I’ll outline the situation that David has used and I’ve put similarly in my explanations.
- Two tasks – Task A and Task B
- Duration – 4 days for each task
- Task B follows Task A with a Finish-to-Start (FS) relationship.
- It has no lead or lag. It’s a pure FS dependency.
- You saved this plan, baselined and started tracking.
So far, no problem at all. This is shown below.
As shown above, both Task A and Task B, are of 4 days duration. There is a FS dependency between these two tasks. The black bar below the blue bar is for the baseline. The redline is for the status date, which is as on Wednesday (Day 3) end.
But then the problem arises when you start Task B ahead of its “planned start”. In other words, the “actual start” of Task B is ahead of the “planned start’.
It means the following:
- Task A planned start is on Monday (Day 1) and finish is on Thursday (Day 4). It’s going according to the plan. By days, I mean only working days.
- Task B's planned start is on Friday (Day 5) and it finishes on coming Wednesday (Day 8). This is because of the FS relationship.
- But then Task B actually started 2 days before, i.e., instead of starting on Friday (Day 5), it started on Wednesday (Day 3).
This is how it’s represented in MS Project.
Can you see the problem above?
The Problem
Task B has a splitting line drawn in-front when the actual start is on Tuesday (Day 3). In other words, the total duration looks to be 6 days instead of 4 days.
This is what David notes in his problem and tells the Task B becomes 6 days of duration. Because Task B has now the following dates in its duration:
- Day 3 (Wed) + Day 4 (Thu) + Day 5 (Fri): This week, which totals to 3 days.
- Day 6 (Mon) + Day 7 (Tue) + Day 8 (Wed): Coming week, which totals to another 3 days.
The representation at least shows that Task B is of 6 days of duration, instead of 4 days. Hence, it becomes confusing for many.
However, MS Project software correctly notes the values in the Tracking table. The default table is Entry table and I’ve switched to Tracking table by going to View – Data – Tables – Tracking table.
As you can see, in the tracking table, Task B’s remaining duration is still 4 days, not 6 days!
Nevertheless, some management practitioners want to show the dependencies properly with FS dependency and no-split at all and that’s what David’s needs were and also others who sent related questions.
The Solution
To have the dependency shown without any splitting of tasks, all you have to do is clear the related checkbox in the global setting. You can do so by going to Backstage View – Options – Schedule – Scheduling options for this project – Split in-progress tasks.
By default, it will be enabled. You have to clear this checkbox.
After you disable split in-progress tasks, you can have the below representation in MS Project.
As you can see, now the dependency is shown properly. For Task B, the schedule has shifted two days to the left (also from the baseline) and the total duration “visibly” is 4 days, not 6 days.
Cautions
Be careful with such situations as there will be consequences for it. As the MS Project software notes in splitting in-progress tasks the following.
“Allows rescheduling of remaining duration and work when a task slips or reports progress ahead of schedule.
If this check box is cleared, progress information is recorded on the originally scheduled dates, regardless of when the actuals took place. Likewise, remaining work is not scheduled to maintain the task relationship.”
This statement is significant as noted in MS Project software tool. If you are clearing the checkbox, then the progress information will be on the originally scheduled dates. Also, the remaining work of the tasks will not be scheduled to maintain the task relationship.
Conclusion
When a task deviates from a pure FS relationship, then various software will have different representations depending upon the logic set.
When a pure FS relationship is changed–as in our case the actual start of the success task is before the planned start, the FS relationship is no longer pure. The logic is also no longer pure. This kind of logic among tasks is known as out-of-sequence (OOS) logic.
If you are a scheduling manager or a scheduling professional, you should be clear about various OOS logic that can happen in a schedule and the subsequent impact on the schedule.
