Baseline has an at-length article on Social Software's Culture Clash. With some great input from Andrew McAfee, Tom Davenport, Euan Semple and Joe Scheuller from P&G -- it explores how deploying social software is challenging -- because its, uh, social. Creating solutions that engage people and reflect if not transform corporate culture isn't the core competency of most IT departments. Its a good read and chock full of anecdotes (“With these new tools,”
Davenport explains, “unless the right culture, behaviors and
organizational structures are in place, they’re not going to be
successful.”). Here's an excerpt with results from Socialtext customers:
The most successful social software implementations emerge when there is a clear demand, as was the case at MWW Group, a public relations agency based in East Rutherford, N.J. Client teams there were accustomed to collectively editing press releases and other collateral, but their primary mode of editing was in file attachments sent by e-mail, according to Tom Biro, vice president of digital media. Version control was problematic, as was size and number of e-mail attachments. In August 2006, MWW Group implemented wiki software from SocialText.
Currently, about half of MWW’s 250 employees use the browser-based tool to collaborate on client documents. Account managers notify team members via e-mail when a document is ready for review. The server-based application, which costs $11,000 per year for the lease and licenses, can also be configured to automatically alert team members when updates are posted. Coworkers can edit the text, and a history of all changes is readily available.
The wiki has reduced e-mail attachments by 25 percent and boosted productivity, although Biro can’t say by how much. It’s faster and easier to search than a server, he says, and when employees travel to any of the company’s 10 offices, they don’t have to start up a laptop, log into the network and open a software application to view a document. Instead, they can hop on a conference-room computer and log into the wiki.
But wikis aren’t just for internal collaboration. In late 2006, call-center software maker Angel.com created a wiki for customers and business partners to exchange information about products, including likes and dislikes. Angel.com also posted technical documentation, including troubleshooting tips to which customers contributed, according to Sam Aparicio, the firm’s chief technology officer.
The unanticipated result has been a reduction in formal technical support and a 10 percent jump in productivity for the McLean, Va., company. The boost, Aparicio estimates, is equivalent to an annual saving of $500,000, while the hosted wiki cost less than $10,000 during the same period.
These results stem from our model of being engaged with customer deployments and continually cultivating best practices and solution sets. Our VP of Professional Services, Michael Idinopolus, leads this effort. He recently launched his own blog, so I'll quote a post in full:
One of the most common, and thanks to Wikipedia most visible, uses of a wiki is creating a participatory knowledgebase--a shared knowledge resource that is created and maintained by a distributed community. I've built quite a few of these, first at McKinsey, and in my current role at Socialtext. Here are three top-of-mind high-level best practices based on pitfalls I've seen some companies start to fall into:
Structure by topic, not by organization. Every participatory knowledgebase I've ever worked on has started with participants assuming that the wiki's structure would mirror their own internal organizational structure. Bad idea. The whole point of the wiki is its ability to bring people together and connect dots across organizational silos. That won't happen if you structure the wiki around those very silos.
Lead with what you want, not what you have. Many groups, especially research groups, tend to use the wiki as a dumping ground for research they've already done. This research typically takes the form of reports which were written for a specific audience to answer a specific question at a specific moment in time. So the value of the reports themselves isn't so great. What is valuable, however, is the insights embedded in those reports. That's what contributors should be encouraged to post to the wiki. Put differently, a page called "Trends in Retail Channel Marketing" is a better wiki page than "2006 Analysis of our Company's Channel Marketing Spend". (Of course, the report might be useful as backup--so include it as a link from the main page on trends).
Link link link. New contributors don't cross-link. They're not usually averse to it; they just don't think to do it. Encourage them to "linkify" any term (yes, I mean any term) in their entries that is either proprietary vocabulary, potentially unclear to some readers, or describes a strategic concept where the company might have proprietary insights. These three criteria cover a pretty broad range of terms, and in even a short (e.g., 1-2 paragraph) entry, you can probably find at least a half-dozen terms that should be links...even if the underlying pages don't exist yet.