Subtasks Predecessors Controlling Parent Task

I believe the subtasks could be much more useful if this was possible.

  Name                       Predecessor

1  Task 1       

2  Task 2                   1FS, (4FF might not be necessary depending on implantation)

3     Subtask 1           2SS    <---- (can't currently do)

4     Subtask 2           3FS

5  Task 3                    2FS    <---- (can't currently do)

Currently you can't set predecessors on tasks that don't have dates assigned. Once dates are assigned to the parent task, the subtasks won't push out the end date of the parent task if the subtasks are scheduled past the parent task end date. Currently in this case the parent task is shown extended with a transparent extension but that extension has no effect on anything (i.e. can't be used as a predecessor).

It would be a simple matter to allow setting predecessors from other tasks directly to a parent task with subtasks. This would allow creating a task with predecessors set to other tasks as usual. Then at a later date add subtasks under a parent task and set the predecessors of the subtasks to the parent task to allow the subtasks to control the start and end date of that parent task. Adding subtasks to any parent task would NOT require you to modify the dependencies already set up between parent tasks. 

Currently you have to connect the subtask from under one parent task to a subtask under the next parent task to create the correct dependencies. This makes no sense if you support hierarchical task structures.

This would enable parent tasks with their associated subtasks to be treated as a package with other tasks linking to and from only the parent task with the subtasks controlling the duration of each parent task they are under.

This seem like a basic function that for some reason is missing and would address several problems mentioned in product feedback.

 

 

 

 

 

Upvote 11
8 comentarios
Spot On Innovative Approach Stellar Advice
Avatar

I think we are experiencing the same issue, if I'm understanding Ray correctly. By the nature of being a SUBTASK, the relationship is assumed to the parent. 

The missing relationship is causing similar issues for us. The subtask becomes an outlier when we start adjusting durations on parent tasks and it does not move along with those tasks. 

4
Acciones de comentarios Permalink
Spot On Innovative Approach Stellar Advice
Avatar

Same issue for me. If we assume the subtasks are components of the parent task, then the parent task should not have a pre-specified duration. That should depend on the durations of the subtasks and how they are linked.

 

1
Acciones de comentarios Permalink
Spot On Innovative Approach Stellar Advice
Avatar

Thanks for your suggestion and support here! I really think this is a very interesting idea. I'll try to mention this thread where possible on the Community 🙂 To get a status from the Product team, the post will need 60 upvotes from the members. 

 

Lisa Community Team at Wrike Wrike Product Manager Become a Wrike expert with Wrike Discover

Lisa Wrike Team member Become a Wrike expert with Wrike Discover

0
Acciones de comentarios Permalink
Spot On Innovative Approach Stellar Advice
Avatar

Hi everyone who reads this, hope you're well!

I'm adding this comment in the hopes that someone found a solution or workaround, or in the hope that someone else in my situation feels some sanity knowing that this issue still persists. 

Ray explains the crux of the problem: "Once dates are assigned to the parent task, the subtasks won't push out the end date of the parent task if the subtasks are scheduled past the parent task end date. Currently in this case the parent task is shown extended with a transparent extension but that extension has no effect on anything (i.e. can't be used as a predecessor)."
 
If Subtasks cannot dictate the expected finish of a task it resides within, what is the point to creating that hierarchy between tasks and subtasks? 
 
As Ray wrote: "This would enable parent tasks with their associated subtasks to be treated as a package with other tasks linking to and from only the parent task with the subtasks controlling the duration of each parent task they are under." 
 
Angela commented: "The missing relationship is causing similar issues for us. The subtask becomes an outlier when we start adjusting durations on parent tasks and it does not move along with those tasks." 
 
And Michael also commented: "Same issue for me. If we assume the subtasks are components of the parent task, then the parent task should not have a pre-specified duration. That should depend on the durations of the subtasks and how they are linked." 
 
This is theoretically the ideal situation for my use case: I have a project which has a rolled up duration from the tasks within it and has a floating end date (The latest expected end date of any given task within a project is the project's projected end date). The tasks themself within the project also have rolled up durations from the subtasks within it and a floating end date. And based on how those subtasks are dependent, the task's floating end date is adjusted as activity changes (the latest expected end date of any given subtask within a task is the task's projected end date. By default, every task or subtask starts ASAP, but I can prevent that by creating dependencies between tasks or subtasks, to create a string of work to be completed. Each subtask should by default affect the parent task's end date, unless I decide for it not to. In this scenario, I can create more subtasks and have them affect or not affect the parent task it resides within. In addition, as the time for completing subtasks changes (things take shorter or longer than we expected) this would push out the whole project's projected end date and properly allow a team to know at any given time when a project is supposed to finish. This logic would then allow me to keep creating more subtasks within subtasks recursively, and have the dependencies stay properly aligned. 
 
As a default rule, I should not be able to start a task before the project has begun, similarly to how I should not be able to start a subtask until the parent task has begun. This way, I can set up the dependencies within the tasks, and when I create new subtasks within the tasks, that initial dependency still remains in tact and is enforced (What is the point of having task 2 be dependent upon task 1 if task 2 can begin before the subtasks in task 1 are finished?) Again as Ray wrote regarding the gantt chart: "the parent task is shown extended with a transparent extension" as subtasks within it are extended, but that extension does not push out consequential tasks. 
 
I really hope that my inability to configure my dependencies is simply my naivaté with using the platform. Please let me know how I can achieve this desired state above. It seems like this comment is from 2019 and has 14 total upvotes, hopefully a solution has been determined. 
0
Acciones de comentarios Permalink
Spot On Innovative Approach Stellar Advice
Avatar

Kevin Isernio How about a finish-finish dependency on the parent task? Could that help? It will shift the parent task end. Unfortunately also shifting the start of the parent task. You could link the first subtask to a predecessor so you will keep your project plan.

0
Acciones de comentarios Permalink
Spot On Innovative Approach Stellar Advice
Avatar

Hi Sven Passinger

Thank you for following up-- following your example above, why would the start for "test parent" be affected by "test subtask"? If the dependency is based upon the finishing of things, i.e. "FF". Is there any way for this not to happen?

Surely if I started a task 2 months ago, and now create a new subtask within it which adds two days, I would only desire the expected end date to adjust rather than the initial start date. It seems as though as a default, Tasks should not be able to start until a project does, and a subtask should not be able to start before a task does. So a task's duration is comprised of the aggregate duration of the subtasks within it and determined by how those subtasks are dependent upon each other. Similarly, a project's duration is comprised of the aggregate duration of the tasks within it and how determined by how those tasks are depended upon each other. Things start ASAP by default, whereas a task cannot start until a project has begun, and a subtask cannot begin until its parent task has begun. This way I can enter in a start date for a project, and it would spit out a projected finish date. Then as things come up, as I decide to add subtasks within a task, or extend or shorten the duration of a subtask, the ultimate projected end date for the project would properly update. Let me know if this helps. 

0
Acciones de comentarios Permalink
Spot On Innovative Approach Stellar Advice
Avatar

Kevin Isernio I do not know any way that ff correlation does not shift the starting date. Lisa is their any way to make Wrike shift the task end date but let the start day remain the same (so to change the duration of the task)?

 

0
Acciones de comentarios Permalink
Spot On Innovative Approach Stellar Advice
Avatar

Hi Kevin Isernio, Sven Passinger, at the moment, the dates will shift in this situation, you can find out more in this Help Center article

I do however understand the use case here, and I've shared your feedback with the Product team👍🏼

Cansu Community Team at Wrike Wrike Product Manager Infórmate sobre las funciones y prácticas recomendadas de Wrike

Cansu Wrike Team member Infórmate sobre las funciones y prácticas recomendadas de Wrike

0
Acciones de comentarios Permalink

Folllowing List for Post: Subtasks Predecessors Controlling Parent Task
[this list is visible for admins and agents only]

Arriba
Didn’t find what you were looking for? Write new post