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.
Today Socialtext launched Socialtext People and Socialtext Dashboard, significant enhancements that make people a first class object in the wiki platform and give them greater control over their internal and external information. We also launched Four Solution areas that I've mentioned before, that turn features that demo well into strategic implementations, but they need greater explanation.
Recent Comments