The tendency when dealing with many knowledge management issues is often to jump right into the solution phase, when really it makes more sense to determine the strengths and weaknesses of what you’re currently doing, and how your current practices could be improved.

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.