🤔 Should I insist on all requests being a #asana task?

English Forum Tips and Tricks Forum Leaders tips
1

I was asked the following question during a recent session with an client: « As an employee using Asana, when I receive a request from another employee, should I insist on it being a task, even though the request will end up generate several tasks or even a project? ».

An example would be « Bob can you organize the Christmas party? » said in Slack, which can’t decently be a task, but rather a complex project with many involved parties (pun intended).

My advice was that “over the counter” requests, water-cooler suggestions and half-baked email demands should always be a task. Even if that task ends up being turned into other tasks and projects.

The good practice in that case is to create the resulting work, and inform the requesting person, by using a comment with mentions to the new tasks and projects. And complete the original request as a result, leaving the requesting person the freedom of following the new tasks or projects if they decide to.

PS: wow I just re-read myself and that explanation seems complicated, isn’t it?

Do you agree?

:fr: Version Française

6 Likes
2

I whole-heartedly agree with you, Bastien.

We set the standard early on that all requests should be documented in Asana regardless of size or scope. This practice has helped us to decrease lost or missed tasks measurably.

To keep it simple, we start with the basics, add the item to the backlog (unless it’s an emergency - do now task), fill in the details as a team and discuss at our next sprint planning session. At a minimum, we ask the requesting team member to enter the following.

  1. Task Name - be clear and concise

  2. Description - the more information, the better; rough notes and point form are encouraged. We’ll review and refine as a team! If the requestor can capture as much information as possible, it helps reduce the risk that details will be lost or forgotten between the time the task was created and discussed by the team.

  3. Assignee - Assign the task to the person who will be Accountable for the task, and add all other team members as collaborators, providing awareness that the requestor created the task. If the person requesting the task is unsure who will be assigned the Accountable role for the task, we set the task to our PM, who will give the task to the correct person.

  4. Custom Fields - As appropriate - based on your unique circumstances.

4 Likes
3

I agree that forcing all requested tasks to be created and tracked in Asana is a best practice we should all be doing! I remember being on a webinar early on in my Asana training and the instructor mentioning that if she receives a request via Slack from another member of the Asana team that the common response is something along the lines of “Sure, I would be happy to take care of that. Can you please assign it to me as a task in Asana and add it to XXXX Project?”. She said that this is one of their Asana Use Conventions and I think it’s a fantastic use convention to have in place. Having this as a standard practice across the organization can help ensure tasks are not getting lost between email, instant messaging, Asana, in-person meetings, or other forms of communications and that Asana then becomes the single-source of truth when trying to figure out what works needs to be done and what work everyone is working on currently. I haven’t yet rolled this out as a standard for my organization but I am planning on doing it soon! I’ll make sure to update here on how the roll-out went.

Cheers,
Matt

2 Likes
4

At work among developers we use Jira, and we have a strict rule: “No Jira, no work”. If it isn’t in Jira, you are not allowed to do it!

3 Likes