“Should I make this a Project or a Team?” This question, and others like it, comes up often when starting something new in Asana, for both novices and experts alike. And it’s really just the tip of the iceberg.
How can you envision the structural, big-picture view of what you want to accomplish and translate that into an architectural framework in Asana that will enable your workflows, processes and information repository needs durably and flexibly, now and as they scale?
Asana often provides more than one way to accomplish something. This is good: we can do more with Asana as a result. But there’s a downside too: How can we avoid less-desirable solutions, and especially ones that even may lead to dead ends?
This chapter helps you decide how to set up your work in Asana.
. . .
That’s the start of my chapter contribution to Secrets of Successful Teams in Asana, an ebook by @Bastien_Siebman along with experts @Julien_RENAUD @paulminors @Bry_ProjectKickstart @Paul_Grobler and @Tiana_Vallan.
long-winded substantial chapter is yours free (all rights reserved) here:
Learn more about the full volume here:
I hope the chapter is helpful and I’d love to hear what you think of it; either reply here to this post or over in the Medium comment thread.