Why Knowledge Management?

The Demise of KM - Part 1

A well trained lecturer once advised to never begin a statement by announcing how many points you want to make, such as "I have 3 things to say about that..." since there is a good chance that you'll actually think of a fourth (or more) while you are relaying them. I will add to that advice through my experience, saying that you should never declare how many points you are about to make since you are bound to forget at least 1 of them (particularly if you are over 40 like me).  So while I have a list of things that I want to blog about in the near future about Content Management, I have at least 2 things to say about the demise of Knowledge Management.

Over coffee this morning, I was enjoying Perspective on Designing and Managing Knowledgework at the Wierarchy blog. It's a two-part series with the second part located here (it was a little difficult to find). It is a long article, so grab a cup and enjoy.

The posting, which began as a article for Inside Knowledge magazine and was turned into a MasterClass, provides a history lesson of the industrial age and the rise of Taylorism (think time-and-motion studies), which is the doctrine known as Scientific Management. If there is nothing else that I can take away from the article other than its rich history, it is that it took a long time for Taylor, and particularly the disciples of Taylor to get the word out and applied in business.

Speed of spreading the word about KM is not the same problem that Taylor experienced, but speed of adoption is the challenge of all change of this nature.  As the wierarchy posting indicates, if it took Taylorism 30 years to become the standard in a business market that is a fraction of the size that it is today, then the 10 - 15 years that Knowledge Management has been garnering headlines is just the beginning.

So, the disappearance of KM?  Not likely to happen soon....

Content Management: Build or Buy?

When it comes to a Content Management System (CMS), what is better: to build your own system?...or to buy one of hundreds of available applications on the market?  Cody Burke, analyst, posed this question as a part of this week's Basex TechWatch eNewsletter.

[If you want to be completely amazed, alarmed and possibly even overwhelmed, go to CMS Matrix to see how many Content Management System are available on the market today] 

Years ago, as Mr. Burke points out, companies only had the two choices....build from scratch a system that perfectly fits your requirements and can be modified to changing needs, but can be expensive by using internal resources; or, spend to buy a system that has more than you need, is not custom, but can be implemented quickly and utilizes Content Management experts to shape the system to needs? 

The answer usually came down to corporate philosophy...those with NIH (Not Invented Here) Syndrome building their own, and those short on internal resources, but strong in need, opting to find an existing commercial system.

While the argument is far deeper than these couple of positions posted here, it is not the purpose of the Basex news article, which set its focus on Open Source.  In a relatively "old" (maybe mature is a better word) market such as Content Management there are now many offerings that can compete with commercial applications, but remain free of charge. As Burke points out:

There are multiple open source content management solutions available today that come with the benefit of zero cost and full access to source codes.  Instead of building completely from scratch, setting up an open source CMS means downloading, integrating, and customizing the system initially, and ongoing work to support and maintain the system.

The article also mentions the fact that more and more companies are going into business as Open Source experts (Vendors), able to customize one (and in most cases more than one) CMS system to meet a company's requirements. More on this is a future post, but the point is that an organization can now find an Open Source solution (no-charge software with source code available) that competes with commercial software offerings, and hire a vendor that is expert in that system to customize it to meet requirements.  Cody Burke reminds, though, that the price of admission may be 0.00, but you still must have the resources to either customize and support the system yourself, or find and pay a vendor to provide these services. From Burke:

By using open source tools, the cost is significantly lower than a commercial product, the customer possesses the source code, and the system can be fitted to exactly the needs of the user, getting rid of excessive bloatware and unused features.  The negatives of open source, and building a CMS in general, are mitigated by the commercial level of support and pre-integration that negates the need to shift or hire staff to set up and maintain the system.

About 3 years ago, I was part of a team that made such a decision to go with an Open Source CM Solution and hire an outside Vendor to customize it to meet our requirements (and they were expert in more than 1 Open Source CMS system and a few other Open Source applications). It helped us solve an immediate problem, and In the end, we ended up hiring a full time employee to keep developing the system.

This leads to a final point that I feel is critical in any discussion about using a CMS.

For any 'first time' CMS implementation, I would strongly recommend going with an Open Source solution. The nearly 100 point Requirements Document that we created for our CMS did not adequately cover what our real use would be, once the system was implemented and accessed by Users (some things we ended up never using, while other minor requirements became major features, etc). By implementing an Open Source CMS, hiring a Vendor on a project-by-project basis, and then taking over development, our CMS was a dynamic tool that evolves as our needs do.

This is even a good path for those with NIH Syndrome, as going this route has helped us develop requirements for a system that we could build from scratch, but again, we can do it based on several years of experience using a CMS, instead of creating something from a set of requirements emanating out of a few brainstorming sessions. 

Additional Wiki Notes

I like concise statements about the use and benefits of a tool, and I find that in the grind through of information (or the grind through my overload of information) that these types of blog postings are highly beneficial in triggering both a reminder of a way to utilize the tool, as well as innovate from the concept or particular implementation. 

Witness Colin Mooney's blog, Extacit, and a post from earlier this year Wiki as a Knowledge Management Tool. What I like about the post is the value of the content about his wiki pilot implementation, but it is also quickly (and easily) digestible.

Mooney takes the 4 components of the KM cycle (Find, Organize, Share, Use & Re-use), and highlights how a wiki has assisted in accomplishing this.

Wikis are a great tool to have a centralized location for everyone in the community to share and collaborate on content, making that content - or Knowledge, if you will - easy to Find.

The pages of a wiki typically get constructed in an organized manner. Wikis also link easily to other pages and provide the ability to create links to pages not yet written, helping to better organize related subjects and plot a path to the future (or reminders to develop certain content). Colin Mooney's post stressed the wiki's ability to search and retrieve information as an added benefit that his users experienced.

Of course, sharing is one of the things that a wiki does best, from sharing the content to sharing the collaboration and writing.

A collaborative environment utilizing a wiki also accomplishes the use and re-use of the knowledge, if correctly implemented. Specifically, "avoiding redundant effort, avoiding repeated mistakes and taking advantage of existing knowledge and expertise within your organization" (from an answer to a question listing 3 major benefits of KM by Stan Garfield).

All great reminders of the benefits that should be attainable from the use of a wiki.