Having seen a few content management implementations myself (not to mention having talked to many people who have been involved in CM implementations), one of the biggest mistakes that organizations seem to make is not actually talking to anyone who is going to be using the system.

Knowledge management and IT folks sometimes think they understand a system better than the users possibly could; and in most cases, they’re right. But understanding the way a system works and understanding how the content should be organized are two different things.

While letting users (or even admins in most cases) loose on organizing content is usually a recipe for disaster, there needs to be some input from the people who actually have to use the content that’s held within a system.

There also needs to be some kind of planning around how you’re going to make your information architecture exenstible when the content outlives the usefulness of the IA — you don’t want to have to rebuild your architecture from scratch every time you have a huge influx of new content (in this case, I think it’s never useful to plan just for your existing content — you need to plan for the estimated amount of content that will come up within the lifecycle of your content management system).

And finally, whatever your estimate is for how much content you’ll likely end up with, make sure to double it.

First off, I’d like to say that it’s easy to start playing the blame game when things don’t go as well as one had hoped. This is even easier when you weren’t the one who put the offending system in place — “if only they had done things such and such a way”…

This type of thinking does little to address current problems, and can actually run the risk of alienating you from those who put the system in place and have valuable knowledge about how it works. You’re going to need their help, so don’t get off on the wrong foot by trying to blame them for the current state of the system.

The other side of that coin is the fact that they almost certainly didn’t want to put a system in place that doesn’t work. Think back to any project you’ve worked on that didn’t turn out well — you can surely think of a whole host of external factors that contributed to a lack of project success.

The key to turning a system that doesn’t work into one that does work is figuring out where the real problems are. While technology may seem to be an overwhelming problem for people trying to use a system, the real problem might actually be a lack of processes.

While technology is often a symptom of a failed system, it’s very rarely the root cause. Figure out the processes and mindset that is currently in place, and you’ll go a long way to laying the groundwork for implementing improved technology.

Once you’ve figured out where the problems are, develop a strategy to move from the current state (where you don’t want to be) to the desired state (where you do want to be). The point is to have a plan of attack to move in a positive direction.

And that’s really the toughest part — getting the momentum going. Once you’ve got agreement and movement in the right direction, things get much easier. It’s getting the behemoth moving in the first place that’s the toughest challenge.

Similarly, most knowledge management can be broken down into several sub-issues. Depending on the specific problem at hand, most issues can be broken down into the following sub-issues:

1. People: Who needs access to what? Does everybody have the same needs? Are there sub-groups that are readily identifiable within your primary group (this usually works only if you have a large enough primary group)?
2. Processes: How is information/knowledge going to be transmitted/shared between people and groups? What oversight is going to be in place to make sure that processes get followed?
3. Technology: What is the best technology platform to enable our people? What technology do we currently have that we don’t need any more? How are people going to learn how to use new technology tools?

The first two often get neglected, but are just as important as the technology you go with (even if that’s just a network folder structure). Also, getting agreement on a ‘way’ to organize is important (whether that’s by department, by type of content [all presentations go together, all forms go together, etc.] and stick to it (departmental divisions are usually clear and hard to argue with, so they’re a good place to start).

Getting people to start thinking about, discussing and eventually agreeing on other things like what you do with different document versions and what naming convention should be used for files (i.e. if I have a sales presentation from August 2007, it doesn’t really help if I call all my files SALMARPRES0807.ppt and someone else is calling it Sales & Marketing Presentation, August, 2007.ppt) should also be a priority. While this sometimes sounds like just nitpicking, it can alleviate a great deal of frustration.

This work should all happen before you ever even entertain the possibility of selecting a vendor or previewing content management systems (and if you can’t make that happen, then try to at least do these things concurrently).

Thinking about standards and processes is not always glamorous, exciting work, but it needs to be done. Otherwise, you’re just setting people loose on a system that they don’t know anything about — and this will always lead to having to go back and correct yours and their mistakes later on.

As these dedicated content management systems have taken root within most organizations, the question is often asked: what do we do with all that stuff we have sitting on the network drives?

Different organizations have went to different lengths to organize the content on network drives. But really, there’s only one way you can go about organizing that content, and that’s by creating a hierarchical folder structure.

Often, that folder hierarchy is based on the departmental hierarchy — which creates a sort of folder taxonomy via which content is organized. Yet occasionally, people get the urge to start mixing in other facets of the documents into the organizational hierarchy; and this is where things start to get messy.

As you’re probably aware, managing content now relies much more on search engines than it ever did before — and organizing content with accurate metadata ensures that it can be found through search.

However, let’s say we’re in a purely network drive scenario, and we want to organize our content both by content type (forms, presentations, etc.) and by department. The most obvious way to do this would be to create departmental categories (finance, human resources, etc.) and then come up with content type folders beneath those.

But in this scenario, we’re also certainly going to create duplicate folders. Chances are, human resources and finance are both going to have forms. They’re both going to have presentations. So, is it then better to organize by content type and subdivide by department?

And here we run into the real problem: there is no right answer. Department of origin, content type, subject and whatever other metadata we might have about a particular knowledge object (really just a fancy phrase for document most of the time) is just one facet that describes that object. And as far as which facets are important to emphasize, well, that’s a very subjective call.

But the network drive example can teach us something about organizing content. Even in more complex content management systems (take SharePoint for example), content is still being organized into folders. We thus still need to select a primary organizational methodology (department’s usually easiest).

It’s also good to keep in mind that it makes sense to think very carefully about what metadata you’re going to need to find you’re content — and ensure that you’re collecting just the right amount of that metadata, as I said in my last post. It’s much more difficult to go back and fix your organizational structure after the fact.

This article is based mainly on Dennis Deacon’s comment about setting up “best bets” in enterprise search on his own blog, where he points out that instituting “best bets” is often a workaround that’s undertaken after paying thousands (if not tens or hundreds of thousands) of dollars to implement enterprise search.

The first article also points out that adding “best bets” into any search application is a always going to be a manual hack, that is essentially a workaround for fixing what’s wrong with your enterprise search installation.

But what exactly is the real reason for having to institute these “best bets” in the first place? The answer is actually quite simple: poor metadata.

As Dennis points out at the end of his post, “best bets” should never prop up poor search results — yet underlying this statement is the implication that it’s often better to work at improving your metadata over the long term than it is to mask the problem with best bets.

Inaccurate, non-existent or improperly-interpreted (from the engine’s side of things) metadata is the root of problems with search results. Yet fixing problems with metadata (especially in a large organization) usually means one extremely important thing: clearly articulating the link between accurate metadata and better search results to content owners/managers.

If there’s one thing content owners care about, it’s that their content gets found. These same content owners often employ or have relationships with the people that actually post content — and these content posters know how important the content owners believe their content to be.

Yet when content owners ask for “best bets” in search results, what they are really asking for is to have their content highlighted, and given the importance they think it deserves. Now I’m not suggesting that their content is not important, merely that there are better ways to make sure it gets noticed.

Any avid blogger, journalist or search engine optimization specialist knows the importance of the title of a piece. Being vague or misrepresentative in your title will not only hurt your search engine rankins, it will drive your readers away as well.

This is all to say that educating the content owners and managers as to proper metadata creation is often not enough — depending on the size of the organization, it will often take a centralized group who monitors and controls metadata to ensure that users are able to find anything in search.

It’s really just a question of scale. In a smaller organization, it may be more feasible to simply educate everybody out there who’s creating content — while in a larger organization, you’re really going to need that centralized group that monitors and fixes metadata for you.

Unfortunately, I think we’re a long way away from removing humans from the search relevance equation. Surrounding any type of metadata/search implementation is the need for someone to look at things and make decisions about them — a job that technology is currently not very good at replicating.

This doesn’t mean that things won’t change in the near future. But until then, it’s up to your organization to find the human-technology balance that works for you — and it’s more a process of trial and error than a prescribed formula.

But, if you think about it, you also read your favourite newspaper and magazine because of the content they don’t publish. Lots of the time, whether it’s in knowledge management or content management, we think about getting users more content — the old “if they only had the right information at the right time, things would be better” approach.

I don’t know about you, but I have more content to deal with every day than I can possibly handle. Feed updates, emails, voicemails, podcasts, blog posts, the list goes on and on (and I’m sure you can think of many, many more). I would say that around 90% of the content I get in a day remains unread (and the most often unread items are usually automatic notifications, system-generated emails, mass emails, etc.). And I’m not even taking spam into consideration.

I don’t want more content. Period. So what do I want? I more value from what I already get, based on the following 7 principles:

1. Faster. Get me stuff I already read faster than I get it now. Even if you can shave 5 minutes off the time I get it in, it may make a big difference to me.

2. Smarter. Don’t send me an important system-generated message at 4:00 in the morning. Actually, don’t send me anything at 4:00 in the morning.

3. Shorter. Make existing messages more concise and to the point. Provide summaries instead of the entire piece of content, so I easily scan content to pick what I want to read.

4. Easier. Give me a better user interface, a faster search engine and more relevant search results. The more time I spend trying to figure out the interface, the less time I spend reading content.

5. Profiled. I don’t want messages about things I don’t care about. Let me choose what I get notified about — if I care about the telecommunications industry in the Ukraine, let me opt-in to messages about that industry.

6. Less. I like emails and web pages with lots of easily scannable content — finding the perfect frequency for emails is paramount. Weekly summary emails are usually better than RSS feeds for me — it’s easy to miss things in a feed.

7. Personal. I saved the best for last. Getting email or content from a person is highly preferable to getting it from a database, especially if that person can quickly provide me with context for that content. Not to mention it’s always nice to talk to a person.