What way do you recommend identifying what goals are connected to each task ?

Scenario:

  • There is a Kanban-style workboard (think "To Do" and "Doing" columns, etc). The team uses this to get shared understanding of what's currently in-progress, or about to be, to gauge team capacity and coordinate with one another async.
  • Tasks on this workboard all have to have a connected goal (e.g. "Objective for Q3"). In this case, I mean lower-case "goal," not the Asana feature. The general idea is that the team wants to know if in-progress work is relevant (or conversely, if a new goal needs to be created from emergent work).
Question: What way do you recommend identifying what goals are connected to each task?

Here's what I've tried (and the challenges I've had):

  • A custom field (e.g. titled "Goal") that allows for quickly tagging a task
    • This is convenient, as it's easy to do and see. It even shows up on the workboard view cards! And it is filterable on list views. An option exists for multiple tags.
    • The problem is that it seems best used for things that never go away.
      • For example, a category of work could be "Requests". This is specific enough to be different from something else (e.g. "Planned"), but broad enough that it will always exist (there will always be requests and planned work). When using this feature for goals, however, the options eventually become irrelevant. For example, "Objective for Q3" is old news by Q4 (and/or when it's completed). This leads to either a cluttered list of mostly-irrelevant options, or requires deleting old options and thus destroying goal completion data (as far as I can tell).
  • Subtasking larger, goal tasks (or conversely, giving parents to emergent tasks)
    • This relies on using a Section that has goals as items in that section (e.g. a "Goals" column/Section). It's useful because you can just click a goal card and it will show you all that needs to be done to resolve the goal.
    • The problem I've encountered with this is that if something is a subtask of another task, it is fused to that task. It can't be a subtask of something else, as well, and it can't exist in another section. It's more like a simple checklist a la Trello.
      • For example, let's say I have Sections called "Goals" and "To Do" and "Doing". I have a card in "Goals" that represents a bunch of work (e.g. "Objective for Q3"). Each subtask on that card represents a distinct piece of work, and I want to do them one at a time, and represent that by putting a subtask into "Doing". As far as I can tell, this isn't possible without bringing in the entire task that lives in "Goals" and also all the subtasks. If I did that, it would remove the "Goal" Section moniker, and also force me to work on all the subtasks at once (or else drag this giant thing back and forth, as needed).
  • Separate projects per goal
    • This tries to get around the problem with temporary custom fields. If each goal is a project unto itself, it is inherently resolvable, and it's clear what work remains on a goal as the tasks disappear from the project. Empty project? The goal is either met, or needs more tasks. Asana makes this possible by allowing tasks to exist on multiple projects (same as Phabricator), using a drop down similar to a custom field. Cards with other projects show up with a little colored line on tasks (on the board view).
    • The problem I've encountered is that the UI is much more subtle (compared to custom fields) for this.
      • It requires using a color-coded legend to determine what workstream a task is in. More specifically, tasks on the board view have colored lines on them, and the left-menu in Asana shows all your projects with a colored square. Match the colors on the lines and squares and you can determine the connection. It's not user-friendly the way a Custom Field is.
      • Additionally, the List view doesn't show other projects that tasks belong to (this may be addable, but I can't find how).
      • On top of all that, this approach requires either A) each project to have "To Do" and "Doing" etc (which is a baaaaad practice, because it creates multiple sources of truth), or B) all tasks to be cross-added with another project. The latter is feasible (and how many teams use Phabricator), but best implemented with automatic controls, and Asana seems good at adding projects to tasks automatically, but not removing (e.g. when a task is deprioritized from the Kanban).
    • TL;DR, this approach technically works but requires a ton of micromanagement.

Anything else I should try? Things I'm curious about:

  • Asana has a Goals feature! I'm not really sure of the point of it, though, as I can't connect tasks to it, just projects, which doesn't seem to help my Kanban-driven scenario. This feature sort of seems ingrained in "Asana is for orgwide tracking more than just team tracking." As far as I can tell, this feature is really separate from tasks and requires manual interaction for its purposes. It's more like an OKR-tracking thing unrelated to tasks.
  • Triggers: I'm intrigued by automation, but ideally automation that is set-it-and-forget-it, not something that needs to be implemented with each new workstream.
  • Milestones: As far as I can tell, this is just a task type that stands out, but doesn't actually do anything.

Your wisdom is appreciated. :bowing_man:

(I think this is related to https://forum.asana.com/t/goals-in-projects/89103/6)

(I edited your post name :+1: new users can’t indeed edit their own posts :person_shrugging: )

1 Like

Hello @Max_Binder how are you?
Regarding the 2nd topic about subtasks, I think you can do something to make it work for you.

You can have the subtask working as a task by associating it to a project (which can be the same project you are working). When you do that, the subtask is “duplicated” as an individual task so you can manage it individually (moving if through the sections of your project) so it will not impact the its parent task. Doing that, the subtask will be displayed in the Project Calendar and Timeline, as well.

It will be displayed like that:

To associate a project to a subtask you can follow the instructions on this link.

Let me know if it helped you.

Thanks, @Arthur_Campanha ! That is clever. I did try that as a test, and this is what I found:

  • It is more explicit, at least compared to the project color codes. This is true both if the subtask belongs to the same project, or a different “Goals” project. I personally even prefer the latter because it means I can have a Goals project that is one color, and then quickly identify any task that does not have a goal (because it won’t have that color).
  • This approach does show on the list view, unlike the each-goal-is-a-project approach. It’s still not as pretty as a tag, but it’s there:

  • Unfortunately, it’s still not as intuitive as adding a tag. The option is hidden in an overflow menu (I had to read the documentation you provided to find it). It’s also not intuitive to add a project to a subtask when technically that subtask is already in the same project. I can imagine my users getting a headache just thinking about it.
  • The alternative, as I touched on, is to have a separate “Goals” project, and make tasks on other projects subtasks of a “Goals” task. This is sort of like tagging, and it’s useful to have a part of the UI you can visit and see what all the goals are, and what tasks connect to which. The main reason I predict that this won’t be used by anyone who isn’t into bookkeeping (or doesn’t start with goals and then subtask from there): if you have a task that is not yet subtasked into a “Goal” task, when you convert it to a subtask Asana removes the other projects it belongs to. You can add those back, but it’s tedious. For example, say the teams I coach have a habit of putting tasks directly onto their daily workboard (let’s call that “Kanban Board”) they need a quick user interface for shoring up those tasks later. This is common: tasks emerge from work, and bookkeeping doesn’t have the same urgency as just getting something on the to-do/doing list. If I come along and say, “hey, what goal is associated with this task” and the the only way to connect the goal to the task is to convert to a subtask, the subsequent hoops they’ll have to jump through will be too discouraging to actually do the bookkeeping. It’s a great example of a “technically correct” process that nobody (that I know, at least) will actually engage with. :-/