It’s not enough to know a collaborative technology inside and out when teaching someone how to use it. The key is context. A really useful recent posting here by Steven Tedjamulia gives some solid instruction on how to take user requirements and map out a collaboration architecture. But what happens if the key stakeholders don’t know what they don’t know?

I’ll tell you. It gets messy, but you can avoid the mess and help the process enormously by demonstrating the collaboration environment to the prospective users. If you’ve gotten to the architecture point, you already have an idea of at least one environment that would probably fit the company’s scheme. What you’ll need to do is have a demo available to show the people who will be using the environment and a way to show them how other organizations are using it as well.

With each new client, I am always asked "How does so-and-so use this platform to do such-and-such?" And, again, I explain with a short demonstration without exposing so-and-so’s proprietary data to the new client. It is usually sufficient to start the client’s wheels turning.

It’s important to note that before I walk in the door, I really should have done my homework about the client’s work so that the context for their use of the collaborative environment is crystal clear and easily demonstrated.

What I’m really after is the "Aha!" moment where people who don’t normally communicate and collaborate in a highly efficient and collegial way become converts. OK, I usually settle for buy in, but watching the light bulbs go on is pretty inspiring.

Either way, my goal is to try to prevent a disastrous rollout of a platform that people might be unwilling to use based on a number of factors.

To that end, I’d like to address one complaint in particular. First, my caveat is that each person is unique and has his or her own approach to technology. That said, I’ve sat with users who have complained loudly that one platform or another was too difficult to learn or not intuitive to them. These are often the same users who talk through the entire instruction time and/or tend to have difficulty with most applications (the latter is more often true than the former).

The expression "To each his own," comes to mind at these times. I’ve experienced my share of collaborative tools and platforms, and some of them work for me while others are thorns in my side. For that reason, I have a lot of sympathy for the person who has genuinely been trying to learn the platform on his or her own and is simply frustrated because it doesn’t mesh with they way they think about things or process information.

But, it’s my job to help people learn how to use something that might not like, but will need to use to achieve their organization’s goals. In that case, I get a little personal. I do something similar to what Steven suggests – I interview the user and ask him or her precisely what they do at work. Who do they serve, and so on. The better I can contextualize the work within the platform, the closer I’ll get to seeing that person’s light bulb go on.

It often takes more time than I’d like, but it’s worth the up-front time investment to prevent the high cost of re-engineering a whole set-up down the line.