Directing a team, tasks and projects for district schools



We are a small team (four support, three faculty/tech roles) and supporting 1000 users in a K-12 school in NYC. I have been using Asana for awhile but don’t think I’m doing it “right”… I tend to respond to tasks via email, Zendesk, voicemail or just a stop in the hall. I would like to continue to see what is happening in Zendesk without getting stuck in the weeds, support my team and even though my team is often physically close by, their day changes at a moments notice when something arises and their tasks and tickets need responses.
How do we use Asana as a communication tool (as a remote team may use it) as well as encourage and support their needs? Experiences or feedback would be GREAT!



Hi @Scott_Adamson,

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.


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.



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.


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.

Day-to-day Tasks
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.

Helpdesk Tickets
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

  • A task name/title that’s a good overall description for the task

  • An assignee

    • Leaving a task unassigned is an easy way to have it disappear, if you’re not sure who to assign it to, start with yourself and then open discussion in the comments by adding followers
  • Due Date

    • Not required, but good to attempt to set them for yourself and so others have an idea of when you think you’ll have something done by

    • If there is a due date, do it

    • Also useful as a follow-up date so you can push something you know you’re not going to get to into the future and put it in the Later section of your My Tasks

  • Description

    • Try to list the task as a user story so we get a full sense of the reason for the task and who it’s really for

    • Try to have a Definition of Done or Acceptance Criteria to help everyone know when the task is considered done

  • Projects

    • Add a project to a task to have it viewable by the team

    • You can add a task to multiple projects

  • Tags

    • Consider of the task should be tagged. We don’t have many consistently used tags, but there are a couple we try to always use:

      • HelpDesk – Used for tagging any task that comes from HelpDesk

      • B+ Ticket – Used for tagging any task that’s been sent to PowerSchool support

    • Other tags exist, but are primarily used in projects


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:

  • Any project level discussions

  • Approval/Consensus gathering at the project level (@mention and thumbs)

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.


@Scott_Adamson Additionally to the great response from @RyanE here is a link within the Asana guide on how to get your team onboard.

Hope this helps.



Thanks for sharing this with us @RyanE, very interesting!


Holy cow @RyanE - this is epic.


:slight_smile: It didn’t feel that big as I wrote it given most of it was copy and paste. Once I hit post I was worried it was too much. I’m always interested in feedback though. I learn as I go.

The main reason I tend to write things down for my team is so we have something to point to and say, “We agreed to hold ourselves to this.” We share this with our stakeholders as well. Overall it’s helped to create a sense of pride in the way our work gets done and given us a bit of control over the chaos of constantly shifting priorities by being transparent about how we prioritize and do our work.


If you don’t mind, I’d like to share some of this with my team! We use Asana for most of our activity, but don’t really have identified guidelines like this. As we grow, this would make onboarding and refreshing much more streamlined.


By all means, and if you ever have questions, just let me know.