JournalJul 2014

Why the right PM tool for your team is the one that gets used

We spent a long time trying to find a tool which would allow our team to ditch emails and collaborate more fluidly on projects. The choice we made is one that surprises a lot of other people–but it’s paying off handsomely for us.

A lot of managers seem to be obsessed with pushing new tools and processes onto their teams in a drive to find that perfect ‘missing link’ that unlocks amazing team productivity. And when you’re working in a big company, in particular, it’s so common to find heavy, cumbersome tools which are designed to meet managerial needs, rather than those of the team using them. The people on those teams hate it–and rightly so.

Since I’m part of a distributed team, tools which allow us to communicate efficiently and get our jobs done are even more important. I must have trialled hundreds of apps in my search for a better way for us to collaborate and organise tasks.

But none of them seemed to be quite right.

As not just a team lead, but someone who is involved with development too, I loved the idea of a piece of software with the power of Atlassian’s JIRA. The way it can hook into the rest of their ‘suite’ of apps to deliver a powerful code-review and continuous integration workflow is fantastic.

And I still catch myself looking at Atlassian’s suite a bit wistfully. These tools are incredibly versatile, and are so, so powerful. On paper, it looks like their combined feature-set would meet almost all of our needs.

But in reality, that power comes at a significant cost–and it’s not a financial one. As UX designers, we are well aware of how important speed and responsiveness is to the user experience. This speed (and perhaps even more importantly, the perception of it) is what really frustrates users and kills adoption of new software. Despite its potential, we tried very hard over a period of several months to learn, adapt and adopt JIRA with a small group inside our team, and found that it was simply too painful for us to use regularly.

In the end, we were looking in the wrong place?

Not every task we needed to communicate fit cleanly into a ‘bug’ or ‘ticket’ format. That meant that while we could powerfully manage product features on an ongoing project with JIRA, it was far harder to try and organise day-to-day, smaller tasks, within it.

I saw JIRA as a solution to a whole series of problems, without immediately understanding the flaws in that solution. As great as that perfectly smooth JIRA workflow could have been, part of the problem is that not everyone on our team is a developer, nor are we working solely on heavy development projects. We have strategists and designers on the team, and since we were trying to fix a crucial part of the way we all collaborated–one of the building blocks of the way we work–we also needed a tool that was universally adopted.

What we needed was a tool which wouldn’t get in our way, and would allow us to be way more efficient, not less so. We needed a tool that was intuitive and delivered power for those who took the time to learn it, without that power creating a huge learning-curve for new users.

So we had to look elsewhere, and for us, the tool that fit the bill was Asana, rather than JIRA. It’s far more generic in comparison to the development-focused JIRA, and on paper, seems a weaker match for our needs–it forces us to use non-integrated tools for code-review, for example. But it is incredibly fast, and crucially it gets used by the team. There’s never a situation where it feels too ‘painful’ to add a small task into Asana–so we use it for personal and private to-do lists, as well as almost all asynchronous communication in our team.

On our team, if someone needs something done by someone else, they add it to Asana–we’ve managed to virtually eliminate that scenario where someone thinks: “oh man, this is a hassle to fire up the app and assign the task—I’ll just ping them on IM instead so they can add it themselves.”

Asana in practice

Let’s take an example–check out a video of me assigning a couple of different teaks, across different projects and to several team-members, in Asana (their keyboard shortcut integration is fantastic):

I’m still a massive fan of Atlassian–they seem to be a smart and well-intentioned company that’s looking to make lives better for devlopers. And the developer, and software optimist in me loves that. But JIRA simply wouldn’t work for us, even if we all wanted it to. It was crucial for me to let go of that magical solution.

So, what’s best for your own team?

If you follow the agile manifesto (or even, if you’re just using plain old common-sense) then you should be putting people ahead of processes and tools.

I’d strongly recommend Asana to a lot of other teams. But while speed of use was the biggest requirement for us, and was the reason the app got wide adoption within the team, it’s crucial to make sure that whatever tool you pick for your own team, is the right one to meet their needs. Asana is phenomenal, and hugely versatile, but even then, there’s no way that it’s going to be perfect for every situation.

So in choosing your own tools, don’t favour features over practicalities. The right tool for the job is the one which will get used.

Photo credit: florianric on Flickr

Posted by
Jon Lay

Jon is a Partner at Hanno. He wears many hats, but his primary focus is on leading our engineering and technical operations.