I strongly agree with the need for better options/controls for organizing projects in Asana. Not much more needs to be said on that argument, but here are a few thoughts on the primary “workaround” — Create additional teams for project “scopes” — suggested a few times throughout this thread and its shortcomings based on our experience.
Our Digital Team (department) has experimented with this approach — partly because simply mirroring our org’s departments in Asana feels too generalized, and doesn’t accurately represent the cross-dept nature of their workflows that are the best fits for Asana in the first place. Here’s what we’re trying…
Our Digital Department’s Asana “teams”:
Digital Team - departmental equivalent, private to members, houses private 1:1 & team goal/planning projects.
Digital Team Projects - for projects owned/managed by Digital Team members, but Asana “team members” herein include common contributors/stakeholders of our department’s initiative, to ensure they have project-level visibility by default.
Email Projects - similar purpose to the above, just specifically for email marketing-related projects (because we have a TON!). Again the regular contributors & stakeholders from other departments are team “members” to have default access to underlying projects.
Email Backlogs - created for use by specific team members to manage a narrow scope of projects that follow a specific project management structure/workflow (GTD, product backlogs).
|Keeps the project list manageable
||Not all users navigate Asana equally, search bar vs. sidebar,
plus Asana auto-hides anything beyond the top 5 projects/team
|Provides “natural” organization
||Requires more buy-in & adoption (learning curve for outside contributors)
|Aids permission management
||Actually complicates it further (member “groups” would be the real solution here!)
|Emulates “folder” logic
||Requires additional naming conventions/adoption
All that having been said, could this approach work for some orgs better than ours — absolutely. But I think it presents enough additional challenges (both in ease of adoption and limitations of other aspects of the app) that would be naturally avoided through the ability to tag and group projects together — whether that's visually represented through folders or not. Those are such common features of nearly all other apps and UIs that the learning curve would be null.
One thing I love about Asana is its openness in terms of the freedom orgs have to structure projects to match their own workflows and styles. But this is also probably its biggest weakness. Without enough rigidity in the tool’s structure, it doesn’t help teams adopt better conventions naturally. Too much freedom and the lack of (in this case) the standard “tools” we’ve come to expect in a project management app can hinder teams from expanding their adoption and optimizing their practices. Ultimately, that hurts Asana’s viability as a solution.