Hey guys! I wanted to share some thoughts I had.
First of all, these thoughts are the direct result of a lot of organizational changes we’ve had in the last year. I hope this can be a didactic story and provide helpful knowledge for you as you continue working in your own organization.
lLet me get right to the point:
Asana is not primarily a database. That might sound obvious. You probably even agree. After all, you use this software for projects not for storing mass amounts of data, right? …Well, maybe.
Let me explain.
As our organization began to pick up major growth two years ago, we were still quite small so we didn’t have a functioning database or data-management platform. So what did we do? We threw all the “meta-data” relating to our clients into custom fields and the like, all inside Asana. In other words, we kept information like “Marketing Director”, “Client POC”, “Contract Start Date”, full lists of each client’s services, and the scope of each of those services, ALL in Asana. And believe me, much more information than just that.
In other words, we kept referential information that was important to our ongoing knowledge of each of our clients, all in Asana. Chances are, you’ve kept organizational or other datasets in Asana as well. The question is, where in Asana? In tasks. Do you see the irony? It is easy for some of us (as it certainly was for our organization) to hold referential, ongoing information that needs to be seen by multiple teams, in tasks. Well, what is a task? A task is by nature something that is actionable, something that is meant to be completed.
So we found ourselves often confused about our clients scope. Someone would walk up to me and ask “Which clients does x Marketing Director have?” or, “What’s the status of x client’s Google Ads campaign? Is it active?” or, “What’s x client’s Facebook Ads budget?”
Since all this data lived in Asana, we could find an answer–but the problem is that (1) it was growing increasingly difficult to find those objective answers since there were literally over 100,000 tasks tied to our domain, and (2) holding objective information in tasks creates the potential for data redundancy. What is recorded in one task may be recorded in another task by a different user, thus creating two conflicting “stories.”
I sent a survey to the team to prove my initial observations/validate my concerns. It was starting to become a nightmare. Based on my survey results, high percentages of people weren’t aware of the contractual obligations for our clients during their onboarding phase. Some of our Marketing Directors didn’t even know how to quickly identify all the services we were running for a particular client.
As a side note, I don’t want to give off the vibe that our organization is horrible, dishonest, or anything. In fact, we are an extremely integrity-based organization, and we were always able to work through the issues above, but it always took time and we always suffered much confusion.
Once I saw this trend starting, and once I realized that Asana is meant for actionable things (hence everything existing in “Tasks”), I determined that our organization needed a database, or a CDM (customer data management software). Over some months, I created a no-code relational database of all our clients’ data, and much of our organization’s internal data, and created a no-code frontend for it. Long story short, that platform is used to this day, everyday, by almost everyone in our organization.
Of course, tasks can and should contain important information, but only, primarily, information needed to get that task done.
Whereas our CDM is our single source of truth, Asana is our work management platform, where we execute on things. Whereas our CDM is our referential tool, Asana is our actionable tool.
Problem solved.