Using subfolders vs. subtasks

I find pro's and cons with both, and I often feel conflicted about which to use.

Subtasks:

In the List view, it's easier to view the project in its entirety.  All tasks/subtasks appear, and can be easily navigated.  No need to "view subfolders".

Subfolders:

Sucks in the List View, since you have to keep switching between "view/hide subfolders".  But in the timeline, subfolders appear easily, and can be navigated.  But I don't LIVE in the timeline view... I'm only in that view to set up the project.  I spend most time in the List View doing day-to-day work.

Hi Sam! Great question. This is how we think about it internally:

• Subfolders/Subprojects are used to break up Project stages or organize Projects and teams. These aren't the actionable items, but are perfect for categorizing them. For example, I can create a "Projects" Folder, which would include Subfolders for "External Projects" and "Internal Projects". One of those Folders would include "Project A", consisting of Subprojects for the different phases, such as "Planning", "Execution", etc. Circling back to the Folder Structure discussion, here's another one I wanted to share, which illustrates the scenario I described just now:

• Subtasks are action items and can be used to divide the same parent task between different assignees (if their contributions can be completed individually, but are part of the same goal), or to segment a broader task. For example, the task "Post on social media" can include subtasks for the different social media channels. In the second case, it's possible to make all of those subtasks standalone tasks instead. This is something I recommend if your goal is to have a cleaner view in the List, with all items visible. 

Each use case is different and depends on the type of work that's being completed, and I'd love to hear about how other teams approach this!

For many of the projects we run, I have found making subtasks off 'milestones' works exceptionally well. Milestones are made for each of the business relevant deliverables, in business language (such as external development complete, testing signed off, GoLive etc) and the subtasks (which can be hidden) are then built leading up to the delivery of this milestone. 

From a visual perspective, this works really well in the Gant chart view when showing only milestones and the collapsed subtasks. From a team perspective, the language of working on tasks contributing to a milestone also assists in maintaining focus on what is important. 

Hope this helps!

I really like this idea and might try this out.

We have been going back and forth for ages on this but I find that folders are really hard for people to visualize items within.  So we always go back to the subtask route.  however, the date issue makes a train wreck of our workload view.  The idea of milestones sounds amazing actually!

Based on the idea of the milestones I got this response from one of my users:

Answered my own question and made a test project. I actually really do not like this change. Everyone’s dashboards were super clean and organized with it being a 2 or so week long parent task, and the subtasks were nested within it. This way, they are all individual and I think it will be overwhelming to look at and confusing. This was the same problem we had originally and why we designed the template the way we did

Any thoughts on how to respond to that?  i think the workload view is worth more than the nesting in my opinion

Hi Ivan! We deal with change management all the time, so really happy you shared this experience. There are a few different things to keep in mind:

• Was this the best change? Ultimately you want the tool to add value. If the change does help add value to the majority of the team - that's fantastic, keep things the way they are. If the change has taken away value from the majority of the team, it would be great to reconsider the change.
• Think about messaging. People like to keep doing what they're doing, and change is sometimes hard. Explaining the value and reasoning behind the change can go a long way. In this case, explaining that the change occurred because of the Workload View benefits and that it works better for more people now, or will help you do something more powerful than before.

P.S. From a very personal perspective, I just worked on a new roll out here and I really appreciate this type of feedback/questions. It tells me that people are really invested in what we're trying to do and making a real effort to try and make things work for them. The people who I got some pushback from initially really became advocates when they realized I was willing to consider their opinions and suggestions (even if I couldn't always make the changes they wanted). 

Daniel - that's a helpful and simple idea I'll have to try out.

Ivan - Not 100% sure I understand your person's disagreement, but I THINK they are saying that their dashboards previously showed the parent task with its subs neatly rolled-up, and now show a long messy list of subs?  If you kept the milestone assigned to the same people as the 2-week parent it's replacing, wouldn't it appear the same in their dashboards?  Perhaps with a minor tweak to the widget's filter?  It's hard to say since dashboards are so customized...

I once participated in a call with some of Wrike's development team.  I recall a long-term idea being mentioned of unifying the folder list and list-view, so that folders & subfolders all appear in that list.  I think I'd like that change. 

I know at least 1 of wrike's competitors do it that way, but I haven't used that tool much myself.  So there may be unintended drawbacks I'm not seeing.

Sam,

Unfortunately as I understand the milestones do not roll up with the subtasks underneath.  Personally, I am not convinced that is a bad thing as with them rolling up you can miss due dates.  But we'll see.  

I would LOVE LOVE LOVE to see subfolder appear in parent lists.  We have a hard time with the subfolder vs subtask thing for whatever reason.,