Too many tools

Jan 13 2012 by Wayne Turmel Print This Article

There is no shortage of ways for communicating with your project team or virtual employees. So why don't people use those tools? The answer may surprise you. Many people complain, not about a lack of technology, but too much of it.

How can we have too much of a good thing? This is something managers need to understand if they are to help their teams come to agreement on what tools they should use to communicate and how to use them most effectively.

When teaching our How to Create and Manage Remote Teams programs, the question we get most often is "we have all this stuff, but I can't get people to use it!". One major reason is that the options can overwhelm your folks.

In the book "Dynamic Collaboration: How to Share Information, Solve Problems and Increase Productivity Without Compromising Security" (whew!) authors Ray Schwemmer and Rick Havrilla offer one solution: "The idea used to be, 'Build it and they will come', but it's more like 'If you integrate it, they'll use it".

One problem, of course, is that most teams don't take a strategic approach to technology. Someone comes up with a problem, someone offers a solution and you make it work (often by ducking the folks in IT who would probably put the kibash on your plans). So you wind up using Yammer for instant messaging, Basecamp.com to manage your files and version control, Sharepoint for whatever the company makes you save, and who knows what else. Before you know it there are five log ins, five passwords, and five learning curves to go through just to ask the folks in Dallas where the Johnson file is.

There are a couple of things to consider that will help people adopt the tools more easily:

First, engage them early, so that the technology is their choice instead of something that is foisted upon them. (Okay, maybe now that horse has left the barn, but keep it in mind for next time, okay?)

One of the first things you should learn with any of these stand-alone applications is how to set notifications. Most of them are designed to work with Outlook and/or Gmail. People are more likely to utilize tools that notify them when a new file has been added or a question asked than if they have to log in just in case something's changed. People might not want to log into Sharepoint, but if all they have to do is click a link and they're there, it will happen more often.

Take the time to really model and use these tools yourself. People take their cues from their manager or project leader. I'm amazed how many people send out dictates about using certain tools, then avoid using them at every opportunity.

Finally, if you have a choice between something free and something that might cost a bit but will integrate with existing tools, consider biting the bullet and spending the money. Free tools are great for providing proof of concept, or solving a short-term communication problem. Many of these tools, though, are stand alone products that might not integrate with other common tools.

Also (and here's another dirty little secret of the software business) these companies are built to be sold at the first opportunity to larger companies. You don't want to hang your team's progress on a tool that might not be around ( or no longer free) when you really need it. Also free software tends to limit the number of users, so it is hard to scale as your team or needs grow.

Research by several groups, not just Schwemmer and Havrila, shows that the problem with getting people to use technology at work isn't always a lack of tools - it's having too many to choose from and not mastering any of them. How's your team doing on that score?

  Categories:
more articles

About The Author

Wayne Turmel
Wayne Turmel

Wayne Turmel is a speaker, writer and co-founder of The Remote Leadership Institute. He's passionate about helping people present, sell and lead people and projects using today's virtual communication technology. His books include The Long-Distance Team - Designing Your Team for Everyone's Success. Wayne is based in Chicago, IL.