I came across an article in Social Computing Magazine by Venkatesh Rao which asserts that there is a war between traditional knowledge management (KM) and the new social media (SM). Rao sees SM as the Gen-X solution to the problems that boomers were trying to solve with KM, but failed. Boomers and Gen-Xers come from complete opposite approaches. KM stresses strict order, hierarchy, taxonomy, and content. SM stresses openness, collective knowledge, folksonomy, and people. Regardless of whether you buy into Rao's thesis or not, he raises some interesting observations. Who will win? Rao believes that SM will prevail quietly by default as the boomers slowly retire from the workplace.

In a companion piece by Jeff Kelly, Rao's position is refuted. Kelly not only doesn't believe there's a war, he thinks that SM actually represents a logical evolution of KM. Kelly accused Rao if trying to instigate a war that doesn't exist.

Personally, I've struggled to reconcile the relationship between KM and SM. I'm old enough to have experienced KM and find that a lot of my boomer colleagues still use the term. However, you never hear a Gen-Xer refer to KM. Rao's article made me realize, in a way I had not previously noticed, that KM and SM are diametrically opposed in many ways. At the same time, KM and SM have so much in common, especially in terms of the goals they strive to achieve.

What do you think? Is there a war? Or just a quiet evolution? Does it matter?

A little more than a year ago we learned that people in our company were standing up wiki solutions on their own because IT did not have a wiki standard. At that point we identified three wikis, all built on a different open source platforms, including OpenWiki, MediaWiki, and Flexwiki. Clearly we missed the opportunity to anticipate demand. However, it wasn't too late to limit our risk.

In less than two months we identified stakeholders, gathered requirements, evaluated wiki solutions, and selected a standard. The goal of the standard was to prevent (at least going forward) the proliferation of disparate wiki platforms. We selected Screwturn Wiki because it was open source, built on Microsoft .Net and SQL Server, and met our functional requirements. However, due to our need to establish the standard quickly we did not have time to operationalize it. This meant that there was no centralized infrastructure, no internal support team, and no guidance on how to implement a Screwturn wiki to work well within our company. Development teams were basically on their own to build and support their Screwturn wiki instance.

While the Screwturn wiki standard met our goal of building new wikis on the same platform, the way we implemented the standard did not meeting the needs of our end-users. They wanted a standard that was fully supported by IT and on a centralized infrastructure. Self-provisioning of wiki sites was also an important requirement. They didn't want to engage IT people to create a wiki. They wanted to simply push the "new wiki" button.

As all of this was going on, we were in the process of implementing Microsoft Office Sharepoint Server (MOSS) 2007. We had heard that MOSS included its own wiki out-of-the-box. This was intriguing to us since it would mean that we could leverage our MOSS infrastructure and support structure. It also would meet the self-provisioning requirement. However, we immediately learned that the MOSS wiki is a really a WINO: Wiki In Name Only

The out-of-the-box MOSS wiki lacked many features that had become standard in today's open source wikis, including table of contents, sections, sectional editing, and intra-page linking. This perplexed us. It was as if Microsoft had thrown their "wiki" into MOSS at the last minute so that they could check the wiki box on the feature comparison chart. While the MOSS wiki may have some value for people who had never used a wiki before, those who had find it utterly lacking.

So, we had a problem. Do we try to use the MOSS wiki for the masses and allow people that need a real wiki to continue to use Screwturn? This would require us to address the operational shortcomings of our Screwturn standard, which would take time and money. It would mean that we would need to operate and maintain two separate wiki solutions, which is complex and redundant. We needed a better solution

Our research revealed very few full-feature wikis built on MOSS. In fact, we only found three possibilities: Kwizcom WikiPlus, Community Kit for SharePoint (CKS) from Codeplex, and WikiPoint by Neoworks. We ended up dropping the CKS from consideration because it lacked sectional editing and intra-page links. We also eliminated WikiPoint because it appeared to only be supported on WSS 2.0. That left WikiPlus. If that didn't work, we were prepared to do what was necessary to operationalize Screwturn wiki.

Our initial evaluation of WikiPlus was not great. While they did add a few interesting features, such as reporting, lifecycle management, and an enhanced editor, they were missing critical features, such as a table of contents. We contacted them and learned of a new release that would not only include a table of contents, but sectional editing and intra-page links. Over the next several weeks we worked closely with Kwizcom to address our unmet requirements. They were very responsive to our needs. The result was a feature-rich wiki solution built on MOSS. Our people who evaluated WikiPlus liked it better than Screwturn, primarily due to the WYSIWYG editor.

Someday Microsoft's wiki may grow up and eliminate the need for a 3rd party solution like Kwizcom WikiPlus. Until then, its nice to know there's a viable alternative.

Check out Lauren McKay's article at destinationCRM.com which summarizes some recent research by Forrester. Not surprisingly, they find that blogs, mashups, RSS, and wikis are experiencing the most growth, in terms of enterprise adoption. The part I found most interesting was the assertion that enterprise podcasting and social bookmarking have run their course, failing to take off as predicted. I'm not sure I would be so quick write them off. They may simply follow blog and wiki in terms of enterprise adoption, as this is where the big enterprise vendors are focusing right now. Our end-users are asking for podcasting and social bookmarking. However, we're telling them to wait. We beleive that the future enterprise 2.0 suites will include this functionality out-of-the-box. What's your experience with enterprise podcasting and social bookmarking?

Ray Sim's Learning Connections blog posted one of the best wiki use case lists I've seen. In addition to those on Ray's list, I thought of a couple more. I came away from the exercise with the sense that it is possible to do almost anything in a wiki, whether it was the best tool or not. It goes back to the idea that if there's nothing in your toolbox other than a hammer, then you'll try to fix everything with a hammer. That being said, I think the following list has some creative and interesting use cases:

• The Wikipedia use case: "community creates consensus-based truth regarding a particular topic."
• Documenting a business process (step by step instructions) — either as an initial draft for what is later to be "locked-down" in a document form (e.g. as required by government regulations), or not.
• Sharing tips and personal experiences related to a business process that is documented elsewhere.
• Creating a Frequently Asked Questions (FAQ) to support a software application or business process.
• Creating a glossary of terms that are specific to the project or company.
• Creating a "portal" to commonly used resources within a team or community, e.g. frequently used URLs to applications, documentation, contact information, etc.
• Creating a bibliography of team/community member's reading that they found valuable for the project or topic.
• Preparing for a face-to-face or virtual event. Gathering participant input (e.g. proposing and finalizing agenda topics) and defining logistics for the event (e.g. when participants flights land, arranging car-pooling to the venue, selecting dinner locations, etc.)
• Supporting weekly (or other periodic) face-to-face meetings. For example, conference room(s), phone numbers, facilitation assignments, agenda, minutes, etc.
• Augmenting live conversation, e.g. taking jointly visible notes during a virtual meeting — either as part of a web conferencing solution, or independently.
• Maintaining a "lab or project notebook" to share across shifts (teams working different hours on the same project) and/or physical locations.
• Collaborative writing - For example, user documentation, proposals, policies, etc.
• Collaborating on product or solution development including design, features, and technical specifications.
• Disaster management site – Real-time communication and coordination of recovery efforts.
• Strategic Marketing / Competitor Information - Document marketing strategies, results of market research and comprehensive information and analyses of competitors and link them to supplementary information – before, during and after the product launch.
• Knowledge-base or support site – support questions, issues, solutions, how-to guides. comprehensive documentation of so-called ad hoc expertise to assemble a network of unstructured knowledge, for example, of specialist knowledge about corporate processes, guidelines, recurring organizational processes, checklists, etc.

Let me know your thoughts on these use cases and if you've encountered others.

In my last post I listed nine benefits of internal employee blogs. In addition to the potential benefits, internal employee blogs may pose some risks, including the following:

• Potential disclosure of false, personal, sensitive, or embarrassing information that could put the company at risk – Assuming these blogs are only accessible inside the firewall, this risk is somewhat decreased. However, when you give every person the ability to publish content that could be accessed by every other person in the company, there is good chance that someone will eventually post content that should not have been published. The biggest deterrent to intentional abuse is to ensure that the name of the author is always clearly visible. The lack of anonymity assists most people in making the right decision. Additionally, a strictly enforced policy with real penalties is a good practice. Many companies today have adopted the simple policy of "don't do anything stupid. And, "if you do, you will be fired." Then they follow through on that threat quickly and decisively.
• Difficult or impossible to monitor or control blog content – The old model of having a corporate gatekeeper edit and approve any content that it published to a large audience cannot support the scale required by social networking technologies. It remains to be seen if automated, rules-based content scanners will be able to flag and perhaps quarantine risky content. Making authorship explicit and having an enforced policy should sufficiently mitigate this risk.
• Loss of productivity – Of course the big fear from many managers is the potential loss of productivity. Are people going to stop doing their "real job" in favor of posting to their blog? It's unlikely. This sounds like the worry that employees would abuse telephone or internet access. Most companies at least seen clear to allow every employee to have access to these technologies. In reality, only a small percentage of employees will consistently write to their personal blog anyway. Of those, an even smaller percentage will develop a following beyond their immediate team. In the end, every person's performance should be measured against quantifiable job objectives. Effective performance and compensation systems will help ensure that people do what is in the best interest of the company.
• Increased support costs – With any new application there are ongoing support costs. That is also true for internal employee blogs. In addition to looking for a solution that is supportable and robust, consider the offsetting benefits and base your decision on the total value of the technology, not just the cost. In my current company we plan to leverage the blogging functionality built into Sharepoint (MOSS 2007), which should keep the support costs in check. When you compare the relatively low cost of internal employee blogs with the potential benefits outlined in my previous post, the decision should be clear.
• Content will become stale – With any content repository, one of the greatest risks is that the content will lose its value over time. It is difficult to automate the process of assessing content value on any basis other than age. We assume that the older the content is, the greater the potential is for being stale. While that may be true, it is equally true that some content is stale within hours and other content retains its value for years. This risk should be considered as part of an overarching content and records management strategy. Of all the risks, this one may be the most difficult to mitigate adequately. To date, the most common approach is to accept this risk or enforce a draconian retention rule to the entire repository instead of basing retention on the content itself.

While there are some risks related to internal employee blogs, most of them can be successfully mitigated with an effective risk management strategy. Can you think anything I missed?