Interested in what I read about over this past weekend? No? Well... go ahead and stop reading then. Here's something entirely more entertaining.
Yes? Well, the Internet was a-buzzin' with articles, comments, and opinions on bringing "Web 2.0" concepts "inside the firewall" i.e. using them in the "Enterprise" with emphasis on how it all relates to Knowledge Management Tools/Systems.
A lot of it was in reaction to Associate Professor at Harvard Business School Andrew McAfee's article "Enterprise 2.0: The Dawn of Emergent Collaboration", which the author summarized:
There is a new wave of business communication tools including blogs, wikis and group messaging software — ... Enterprise 2.0 — that allow for more spontaneous, knowledge-based collaboration. These new tools... may well supplant other communication and knowledge management systems with their superior ability to capture tacit knowledge, best practices and relevant experiences from throughout [an enterprise] and make them readily available to more users.
No matter how technologically elegant their design, knowledge management "platforms" and "repositories" tend to quickly collapse under the weight of their own complexity. Using them turns out to be more trouble than it's worth - particularly for those employees who have the most valuable knowledge - and the platforms and repositories fall into disuse and are eventually, and quietly, dismantled. People go back to using efficient, direct conversations - through meetings, or phone calls, or emails, or instant messages - to exchange useful knowledge...
He then explains what makes Web 2.0 technologies different. "The good news," he writes, is that the new technologies "focus not on capturing knowledge itself, but rather on the practices and output of knowledge workers."
Andrew McAfee comments on Nicholas's comments in Does Web 2.0 guarantee Enterprise 2.0?:
If you believe that this migration [of enterprises using so-called "Web 2.0" tools] won’t take place, you believe essentially that companies—interdependent groups of people with a common mission and a profit motive — are less able or less likely to engage in free-form collaboration than the mass of previously indepedent volunteer freelancers that have made Wikipedia, Flickr, MySpace, YouTube, del.icio.us, Digg, etc. so powerful and successful.
Lots of knowledge workers spend lots of their time on two activities: keeping their colleagues appraised of what they’re doing, what progress has been made, what they’ve learned/concluded, etc. and trying to locate resources within their own organizations... Blogs (like the other Enterprise 2.0 tools) can help with the first of these tasks, and in doing so also help with the second. It’s not too farfetched to envision companies in which people use Enterprise 2.0 tools to report progress, collaborate, and share the outputs of these collaborations.
In another article, Taking Web Services To The Office, Fred Wilson compares how technologies used to emerge for "Enterprises" and consumers with how they emerge now:
Esther Dyson observed in a Release 1.0 issue in 2004 (well before web 2.0 was upon us) that it used to be that technology would start with the goverment (military or space), then move to the enterprise, and end up in the consumer's hands. But, she said, these days technology starts with the consumer and moves up to the enterprise.
Commenting on this thread that is spreading is the article Knowledge Management 2.0 which discusses the growth of current KM tools versus how "KM 2.0" will grow:
Many of the failed knowledge management projects at financial services and professional services firms were top-down initiatives staffed by technology and information professionals. They required complex technology infrastructures and very long implementation timelines. One challenge was getting employees to share information through use of the system; another challenge was proving an acceptable ROI, given a very high level of investment and a difficult to measure return. In many cases no amount of management evangelism could lead employees to share knowledge in a complex and often difficult to use platform.
These "top-down" initiatives usually involve someone (called "a consultant" or a "salesperson") who is master of spin i.e. a person who can BS with the best of them convincing those with decision making power that complex/convulated KM systems will enable their "Enterprise." The easiest way to cut through these persons' BS is to make them step away from the carefully constructed Powerpoint buzzword generating machine and ask them to actually demonstrate how this system they're trying to hock will help Jane in sales find information from Greg in Engineering better than email or a phone call. Make them demonstrate the entire system from creation of "knowledge" all the way to the point where Jane retrieves it. If after the demonstration, it is still incredibly obvious that Jane sending an email to Greg and getting a response back is easier than their "workflow enabled digital repository of knowledge," tell that consultant/salesperson to take their $600,000 contract, 7-9 month timeline, and ROI estimates elsewhere.
The final article I read was a month old one written by Ross Mayfield, CEO of Socialtext, entitled An Adoption Strategy for Social Software in the Enterprise. It's a long article and should be read in its entirety (like all of the other links), but I'll pull some quotes from it.
Experience has shown that simply installing a wiki or blog (referred to collectively as 'social software') and making it available to users is not enough to encourage widespread adoption. Instead, active steps need to be taken to both foster use amongst key members of the community and to provide easily accessible support.
There are two ways to go about encouraging adoption of social software: fostering grassroots behaviours which develop organically from the bottom-up; or via top-down instruction. In general, the former is more desirable, as it will become self-sustaining over time - people become convinced of the tools' usefulness, demonstrate that to colleagues, and help develop usage in an ad hoc, social way in line with their actual needs.
I can personally vouch for that in regards to the Case Blog, Case Wiki, and ITS internal wiki.
... consider how social software fits in to the context of their job, their daily working processes and the wider context of their group's goals.
- What specific problems does social software solve?
- What are the benefits for this person?
- How can the software be simply integrated into their existing working processes?
- How does social software lower their work load, or the cognitive load associated with doing specific tasks?
That harkens back to the earlier mini-rant I did in this post regarding KM contractors/consultants/salespersons. Make them show you, not in Powerpoint or whitepapers — in an actual demonstration, from beginning to end, from creation to retrieval, how this system will help and enable and empower and empassion the users whose job it will be to use the system. If email or a phone call trumps their system...