The best way to build Asana Structure for big company+Best High-level View Decision in 2020

Hello!
I am new with Asana and our company is deciding whether to choose Asana or no for the whole company. I’ve read a lot of information here on Forum and in Guides, but still need help.

We are 500+ people company with complex department structure.
We need to have all in 1 Workspace.
Very important to have great high-level view and analytics for our CEO.
This is our company structure:

So my questions are these:

  1. We have 7 big departments within the company.
    I guess it should be Teams.
    Each Department has many smaller divisions.
    For example, Product Department=Product, Business Analyses, and Tech Support divisions.
    Each division has smaller projects.

I’ve read that it is possible to use Teams, based on any common: gathered with Clients, gathered with Projects etc.

But we need based on company structure and CEO requirements create such Teams.

How should we create projects?
If we create too many projects, it would be overloaded I guess.

Can you please recommend what is the optimal Asana structure for our company? We need to have all in 1 Workspace.

  1. I tried to use also Sections in order to separate projects and not to create too many Projects.
    in this case, Kanban view does not have statuses TO DO, IN PROGRESS, CLOSED.
    My question is: is there any way to differ Sections from Statuses to have Section View in List View and Status Board in Kanban View?

  2. The very critical thing for us is High-Level View and Opportunity for CEO to see the most important high-level tasks from top managers but sometimes to have an opportunity to dive deeper into separate tasks at the low level.

How can we realize this for our Company?
I’ve read about reports based on custom fields, but it is not the best option to truly say.

Can Asana Portfolios be an option?
Are there any other best decisions for the CEO to have a high-level view, control, analytics, and reporting?
On this level of TOP managers:

Thank you very much,
Olga

1 Like

I can’t remember where I got this screenshot, however, it is a good starting place for team structure.

I use teams within our company from a CEO viewpoint to keep similar projects grouped together. It would be your preference to keep all of the Product Department projects in one team, or make separate teams for each division. I assume the same people within each division would be working on the same projects. You could name them: Product - Product, Product - Business Analyses and Product - Tech Support to keep them alphabetically grouped in your master Team list. When it comes to viewing the projects in the Kanban view, you can customize the column headings in the Board view, however, I do think those become the Section headers in the list view. You could use a customized field to track statuses with a drop-down choice of: Todo, in progress, closed, etc. Then a sort in your list view would display current status. I would recommend another custom field for Priority, choosing High, Medium, Low. Then you can sort the priority column by those and bring the high priority to the top.

9 Likes

@Olga_Reznichenko, I think you might find this book chapter I wrote (in Secrets of successful teams in Asana) helpful:

Larry

1 Like

Brenda, thank you very much!

Larry, thanks!

1 Like

You are welcome

Hi @Olga_Reznichenko my team and I are currently offering one hour free consulting on how to use Asana. We’re showing best cases based on 8+ years of Asana experience and we can challenge your current setup. Feel free to book a free spot and we’re happy to help. 1. http://stg.onl/bridgeflow-1stunde-erstberatung

Hi Bernd, I booked tomorrow 11.00
Thanks

1 Like

Hi there! Sorry that I am late to the party. Not sure if you have found your ideal structure, but wanted to give my 2 cents, as I am super passionate about these questions. Feel free to reach out if you have any questions.

Do’s:

  • Think first about your CEOs favorite report. What’s important about it? Who updates who and on what? Make sure that your PROJECTS line up with what he/she wants to see daily/weekly. If reporting is important, this will be the most crucial step. There is no reporting at the Team Level and the Portfolio view can be designed any way that you want. Teams have no impact and only Projects matter.
  • Focus next on ensuring that every task (including Milestones & sub-tasks) have an assignee, are based on an end date, and have a task name that represents the completion of a goal at hand. Your Team, Project, Milestone, Task setup means so little if this is done correctly. This will let you use Advanced Search, Collaborator views, and timelines easily.
  • Focus your Teams on what the work is and how it will be completed, rather than a reporting structure. Theoretically, it makes sense to have a team called Marketing and one called Business Analysis. When you are saving files on a shared drive, this does make sense. However, where do you store the tasks around a new automation service to your phone system? Does it go in IT, Markeing, etc.? I’d rather name a TEAM after an Enterprise Goal like “Eliminate Manual Processes.” Then, when you begin work on the automation, the project can be made up of milestones and tasks that represent all of the SMEs, POCs. Executives from all areas that will contribute. Dont worry about how to report on this. You can use your Portfolio to show the progress on the automation and an advanced search to illustrate the work of everyone inside of Marketing only.
  • There are two types of Asana users. The first, I like to call, “Let me pull Up MY TASKS and show you.” The other is called, “Uhhh…let me think…where did I put that.” Focus on who is doing what, when they plan to be completely done. Then, consider when it will start, what company goal does it build on, and what specific actions need to be done for success. If you get commitment from your company to do this and do it, your grand structure in the tool will not matter.

Don’ts:

  • Never build your Teams & Projects based on an org structure. This will teach people to create tasks without assignment or accountability, eliminate consistency by teaching people to nest inside of their own space, choose to not add important items due to forgetting where to put it, and using the tool only to update the team after work is done. These are the reasons that people give up on Asana, determine that it takes too much time, and go back to living out of the Outlook Inbox.
  • Never name your Teams/Projects/Tasks like you would a file, a folder, or the subject line of an email. In the example above, you could name a task “Demo new system to all executives.” Never name it “Demo.” Demo is a file folder that I would dump something in or search for something. Asana is about action, transparency, and updates. Your worst enemy in Asana, and the person that will make you hate life, is the person in the meeting that pulls up Asana and state, “hmmmm…let me see. What does that mean? Oh, this one is about phones. I don’t remember what I needed to do on it though. Let’s move on. Maybe I’ll remember what that is and then be able to tell you all of the things that I should use the tool for, but dont.”
7 Likes

This is amazingly concise on what to focus on: Base your structure on the work being done and not on organizational chart

Hi Heath,
that’s great!!!
Sorry for the late response.

Thank you for sharing your knowledge and experience.
Actually, I loved your logic very much!!!

Do you have any advices om providing the reports on different levels?
I discovered such ways:
-Creating Master board for each Team (for Team Heads, project managers)
-Creating Master board for the whole company (for top managers)
-Creating Company Board with KPI (for top managers)
-Using Advances Search and Reports (for all)
-Asana Integrations for reports (I loved that here we can buy plans for 10 TOP managers who will use these reports, but will not pay for whole 500 members in our company)
-Of course Portfolio. But here I calculated for our company Portfolio will cost about 100 000 dollars/year.

What is your opinion about this?
Have you tried any integrations?

Glad that you liked the logic. I can tell that your mind is working in an awesome way to solve this. Here are my thoughts to your questions. I apologize in advance if I have mis-read your context:

Levels for Reporting:

  1. Generated centrally (from you for everyone’s use):
  • Report titled "Team X or Leader Y (all tasks assigned to direct reports or skip level reports to your chosen level.)
  • One dashboard for CEO can be used at lower levels. CEO is added to all Teams and can see all Teams, Projects, Milestones, etc. Lower levels can use the same dashboard, but be restricted only to the items that they have access.
  1. User Created
  • Have leaders add themselves to milestones, tasks as collaborator. Then, they can create advanced search for items in all/specific projects, exclude certain projects, show on milestones, show only tasks, show only items due this week, etc.
  • Create a Tag system using Agile Team Names, categories, names of reports, etc. and tag all items that should show up. Then, advanced search can find all items tagged, exclude tags, etc.
  • (EXPERT LEVEL TIP: USE ONLY IF YOU FULLY GRASP CONCEPT) - Allow individuals to use multi-homing. Remember, a task does not truly have a single home. The same exact task can be homed in multiple projects. So, a marketing leader could add all relevant tasks to a private project called “Timeline.” Then, he or she can see any level of task as a primary task for purposes of Gantt /Board View using sections that only he/she/team can view, create a timeline view specific to that set of tasks, and even add it to another dashboard as its own project.

There are definitely other ways of reporting that are possible, but this is all I can think about right now. Here’s an exercise that you can lead with any size of group.

  1. Have them draw out the perfect dashboard on paper/dry erase board without using the name of a tool, without graphics, and without calculations.
  2. Once they have completed, help them remove any barriers or restrictions that they have built with limited knowledge based on what current tools can do (Ex. Sends me the spreadsheet every afternoon, fit it all on one page for screenshot to put in PPT, tedious text updates that are manual no matter what.)
  3. Use the examples to create better task names, need for more/better custom fields, cadences, etc.
  4. Commit to an accountability to the tool that is engaging and fun. Here are my favorites: Team pays $1 for every text message/email sent for items that should use Asana conversations, Give a bowling pin dummy award to the team that emails the most spreadsheets, PPT decks, etc. In meetings, skip the person that speaks on an item from the top of their head when it conflicts with the elements in Asana, prepare and enforce a group chant when someone says “I haven’t put this in Asana, but we need to…” (everyone screams “If its not in Asana, it doesnt matter” or “Sticks and Stones will break my bones, but injects will never phase me.”

Have fun!

1 Like

Thank you! Glad we are on the same page!

This chapter was very useful, particularly as I contemplate the Team Structure/Architecture for our complex, matrixed organization with International Offices. Thanks for sharing :+1:t6:

Thanks, @Kemoy_Liburd-Chow, I’m glad it was helpful.

And I’m happy to report there’s an even more in-depth presentation of this information now available in the Asana Academy, an hour-long workshop, including extensive Q&A, based on that chapter in part:

Larry

1 Like

That’s awesome. Thanks for the reference, which I will explore.

1 Like