Forum Discussion
Finish-to-Finish constraint not allowing representation of early start.
Hi All,
Hopefully you can help provide some clarity.
I have a task 'Task A' which has a predecessor 'Task B' with a finish-to-start relationship
Task A can start as soon as Task B is complete.
The issue is that Task A also has 2 predecessors with finish-to-finish relationships (Task C & Task D).
MS Project is reporting the start (and early start) of Task A as the finish date of Task C or Task D (the later) less the duration. Where as realistically Task A can start as soon as Task B is finished but not finish until C & D are finished.
That's better, or at least it now makes more sense.
As set up the predecessors for 'Task A' effectively determine when 'Task A' can start. The driving dependency is the finish-to-finish with 'Task D'. A finish-to-finish dependency means that 'Task A' CANNOT be completed until, in this case, 'Task D' is complete. There is no conflict with the finish-to-start relationship with 'Task B' since that dependency means that 'Task A' cannot start until 'Task B' is complete. It does NOT mean that 'Task A' will start immediately after 'Task B' finishes.
I note that tasks 'C' and 'D' have start-no-earlier than constraints but the start of 'Task B' is apparently defined by the Project Start date. If there is some flexibility in when 'Task B' starts then this dependency configuration will get what you want.
If that doesn't work in your situation, then the only way to have 'Task A' start immediately after 'Task B' finishes is to remove the finish-to-finish relationships.
John
9 Replies
J_Tebbens,
You're welcome and thanks for the feedback. Now I see my first response. I don't like the format of this forum. It would be much easier to follow is all the entries were in chronological order, but it is what it is.
John
J_Tebbens,
Wow, it looks like you dug back into the archives. What you want is known as a Hammock task. This Wiki article will explain how it works and how to set it up:
https://web.archive.org/web/20200723171939/https://social.technet.microsoft.com/wiki/contents/articles/32040.ms-project-hammock-tasks.aspx
John
- Jay,
You have not asked a question, but you seem to expect that MS Project's scheduling algorithm will treat task durations as elastic. It does not. While task duration can be made to automatically respond to resource assignments, it is rigid for the schedule calculations. Consequently, the ES-EF and LS-LF intervals must equal the duration. As a result, the ES of your task A is pushed out as needed for the EF date to satisfy the more stringent FF restraint from tasks C and D.
Elastic durations were allowed in early CPM scheduling software, but the introduction of non-FS relationships and extensive resource-loading makes for a lot of complications.
Most importantly, elastic durations are anathema for efficient resource use. E.g. assume your task A's optimal duration has been estimated on the basis of a large machine and crew working for two weeks, but task B finishes four weeks before the finish of either C or D. You may start work on Task A immediately after B finishes (your expected early start), but the crew will soon need to slow down or interrupt work to avoid violating the later constraints. Productivity suffers. MS Project (like other modern scheduling tools), delays the early start of Task A until a clear path of uninterrupted progress to its completion exists - i.e. two weeks before the completion of tasks C and D. Right off the bat the second paragraph about 'Task A' having a predecessor of 'Task B' with a finish-to-finish relationship is contradictory. It can't then also start as soon as 'Task B' is complete.
This is how I read your scenario
If you can clarify what you mean, perhaps we can help.
John
Thanks for the Prompt Reply, Apologies my description was wrong. I should have stated:
I have a task 'Task A' which has a predecessor 'Task B' with a finish-to-start relationship
In the below example I want to show it is possible to start Task A on the 07/07/2022.
That's better, or at least it now makes more sense.
As set up the predecessors for 'Task A' effectively determine when 'Task A' can start. The driving dependency is the finish-to-finish with 'Task D'. A finish-to-finish dependency means that 'Task A' CANNOT be completed until, in this case, 'Task D' is complete. There is no conflict with the finish-to-start relationship with 'Task B' since that dependency means that 'Task A' cannot start until 'Task B' is complete. It does NOT mean that 'Task A' will start immediately after 'Task B' finishes.
I note that tasks 'C' and 'D' have start-no-earlier than constraints but the start of 'Task B' is apparently defined by the Project Start date. If there is some flexibility in when 'Task B' starts then this dependency configuration will get what you want.
If that doesn't work in your situation, then the only way to have 'Task A' start immediately after 'Task B' finishes is to remove the finish-to-finish relationships.
John
