[Status: Investigating 🕵️] Allow Subtasks to Update Start and End Dates of Parent Tasks

Hello everyone! I am excited to let you know that we have just released the long-awaited update. Now when you reschedule a subtask and its dates fall outside a parent task dates Wrike offers you to align the parent task dates. Also, if you reschedule a parent task you can reschedule its subtasks accordingly. Read the Help Center page for additional details and let us know if you have any questions!

Anna G Community Team at Wrike Wrike Product Manager Erfahren Sie mehr über Wrikes leistungsstarke Funktionen und lernen Sie Anwendungsbeispiele kennen

Anna G Wrike Team member Erfahren Sie mehr über Wrikes leistungsstarke Funktionen und lernen Sie Anwendungsbeispiele kennen

Wahoooo!  This will be very helpful.  Can't wait to try it out.  Now, I'll shift my posting focus to the Leads/Lags topic, another needed feature to make this system a more complete PM tool.  :)  Thanks!

Will my parent tasks automatically update for projects that have already been created? Right now all of my parent tasks are set to "backlog" and my subtasks are all connected by dependencies. I'm not sure how to initiate getting all of the parent tasks to update with the roll up. If there a button I can click to just "auto" roll up everything, or do I need to go into every parent task to activate the rollup?

Hi. We are in the middle of a wrike rollout for our entire organization.  I've been closely watching this thread, since the parent/rollup tasks have been a sticking point for us. I hate to start out with negative feedback, but there's a couple key things here that prevent this new feature from being useful for us.

1.) Alignment only happens when you "reschedule subtasks to before or after the parent task’s dates".  This means parent tasks can grow, but not shrink.

2.) Changing upstream task dates does not align the parents of downstream dependent tasks.

As a result, you end up with something like this:

Crossing my fingers that these issues can be addressed with a future update!

I'm excited about the progress, but feel that there are major issues.  

- Can't there just be a check-box in a parent task that automatically have it automatically span the subtasks?   The repeated notifications are inefficient.  This will get confusing when a task's duration is changed that is followed by multiple parent tasks.  Will there be a request to change each of them?  

- Following that, I actually can't get the above to work.  When I extend the duration of a task which affects a later parent task, that parent task doesn't change.  

- And absolutely agree with Dave that the parent task must be able to shrink as well as grow is essential

Agree with Brad.  I was hoping this would be a task scheduling option (ie "Rollup") that would silently update the parent task start and end dates for any and all subtask updates.  Implied is that manual changes to the parent task dates would be locked out when in this mode.

Please, make it possible to turn off the notification. I don't want to click the X with every task that I change the date of. 

Hello everyone!

@Keeley Wrike doesn’t offer you to schedule backlogged tasks that have scheduled subtasks. To trigger the alignment, you would need to schedule a parent task to any date that’s in the range of subtasks’ dates. When you see a notification about dates alignment click “Apply” and the parent task will expand to encompass its subtasks’ dates. I realize that this process is tedious but I wanted to provide at least some way to do it.

@Brad At the moment Wrike doesn’t suggest extending dates of parent tasks that are linked to other tasks with a dependency, but it may be changed in the future releases. Please let me know if I misunderstood your issue!

@Megan, @Dave, @Chielant Thank you so much for your feedback, it’s really important for our product team and I will certainly pass your requests to the PM of this feature.

Anna G Community Team at Wrike Wrike Product Manager Erfahren Sie mehr über Wrikes leistungsstarke Funktionen und lernen Sie Anwendungsbeispiele kennen

Anna G Wrike Team member Erfahren Sie mehr über Wrikes leistungsstarke Funktionen und lernen Sie Anwendungsbeispiele kennen

@Anna thank you for the heads up! I went in and updated the parent task (or rather am still in the process, but it's working and readjusting accordingly). I have noticed that it only adjusts the end date of the task, however, and does not readjust the start date if the start date on the parent task was entered as a later date than the start of the first subtask. 

Additionally, I'm seeing that the date range for the Project itself is not updating to match the new date range for all the parent tasks. It should all roll up from the subtasks to parent tasks to the project as a whole, because the project itself can only start as early as the very first task and end as late as the very last task (or at least users should be able to use the "apply" feature if they run projects that way... I understand more Agile projects use backlogs and therefore have a project end date that is set but many backlog tasks that are not)

Akira IT manager

Okay, so I tried this out, and I am disappointed, sorry to say (see my test explanation later in this post).

Why this cannot have the same logic for parent and subtasks like Microsoft Project or Smartsheet is beyond me, and is what has halted my team from adopting Wrike, even though we are still paying for a multi-user account while waiting.  We've actually reverted to Smartsheet, to be honest.

I know I am hitting a little below the belt mentioning other products' names (and gave others grief for it in the past), but if this area of Wrike could work the way I (and many, many others) need it to, it could move mountains, literally.  Smartsheet's native alerts and collaboration capabilities stink in comparison to what Wrike has to offer, but the basic functionality which everyone expects in a PM tool, like this thread has discussed, is not present in Wrike and is too critical to deal without. 

There are others, like setting dependencies in Table View AND leads and lags with dependencies that are critical to making this a holistic PM tool.

THE TEST

So...here goes my simple test which shows me that I cannot yet expect my users to adopt the system

Parent Task 1 - no dates assigned - going to let it get its dates from the subtask (so I think...see below)

      Subtask 1 - scheduled 10/16 through 10/20

Expecting Parent Task 1 to take on the 10/16 through 10/20 dates... NOPE!  Didn't even get a prompt (which shouldn't be necessary anyway).

Another test - adjust Subtask 1 dates to be 10/23 to 10/27 thinking that may trigger the prompt to move the Parent Task 1 dates.. NOPE .. nothing.

Would also be nice to see the range of dates Oct 16-Oct 20 rather than just Oct 20 (5d) on the task.

Please, please, please Wrike bring the features that will blow other solutions out of the water.

Is there some type of customer panel you'd consider for those that are passionate about the potential of the tool, but still need to see more features before it's really going to fit their organization?

Guys,

My company just decided to stop using Wrike and move to Smartsheet & Jira, and one of the main reasons named was this issue about parent tasks not changing date ranges when dependent tasks change. We waited long enough for you guys to fix this and many people did not like the tool. Hope you fix this for the sake of other users who are willing to wait, though reading this discussion, it seems useless to wait.

Please tell me.

Although I don't know the structure of the task table of Wrike, we should simplify our discussion, I think.
I guess Parent task should not have own "Start date", "End date" and "Duration".

These item of Parent task should be set based on the information of Sub-Tasks and Wrike should prevent registering these as Parent task.

The earliest Start date of all Sub-tasks belonging to the Parent task should be Start date of the Parent task.
Equally, the latest End date of all Sub-tasks belonging to the Parent task should be End date of the Parent task.
And Wrike can calculate Duration of the Parent task from the Start date and the End date of the above.

Everyone don't need the function that maintain "Start date", "End date" and "Duration" from Parent task side independently.

We are requesting Wrike to keep this rule in any case.

This is my understanding.

Is my understanding correct or incorrect?

Akira IT manager

Thanks Akira for simplyfying the problem - I totally agree with you that this would also be a solution for us. 

Thanks everyone for your comments! I just wanted to reiterate that your feedback is very important and it is passed to the Product team on a regular basis.

@Keeley Currently Project dates aren’t connected to dates of tasks and subtasks in it, but it may be changed in the future. Start date of a parent task should change though if you schedule it for a later date than the first subtask’s start date, I showed it on a GIF below. Would you mind sharing the same GIF where it’s not working for you this way?

@Akira Thanks for writing up your expectations so clearly. Would it help if there’s a setting that allows you to always roll up subtasks’ dates to a parent task?
About your question: to trigger the alignment of a parent task you need to reschedule any of its subtasks (not tasks connected to it with dependencies) or change the parent task’s duration. Once you do it Wrike will suggest aligning the dates: click “Apply” and the date (or dates) of the parent task will change.

@Megan If a parent task doesn’t have dates, then Wrike doesn’t suggest applying subtasks dates to it, but I understand that it’s a “must have” feature and have passed this request to the Product Manager.

@Oliver I am sorry to see you go and hope you will give Wrike another try some time in the future.

Anna G Community Team at Wrike Wrike Product Manager Erfahren Sie mehr über Wrikes leistungsstarke Funktionen und lernen Sie Anwendungsbeispiele kennen

Anna G Wrike Team member Erfahren Sie mehr über Wrikes leistungsstarke Funktionen und lernen Sie Anwendungsbeispiele kennen

The parent task SHOULD have dates... see the mock up I've done below.  This is standard PM practice.

Our csm Dury was kind enough to let me meet with the developer of the subtask alignment feature.  I showed him the 'Auto Scheduled' mode for parent tasks in MS Project, which seems to be everyone's expectation of how this should work.

The wrike implementation could be an additional scheduling option like this:

As others have suggested, the parent task still has a duration and start/end dates.  The difference is those need to be driven by the subtasks and not user-entered.

As Akira noted previously, the timeline view basically does this already with the shaded area.  We just need the ability to apply that to the actual task dates.

one last post to illustrate...

Thank you for everyone.

I guess everyone are imaging the same things.

I agree Parent (Summary) task should have Start-date, End-date and Duration.

But those are not physical information that user input and those are logical information that are summarized from Sub-Tasks.

I hope the development team of Wrike can realize everyone's request.

Akira IT manager

@Anna,

Thank you for your advice.

I probably have understood the current function that was improved, I guess.

But as long as Parent-task is having own date information physically and user can modify those directly,

some contradictions will happen somewhere and user will have to adjust such contradictions manually.

I don't want any temporally solution that is keeping this risk and I hope that you modify the function basically

like everyone is requesting.

I will use current function and I'm going to wait the completion of your modification for a while.

Akira IT manager

Hi,

I'm not able to get this to work correctly. It would be ideal if there was a setting that just automatically updates so I don't have to apply everytime. It's taking a lot of time and trial and error to force the parent task to update. I can get the "Update" dialog box to come up but it's not updating to the range of the sub-tasks.

Thanks,

@Jimmy Hi there! There are a couple of exceptions when the subtask alignment doesn't work and I want to figure out if that's whats going on here. Can you let me know if those exceptions apply? If not, I can raise a Support ticket so we can figure out what's going on. 

I want to say this feature is basic for PM. Automatic adjusting the parent task start and due date (should be fixed and not user entered).

Is there any advance in this topic?

My company is testing Wrike right now and it is basic to have this feature. Do you have a timeline of when this feature will be available?

@Erick Hello! Our team intends to improve the way this functionality works. Implementing changes does require an overhaul and alignment between multiple teams - which they want to do, but it will take a little more time. As soon as I have a more concrete idea around when things are planned for, I'll make sure to update this thread. 

Joining the conversation as well since I'm currently evaluating PM/collaboration tools for our company.

I first started out with Smartsheet as well but the collaboration features didn't quite meet our requirements.

However, all the great collaboration features Wrike offers become quite meaningless when the PM basics aren't in place.

@Akira simplified the problem very well in the October 17, 2017 post.

From a project management perspective, I see the task structure as a representation of the WBS.

As described under '5.4.2.2 Decomposition' in the PMBOK Guide (6th ed.), "The work package is the work defined at the lowest level of the WBS for which cost and duration can be estimated and managed."

It thus follows that duration estimation and management only takes place at the work package level and nowhere else. (Although material for a completely separate thread, it's important to note that this also means actual work is also only carried out on the work package level, as implied by the name already. Adhering to this principle would also allow a properly functioning time log. Right now, a summary task is also considered separate work and not a summary of the work to be completed in the sub tasks, rendering time log analytics meaningless as highlighted by @Megan in her January 25, 2017 post.)

The summary tasks are only summarizing (as the name implies) information collected from the subordinated tasks.

From a business logic perspective that could be translated into code regardless of how many levels the WBS has, I'd describe it as follows:

• If a task has no sub tasks (ergo it's a work package), start date and end date can be modified.
• If a task has sub tasks (ergo it's a summary task), start date and end date become unmodifiable and are inherited from it's sub task(s).
• If a task had no sub task(s) (ergo it was a work package), had a start and end date, and is now assigned at least one sub task (ergo it becomes a summary task), start date and end date are set to null*, become unmodifiable and are inherited from it's sub tasks.
• When a sub task's start date and/or end date is modified, the summary task's start date and/or end date is updated (as nicely shown in @Dave's October 17, 2017 post).
• When all sub tasks of a summary task are removed (ergo the summary task becomes a work package), the start date and end date are set to null and become modifiable.

* Setting the values to null before becoming unmodifiable and inheriting from the sub tasks ensures proper functioning if the sub tasks have no date assigned yet, thus leaving the start date and end date fields of the summary task empty until at least one sub task is assigned start date and/or end date values.

Based on this logic, no matter how many levels the WBS has, the start date and end date values are always retrieved from the lowest level (the work packages) and passed up the hierarchy.

I understand that the actual code to be written is incredibly complex since it has to account for all possible scenarios (which I'm sure is a much longer list than my non-exhaustive attempt above).

I really hope this feature will become available as soon as possible as I'm sure it'd make Wrike 'the PM/collaboration tool' compared to 'another PM/collaboration tool' now. I hope the overhaul and alignment between the multiple teams aren't depending on the functionality they're supposed to create, otherwise we're stuck in a unsolvable situation 😉

What happened to the comment added by Patrick?  I came out here to vote on it (would LOVE his comment if there was such an option), but it's not here.  I got an e-mail Friday evening with his comment in it as a notification to this thread, which I started.

Here's a screen shot of the comment, which I grabbed from the e-mail notification...

The conversation about this topic is almost 2 years old with a neverending stream of "i don't know when we will launch it" comments. We are working on a rollout for our company and this feature is going to massively hurt our workflow. 

When will it be fixed?

@Megan

I can't see Patrick's comment in this thread, too.

I think that his comment is very important summary of this thread.

So, let me paste his comment here again as Text.

@Diane,

I agree to your comment.

I guess almost users want to hear the clear schedule and the concrete plan of Wrike.

-----------------------------------------------------------------------------------------------------------------------------------------

Patrick Scheuchzer 

Joining the conversation as well since I'm currently evaluating PM/collaboration tools for our company.

I first started out with Smartsheet as well but the collaboration features didn't quite meet our requirements.

However, all the great collaboration features Wrike offers become quite meaningless when the PM basics aren't in place.

@Akira simplified the problem very well in the October 17, 2017 post.

From a project management perspective, I see the task structure as a representation of the WBS.

As described under '5.4.2.2 Decomposition' in the PMBOK Guide (6th ed.), "The work package is the work defined at the lowest level of the WBS for which cost and duration can be estimated and managed."

It thus follows that duration estimation and management only takes place at the work package level and nowhere else.

The summary tasks are only summarizing (as the name implies) information collected from the subordinated tasks.

From a business logic perspective that could be translated into code regardless of how many levels the WBS has, I'd describe it as follows:

• If a task has no sub tasks (ergo it's a work package), start date and end date can be modified.
• If a task has sub tasks (ergo it's a summary task), start date and end date become unmodifiable and are inherited from it's sub task(s).
• If a task had no sub task(s) (ergo it was a work package), had a start and end date, and is now assigned at least one sub task (ergo it becomes a summary task), start date and end date are set to null*, become unmodifiable and are inherited from it's sub tasks.
• When a sub task's start date and/or end date is modified, the summary task's start date and/or end date is updated (as nicely shown in @Dave's October 17, 2017 post).
• When all sub tasks of a summary task are removed (ergo the summary task becomes a work package), the start date and end date are set to null and become modifiable.

* Setting the values to null before becoming unmodifiable and inheriting from the sub tasks ensures proper functioning if the sub tasks have no date assigned yet, thus leaving the start date and end date fields of the summary task empty until at least one sub task is assigned start date and/or end date values.

Based on this logic, no matter how many levels the WBS has, the start date and end date values are always retrieved from the lowest level (the work packages) and passed up the hierarchy.

I understand that the actual code to be written is incredibly complex since it has to account for all possible scenarios (which I'm sure is a much longer list than my non-exhaustive attempt above).

I really hope this feature will become available as soon as possible as I'm sure it'd make Wrike 'the PM/collaboration tool' compared to 'another PM/collaboration tool' now. I hope the overhaul and alignment between the multiple teams aren't depending on the functionality they're supposed to create, otherwise we're stuck in a unsolvable situation 

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Akira IT manager

184 upvotes, 15 months and counting. I guess I shouldn't hold my breath for this ticket with 7 votes.
https://help.wrike.com/hc/en-us/community/posts/115002785409-Table-View-should-have-the-same-functionality-as-List-View#

Signed up for a Trial today and was loving the platform! Right up until I found this functionality gap.... which sadly it's a deal breaker issue.

If a parent task is composed of multiple subtasks I have to be able to see the accumulated total of time in that parent task, when that parent task starts and stops. Changes made to the child tasks should be applied to the parent correctly.

We currently use Clarizen and were hoping that we could move to something with a great interface and some nice integrations. Pitty...