We’re a content marketing agency with a team of 6. Our co-founders are the head of copy and head of design, we have a finance/ops guy, a data team of 2, and me, the PM. They’re looking to expand in all directions and I’m tasked in restructuring their Asana hierarchy to better fit their growing needs.
This is how I’m thinking to break it down:
Teams = Internal (for now: Org. wide, Operations, Data, Copy, Design, PMO)
Portfolios = Collection of Projects - 1 portfolio per client
Projects = Client projects and internal projects
Here is where i need help deciding - should each deliverable be a separate project or should a project hold a collection of deliverables outlined in a proposal.
For example: We sign a client and agree to deliver 8 blog posts and a virtual interview with transcript. I make a client portfolio and fill it with deliverables/tasks/deadlines/project resources/add involved stakeholders etc.
Is there a clear winner between these choices at these point:
Choice 1: Each deliverable is a separate project (9 projects for 8 posts and 1 interview )
Choice 2: Deliverables are grouped by type (1 project for 8 posts and 1 project for interview)
Choice 3: 1 project per proposal (1 project for all 9 deliverables that were outlined in the proposal)
Another question:
-Would teams be a better spot to create a client “portal” rather than my current plan to use portfolios as a collection of client projects with a designated “About” or “Welcome” project in each portfolio to home resources, comms, etc shared between us and clients? Or should i keep teams for internal teams?
Things to consider:
-Team is intending on growing internal teams
-Team would like to be able to assign tasks to freelancers hidden to the view of the client
-Team really needs a comprehensive view of projects/tasks per department and workloads for resourcing
2 Likes
Hi @Kelso_Bahia , welcome to the forum 
As you’ve probably gathered, when it comes to Asana, there is no right or wrong and there’s always more than one way of structuring your work!
Without a deep dive into your ‘ins and outs’ via a live engagement, it would be risky for myself or any other Solutions Partner to advise on which of your choices to go with. However , I am inclined to your 3rd choice, since each project would reflect a contract/appointment which you could track and report on as a whole in a Portfolio, and use its Timeline view to show you how all projects are running in parallel, along with those high level milestones.
Regarding Portfolios, note that you will be limited to 100 portfolios on Advanced tier (unlimited on Enterprise, and for the time being on Business). So it may not be a viable/scalable option to have a portfolio for each client.
So instead of clicking in and out of fairly ‘empty’ portfolios, it might be better to have ALL projects in one portfolio and use a single-select field to set the ‘Client’ value to each project so that you can then sort/group by that.
Or you could opt to split these into a few portfolios; one per client type, location, owner, etc but for a team of 6 I would keep them in one. That would also provide you with one single Workload view to see everything your entire team is working on.
Yes, you could create a team for each client (Teams are unlimited in any tier) and store each client-related project in its own dedicated client team, along with a project for meetings or a contact list for that client’s contacts, or any other info as you mention.
Hope this helps! 
3 Likes
Thank you! SO many possibilities.
I appreciate your response! With all that in mind this is now what I’m thinking:
Teams = internal AND external (teams as client “portals” that hold collab details, project info, resources, comms, etc.)
Portfolios = 1 sortable portfolio for workload views + others as needed
Projects = internal and 1 project per client proposal housed in the appropriate team
The org is currently only using projects.
Teams are unused
Portfolios are unused
1 project per client used as a client “portal”
Tasks = deliverables
Subtasks = steps to complete deliverables
1 project used to house all client deliverables for tracking
Using only a project per client created too many subtasks and made comments, dependencies, tracking, and workload views hard to manage. This is mostly what I’m avoiding with the restructuring.
I’m hoping that by using teams, I will be expanding capabilities for managing clients while limiting the amount of possible asana roadblocks we could encounter (at least in a way that’s better than keeping clients at project/task level)
Does anyone know of roadblocks with using teams for client portals?
2 Likes
Glad to help, @Kelso_Bahia .
The only draw back I can think of with using a Team per clinet is that , currently, they cannot be ‘archived’. So, let’s say a client is no longer a client or goes dormant; in order to remove a Team from one’s sidebar, you need to remove yourself (or other members) from the Team.
Note, if a Team’s privacy is set to private, then at least one member (or Asana admin) should always stay as a member , in order to add other members back in again in the future. Otherwise if Teams are set to public, then any member (not Guests) can search for a public Team and rejoin it (to add that Team to their sidebar).
2 Likes
I think it’s best to proceed with your own image.
Regarding this question, “Does anyone know of roadblocks with using teams for client portals?”, the problem may be that you can’t manage your team’s projects.
See here. Management functions for projects within a team (list, sort, filter, etc.)