Take slack time into account when rescheduling dependancies
building now
T
Tadej Jevsevar
If you reschedule a task and there is sufficient slack time do not reschedule the dependent tasks.
(Submitted via User)
Log In
Vasil Enchev
updated the status to
building now
Moving to building now.
Five and a half years on this thread and not one word from us. Correcting that.Today a reschedule moves the dependent task by the same number of days as the task you moved, room or no room, so the slack you deliberately built in gets eaten. The fix in QA makes that gap a value stored on the dependency instead of the distance between two dates, which gives a reschedule something to respect. Float and critical path come after it.
The 2021 comment here called it correctly: this needs dependency lag underneath. That is how it is being built.
One thing worth settling while we still can: should respecting slack just be how rescheduling works, or do you want it as a setting you turn on per project?
Brendan W
Merged in a post:
Autoscheduling of dependencies to take into account slack time
Gion Herren
the re-scheduling of dependent tasks should only begin once the previous task has used all the time allotted slack time before the next task.
As of now, the autoscheduling moves dependent tasks by the same amount, leading to a cascade that hurts the integrity of the data present in our projects.
We really want to use the autscheduling feature, but it should consider slack time before moving all tasks downstream.
Photo Viewer
View photos in a modal
K
Kyle Denny
It appears initial comment is from 2021. Almost 5 years and still no development. Completely agree with everyone hear. Slack time or float is one of the most important items when handling a project management schedule. Please implement or provide update.
Vasil Enchev
Update, and a real one this time. Today a reschedule moves every dependent task by the same number of days regardless of the room between them, which is exactly the behaviour you are describing. The work to change that is in QA: the gap between two dependent tasks becomes a value stored on the dependency itself instead of just the distance between two dates, so a reschedule stops eating it.
Float and critical path calculated from those gaps is the milestone after that one.
Credit to the 2021 comment on this thread, which said this would need dependency lag underneath to work properly. That is precisely how it is being built.
Vincenzo Ursino
This is vitally important for us when we build a medium/large projects. Paramontly important and we wonder why this has been designed in such wrong way from a project management point of view!! Please, fix this ASAP...please!
J
Jagan S
+1 Need this feature. The easiest thing would be to make this a configurable option - so we can select if to use up slack or not.
Shaun Munro
This is vitally important for us when we build a large project. There is only one critical path generally and slack is built in throughout other parts. A task should be able to move within its given slack until it bumps up against it successor with out moving everything else downstream. I'm guessing clickup will have to support dependency lag to also make this work correctly.