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?