none
Finish to Finish isn't Being Enforced - Why? RRS feed

  • Question

  • Hi All,

    I'm struggling...I have a task that needs to have a Finish to Finish (FF) relationship to a prior task because the task cannot finish before the first one finishes.  It was working fine until Actual Hours were entered. now the FF isn't being enforced and I don't understand why.   It is allowing the task to finish months prior to the first task finishing.

    Task Inspector doesn't show anything useful I can find, but if I delete the predecessor and then add it again, I get a warning:

    but I don't think there's any conflict.  The task has no constraints on it, nor does the predesscor task.  Row 41 is the one I am speaking of specifically, it should have a FF with task 35, but you can see it's not enforced like the other tasks that also have a FF with 35.  The difference are the Actual Hours on 41, which I understand will effect the Start, but shouldn't effect Finish.

    What am I missing?

    Thanks!

    Wednesday, August 20, 2014 5:37 PM

All replies

  • RichPM,

    Normally any dependencies on a task become null and void once the task has an actual start date.

    The piece of information missing from your screenshot is the Baseline Start date. That will show if the task started on the original planned date, the one that helped define the duration and dovetailed into the finish-to-finish relationship with Task 35. If Task 41 started earlier (or later) than originally planned the duration will define a new finish date, assuming nothing was done to change the duration, and that finish date will most likely no longer coincide with the finish date of task 35.

    If you still want task 41 to finish at the same time as task 35 and the actual start date of task 41 is not the baseline start date, then you will need to change the duration.

    Hope this helps.

    John

    Wednesday, August 20, 2014 6:48 PM
  • Thanks John.  The actual start date was not the baseline start date, the start date was revised once actuals were submitted by the resource through Project Server.  Let me make sure I understand...

    Once an Actual Start Date is entered, any dependency is invalidated but not removed from the predessor colum, right?  It makes perfect sense to me that an Actual Start Date would invalidate a dependency that defines the START of th task, but it doesn't make sense to me why it would effect the FINISH of the task in my situation.  I'm sure you're correct, but if there's logic to it I'd appreciate understanding it better.

    So now I need to change the finish date of task 41 manually to it doesn't finish before task 35?  If I do that, won't it set a Do Not Finish Before constraint on task 41?  There would then be no link between 35 and 41 any longer, am I right?  So if 35 gets done a week early and 41 could have started. it won't because of the new date constraint that occured when I moved the date, correct?  Similiarly, if task 35 is delayed, there will be no corresponding lengthening of task 41 finish date, right? 

    Thanks so much!

    Wednesday, August 20, 2014 7:03 PM
  • RichPM,

    Yes, that's correct, once a task has started, the predecessor link still exists but it is as I said, null-and-void. Keep in mind that task dependencies define the dynamics of a schedule - how things will play out according to the original plan. The plan remains dynamic until actual data drives a stake in the ground. Network logic continues to drive the schedule for any tasks that have not actually started.

    I was going to use your tasks as an example but you apparently have some custom calendars that make it difficult to replicate your dates so I'll use a simple example. Let's say we have two tasks A and B that are set up with a finish-to-finish dependency. Task A has a start date of 8/18/14 with a duration of 10 days and task B has a start date of 8/25/14 with a duration of 5 days. The start date of task B is driven by the finish-to-finish predecessor with task A so both tasks have a planned finish date of 8/29/14. Task A starts on plan (i.e. 8/18/14). The resources were available to go ahead and start task B so an actual start of 8/20/14 is entered for task B. Since there is nothing that changed the duration of task B, it remains at 5 days, and that then pulls the finish date back to  8/26/14, three days earlier than the finish date of Task A (8/29/14). Oops.

    If both tasks must finish together, how do we fix this? There are a few ways, but trying to set up a finish-no-earlier-than constraint isn't one of them. We could simply extend the duration to 8 days but that will increase the work content. If the work content must remain unchanged, we can edit the work or resource assignment level such that the desired finish date of 8/29/14 is maintained.

    Note that if task A has a delayed start date, and task B has not been started, then the schedule dynamics will still be in effect and task B will slide out such that it still shows a finish date the same as task A.

    Hope this helps.

    John

    Wednesday, August 20, 2014 8:11 PM
  • Thanks again John, that makes it much more clear.  I was under the impression that with a FF, Project would effectivly put a finish no earlier than the finish date of the predecessor task and lengthen the duration accordingly on its own. 

    Knowing this, using a FF at all seems like it may be a bad choice for me going forward since at the time I'm building the plan it is based on rough estimates and is almost certain to change and blow away the FF leaving me to have to watch it manually.  Is there a better way to accomplish this from the onset?  Hammocking the two tasks for instance?

    Thursday, August 21, 2014 1:19 PM
  • RichPM,

    Project has no intelligence of its own and that's probably a very good thing because creating time based activities (i.e. schedules) are dependent on many variables, many of which are "soft" (e.g. managing labor resources). So it has no way of knowing for example, the user's intent with regard to a finish-to-finish relationship. And that brings me around to your question about a better way to accomplish "this" from the onset. What is your reason/need for the finish-to-finish relationship? There may or may not be a better way to do what you need/want.

    John

    Thursday, August 21, 2014 4:00 PM
  • Thanks John, here's my situation...

    The "Service Establishment" tasks is basically setting up servers.

    The "Shares, Passwords" task is work for the Security team on those servers.

    At this stage, I have only high level estimates and not detailed tasks.  I know the Security team has already begin some of the work, but we don't know how long all the work will take or when it can or will need to be done.  Generally they do some work throughout the server setup and then some finalizing work at the end.  I would like to just have the Security task span the entire length of the Service Establishment until I know more.

    Thanks!

    Friday, August 22, 2014 1:55 PM
  • RichPM,

    Okay, then that's a situation where you might want to create a hammock task. Be advised however that a hammock task requires the use of paste links and those are prone to corruption, and since your plan is not fully developed, why risk complications on something that will change.

    Here's an alternate approach you might want to consider. Instead of trying to tie the security team effort to a definitive time span, why not simply break it into weekly or monthly bites. For example, create a task called "Create passwords for August", another "Create passwords for September", etc. Do this as long as necessary. If the security team won't have effort in a particular month/week, either don't create that period's task or simply enter zero work effort.

    John

    Friday, August 22, 2014 2:48 PM