We are seeking to create a Project Gantt Chart w/ (2) Levels: Deliverables & Tasks.
Tasks live under deliverables. Deliverables are dependent on other deliverables. Tasks are dependent on other tasks.
We have used the mirror Timeline to show the Task Timeline in the Deliverable Item already. The duration of the Deliverable is determined by the duration of the Tasks underneath it.
The first task of a Deliverable should not be allowed to start until the Parent Deliverable’s Dependents have been completed / their timeline has passed.
An example:
D1 (d1-d5 from Tasks)
T1.1 (d1-d2)
T1.2 (d3-d5) Dependent on T1.1
D2 (d6-d10 from Tasks) Dependent on D1
T2.1 (d6-d7)
T2.2 (d8-d10) Dependent on T2.1
This has not worked. T2.1 tries to start on (d1) The minimum start date of the tasks is not controlled by the minimum start date of the parent and the mirror columns don’t recognize themselves as drivable.
@basdebruin this one is right up your alley I think. Seems to be as simple as the earliest subitem must pull its start date from the parents start date, and the parents end date is set by the last subitem end date. Any thoughts?
not as easy as you might think. The challenge is knowing what the first subitem is and what the last. Closest I can think of is SchedulerPro from WorkPerfect. Support items and subitems, but not sure if subitems can be made dependent on parent item.
I can identify what the “first” is by identifying any subitem without a predecessor.
The last is whichever has the last / max end date. I’ve written the logic before for other software, its figuring out how to make Monday behave.
I have written some conditionals into Monday to define these things via their formulas but then I can’t access the “Finish” date of the Deliverable predecessor, only the text of the name of the dependent, not an actual object.
If SchedulerPro allows this kind of definition I am in because I have a thousand deliverables from several teams and I don’t want to manually link them.
Didn’t realize this limitations when we did project setup earlier this week.
Yeah the dependency issue is because dependencies only work within the same board. So it is the same root cause. The only clean solution involves automations that will respond to a change in the timelines of items, and update the deliverable end date based on the last task, and the first task based on the deliverable start date. You’re definitely getting into custom programming work here. Unfortunately dependencies also seem to restrict themselves. The problem with automations is if you’re changing fast things can get out of sync.
However you can possibly manually work around it by making your tasks dependent on tasks of other deliverables - but this is brittle if you change task orders or add/remove tasks.
Then you’d just need to set your deliverable dependency to no action, and then roll-up the subitem timelines to the parent (@basdebruin does Rollup Subitems handle that part?).
Since the deliverable timeline is driven by the task timelines, which is the real dependency - the deliverable dependency would be “for show” to just appear on the gantt chart.
Then if you edit tasks on other deliverables they will impact downstream tasks regardless of the deliverable.
This is where making the first child dependent on the last child of the item the parent depends on comes in. You can cross parents with dependencies of subitems.
So when the last child of the preceding parent changes, it affects the first child of the item. Then those changes roll up to their parents.
Yeah, could do that, but 1) I shouldn’t have to. This is basic project management and 2) that is thousands of items and Mondays dependent search field has a horrible habit of glitching out making that a nightmare and 3) that is adding extra dependency lines into the gantt creating confusion.
If I have to do this all manually I will spend 10 hrs doing that, but what I’m seeing is that Monday is just not designed to handle basic tasks
I can generate the initial schedule by turning on the RollUp Subitems automation, to adjust the parent timeline.
Then I can turn that off and use the SubItem Automation to adjust subitem start dates based on adjusted parent timeline and turn on flexible dependencies which moves it out…
But then I can’t do anything going forward as the system is locked and nothing will drive the child items.
I need to control the start date of children to simply not start before the parent. Parent moves out, children move out. Parent moves back, children move back. Children stretch longer, parent stretches longer.
You can manage this in a grossly convoluted manner for pushing things later but not pulling them back.
ON: Parent from Child
Dependency: None
Off: Adjust child by parent
Adjust the Children
OFF: Parent from child
ON: Adjust Child by Parent
Dependency Flexible
This allows the driving item to shift and adjust its own parent. Then you control the order of Monday operations and drive the dependents out and then adjust the dependents children
Daniel from Subitem Automations here. Just to make sure I follow - You basically want to set up the original due dates on creation and from that point on to have them move together whenever you make a change in the item (deliverables) is that correct?
If that’s the case you can set up your deliverables by hand, make sure that if the parent item change, you make the same changes in the subitems using this →
The only manual work you need to do is to define the initial setup on creation, which can be a bummer. If I’m thinking how to automate this process, if the subitem always have the same name you can use this to define the default values →
Simply put, a task has subtasks underneath it and the task is dependent on other tasks which drive the tasks start date.
A subtask may not begin before the beginning of its parent task. A parent should end when its last subtask ends
The issue above is that it creates a loop as it isnt confined to pushing the start down and the end up…
We tried something similar yesterday, if you increase the duration of a subtask because it took too long, the parent increases per automation (2). Then automation (1) occurs extending the duration of the subtasks, which kicks off (2) again.
Here is the flow of how this should typically work. Would work the same way if a subtask shortened in duration.
If a task has subtasks, the duration of the task should always be driven by its subtasks (that’s the purpose of subtasks in scheduling). A child, by definition should not be allowed to start before the parent is capable of starting. If the parent has dependencies, those dictate the start of the children as well. When the children are completed, the parent is completed as well.
This is how all other systems manage this and is, as noted, basic project management definitions.
The purpose of a sub-task is that you break down a task into more manageable chunks however the subtasks should encompass all work for a task. They aren’t a checklist of things to do, they are the body of work.
From an order of operations perspective, parent duration is always over-ridden by the sum of child durations.
Children can be dependent on other children and their start is driven by the end of their dependents & start of their parent (whichever is last. The parent should have dependents controlling its start date already).
The Parent should have its duration controlled by its children once it has children.
You must split and separately calculate the start date, end date, and durations… Calculate start date, hold duration, calculate end date…
@NickGiglio we’re now working on a new version and we’ll add the ability to make sure a subitem doesn’t start before its parent item or connect item date.
Would be great if you could shoot me an email to daniel@fantasymedia.io, would make the conversation much faster
When you say parent ends - That would be a date column? Timeline column? If I understand correctly you want the date of the item to be determined based on last date of its subitems. Is that correct?
