Category: Enterprise 2.0

The idea has been around for years–using tools like blogs and wikis in a corporate setting–but now it has a catchy name: Enterprise 2.0.

Sharing is its own reward?

Offering rewards (recognition or even monetary incentives) for knowledge sharing is a pretty common practice. David Gurteen wonders if that is a good idea. He uses Wikipedia of a good example where sharing is its own reward.

My philosophy is that I expect people in my organization to contribute to the knowledge base. There’s a bare minimum level of effort there that is really considered part of their job.

As David points out, some folks are more passionate about topic areas than others. Those people tend to contribute at a higher level and quality than those who begrudgingly contribute because they “have to”. A performance review is a good time to recognize those who are exceeding expectations there. Public recognition for a particularly valliant effort is also obviously good. This seems like Management 101 to me.

One-time cash rewards for knowledge contributions–even with a “quality rating” built in–doesn’t enforce the right behavior in the right way, in my opinion.

Where are the “internal blog initiatives” case studies?

Yesterday was my first day at the KMWorld and Intranets 2005 Conference. I spent most of the day in the Collaboration track which, on this day, was focused heavily on blogs and wikis.

There were a couple of good nuggets in the presentations but I guess I was disappointed in the track overall. Or maybe what I was really disappointed in was the apparent lack of progress corporations have made incorporating internal blogs into overall Knowledge Management initiatives.

It is unfair of me to generalize that because there were no case studies from real corporations Corporate America must not be doing enough to leverage technologies like blogs, wikis, and RSS as a meaningful component of their KM program. And, there were a couple of examples given of companies, like IBM, that are doing this. But this is the KM World conference, is it not? If companies had compelling stories to tell around internal blogging initiatives where would they be presented if not here?

My company is a small services firm so our experience may not be transferrable to companies the size of our typical client. But, for what it is worth, here is an old post I wrote on why I think our internal blog initiative failed. At some point, I hope to correct these mistakes and take another run at it. Maybe by then many others will have shared their stories.

Internal KM post on slashdot

This is an interesting thread on Slashdot. Someone asked about capturing, organizing, and sharing knowledge in an IT department and the majority of folks are responding with various wiki tools and open source portals. Although the question was directed at the needs of an IT department, the advice is probably applicable to any department in an enterprise, provided the UI of the chosen tool scores high in the usability department.

Knowledge Management for an IT Department?. Slashdot Sep 30 2005 8:25PM GMT [Moreover Technologies – Knowledge management news]

The key issues, as I’ve mentioned before are:

  • it has to be easy to contribute content
  • it has to be easy to find content (via search and possibly taxonomy browsing)
  • it has to be secure
  • it has to have all of the “-abilities” (eg, scalability, extensibility, usability, etc.).

Something like a combination of blogs, wikis, possibly a document repository, and a search engine for the whole thing ought to do the trick.

Blogs and wikis as KM infrastructure

This is worth a read. It has definite applicability to corporate use of wiki and blog technology. The key paragraph is

The Wiki and the Blog are complimentary companion technologies that together form the core workspace that will allow intelligence officers to share, innovate, adapt, respond, and be—on occasion—brilliant. Blogs will cite Wiki entries. The occasional brilliant blog comment will shape the Wiki. The Blog will be vibrant, and make many sea changes in real-time. The Wiki, as it matures, will serve as corporate knowledge and will not be as fickle as the Blog. The Wiki will be authoritative in nature, while the Blog will be highly agile. The Blog is personal and opinionated. The Wiki is agreed-upon and corporate.

Andrus goes on to add additional supporting components to the core of blogs and wikis which consists of search, feedback, and an underlying document repository.

The Wiki and the Blog: Toward a Complex Adaptive Intelligence Community. Bill Ives finds a nice report on the use of new technology within the intelligence community…

The Wiki and the Blog: Toward a Complex Adaptive Intelligence Community. Here is an article by Calvin Andrus of the CIA on how they can use blogs and wikis to help them change, The Wiki and the Blog: Toward a Complex Adaptive Intelligence Community, which is not a bad idea. As… [Portals and KM]

[McGee’s Musings]

Note that the Stanford Law School link to the PDF does not require registration.

I definitely like the idea of using the repository as a sort of loosely organized collection point for raw knowledge. At Navigator we call this the “unstructured data warehouse”. It needs to be secure and I suppose it needs some amount of organization but the key is to make it easy for employees to contribute, easy to administer, and as open as possible.

Then, on top of that you add tools to glean intelligence from the warehouse (ie wikis) and a mechanism for expressing opinions about that separately (blogs). Index the whole shooting-match with a search engine and you’ve got something.

The final ingredient is incentive. You’ve got to make it beneficial for employees to leverage this infrastructure (and painful if they don’t!).

Internal blog and wiki survey

Gilbane Enterprise Blog Survey.

The Gilbane Report recently posted the results of their Survey on Enterprise blog, wiki, and RSS Use. While the survey sample is not representative of a larger population of companies (the survey was voluntary and Gilbane readers are probably ahead of the curve), the results are interesting. Of the 58 respondents (mostly from companies under $25MM in annual revenues but 10 from companies of over

By noemail@noemail.org (Seth). [Enter Content Here]

Why our internal blog pilot failed

Our internal blog pilot has failed to move off the mark after a little more than a year. Here are what I think are the top reasons why. Note: This feedback should not be taken as “Why Radio Sucks”. It’s just a brainstorm of some of the reasons why it hasn’t taken off (yet?) within our particular organization. Most of the issues are probably things to watch out for regardless of the blogging tool being used.

What we did

We gave a copy of Radio to our most ardent “sharers of knowledge”. We basically painted a modest vision of what blogging could do for us internally, showed how the tool worked, and then let nature take its course. We gave each blogger space on an internal Zope server (running on Linux) and provided detailed instructions on setting up a category within Radio that would upstream to the Zope server.

Why it hasn’t grown like crazy

1. We made it harder than it had to be for people to upstream to the internal server

The blog pilot particpants are typically always on a client engagement. The Zope server sits on the intranet behind a firewall. You have to VPN to get to it. Most of the time that works but not always due to proxy configs at the client. So, upstreaming to the internal blog web server was an extra step for most and impossible for some, other than what little time could be spent at home or at the office upstreaming.

2. We didn’t index the blog content

Our Zope server does not currently get indexed by the corporate search engine. So, the content that does get created by our bloggers for the internal server doesn’t get seen by people who aren’t subscribing to those feeds.

3. We didn’t drive traffic to the blog content through the portal

This is related to the search engine point. One way to drive use would have been for people to get to valuable content and then ask, “Where did that come from?” or “What are you using to create that?”. We could have driven more traffic to the blog web server by dropping in a couple of RSS portlets on the main page of the portal.

4. Email is easier

As much as I hate getting “internal spam”, for most people, email is still easier to use when sharing links, news clippings, or thoughts on a topic. The client is almost always open on a user’s desktop and the interface is very familiar. And, many things you want to share about come in the form of email so you hit forward and go. Also, unless everyone is aggregating internal feeds religiously, you cannot be sure someone got your post. Email is closer to a guaranteed read.

Because not everyone uses an aggregator, I always felt like I had to do double-entry–post once on my blog and then send a link to my blog post via email to the people I thought would be interested but who don’t aggregate feeds.

5. Radio is still beyond “typical” corporate users

Although it is a relatively simple tool, I think Radio is still beyond “typical” corporate users. Yes, the install is fast and simple. Yes, you can be publishing in minutes. But, there are a few things that should be table stakes for a desktop tool that aren’t there yet. Reliable backup/recovery/migration procedures are a good example. Try installing Radio on a different computer than you have now and moving all of your posts and stories over intact, even if you are using the built-in backup tool. The two or three times I had to do this due to laptop swaps, I was able to get all of my posts, but the stories had an annoying feature where the original post date was updated to the file modified date. I’m not sure a non-technical user would be able to execute the recovery procedure.

Debugging and troubleshooting has also been an issue. If a business user is having trouble upstreaming and the events page doesn’t have an obvious indicator as to what’s wrong, it can be tough to figure out how to get them going again.

Modifying the navigation is another example. It is extremely easy to update the XML file that controls those links. But would our CxO be up for doing that? Maybe. Maybe not.

6. Radio is a desktop tool but sometimes you need to blog from anywhere

For the most part, I like that Radio is a client-side tool, but there have been times when I wished I could get to it from a different machine. I know you can set up a POP3 account to send mail to that Radio would look at, but that seemed lame. And, I know you can set up Radio for remote access, but for me I’m not sure that would work very well. Radio is installed on my laptop and my laptop is not always-on or always-connected.

7. We didn’t offer clear instructions on when to use a blog versus a teamroom

We have standardized on a teamroom technology for group collaboration. Usually, the subject area for a team room is a project or client engagement. Sometimes, though, it is more horizontal, like in the case of a teamroom focused on a particular vendor. We handed out Radio to our early adopter/collaboration junkie types and said, “Here’s this cool tool. You can aggregate RSS feeds from the net and each other’s blogs.” But, we didn’t clarify the types of things that should go in a blog versus when a teamroom is more appropriate.

I don’t think it is too late for blogging to catch on here at Navigator. And, I will continue to use Radio because I like the tool despite some minor annoyances. But, the items listed here are going to have to get addressed to re-energize the original pilot group and to grow it beyond that.