Several years ago, I had become introduced to David Snowden's 3 rules of Knowledge Management. I thought for sure that I had posted something on the subject, but all I could find was a brief note about how Snowden seems to always be ahead of the pack where KM is concerned.
At the time, I had read some of Snowden's work (some of it admittedly well over my head), but the 3 rules were easy to grasp and seemed instinctively true. For instance, "we always know more than we can say, and we will always say more than we can write down." It's a very basic truism - previously unstated - which as a defined heuristic provides some insight into Knowledge Management.
All this because my Google Alerts indicated that Claire at Fletchspace had blogged that David Snowden had updated his original 3 rules to 7 principles of KM. I had hoped to see where I noted the 3 and any thoughts I may have had at the time, and then see how things had evolved. Not to be found...but the update is available at this link at Cognitive Edge, and includes the direct straight-forward principle, with a description.
But anyone dealing with Knowledge Management and knowledgeworkers should be familiar with these principles and should bookmark them and refer to them often.
I had the pleasure to run into water&stone a vendor that focuses on web applications and also on installing and customizing Open Source Content Management Systems (CMS) for clients. A few weeks back, Cody Burke of Basex, suggested - in their TechWatch newsletter - this very approach of using an Open Source CMS with a vendor capable of customizing it to a company's requirements.
The purpose of the report was to look at 19 of the most well known of the Open Source Content Management Systems. They attempted to assess these CMSs on the basis of Rate of Adoption and Brand Strength. As they disclose in the report, metrics
in the industry are lacking – so the report is very open in its approach, results and any extenuating circumstances, with an end result of attempting to determine the trends and patterns in this marketplace.
Overall, it is a very satisfying report...open in its methodology and replete with necessary footnotes.
The goal of the report as described early on is, "to present a variety of metrics in one easy to
access document and thereby help inform our readers about what is happening in
this dynamic market."
As a part of the study, they included traditional Open Source web content management (WCM)
systems, wikis, and blog-style approaches to publication. The report comments on the blurring of lines between these
three types of applications, so they sought to be inclusive. Hosted and commercial solutions are not included (Ektron, Red Dot, as well as Blogger are among those not included).
With no standard metric in the marketplace, the report's author began by brainstorming methods of tracking popularity and adoption, and all cards are on the table on how they did this.
The report segments each area of Rate of Adoption and Brand Strength, looking for Leaders, Movers and Laggards, this is similar to Aberdeen Group research projects that groups their studies into Best-in-Class, Industry Average Middle, and Laggards, they are both easy ways to look at and evaluate the results.
The report admits that there were challenges, such as b2evolution (blogging
software that I’m familiar with) which badges many of the pages created by
users with their name (effectively skewing results), and MediaWiki, and Open Source Wiki – which is on millions of pages due to its
use as the engine for Wikipedia.
Adoption figures looked at Downloads, Installations and Third Party
Support…and they list the problematic aspects of each category. But where
available (not all applications track this), the total downloads and average weekly download rates were
reported. It was not possible to even try to track live installations. For third party support they looked at Developers using the application and
Publishers (books written).
Brand strength looked at things such as Search engine
visibility, Popularity Metrics, looking for evidence of mind share and evidence of
reputation.
For search engine visibility, they actually include the search
terms used and rated/ranked accordingly, giving a) clues to their methodology, and
b) taking into account a variance in response.
Google Search and Alexa Rankings were employed for Brand
Strength metrics, and the Alexa rankings were done for both February and July
of this year (they checked twice for demo downloads as well to track trends and totals).
Google Trends was also used in the method.
They even used blog mentions to help provide a sense of goodwill, since bloggers do not have to mention these solutions, so they checked Technorati, BlogPulse (from
Neilsen) and IceRocket as well as Google’s new Blog Search. They even pulled out the social networks, tracking fan activity by looking at Facebook, MySpace
and Google Groups looking for collections of like minded individuals on each.
As a part of the results section (that includes the Leaders, Movers and Laggards), they named the 3 top solutions. I won't get into details, but WordPress and Joomla! far exceed the others in the two categories combined....but the report also lists projects they feel may be at risk due to
declining statistics in the areas that they were looking at, and those Open Source solutions whose window of opportunity may also be closing...Oh yeah, and the systems on the rise and worth watching.
The report was done by Ric Shreves, one of the founding partners
of waters&stone. He writes and speaks on Content Management systems and web
applications and has worked with Open Source CMSs since 1999.
I've been thinking a bit about Content Management recently since receiving the Basex newsletter that discussed the benefits of an Open Source Content Management System (CMS) versus a Commercial CMS (of course I blogged my two cents worth).
As I started to get back into things, I noticed that the majority of hits to this site are those coming to check out the CMS Reviews I did on Reddot and Ektron (I reviewed 5 or 6 CMS systems, but these 2 get all the hits), and they were not all that favorable. The posts on my reviews are now three years old, and apparently are still pretty high up on the search results, which leads me to believe that perhaps I should be reviewing and blogging about various CMS systems, but I hate that idea when I think about the different requirements that users have.
The primary force preventing me from writing about CMS systems is that there are already some great resources out there for finding this type of information. CMS Matrix is a good for getting started and finding out key feature availability for each of about 1200 CMSs. From there, CMS Watch kind of owns the review market. But perhaps there's a middle ground.
All of this is leading to the fact that there is a new industry report out that I need to read...a 2008 Market Survey on Open Source CMSs....at 50+ pages, it looks like a properly done research project.
The folks at Eat Media have put together as a part of their blog, the Top 10 Half-Assed Content Marketing Solutions. Actually, it's an old posting from earlier this year, but I'm back thinking about Content Management again, and it caught my attention.
There's not really much preamble to the posting, just the list of 10 bad ideas with some details and an example. The list includes things such as having multiple people responsible for content without management, creating a content strategy without seeing what the competition is doing, and shooting at too wide an audience in one message.
Great list....good advice. Many I have violated such as not blogging often enough and the too broad an audience suggestion. Good things to keep in mind.
The Eat Media folks are very creative, I've mentioned them and their advice here before, and they are also insouciant in their approach, so I'm sure they will not mind me poking a little bit of fun at them....a top ten list?...I think #11 of poor content management and content marketing strategies is resorting to top 10 lists, no matter how good it is.
Hey, everyone has done it...I have definitely done it before. But I think this eleventh lesson learned is to keep lists punchy - and always less than 10 items...maybe prime numbers only.
Groucho Marx (American comedian) was often quoted as saying something like, "I won't belong to any organization that would have me as a member."
Pumacy Technologies AG, a German-based company released this past week the results of an exploratory study that they did of Knowledge Management blogs, and named 50 blogs that are a part of their study.
In a roundabout way, Google Alerts notified me that Mary Abraham's blog, Above and Beyond Knowledge had linked to Jack Vinson's Knowledge Jolt announcing the study. So I eventually get around to the study and YKM (this blog) is listed on it. This is surely the sign of the KM apocalypse.
Of course, I appreciate the attention to the blog...why not....most posts are breadcrumbs for my own future re-use, but what was the selection process?
In fairness, Pumacy is a Knowledge Management vendor. They appear to just be supporting the fact that the KM space is thriving and full of active participants writing about various aspects of KM....which is done here...and Pumacy did locate some prolific bloggers including the 2 mentioned above...but based upon the amount of postings, amount of comments and Google ranking, it just strikes me as a lack of good research (time and/or effort) on Pumacy's part add this blog to the list, instead of going out and finding the really active KM blogs and list them as a part of their study.
Since they studied and printed it once, hopefully Pumacy will continue their study and bring to light some great blogs.
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.
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....
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.
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.
I wanted to catch up on what has been happening in the world of Wikis, and I stumbled upon Stewart Mader's Grow Your Wiki blog through an article he had written for Website Magazine entitled 5 Effective Wiki Uses. Mr. Mader is a huge proponent of wikis and has an excellent series of short videos as a part of a series called 21 days of wiki adoption.
First, I am a lover of wikis as a tool. I use one that has enhanced efficiency and it has proven
very useful for certain collaboration projects. So after having watched the twenty-one, 2 - 5 minute videos, I must say
that Website Magazine did Stewart a huge disservice by either
requesting, or allowing a condensed version of Mr. Mader's work.
The article names the 5 effective uses as,
Project Management
Customer/Client Collaboration
Documentation
Online Community
Policy, FAQ, Guidelines, and Best Practices
Standalone, with only a small paragraph to describe each of these in the article, I was left with a number of gaps, questions, and even disagreements with using a wiki for a few of the purposes mentioned. However, having watched the 21 videos, there was enough content and scenarios to where I can now see the way in which Stewart is envisioning the use of a wiki in these areas of business. I still think that in some cases, another tool could be better, but I can definitely see a wiki working.
For someone new to wikis, skip the magazine article and go straight to the blog and the videos that cover subjects such as, Wiki vs. Email, Run a Pilot, Don't Rush It, Better Meetings, Project Management, and Wiki vs Content Management System.
For a consultant, or someone knowledgeable in wikis, the videos provide guidance that will help get a wiki implemented and accepted within an organization or portion of a business. Mader's web site provides some testimonials, guides, and case studies to help.
There's more study to be done to get current on wikis, and Grow Your Wiki is a good launching point.
I've been tracking Information Overload (IO) for quite some time...a subject that is at the forefront of much of Basex's research and the subject of several posts here. Along with tracking this issue, I'm most interested in solutions. The best seen so far however comes from Luis Suarez at ELSUA, who has started a new mantra of giving up email.
Of course, the immediate reaction is that there is no way that we could possibly live without email. And in truth, with the state of the workforce at this time, that would be a true statement. However, Luis' How to Collaborate with Customers without Using Email provides an excellent guide to getting control over information overload by controlling certain work email.
The prime argument is that email is a horrible collaboration tool. Face it, when using email to collaborate, you are left with no good choices. Take a small project where 5 people need to collaborate on a document. In order to avoid dozens of "Reply-All" emails that will fill in-boxes (often with unnecessary emails), side emails are sent, multiple versions of documents/spreadsheets/etc are begun and circulated. Email 'conversations' about the document or project are made between various segments of the group, and/or are then circulated to all members - some who do not have the full context of how the document got to this point. And of course, some of us MUST answer emails as soon as they arrive, while others of us handle them at certain points during the day (or ignore them altogether), causing the collaboration to be out-of-sync at the very least and filling our in-box in the process - all of course, having the same level of priority which we each individually assign for ourselves. As the size of the project - in number of players - increases, so does the traffic and lost effort. And this is only a part of the problem.
I must say that I have not done as well as Luis Suarez has on his 26th week without email,
but by using social networking solutions, I have noticed a dramatic
decrease in email traffic, and improved project completion,
coordination and communication by using the right tools for the right
job.
In my attempts to keep tabs on and learn from Knowledge Management, Content Management, Wikis and Social Networking processes and tools, I have endeavored to never mention the company that I work for and any of our internal processes, and I will stick closely to that and not give away any secret sauce, but in this case I just want to say in nondescript terms that we are 'members of this choir'; management down to staff are huge believers that email is NOT a tool for collaboration as Luis has discovered. With a corporate culture where everyone is a watchdog that ensures that social networking tools are used when required, and that email is only used as a vital form of direct, two-way, non-collaborative communication, there is a correct focus that reduces one of the causes for information overload.
Email is just one of the contributors to information overload, but some would argue that it is a significant part. If that is the case in an organization, Luis in his post names some specific software solutions that they have employed or that he is looking into that seem to be making a difference and which deserve some investigation.
Social Net Links