A diagnosis from the Asana Doctor 🩺

A metaphor to start us off

When you’re sick, you don’t go to the pharmacy and take one of everything; you go to the doctor for a diagnosis and treatment plan. Approaching change management (e.g., a software implementation) without thoughtful consideration of your pain points–the impetus for change–is akin to mixing all your pills together in one bottle and hoping for the best. Theoretically, there’s a slim chance that things will work out, but it’s far more likely that you’ll end up in the hospital (i.e., your processes will end up worse than they started).

Back to reality

What does this (overwrought) metaphor actually mean for teams planning to embark upon an Asana implementation or optimization? To effectively manage your change, you should begin with a structured assessment of your current state and why you want to alter it. Failing to do so makes every subsequent phase of the change harder and less effective. Without a clear understanding of your present challenges, how can you expect to build something better? Without articulable motivations, how can you expect to inspire your team to alter their way of working?

Identifying your “Why?” and “How?”

There are many approaches to this definitional phase. Some ideas to consider are:

  • Conduct an organization-wide survey (perhaps using an Asana form): ask people what is working well, what they wish they spent less time doing, and what one change would most improve their workday.

  • Select a representative from each functional team to participate in an ideas summit: ask each representative a standard set of questions and compare their answers to spotlight misalignment and opportunities for improvement.

  • Engage an external consultant: if you have more capital than time (or simply want a fresh, unbiased pair of eyes), consultants can be a valuable resource in documenting your status quo. They can shadow team members without drawing focus from day-to-day operations, bridge hierarchies that internal team members might not, and synthesize data from broad sources that might be less available to internal parties.

The output of this work is ideally a brief (1-2 sentence) mission statement of a format: We are {making a change} in order to {mitigate overarching pain points}. For example: Our organization is moving from Excel sheets and emails to Asana for our project management needs in order to simplify processes, centralize communication, and eliminate parallel efforts.

This statement should then inform all decisions in your change process, including what you build, how you build it, and how you socialize it with your team. In practice, that might mean:

  • Prioritizing simple, repeatable project templates over complex, automation-laden ones at launch (simplify)

  • Defining and enforcing best practices for when to use task comments, project messages, or external communication methods (centralize)

  • Identifying a desired tech stack and planning an integration strategy (eliminate)

Ideas in practice

With a mission statement in hand (along with the supporting information used to craft it), there are many ways to make the theoretical real. You may use Asana to ensure symmetry between plans and objectives, track progress on discrete implementation details, and maintain open communication with team members. In practice, this may mean:

  • Identify a small group of stakeholders who have expressed excitement about the change or whose influence is significant (ideally, both of these conditions are met!). This core team is responsible for the implementation, with a heavy focus on driving excitement and sustained usage across teams.

  • Create a project to categorize inefficiencies by the team that raised them, the priority, and the effort to mitigate. Distribute a form on this project for people to report additional inefficiencies (similar to bug reporting in software), which can be triaged in the future.

  • Build a roadmap, prioritizing high-effort/high-priority “tasks”, and publish it to all team members. Use the project’s messaging feature to regularly deliver updates to everyone and provide an open forum for feedback. This will foster a sense of ownership and inclusion that greatly enhances people’s appetite to change.

  • Use a project to visualize your tech stack, including dependencies, to understand how and where you should apply resources to be most effective. This may mean delivering bad news (e.g., we’re integrating Asana with Google Drive before tackling auto-assignment rules within Asana), but with data-backed logic (e.g.,more people need the Drive integration immediately).

  • Find heavily manual processes executed by many team members (e.g., emailing weekly status updates to project stakeholders) and determine ways to systematize them (e.g., use Asana’s new AI Smart Summary functionality).

Ultimately, when people understand what is changing, why, and how it impacts their day-to-day work, they’ll be more excited about the change, which serves to increase its longevity. These are just a few examples to get you started, but there are innumerable ways to approach this. As long as you’re being thoughtful and encouraging ongoing feedback, the sky’s the limit!

How have you approached the early stages of implementing Asana with your team? Is there anything you would do differently?


Great Forum Leader Tip, @Stephen_Li, on a crucially important topic!



Great tip :clap:t3::clap:t3: an effective deployment should always start with the why!


Great analogy @Stephen_Li!

The doctor who hands out medicine without understanding why the patient is asking for it is a poor one.

Yet it’s how a lot of us operate, and I sometimes catch myself doing it.


Excellent piece of work @Stephen_Li :clap:


Great Post! I love the reference (metaphor)

And I do agree this is a very important topic. When people know the WHY and how their task will contribute to the whole project they will not only be able to work more efficiently with a clear goal in sight but also be way more motivated.