CTO Blog

Excellent point.

My take (at least at this point of time).

1. Structured information is required for atleast dissiminating to the masses. ie. their is a significantly bigger audience that relies on structured information based on the model of Barnes and Nobel , the official story line , the directions from the top.

2.Unstructured information creation techniques have proved to be very good at keeping the information live , recent and with a lot of depth in perspectives.

So if you look at unstructured information as a way of creation and maintainence of information and structured information as a way of use of information you automatically have a strategy of knowledge management.

As an example:
One of the challanges faced by consulting companies is "How to move the stuff done by Associates to information that can used by the salesforce".

People have stuggled with several strategies including -Institutionalizing Knowledge Management, Having exit criteria for projects where the PM creates a Project exit form describing the project etc. All of this has obviously not worked in the past.

Here is my answer to the problem.

1. Use Unstructured information formats for Project Management and internal project workings. (Wiki's , Tickets , blogs ,etc). AND most important expose your inner workings of the projects on the knowledge management portal by default(and selectively choose what is confidential - I say this because it is generally the other way).
2. Make things like WIKI's part of normal workflow of doing work on a project. ie. things like requirements documents, architecture documents should all be in WIKI. Reasons. The deeper knowledge lies in these documents and unless you have a big budget of moving this knowledge in structured format this will probably never be exposed to the sales force and others in the organization
3. Use current "State of the art" search tecnologies that search PPT , Word and Excel information. refer google desktop or google search appliance.
4. After the project is done , someone from the Knowledge Management team should structure some of this information to set a context for the Mass consumers of this knowledge.

an excellent detailed post and for me the comments on project management definately work. i am more troubled to figure out how to approach this in general enterprise approaches to creating and managing knowledge or may be more corectly working experience.
any views??

Since the advantages of the traditional methods (books, etc) seem to be with the users, and the advantages of the web 2.0 methods seem to be with the creators, could some system be reached where there is a 'bleeding edge' version in (eg) a wiki which is periodically published and an official version in a similar way to most open source software developement? Allowing the users a standard, agreed version, but the creators can still collaborate in a modern, dynamic manner.

From an Enterprise Approach standpoint. The ball is really in court of the governing authority to pilot an approach , test it's success and launch it grandscale.

A few things that generally get overlooked and can be a receipe for failure are: (in order of priority)
1. Ease of use the proposed system. no one in this day and age has the patience to jump through hops to sign on to the system OR get access to the system.

2. Too much policy is BAD. people want to use different tools as they always see "their project" to be unique. Let them use that. But make sure that they comply with a few basic guidelines like - all content is searchable and hyperlinkable. Ideally you should have an viable alternative to what they want.

3. Too little policy is BAD. There is fine line between making sure that you are getting the consistency in the organization and people doing their own things.

4. And cannot emphasis this more - use good search technology.

5. have a monthly cycle running for clean up and categorizing content.

Andy
I have read carefully what you say and as a businessperson tried to put into a business context. I am going to focus on your comment… “conventional approaches where the knowledge is gathered first and structured to be made available to support the unstructured interactions". In business unstructured interactions are in reality how business works but “IT” has not had the effective tools to capture. As people create information /data it then enters the structured environment “ERP, General ledger maybe even the dreaded spreadsheet, etc. The process to create this information is where IT convention has in the past failed and why you have rightly raised as an issue, not least because here lies the power to make a meaningful difference in running a business – it is also where people are likely to send their CEOs to jail!

I picked up a quote you made and used in a Forrester Research report “An IT innovation must marry the art of the possible with the art of the valuable” You and your team recognise the issue and the “value” now you have to find out what’s possible. It is likely to be “disruptive” (as Forrester indicated) and sit outside the comfort zone relationship with large vendors. Therein lies your real challenge!

as i read the above two very good builds on the subject i think we are in agreement, but we are still struggling with the question of who decides when and how to make the shift into captured structure.

this question seems to lie at the heart of David's comment.

Who decides is one question? What is structure is a second? Why Strucutre a third perhaps... all pointing to what I would consider to be the central factor as to whether any attempt will deliver value - i.e. the user / customer for knowledge and insights. In this discussion there is a natural tendecy to apply or design a systematic approach to reflect often convenience from the provider / publisher of knowledge i.e. we get 'used' to reading newspapers - we get 'used' to shopping on Amazon. The user will invest time accimatizing to any stucture if the end outcome is worth the effort. This implies a sequence of priorities that would drive interest -
1. The user need to get the 'stuff' you are organising (strucutred or unstructured)
2. The quality and usablility of the content
3. How it is strucutred
4. What platform it sits on...
Just nudging the argument towards "Use" - i.e. the point at which all KM arguments move from cost to value....

good and interesting comments here that are making me think that what was missing from my orignal post was the link to who (person or organisation) gets the value and from what.

structure really is a code word for saying organisation or computer aligned, and may be this is not required as the value case is not there in many cases so why bother.

interesting direction to go towards and fits with the book Wikinomics which questions the need for structure in enterprises.