WBS relationships

[Vadim_K]

I am evaluating Asana around WBS topics.

And I came across the post Two main features - Print timeline & add duration to task, still not even a basic feature after 6 years! - #8 by Tom_Huntford, in which @ Tom_Huntford shared his process of working with WBS.

In that post, he recommended

and establish the “sub” relationship using the Gantt and your WBS numbering

What additional controls the Gantt view provides to establish such logical sub ordinance between tasks?

I kind of getting manual task naming to follow WBS levels, but it will not be used for headings around a sibling tasks under the “parent” task (a heading).

So far, it looks like sections are the source of Gantt heading. Can we setup hierarchical sections in Asana?

Even if it does it will be kind of limiting since true WBS should allow tasks with children and tasks without be siblings:

01 Main task
0101 Level 2
010101 Task A
010102 Task B
0102 Task C
02 Next main task

Also, the structure has to be flexible and survive the project evolution: the Task C might be split later on, and Level 2 could become an atomic task with tasks A and B be moved under another parent or becoming direct children of the main task. and so on.

I hope I am explaining the issue clearly.

Thanks.

[Tom_Huntford]

@Vadim_K Hope I am addressing what you asked:

1. Asana has limited sub-relationships.

   a. It appears Asana is limited to 7 layers of nesting: Section-Task-Subtask, Sub-subtask, etc. Starting with the Section as 1.0, it will go to 1.1.1.1.1.1.1 and then no SubTask is offered.
   

   

   b. Asana will only explode 3 levels on the list view: Section, Task, Sub-Task
   

   

   c. Asana will only explode the 3 same levels on the Gantt View:
   

   

   d. Asana will only explode the 3 same levels on the Board View:
   

   e. Asana will only explode the 3 same levels on the Timeline view. And I could only get the sub-task to show by clicking the dropdown arrow on the graph’s bar, instead of the list at the left:
   

   

Personally, I do not like having to click tiny arrow to show sub-tasks. I want to see the whole project.

So, my approach and my suggestion is:

 1. Use only Sections and Tasks, no sub-tasks
 2. Establish parent/child relationship by WBS #'s (always by 10, so that changes to the project can easily be made, such as adding new sub-tasks, moving a task from one place to another, moving a task from one level to another
 3. Establish and maintain dependency based on work or capacity constraints in the Gantt view using Buffer Management.

Actually, #2 is not even needed. Because the bottom line is not a fancy WBS # scheme–the bottom line is what needs to get done, when, and by whom. Just use the Gantt to build the project:

 1.  Use the Gantt to build the project.  It is FAST!  
      a.  Just enter a Task name, hit Enter, and start typing the next task...AND!!...
      b.  The Gantt automatically puts sequenced time-bars in place, saving a LOT of work!!  
      c.  Turn Buffer Management to "Off" for the initial build.  
      d.  Sort by "None" instead of "Date": this will keep the Gantt in the order you enter Tasks.
      d.  Arrange the Tasks in time, with overlaps and delays as needed.  (Note: you can build the project in List if preferred, then go to the Gantt.  But if you do not have WBS #'s, then putting the project together in the Gantt avoids having to remember all the dependency relationships you had in mind...)
 2.  Link all the tasks using the drag-n-drop Dependency builder, or the more time-consuming "Blocked By" and "Blocking" in the Task itself.  You cannot set Delay or Overlap in Asana, except by  placement in the Gantt View.
 3.  Turn Buffer Management to On to lock the arrangement.
 4.  When a Task is going to be longer or shorter, drag it to be wider or narrower: all dependent Tasks will move  and the Dates will move with them.

I like making a custom Status with Red for Not Started, Green for In Process, yellow for Blocked, and Grey for Complete. Then I like to add a rule that when I change my custom Status to Complete, Asana’s standard Status is marked Complete. Then I color the Gantt by the Custom Status:

To re-arrange dependencies, turn work with Buffer Management options. Like, you can break one dependency, leave Buffer Management on, move one Task out and everything dependent on it moves, insert a Task, link up dependecies, and away you go.

Here, I’m just showing one task took way longer than planned. I had to use Consume Buffer in Buffer Management.

[Vadim_K]

Big thanks for you taking time and providing such detailed answer!

[Tom_Huntford]

[Vadim_K]

@Tom_Huntford

Because the bottom line is not a fancy WBS # scheme–the bottom line is what needs to get done, when, and by whom.

I understand this sentiment - especially in task management tools like Asana (which manage trackable human activities) and not project management tools (which manage deliverables - often regardless of details around individual activities).

If you take a deliverables management approach, the importance of parent tasks becomes apparent.

I - like you - prefer thinking of sections as phases. This fits well into a traditional level 1 of WBS - phase, initiative, major release etc. Each level of WBS is expected to be hierarchical (like Phase 1 - design, implementation, deployment; Phase 2 - design, implementation, deployment). But it can be represented in flat way without much of the loss (maybe that would be different projects within a portfolio or something like that).

The level 2 of WBS is subsystems (major breakdown of components). In simplest of projects this tier has 2 levels (order management - products list, product details, checkout; reporting - report 1, report 2 etc.), in more complex situations I easily had 2 more levels - admin portal / subsystem 1 / module 2; microservice X / cache manager / core components; etc.).

The last level of WBS is actual deliverable - report 1 UI, report 1 presentation, report 1 back-end, report 1 business logic, report 1 integration, followed by the milestone “report 1 complete”.

In traditional WBS actual tasks - human assignable activities - don’t even start until below level 3. Which is in most my cases I don’t need to go into. So I will keep it from going below level wbs 3 (but you already see, we are at least at the level 5 of top to bottom hierarchy).

One can ask - why being that fancy? Well, let’s remember the purpose of the project management - an ability to understand the status and answering questions [from clients, for example]. How can I answer the question about the % of completion of report 1 without having proper grouping of child tasks?

As far as sub-tasks go, I typically use sub-tasks for the purpose of “definition of done” - the simple checklist of things that must happen to complete a task (code is managed, reviews are complete, testing is complete, technical documentation is complete, database scripts are published to the master update folder for the release, user documentation changes are posted etc.).

Another purpose of subtasks would be to monitor % of completion of the task (by checking off sub-tasks with pre-assigned weights).

But neither of the described purposes would require to end up to the timeline / Gantt charts.

I understand, Asana is fundamentally task management platform to monitor assigned work. This is why I am using SmartSheet for PM purposes (good for PM, but terrible for task management). And I would hate paying for both tools.

This is why I am looking how much I can compromise on WBS to consolidate under Asana.

[Tom_Huntford]

@Vadim_K totally get it. All I am saying is that, given Asana’s architecture, my preference is to:

1. Make EVERYTHING below the Phase/Section level a Task. No Sub-tasks
2. Handle project structure through WBS #'s, spaced at 10 to begin with in order to allow insertion with minimal work, including the first level.

   10.00 Phase 1
   10.10 Prep
   10.10.10 Client Discovery
   10.10.10.10 Prep Discovery Sheet from Template
   10.10.10.20 Arrange Meeting online
   10.10.10.30 Discovery Meeting (Milestone)
   10.10.10.40 Discovery Write-up
   10.10.10.50 Deliver Discovery Write-up to Client (Milestone)
   10.20 Planning
   10.20.10 Develop plan based on Discovery
   10.20.10.20 Flowchart
   10.20.10.30 Translate flowchart into Asana project sketch
   Etc.

3. Use Asana’s Gantt to establish and maintain timing
4. Use Asana’s custom fields and rules to track % complete to budget etc.

I just don’t like the way sub-tasks are hidden in Asana. So, given the way it’s built and the way I process information (which is I need to see it, I don’t have a strong memory like some folks), this is the best I can come up with at this time for using Asana as a PM tool.