Having worked with 100+ client organizations from large enterprises to individual entrepreneurs, I’ve designed or redesigned a lot of team workflows/processes in Asana.
I enjoy finding common patterns/abstractions and want to share one such pattern in this tip that you may be able to apply to your team-based Asana usage. While I’m not guaranteeing applicability everywhere, the work of Marketing teams, Communications, and Helpdesks may all benefit from this single pattern.
Using a Marketing team as our example workflow, consider viewing your work from three perspectives in the pattern presented below:
Marketing Requests project
- A single project to house all your team’s current/recent requests as tasks
- The place to define your request form, perhaps one or more task templates, all common custom fields for any requests, and a set of common rules (requires an Asana Business or Enterprise plan) as follows:
- Rules to multi-home parent tasks into one of the Request Type projects (see below)
- Rules to add subsections/subtasks to enumerate each request type’s workflow steps, homing corresponding workflow subtasks to their appropriate Workstream project’s “New” column (see below)
- For this project’s layout, consider this flexible design idea from another Forum Leader tip of mine
- You can age off tasks annually into yearly YYYY Marketing Requests archive projects to keep performance up and simplify searches and reporting
Workstream projects, one per sub-team
- One project corresponding to each subgroup handling one or more request types; even if it’s a subgroup of one, this is still recommended to avoid relying on someone’s My Tasks
- Example projects might be Web Workstream, Social Workstream, and Content Workstream; the Web Workstream subgroup might handle landing pages, minisites, and graphics request types
- These projects allow subgroups to see/triage/manage/juggle their individual workloads at their sub-team level
- A popular layout would be Board View with columns like New, Ready To Do, Doing, Blocked, and Done; note that because each subgroup has its own project, they can choose their own preferred layout/view
Optional Request Type projects, one per request type
- One project corresponding to each work request type
- Example projects could be Landing Pages, Minisites, Graphics, Blogs, Social, etc.
- These projects are helpful for reporting purposes; each can have unique Dashboards
- This set of projects is considered optional because the Workstream projects may be enough for some environments; these provide an extra, more fine-grained means of codifying your work
Clients have deployed this basic framework in many different environments with success. It requires some finesse to design and implement fully, which I usually do jointly with clients unless they already have staff strong in Asana workflow design to carry out the steps.
If you were to consider your workflow designs at this level of abstraction, do you use a similar pattern? It would be interesting to discuss that in the comments (rather than very specific workflow design requests better handled in interactive work sessions).
Thanks for reading,