The most common KM tool for sharing documents and other items with colleagues is the shared drive. But why is that, and is it really such a good idea?

Adoption

The shared drive is the most popular KM tool because it is drop dead simple. We all know how to use it and therefore have no adoption problem. Some KM tools require us to stand on our heads and pat our bellies, while we attempt to add content to the system. This usually leads to low adoption rates and eventual failure of the KM system. But with the shared drive, everybody is in the pool! That’s wild success, right?

Organization

The issue with the shared drive is that with no rules or regulations, anarchy reigns. The shared drive becomes like the junk drawer in your kitchen. It’s just a whole bunch of stuff thrown together, which means it’s hard to find anything - and critical items are often next to useless stuff. The only organizing principle for the shared drive is the directory structure, which is often built by different people at different times, with some files organized by time, others by region, and others by some logic that you simply cannot understand. Remember that KM pool party? It’s really a hot mess.

SharePoint

SharePoint embodies many shared drive characteristics. In its simplest form, SharePoint is often implemented as nothing more than a shared drive with a browser-based front end. As the RealStory group put it, "Basic file sharing collaboration at a workgroup level remains SharePoint’s biggest strength.” But basic SharePoint implementations often lack an information management strategy, and have no content rules or regulations - so SharePoint too can easily be a mess.

The key to building a successful KM system is finding a way to achieve high adoption without creating a mess.

Let’s first look at some ways to ensure that we keep the system simple. That means borrowing well known UI elements that everyone knows how to use, and avoiding things that require training, like proprietary search syntax. In other words, the KM system should be frictionless - for example:

• Search should look and work like Google (try to avoid proprietary search syntax, etc.)
• Guided navigation should look and work like Amazon
• Browsable directories (or information pathways) should look and work like Windows File Explorer

With a frictionless system you reduce barriers to usage and encourage adoption of the system. This is what I call a KM pool party – everyone is in the pool.

In my next post, Throwing a Successful KM Pool Party, I will discuss strategies for avoiding a content mess.