You've probably read here (and in other fine sources by much smarter people) that there are three common reasons virtual and remote teams fail to gel or achieve their project goals:.
First, the teams lack good information (this is not so often critical data, but context and implicit knowledge of where to find resources, who knows what and who to go to when you REALLY need that PO expedited).
Second, systems don't work (or people think they don't, which is the same thing). If you have really cool productivity and collaboration tools sitting unused, you're probably suffering this syndrome. And finally, priorities are out of alignment (your project withers on the vine while they do something for their "real" boss).
Today I want to take a deeper look at the notion that systems don't work or people don't make the best of them. Recently I've been speaking to a lot of PMI (Project Management Institute) groups about making their project teams work. One of the most common complaints I hear is "we bought xxxxx to help us communicate, but nobody uses it".
There are a number of reasons that tools get left unused or are abandoned. Work with your team to uncover why they think things don't work like they should:
1. People have never seen what it can actually do. Talk to any software vendor (make sure they're buying, you could be there a while) about their frustration with users, and you'll hear "they keep asking for ________, but it already does that. We just call it _____".
It's a sad fact that while some tools have a lot of features (usually more than any human needs) people use fewer than a quarter of them. That's because we usually get shown the basic functionality of the tool, then get directed to the manual or the online tutorials. This saves a lot of time, money and training, and is largely ineffective.
(Note to software vendors: the answer to a frustration with technology is NOT more technology!). Start with a small group of users and let them ask questions they actually want answers to. People retain what will solve their problems, not what you think they should know.
Telling ain't training. Getting the whole team together, making them sit passively through a webinar listing all the cool functions and then taking a month to get their accounts set up is no way to help people learn. Small groups of users, trained when they're expected to use something, coached by someone who actually knows what they're doing, then trumpeting successes as getting the next group up and running is the single best way to get a group to use something.
If it's a pain in the neck, they won't bother. Sometimes a perfectly good solution comes in the disguise of more work. People aren't thrilled with learning a new software package. If it requires a separate log-in, looks radically different from what they're already using, requires yet another password (that is not their dog's birthday) and isn't intuitive (defined by the user, not the engineer who built it) people will throw up all kinds of barriers.
If it's someone else's idea, forget it. Even the most highly functional, well-meaning project team rejects ideas that are imposed on them, even when they're perfectly good ideas. You've probably suffered the, "if home office likes it, we'll hate it" syndrome. Instead of mandating solutions, start with the problem and let the team suggest what they need. A surprising percentage of the time that solution already exists in some form.
So instead of saying "we have this great filesharing tool", ask them if they get frustrated always searching for the latest version of something, and not finding it in their email. Gosh, what can you do about that? "If only there was a way to find the latest version of things in one easy place". Hey, by a bizarre coincidence, we have a tool like that already.
Try to resist the urge to add, "and none of you have used the bloody thing". It isn't productive.
Once people adopt a system, work it like crazy. Coach people to it (make sure they go to the file site, don't just email them the document one more time). Hold people accountable, and share successes so that people see it working the way it should.
Oh, and if the system truly doesn't work? Fix it as a team. Most of the time the answer is there, it's just disguised as another one of your goofy management ideas.
