Directing a team, tasks and projects for district schools

English Forum Use Cases
, , ,
1

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!
Scott

Blockquote

2

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:

COMMUNICATION

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.

DOCUMENT SCOPE

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

DAILY PLANNING

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/Later
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

CREATING TASKS

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

TASK NORMS

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 collaborators

  • 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

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:

  • 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.

9 Likes
3

@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.

Jason.

4

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

5

Holy cow @RyanE - this is epic.

1 Like
6

: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.

3 Likes
7

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.

2 Likes
8

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

3 Likes
9

Hey @RyanE, your share was absolutely what I’m looking for.
Would you mind sharing how you’ve updated your Asana use over the past 9 months?

I’m a director of curriculum & operations and I’m looking for a way to get my team onto Asana but structure works best, so I’m trying to build my own set of guidelines and I’d like to know what pitfalls you’ve encountered that would be best for others to not have to learn the hard way (or at least things to watch out for)

Thanks in advance!

10

Hi @Sterling_Archer,

When we got started, recognizing that we were going to evolve with time, we devoted a lot of time up front discussing what we liked and didn’t like about how we were using Asana and tried to stay flexible. Also keep in mind that Asana might have better ways to do some of the things we do, but we’re on the free version.

Our use of Asana had solidified a lot by the time we wrote the norms that I posted here. The timing of this is funny as we have a meeting this Thursday to review our norms and update them. We’re supposed to have our suggestions ready by the time we meet, so now I’ve done the work to review this section of our norms.

One suggestion I’m going to make in that meeting, is that people be more deliberate when they’re creating tasks by filling out the task in a particular order. It’s pretty nitpicky, but I’d like people to wait to add collaborators or assign the task to a project (where many people are collaborators) until the task is done being written up. The reason for this is I rely on my Inbox to keep me informed. Most of us check our inbox throughout the day when we have breaks in our work. If the description for the task isn’t fully written up when added to the project, I can see it before it’s done and after a bit will realize that what I initially thought was a poorly worded task is a team member still composing their task while I watch. I have to then remember to check it later. It’s a minor issue, but easy to avoid.

As I read through the sections of my post, I do have a couple comments on things that have evolved.

In the Daily Planning section, the use of My Tasks for personal planning never really took off. I think I’m the only team member that finds much value in it. While it’d be nice to be able to go to a team member and see their plans, if they don’t find personal purpose in it, there’s little I can do. Although, I feel like I have reasonable evidence that people manage their work better if they spend time each day reviewing it. We plan our teamwork, so it seems weird to me that we wouldn’t then plan our personal work. When I fail to do this I often feel less prepared and run into more surprise last minute tasks, but my failings are my own and others’ mileage may vary.

In Task Norms, I talk about the Due Date. We almost never use it except on “reminder tasks” where we set up a task simply to remind us of another task. This is to work around not being able to control when Asana sends a reminder. For me personally, when I’m following my daily planning process, I find I rarely need things like this.

I also mention in the Task Norms section about adding a “Definition of Done” (which we abbreviate DD) to task descriptions. I wanted to call this out as it’s ended up being one of the best practices for us. It’s eliminated those lingering tasks that people sometimes create that never seem closable. It forces us to think about how we’ll know when we’re done up front. It’s also as much to help the task owner as anyone else. It’s not uncommon to see a comment along the lines of “I’m changing the DD to X” as the task owner learns more about a task they’re on, gets new information, or finds a better way. They’re not set in stone, but I’ve found if people don’t do them, some tasks will linger for extended periods and no one can decide when they’re done.

Finally, I plan on asking my team Thursday if they like a new norm I’ve been thinking about. I’d like us to be more deliberate about keeping the last comment on a thread some kind of “current state” comment. Sometimes we’ll post a bunch of research or information to a task and then you have to start scrolling around, clicking “X more comments” and “see more” and what not, to find out what the plans were (Vote if this bugs you too). I find that posting “Next Steps” is often very helpful, especially at the end of the day. It reminds me what my next steps are when I’m setting a task aside for other work and lets my team know what’s up as well in case they need to cover for me or answer questions.

Hope this helps and thanks for giving me the excuse to get some norm review done.

2 Likes