So you just started the trial for a new collaboration tool. It has all the promise of transforming how work gets done by your team. It has a snazzy UI built on Backbone.js, the site proudly claims, and the on-boarding flow made your heart skip a beat. Tech bloggers have been going bonkers for the last few weeks about how this tool is the future of work. You see that too, after having spent a sum total of 5 minutes with the tool.
So in your initial excitement, you invite your team-mates on to it, and quite a few of them quickly come on board. You create tasks with names like “This is a test task”, post comments like “woohoo – comments work!”, and tinker around for sometime, very happy about your discovery.
Your team actually starts using it, very diligent initially with all the filing, commenting and tagging. But within a few days, something happens. Everyone seems to be getting lazier with the filing, commenting and tagging. And in a week, it all stops, with everyone going back to what they were using earlier – Email!
Everyone has seen this play out at work – in exactly this, or similar manners – innumerable times. Why is it so hard for teams to adopt new tools, even with the promise of increased efficiency. The answer to this question would also definitely contain the key to building better tools, and building them to solve real, not perceived problems.
Here’s an attempt at answering this question.
1. Its only managers who need the tool
This is the most likely case for most project management tools. Its managers who need to be on top of what needs to be done, by whom, and by when. For everyone else in the team, it is an ‘overhead’ and a distraction to go into the tool to update, tag and report stuff.
Work isn’t done in a project management tool. Work gets done in IDEs, design tools, Excel sheets, Powerpoint and Word files. It is only reported and tracked in a project management tool. To tell non-managers that they’d be more efficient by using a project management tool is preposterous. Its only managers whose efficiency they help.
2. Email is “good enough”
And that exactly is the reason why people keep going back to it. Beyond the initial euphoria of discovery, a tool that is promising people to get out of email must be infinitely better than email. It must present a very strong case against email. That might not be true in many cases.
If all a project management tool gives the team is a better UI to do what they were already doing with email, then the team would quickly see through it. Even when there are some improvements offered by the tool like better task management, people might find the comfort and ubiquity of email too big a reason to not learn and switch to a new tool.
3. The tool needs everyone to be on it
Project management tools do not tolerate slackers. Unless everyone in the team adopts it, it might not work out very well. For instance, if one person in the team continues to send files as email attachments instead of adding them to the files area in the collaboration tool, everyone would now have to refer back to their emails.
Getting everyone on-board can be very challenging even for small teams with very few people. And for large teams, on-boarding usually is a task that goes on for months, and very often fails.
4. Too much workflow/structure
It is for the workflow or structure that one wants to move to a collaboration tool. But then, the level of workflow you’re imposing on your team with a new tool can be extremely daunting and distracting. For instance, creating and managing a task in your collaboration tool for every small thing can be a pain for your team.
For many teams this usually leads to breaking the workflow – an example is people posting tasks on the message board, or as as messages to colleague through the collaboration tool. Once that starts, the promise of sanity and structure that the tool came with falls apart, and the abandonment of the tool is the usual next step.
So the next time you try out a new tool, think of the above. Your team will successfully adopt one only if they really need the structure, and are ready to make some sacrifices to adopt the tool.