I work in K-12 also, on our district’s business team. We’re a small team with 2 analysts and a support person but we have stakeholders just about everywhere in IT, district office, schools, etc. We tend to keep communication in Asana to just our team, our manager(s) and a couple key stakeholders in IT and the business area. For communication outside our team we tend to rely on other services (email, Microsoft Teams, etc.).
I think the thing that helps us make it all work is establishing team norms. Recently, as a team, we stepped back and tried to get a handle on what was working, what wasn’t, and then agreed on the norms we want to use inside and beyond our team so everyone we work with would develop a sense of consistency from us and tried to align with the organization as a whole, but this is a bit of a moving target and something we hope to help influence as we’re a large and fast growing district.
So we set down our expectations in a Team Charter and this is the relevant section:
We strive to be focused and less interrupt driven. We use the following tools and strategies to help with that. Subsequent section will give more details on norms specific to a communication method.
ASANA – Used primarily for task and project management. Communications occurs through comments to tasks or conversations in a project. Comments should be specific to the task they are in and can serve multiple purposes. Tasks are described in the task’s Description. More information Asana Norms can be found in Teams.
MICROSOFT TEAMS – General team communications and quick notifications. Need feedback before end of day. Use for new topics, alerts, and emergency communications. Collaboration and coordination between team members on currently defined projects or tasks.
TEAMS CHANNELS – Project specific communications, collaboration/coordination with SMEs. Collaboration/coordination between team member on currently defined tasks
MEETINGS – The team has several meeting types and norms
EMAIL – Communications to people outside the team
FACE to FACE – Defined meetings, emergency situations, highly technical/complex or personal discussions
WHITEBOARD – Used to offline discussion topics that come up during stand-ups
SMS/Text messaging – Emergency communications outside of normal hours of operations
The Norms we made for Asana specifically are in a separate document and a bit more involved. The below is pasted from a Word document and I’ve tried to spruce it up for readability, but I’d say the most relevant section might be the Communicating in Asana section, but I’ve included it all as an example of what we tried to do. It’s also out of date, we plan to have quarterly/annual review processes of our norms to try and have retrospectives and make sure we’re either still on track or need to re-evaluate.
PURPOSE OF ASANA
Asana’s main purpose is for tracking our tasks and projects. The process for how we do this is always changing and mostly verbal. Some conventions are beginning to form for the various areas in Asana and as best we can they’re documented here.
This document focuses on the norms we should follow when communicating and creating tasks within Asana.
Asana is complex solution that’s always being updated. Specifics of how to use it will be considered mostly out of scope as it’s a fairly user friendly tool and has many guides and help resources.
PLANNING IN ASANA
Each day you should be looking through your assigned tasks and planning out what you think you’ll get through in your My Tasks which is broken up by Asana into “Today”, “Upcoming” and “Later”. This should be done prior to the Daily Standup meeting so you have good information to report on.
My Tasks - Today
Use this area for the things you plan to be working on and completing today. You can further split up you My Tasks for more clarity into subsections: Finish Today, Working on Today, Waiting/Blocked, and Uncategorized. These sections have to be made public or shared with your teammates for them to see them. The Uncategorized section at the bottom will catch anything new that you move to Today so you know it’s new.
Upcoming generally will be used for weekly/sprint planning and Later for things you don’t plan to get to within the week/sprint.
ASANA USE CASES
Here are some of the common ways in which Asana is used
Tasks are typically created for either tracking some day-to-day item that needs to get done, a helpdesk ticket, follow-up items that are someone else’s responsibility, or as a placeholder for a project in a project management board. All tasks should follow basic norms for tasks, see the Task Norms section.
Sometimes we want to remember to do something, but it’s not really related to a project or a support item.
Support Tasks (Board Project) – Landing project for all Helpdesk tickets. Also good for any task that could be related to helping a user. Follows a Kanban style of work.
Personal “follow-up” project – Use a personal project if it’s not a task that the team needs to be kept aprised of but you want to remember or track.
These tasks are created from an Outlook Rule (see BusinessPLUS OneNote – Asana Outlook Rules). These are assigned to David by default, but if someone else grabs them they should take ownership of the task.
Other things that should be done for tasks from Helpdesk tickets:
Change the task title
Replace the “A new ticket has been assigned” with the ticket summary
If it’s not a helpful ticket summary (e.g., Problem with B+, Help, etc.) make something better
Spend some time trying to create a story and a definition of done at the top of the description, if we can’t we need to probably get more info from the user
When creating a Task, use the following as a guide for filling in Asana’s fields
COMMUNICATING IN ASANA
Asana Comments are generally used for:
Posting updates and resolutions
Asking questions specific to the task (@mention the person you want the answer from)
Requesting approval or consensus for a decision or action (@mention and request thumbs up or more comments for discussion)
Asana Project Conversations are rarely used but:
Other Asana Uses/Norms
Tasks should generally be assigned to a person so they’re owned
Stories and Projects should only be assigned to a person when ready to be worked (e.g., taken out of “New-In”)
Meeting notes (see Meeting Notes section
We have other norms that the other analyst and I follow for our project management board and the various projects we work on. Given it’s just the two of us and we do well working out our norms and holding each other to them verbally, we haven’t taken the time to really document all of them yet. Some we track in our template tasks as we do our sprint planning. These are the norms we follow in that planning project as it relates to projects in Asana:
Project Management (Board Project) – Sprint planning board for analysts. Tasks are fed here from the various story planning projects. This is done by dual-homing the tasks in both their originating project and in this one.
Project specific projects (List Projects) – For each new project we create a list project where we develop epics and stories and continue to break them up until they’re small enough to go in the Project Management board’s backlog with story points.
If you have any questions or feedback, just let me know.