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?

I work for a Fortune 500 company with nearly 30,000 employees scattered across the U.S. We have been experimenting with internal employee blogs for a couple of years. However, to date only senior business leaders have been allowed to have a blog. These popular sites have gone a long way toward improving transparancy and providing a way for the masses to provide feedback. We’re now on the cusp of deciding whether or not to open up internal blogging to every employee.

To be clear, these are internal blogs. They would be accessible only to employees and contractors inside the firewall. Although the capability would be made available to all employees, we assume that a large majority would never actually make the effort to create a personal blog. And, of those that do, only a small percentage will ever attract much of a following. Even so, there are a number of people, mostly business leaders, who have a hard time grasping why we would even consider letting any employee write his or her own blog. After all, how is letting our employees blog going to reduce expense or increase revenue?

• Publish content instantly and efficiently. Sure, there’s always email. However, email lacks context. Whether it is a line manager who needs to get the word out to his team or a thought leader who wants to float a new idea while its fresh, there is power in self publishing.
• Capture and search knowledge that would otherwise only exist in the heads of our people. There’s a lot of knowledge burried in email. Unfortunately, it is completely useless to everyone except the person who happens to have a copy. Even for them, its unlikely they will find it when they need it. Email retention policies and quotas result in deleting messages that still have residual value. When an employee leaves a company, his or her email account is deleted within days of their leaving, and a long with it, the embedded knowledge. Blogs, on the other hand, are accessible to and searchable by everyone in the company. The knowledge contained in a blog could remain as long as people are accessing it regularly, even when the original owner has long since left.
• Provide a communication platform for thought leaders, regardless of where they are in the official corporate hierarchy. As I mentioned, only a few leaders at the top of the food chain have the privilige of blogging in our company today. This sends the message that we have a traditional, top-down hierarchy. To our people, it can appear that we don’t value the thoughts and ideas of people unless they happen to be an executive. By opening up blogging to the masses, that all changes. Thought leaders will emerge from any level in the corporate hierarchy. What matters is the value of their ideas, not the size of their pay check.
• Build internal, business related communities of interest that would not otherwise exist. People naturally converge around known likenesses. In a large organization, even the most unusual interests are shared with several other people. Until now, finding those people has been next to impossible. In my own experience there are people scattered throughout our company who are passionate about collaborative technology. Most of them have no idea what’s happening in this space and who is on point. If they had an idea, they wouldn’t know who to contact. By writing a blog, I could begin to biuld a community of interest around collaborative technology. I could share ideas and expect truthful feedback from people were previously invisible to me.
• Allow people to market themselves internally, demonstrate the value they have to offer, and gain status and exposure. We all have the responsibility of marketing ourselves. In the past, each person’s potential sphere of influence was limited by their position in the corporate hierarchy and geographic location. With a blog, smart people can market themselves and their successes much more broadly. However, they need to be careful. No one likes a self-promoting bragger.
• Allow people to subscribe to the blogs that interest them through an RSS reader. Thanks to syndicated content, we don’t need to visit our ten favorite of blogs looking for new posts. Instead we can monitor our favorite blogs efficiently through a single RSS news reader.
• Create an efficient feedback loop between the blogger and readers/subscribers. A blog is not a broadcast, it is a dialog. Blog feedback is a gift. By putting an idea out in the open, a blogger opens herself or himself to feedback from the masses. Almost all feedback has some value, even negative feedback.
• Support openness and transparency when any employees are empowered with the ability to publish content. The executives in our company who post to their own blogs have received extremely positive feedback from their staffs. Employees feel like they now have a direct line to the business leader instead of waiting for messages to trickle down and morph through the management layers. They know that the business leader will read and respond to their comments in public. Almost no front line employee would dare send an email to a CxO. However, commenting on that CxO’s blog feels much less threatening. This sense of openness and transparency grows exponentially when all employees are allowed to blog. Suddenly I’m able to benefit from the ideas of a person across the country who happens to be in a completely different business unit.
• Encourage people to blog internally instead of externally, where the risks to would be much higher. Okay, I know. I’m blogging externally. Ideally, however, we would always prefer employees to blog internally, as opposed to on the Internet. We want to secure our intellectual capital and ensure that our best interests are protected. Most employees will find that an internal blog will satisfy their need to share and build a following. Without an internal option, however, more people will turn to public blogging.
  

Okay, I know what you’re thinking. I’ve still not answered the question of how letting our employees blog will reduce expense or increase revenue? I can’t do that, at least in terms of hard dollars. In my experience, however, the costs and risks are low enough to stand up to soft benefits.

Are there benefits I missed? Have you been built a business case for employee blogging on hard benefits?

I respect your privacy and am committed to protecting it at collaborationtech.blogspot.com. This page discloses information about the data gathering and disseminaton practices of this web site.

Log Files
Like most standard Web sites, I use log files. These logs may gather non-personally identifiable information about your session at this site, such as your IP address, browser type, internet service provider (ISP), referring/exit referring page, platform type, date/time stamp, etc. This information is used by me to administer the site, track user movement in the aggregate, and gather broad demographic information. Your session information, including IP address, is not linked to any personally identifiable information.

E-mail Subscription
If you wish to subscribe to my posts via e-mail (powered by Feedburner), I may ask for contact information such as name and email address. However, out of respect for your privacy, there is a way to opt-out of these communications.

Cookies
A cookie is a piece of data that is stored on your computer by a web site. My site uses cookies for tracking activity. Some of my business partners, including Google, may use cookies. However, I have no access to or control of these cookies or the data contained within them.

Links
This Web site contains links to other sites. Please be aware that I am not responsible for the privacy practices of other sites. I encourage you to review the privacy policies of web sites you visit. However, this privacy policy applies solely to information collected by this web site.

Advertisers
I use Google Adsense, a third-party advertising company, to serve ads when you visit my website. They may use non-personally identifiable information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and how to opt out, click here.

Contact Information
If users have any questions or suggestions regarding this privacy policy, please comment to this post.