The past couple of weeks I have organized and have been monitoring a very small pilot of Yammer in our organization. For those who may not be familiar, Yammer is positioned as 'Twitter for the enterprise', a service that allows people to provide short text updates, ask questions, and provide information to their colleagues in (nearly) real-time. Unlike Twitter where updates are typically visible to anyone on the service, Yammer networks are restricted to members of individual organizations, by means of valid
;)
possession of a valid e-mail address from the company domain.
I managed to get several team members to register at the site, join the dedicated, private group that I created to keep most of their updates 'private' and internal to the group, and also walked everyone through the steps to download and install the Yammer desktop client.
So far, the adoption has been decent, and I think there is at least a 50-50 chance that Yammer will eventually become a reasonably important part of the every day communication process in the team. But there are already a few key lessons that I have drawn from this brief experiment, lessons that I think would be broadly applicable to most other new 'collaboration' technologies (wikis, internal networks, or idea markets) that you may try and introduce into the organization.
Lesson 1 - Tools won't create collaboration immediately
Most of the work that is done by the team members has typically been done individually. The practice and culture of primarily individual effort doesn't miraculously change or morph just because a flashy new 'collaboration' tool is available. Analysis of the traffic on the Yammer network reveals a modest amount of communication on actual 'work products' primarily centered around simple 'status' type questions and answers. The tool has not immediately impacted the group to foster or encourage more collaborative problem-solving, development, or design. That may come in time, but the tool itself won't make that change happen overnight.
Lesson 2 - The right people need to be included
One reason the collaboration levels inside this group are relatively low, is that much more interaction and collaboration actually occurs with folks outside the group, the customers for this team's development. Inclusion of some of the key customer contacts in the pilot would likely lead to increased traffic and added value on the Yammer network. In time it is anticipated that the 'wider' network will begin to communicate and collaborate more freely. So when organizing a pilot program, don't be afraid to cast a wider net in soliciting and including participants.
Lesson 3 - Simplicity is more important that almost everything else
Even with a dirt-simple tool like Yammer, I have had to spend quite a bit of time explaining how the tool works, how to get signed up, and how to download and configure the client application. There were several moments of confusion and mis-steps along the way, while none of them are that complex, they still introduce unneeded friction into the process. Any participants that are perhaps unwilling or disinterested in the pilot, or are slightly technology averse, may very well be completely turned off by these issues. Whatever tools you plan to introduce to the organization, make sure you keep them as simple as possible, at least initially, if not forever. Find the one or two key features you need, find a tool that supports them exceedingly well, and put everything else on the back burner. Simplicity is essential.
Lesson 4 - But not as important as executive support
This experiment may be successful, or it may not. But I am 100% sure that if the 'right' senior executive found out about it, and was not comfortable or supportive, the project would quickly end. Once your collaboration project moves beyond just a few users 'playing around' and starts to gain some traction in the enterprise, you have got to secure senior level support. This is so important. To have an executive sponsor that can break down barriers, protect your project from the budget ax (maybe), and serve as a champion in those meetings that you don't get invited to may be the determining factor in your success. The most crushing and disappointing outcome sometimes is the hammer coming down from on high ending your project due to the lack of the right executive support.
Lesson 5 - You won't know unless you try
In my example, we are experimenting with Yammer, a free online tool. The only cost is the internal staff time spent testing, explaining, and documenting the registration process. The 'barriers' to this type of project are therefore extremely low. So consequently, it is an easy tool to try out. Not all technologies in the collaboration space are completely free, but most are relatively inexpensive compared to most other enterprise software. Wikis, internal social networks, and hosted blogs can all be tested and experimented with at modest costs. Many technologies have 30-day free trials that give you just enough time to get the feel of the technology. You really can't just discuss these technologies to determine if they truly will be effective and important to your organization and deliver on the promise of increased collaboration and communication. You really have to give them a 'real' test. Fortunately, most of these tools are offered in the SaaS mode, do not require an upfront license fee, and allow you to walk away from the project with no penalties at almost any time. But you may need to secure at least some funding to truly give these tools a try.
So far our project is progressing, and I anticipate over time, if we can keep in mind and learn our lessons, it will be successful.
I would love to hear what some other technologists have to say about the key lessons in introducing collaboration tools to the organization.