Subtasks of subtasks and their subtasks
Hello,
Has anyone encountered any issues or confusion using too many subtasks?
any insight would be helpful.
Thanks!
Die von Ihnen gesuchte Seite ist nicht in übersetzter Form vorhanden, wir verfügen jedoch über andere Inhalte in deutscher Sprache und bieten deutschsprachigen Support an.
Wie können wir helfen?
Learn. Share. Discuss.
Hello,
Has anyone encountered any issues or confusion using too many subtasks?
any insight would be helpful.
Thanks!
Folllowing List for Post: Subtasks of subtasks and their subtasks
[this list is visible for admins and agents only]
Hi David!
I'm sure other people have different experiences, but personally I prefer to limit the amount of subtasks I use and I try to stick to using them in specific situations. Here is how I've been using them:
- Information storage - If I want to store information (like in an internal Knowledge Base for example), then I stay away from subtasks. If someone happens to find a subtask, they might not realize it's a subtask and miss some crucial information from the parent task. Also, using too many tasks/subtasks tends to silo related information and might make things confusing. So for information storage I tend to use Folders/Subfolders and naming conventions to organize information.
- Action items - This is where I've found subtasks to be most useful. If there's one action item that's made up of various smaller action items - then I use a task for the main action, and subtasks for the supporting items. That way you can assign and set dates for the subtasks individually. Normally I stick to tasks and subtasks and avoid adding subtasks to subtasks.
Does that help?
I tend to avoid subtasks because when they appear in your tasklist or dashboard you can't see what task or project they belong to until you open them up.
I sit somewhere in the middle on subtasks - I like to use them to define timelines and assignees for each action item, but as discussed, I've been at a bit of a loss with how to deal with spreading the required information between the parent task and the sub task. I find that a bit of information overlap is required, which isn't ideal.
I think one way to solve would be embedding the subtask within the information flow of the main task - This way the user that needs to complete the subtask would be able to see the parent information as well as any relevant information for them to complete the sub action.
Cheers!
Kevin
Hi everyone! Thanks for bringing this topic up - task structures can be very diverse, and I wanted to share some suggestions which will help avoid both information overlap and lack of details:
Happy to hear your suggestions based on the use cases you encounter!
Thanks for the response Anastasia -
What you mention brings up one additional recommendation!
What I would like is an option to more easily create links to other tasks. Currently one needs to navigate to the task, click the link icon, copy the link and then navigate BACK to the task in which you want to post the link. It would be very nice if there were an option to autocomplete a link within the task work space ( same functionality as ADDING a subtask? ). Even simply to add a link menu to the sub task right click context would be helpful, as I often make a summary of the subtasks within the parent task. This is currently a cumbersome process of navigating back and forth between the parent and sub tasks!
Cheers,
Kevin
Kevin, thank you for sharing that idea! I can definitely see the value in being able to easily reference tasks and subtasks, and I've shared this feedback with our Product Team :)
I have also experienced the unintended labyrinth of subtasks, especially when used by users who don't fully understand what they're doing. It may be helpful to explicitly decide & communicate the WHY of a subtask, which will dictate WHEN to use them, and when not to. The "why" will vary per your use-case.
After some experience, I think I'd advocate a general rule - no subtasks of subtasks.
... You should only go 1 level deep. Otherwise you create a needless "rabbit hole" that other people will tumble down.
Also, @Kevin I totally agree.
Once upon a time... in an earlier version of Wrike... you could @Mention tasks/folders in a comment. IMO this feature wasn't overly helpful, and has apparently gone away. However, I'd love to see it come back (sorta) but utilized in task descriptions, for exactly the reasons you've already described.
@Sam, I'm adding a +1 to Kevin's request on your behalf :)
Regarding the feature you mentioned, you're absolutely right - we found that removing it not only made the workspace faster, it also made the whole process of @mentioning a user more intuitive.
Our rule is to only go 1 level deep. We have one parent task, where all project information resides and team conversation happens. The subtasks are for individual assignments, each with their own due date micro-budget, so people can add time and easily keep track of the budget of their contributions. Basically, we use subtasks only for deadlines, timetracking and status markers for at-a-glance project progress.
The downside to this is that on dashboards where you have a by-due-date task list for a certain user, if they're assigned to the parent task and sub-tasks, it's possible to miss a deadline for a sub-task, since it's nested under the parent task and listed by the parent task's due date. Which is what I was looking for a solution to when I stumbled on this thread...
Hi Lacy! I think that using subtasks for individual assignments is a great idea. Are there any actionable items for individual users remaining in the parent task? If not, leaving the parent task unassigned, or assigning it to a supervisor, might do the trick here. This will help easily track subtask deadlines on the Dashboard for specific users. The parent task can be easily accessed right from the subtask, so users won't lose sight of any valuable information which may be stored there. Would this solution work for your team?
@Anastasia - it doesn't solve the problem for (I'm betting) small teams, where the supervisor also has a role in completing the task (approvals, sending to client for review, or even copyediting). Thus, the problem would persist.
Lucy, I started off with the method which you mention - On a typical task we were ending up with the equivalent of 3 pages of information. The issue we had is that people would have difficulty referencing the information that was relevant to their portion of the work. We also found that the people who had a specific responsibility actually didn't require about 90% of the information related to the project that was being entered. This also could have been partly related to several people being so used to managing everything through email, that changing to a different system was confusing.
I've now taken a path where all the information required is in the sub-tasks to make life easier for the recipients of the tasks, but as I am usually tracking the project it tends to fragment the information, and sometimes makes it hard to decide where to put information, and typically leads to requiring at least some details in more than one place.
Right now I can't see any perfect method, but I don't see myself going away from sub-tasks as I also use them to set timelines and track specific project stages ( Review -> Quote -> Design -> Release -> Manufacture -> Assemble -> Inspect -> Ship -> Install ). Each sub-task is linked together through timeline dependencies which helps schedule each stage to support the final delivery requirements :)
Very beneficial to see how everyone else is breaking up their work!
Personally still wondering why there is not direct connection between a subtasks start/end date and the main Tasks start/end date.... logically if subtasks are a breakdown of the main task, then they wouldn't start before the main task does, and wouldn't end after it - and if any of the subtasks dates were outside the range, than the main task would adjust to reflect this. Wondering why Wrike thought differently but it's making administration of the project plans a nightmare!
Hi Leona, thank you for the question! Subtasks are designed to have independent dates and durations because the same ones are often added to different parent tasks, or can even be standalone tasks in a separate Folder or Project. To keep information in order, and because everyone uses subtasks in different ways, users have the ability to adjust the dates in each location (tasks and subtasks) independently.
And that is one of the many reasons we are actively looking for an alternative for Wrike.
If you've ever managed a large project, you know you don't have time to adjust every task date because one of the subtask dates changes - fundamental flaw in the Wrike product logic.
Hi Leona, I'm sorry this isn't working for you. I just spoke with your Account Manager and she is happy to get on a call to talk about your use case and how we can help make Wrike work for your team. She'll be sending you an email soon to setup a time to talk.
At first we encountered issues with subtasks, but we use them vary effectively now. As project managers in our organization and based on our volume, we like to manage the stages (parent tasks): planning, SEO, copy, design,m production and web publishing. Under these parent tasks we have subtasks and tag them to the parent task so when the task lands in the assignees MY WORK it's connected to the parent job.
Very effective for us.
Patricia, that's a great way to use subtasks, thank you for sharing! Do you include general information about what to do in the subtasks within the parent job, or in each individual subtask?
Hi all: Our Parent tasks are: lanning, SEO, copy, design,m production and web publishing.
Our subtasks under copy (CW is copywriter) would be: 1 CW | Create draft: Job name or #, 2 CLIENT | Review draft: Job name or #...that way the task description is always connected to the parent task/job.
@ Anastasia: You responded to Leona on October 05, 2016 09:30 with regards to you saying having sub-task timelines linked to the task timeline is not a value add due to the different ways that people use sub-tasks. This is a feature that would greatly assist our efforts. As you have suggested earlier, we have been using sub-tasks to provide granularity and independent tasking of bigger topics that are grouped, but not being able to link the time lines is a big limiting factor. It would be great if there was an option to have them link or not. This way people who want an independent "to-do" list can, and those of us who would like the parent task to reflect the timelines of the sub-task are able to. Thanks!
Hi Stephen, thank you for the input! I've passed this feedback to our developers because I can definitely see the value in being able to toggle this setting. Thanks for sharing your thoughts on this!
@Anastasia - would also like to get sub-task timelines linked to the task time line.
Part of what we do, is working directly with our clients in our Design, Build & Validate phase. And while each of the task and subtasks are the same; they vary in complexity & duration. So we clone a project, rename it and then go in an update subtasks. Its very time consuming to re-order and re-align all the sub tasks & parent tasks once duration and complexity has been taken into account. So would be great if you can make this work, by being able to toggle this setting!
Many thanks
Hi Julian, thanks for commenting here! We now have some suggestions regarding subtask dates in our Product Feedback section, and it would be great so see your comment about this there. Our Product Team is already working on changing the logic of subtasks, and they're closely monitoring this feedback:
Happy to hear your ideas about this functionality!
will do!