Switching to Asana Project Management After 10 Years

Big projects don’t always provide a visual impact to our customers. Sometimes, behind the scenes efforts are critical – things like introducing new software into a company’s workflow to improve project management and productivity.

We took on one such project when we switched our team to Asana’s project management software. The project was led by our amazing integration engineer, Amy, who did the bulk of the research, all of the coding, led communications, and documented the process along the way. Today, we have a look at the steps Amy took to get a final decision and implement the right project management software for our entire team.

Switching to Asana Project Management After 10 Years

Deciding on the right tools to use for your business can be a long and involved process. Such an undertaking requires research, reviewing company goals, and LOTS of trial and error.

Remote workers, engineers, data analysts, marketing, and other team members create a workplace where incorporating project management tools is essential. Staying on top of projects, tasks, due dates, and getting the proper approval can be a nightmare. Or at the very least a headache, especially when something is missed and holds up getting product features or other deliverables released on schedule.

Recently, the ExaVault team switched over our project management software from Unfuddle Stack to Asana.

Why Did We Do This?

Photo by Ken Treloar on Unsplash

After many years of using Unfuddle Stack as our business task tracking system, we felt dissatisfied. The lack of a calendar-based view and an inflexible search made it challenging to organize team tasks and get a holistic view of any worker’s schedule. One of our engineers had over 300 tasks assigned to them as “current work.”

The Unfuddle Stack web interface felt old-fashioned and cumbersome to use, making some of us less inclined to keep entries up-to-date. Each month, managers devoted extra days, tracking folks down to ask whether a task was truly not completed or simply not updated in the project management system. We decided it was time to see what other small business project management tools were out there that would be better suited for our fully-remote team.

Options for Small Business Project Management

In our brainstorming sessions, a few key points came out to help us move forward on our journey to improved project management. Everyone agreed we needed a system that was more modern and usable for team members working from separate locations.

In addition, we wanted a system that would organize team tasks for all of our workflows, such as engineering, marketing, and customer support. There were several votes to find an online project planning tool that included some type of Gantt chart for more visual task management. Our marketing team was already familiar with and advocating fiercely for Asana Project Management.

To humor them and to ensure a knowledge-based decision, we investigated and tested several web-based small business project management options, including these top three contenders:

• Jira: A very flexible project management tool, but annoying to configure.
• Asana: Pretty sweet calendar views with a responsive web app.
• Plan.io: Planning our iterations within this application was too cumbersome.

And the Winner Is….

Long story short, those wacky marketers were right.

We chose Asana. As an application designed to help organize teams, Asana offered the highest number of key elements required to switch over:

• A clear and understandable calendar view. Provides an easy way to see who is doing what and when quickly.

• Search. A well-designed search function is invaluable for locating tasks to avoid duplicating customer support issues and bug tickets.
• A well-documented and supported API. Proper documentation gives us the ability to enforce our own specific workflows, including the Directly Responsible Individual (DRI) for each task.
• Tons of video training and community support forums to answer our questions.

• An application under active development, with helpful new work tracking and team management features added all the time.
• Integrations out the wazoo. Seriously.

We chose Asana not only because it would improve our workflow, but because it was the right choice to keep us accountable to ourselves and in turn to our clients. When we find an inconsistency with our product or on our website, anyone can create a task, attach detailed notes and screenshots, and assign it to the correct person or team. Overdue tasks are easy to spot, and through customization, we were able to end up with a project management tool that helps us reach our goals and stay on track no matter what part of a project each individual is working on.

Switching to Project Management With Asana

Now that we knew we wanted to use Asana, we needed to figure out how we should use Asana. The new project management tool had to fit into our workflow with minimal disruption to projects that were already underway. Many people don’t deal well with change. Several years working with the same web-based tools can make a switch to something more modern seem daunting. And we had a decade of inertia to overcome.

The first thing we did was check out Asana’s excellent video tutorials. We focused on learning the features of Asana and discovering any best practices we should incorporate into our Asana import project or team onboarding plan. This included best practices for how to use Asana for project management as well as getting the entire team on board with the new software. We also scoured the Asana community forums for ideas about how others use Asana for small business project management.

Our next step was to map our existing project structure from Unfuddle Stack to a new structure within Asana. We set up several example teams and projects within Asana, trying to determine the best organization for us. Then we set up a few more and argued about it in Google Doc comments. When we finally came to grips with our own meaning for Asana teams and projects, we could, at last, begin converting our existing task history from its original Unfuddle context.

Ten Years of Data

All of the design and development decisions, all of the feature requests, all of the reported bugs, and most of our arguments had been recorded in Unfuddle Stack since 2008. We needed to get over ten years of data from the old project planning app into the new project management system without losing the institutional history.

First step: download all our data from Unfuddle to a local holding area. Next, update any missing or invalid fields to make it compatible with Asana’s data structures, mostly because of the way Asana stores custom fields versus the way the data was stored in Unfuddle. Once the data was converted, we would use Asana’s API to migrate the database to Asana — creating our projects and tasks in their new shiny home.

To get the data from Unfuddle, we used their REST API to retrieve our information. Had I been willing to parse their XML, we could have exported a backup of the entire account’s data and processed that locally. Instead, we wrote our own code to download the data from Unfuddle using GuzzleHttp for the REST client. We created a laravel application that grabbed all of our data and stored it in a local MySQL database.

For those of you playing along at home, downloading the data from Unfuddle populated:

• unfuddle_projects: Analogous to departments or functional areas.
• unfuddle_milestones: A sort of sub-project representing the work for one project for one month.
• unfuddle_tickets: Each individual ticket, such as “Create Migration Script Unfuddle->Asana.”
• unfuddle_ticket_attachments: Every file that was uploaded and attached to a ticket. Lots of screenshots.
• unfuddle_comments: Every individual comment on a ticket.
• unfuddle_ticket_associations: How each ticket relates to any other ticket in Unfuddle. Tickets can be “related” or have a “parent/child” relationship, or they could be “duplicates.”
• unfuddle_messages: Think of these as sort of blog posts nobody reads after the first time they’re posted and shared with the team. We used a message for each month to document our planning process and priorities for each upcoming month.
• unfuddle_dri_fields: ExaVault uses the Directly Responsible Individual, or DRI to assign task owners. DRI isn’t a standard field in Unfuddle, so the data was returned as its own embedded object within each task, and this table converted that to a human-readable value.
• users: Individuals with permission to log into Unfuddle and/or who have tickets assigned to them.

Download, Convert, Upload

With the data downloaded to our database, the real fun started, if by “fun” you mean “data cleaning” (and I do.) I used the fun database tools at my command to locate and fix bad data and to create crosswalk tables. For example, our ticket priority field in Unfuddle might be “1” which meant “Low Priority,” but for Asana that worked out to *checks notes* a custom field with the GID “956269514781095” whose value’s GID was in turn “925358618599652”. Shout out to anyone who’s ever manipulated custom fields with the Asana API.

With all our new Asana-specific values calculated locally, we used Asana’s API to create our new projects and tasks. Fortunately, Asana provided a PHP SDK, which sped up matters considerably. Their API reference is first-rate and includes an explorer for testing out calls. Our Laravel application used the Asana PHP library to add the data into our shiny new Asana account.

Interesting Issues to Solve

Those three steps (download, convert, upload) sound pretty straightforward, but it took us quite a while. We tested our process several times on single projects to make sure there were no missing pieces. Along the way, we got to solve some interesting problems:

• Dealing with users existing in the system for former employees who had objects associated with them in Unfuddle, but who were no longer listed within Unfuddle.
• Swapping authentication so that tasks initially created by an employee in Unfuddle would seem to have been created by the same person in Asana.
• Converting Markdown -formatted ticket descriptions and comments to XML-formatted rich text task descriptions and stories. Thank you, Parsedown.
• Updating internal links within comments and descriptions so that a reference to “Ticket #227” in the Markdown became an anchor-link pointing at the appropriate task object within the Asana ticketing system.
• Re-trying failed operations without needing to restart the entire import process.

Initiating the Switchover to Asana

We pulled the trigger on our conversion during the last week of 2018. Aside from customer support, the company essentially shuts down the last week of the year, so that we can spend the holidays with our families and loved ones. During that week, we could foresee having little to no traffic on the Unfuddle account, making it the best possible time to grab the data. Exporting our data from Unfuddle so we could migrate the database to Asana took around four days to complete. Then, uploading the data took five more days to finish. When everyone who didn’t spend the week watching the import run returned to work, we were up and running on Asana.

Introducing New Software Into the Workflow

After getting Asana set up and loaded with all our projects and tasks from Unfuddle, we needed everyone able to log in and use the new project management tool. Fortunately, we had a plan for this new software onboarding. And some documentation for our staff. And a MOM.

ExaVault documents all of our processes and procedures in an internal wiki, so we created a user manual for how we use Asana and shared that documentation with all our staff. At the end of our daily standup meeting, we also had a demonstration and training session. Everyone got the chance to see Asana project management in action.

One key goal of using the Asana ticketing system was to enforce specific standards regarding how we manage projects. All of our projects use a Directly Responsible Individual (DRI), who is the “owner” of the project. That person is responsible for ensuring that everything is done in compliance with our best practices and that whatever project we’re working on is addressed thoroughly and correctly. We made use of Asana’s custom fields for this DRI assignment. But we also needed to make it easier to adhere to our practices.

So, we called mom for help. Rather, we created an application named the Morning Organizational Monitor, or MOM. MOM currently serves two crucial functions. It lets us know when we create tasks that are missing data, and it creates tasks to facilitate reviews. During our standup meetings, we review any notices from MOM as a group. We’ll be enhancing our automation even more as we continue refining our workflows.

Success

Photo by Nik MacMillan on Unsplash

After successfully using Asana for a while, we know we have made the right decision and chosen the best small business project management software for our company. Taking the time to research the product, examine our needs, and set up Asana how we wanted, paid big dividends for all of us — engineering and management and marketing alike.

Looking for business file sharing + secure FTP? Try ExaVault Today!