Best practices for task naming - start with a problem, how to link to the solution?

[Eddie_Dawydiuk]

I’m trying to do a better job at making action clear by starting all task names with a verb. A bit of background first, since we don’t have project portfolios and we need to see all open projects for a team(so we can prioritize), we use tasks for projects(things that have a deliverable / end date)…

My dilemma is often a new project starts off with a problem, something not working. Once we figure out what is causing the problem we then come up with a plan of action. To me, ideally we have one task that shows the problem, the investigation, the proposed solution, and the actions to implement that solution so we can look in one place, but logistically I’m wondering how others do this, or maybe you don’t. Any advise?

Original task - Figure out why have so many accidents at the corner of 32nd st and Rose Garden

This leads to a solution something like…

New task - Work with local officials to get approval for a stop sign to prevent accidents

Should I start with a more generic task(no verbs), so I can have a subtask to solve the problem, or …?

e.g. Accidents at the corner of 32nd and Rose Garden

As that way I can have a subtask talking about solving the problem, and another about proposed solutions, implementation, etc

[Bastien_Siebman]

My main advice would be to try avoiding subtasks all together, and also don’t hesitate to have tasks that aren’t actions but rather information, like having a section at the topic to store documentation, problem analysis etc. You could use in the task name to make it obvious this is an info task and not an action.

Does that help?

[lpb]

@Eddie_Dawydiuk,

Interesting and critical work!

I don’t think there’s enough info about the amount, context, and rest of your work to understand at what level you should be starting these: single task, pair of tasks, something higher level.

I disagree with @Bastien_Siebman’s “try avoiding subtasks all together” recommendation. Although subtasks can cause problems if not used properly, this is too strong a caveat and is throwing the baby out with the bathwater.

Both issues above are addressed in my free eBook chapter in Bastien’s book:

Architectural Balance in Asana (Ebook Free Chapter)

“Should I make this a Project or a Team?” This question, and others like it, comes up often when starting something new in Asana, for both novices and experts alike. And it’s really just the tip of the iceberg. How can you envision the structural, big-picture view of what you want to accomplish and translate that into an architectural framework in Asana that will enable your workflows, processes and information repository needs durably and flexibly, now and as they scale? Asana often provide…

I think you’d benefit by taking a look, because it will help you wrestle with the pros and cons of different solutions and allow you to arrive at the best decision for your use case because you know the details much better than we do.

Hope that helps,

Larry

[Bastien_Siebman]

The subtasks topic is really the more complex one =)

[Eddie_Dawydiuk]

This got me thinking quite a bit.

If you don’t have project portfolios, then to my knowledge you don’t have a single view to see all of your projects so you can prioritize them(I picture a kanban board of what projects are WIP, what’s next, what’s blocked, what in the backlog). So lacking project portfolios to me means you have to use tasks in place of projects, and given this you have to use subtasks to define all of the work for the project(which is stored as a task given we don’t have project portfolios).

So where I’m stumped is how you could use Asana with out project portfolios and not use subtasks. Can you help me to understand what I’m missing, or is the assumption when you say don’t use subtasks(as a rule of thumb) that you have project porfolios?

Maybe I’m misunderstanding something or there is an awesome feature I don’t know about…

[lpb]

@Eddie_Dawydiuk,

Yes, you need a task to represent each project to enable you to do a number of interesting things with multi-project reporting, but that doesn’t mean you need to relegate all other work to subtasks; that decision should be made on its own merits. Simply use an extra task to represent the project as a whole.

See also:

OKR Tracking in Asana

I spent time a few months ago designing a quite powerful and very flexible solution for my clients to handle either OKRs or Goals/KPIs (and initiatives generally), that is quick to implement and maintain weekly or monthly, and works company-wide with roll-ups at the company- and department-levels. An optional third tier, sub-department-level, is optionally available too. Unlike both Goals and Portfolios, which both require the Business tier, this solution only requires Premium, and still includ…

Larry

[tsmccallum]

Hi Eddie!
I’ve found that my tasks sometimes change names as they evolve. What was “Determine Structural Design Criteria of Aft Winch Staple” turns into “Revise Final Staple Model” by the time I am going to complete the task, with a living process of how I got from the start to the end in the comments and subtasks. For me, Asana has been flexible enough to let me follow the “thing” through it’s lifecycle. I do the same thing with Tags, projects, etc. - sometimes the scope changes, and the name should change too.
Some may disagree, but I don’t think that it’s super important to name the task right to begin with; make sure you and your team know what it is, but don’t expect that it needs to be perfect.

[Bastien_Siebman]

@tsmccallum

I’ve found that my tasks sometimes change names as they evolve

I agree 100% with that approach and do that all the time!