« April 2005 | Main | June 2005 »

May 28, 2005

Practice or process?

Here is a useful distinction that helps me appreciate subtle attitudes, values and beliefs towards knowledge within an organization.

Being process driven:

  • Emphasis is on inputs / outputs, engineering and efficiency, (faster, better, cheaper)
  • Focus on sequence, flows, authority, connections between activities and roles
  • Work is well-defined, everything is measured, concentration on forecasting and prediction, boundaries are fixed, stable & clear
  • Strong processes are found in procurement, warehousing, QC, billing, receiving, shipping
  • Rules rule, coherence is key, workflow is ordained
  • Design is a dominant paradigm and re-engineering works!

Living the practice

  • Context is king, a holistic POV is valued
  • Self-organization reigns, prediction is down-played
  • Concerns are wider than economics and efficiency, e.g. loyalty, customer relationships, reputation and doing the 'right' thing is key
  • Meaning, judgement and sense-making over-rule the rules
  • Emergence, agility and experimentation rather than design is the way to go, follow the flow
  • Dialog and distinctions are valued over directives and documentation
  • Relationships and communication are key
  • Meaning, awareness and understanding are valued and rewarded

This distinction is very important when working with ideas, insights, intuition and knowledge. Quality questions, creative abrasion, situated cognition, safe spaces, games, metaphor, dialog and analogy are essential ingredients.

So does your company value strong process over practice? That may well be an early sign that knowledge flows will meet many subtle constraints and any KM project is in for rough road.

Thanks to Paul Dorsey for reminding me.

May 22, 2005

KM activities

KM is a difficult domain to define. One way to give a novice a feel for the concept is to explain the core activities.

KmWiki has a large collection of knowledge management tasks, processes, roles, competencies and practices. Paging through these, it is amazing to see the depth, scope, utility and benefits that flow from understanding and practicing in this domain.

KmActivities

May 07, 2005

PKM tools

The roles of networking, collaborative skills and social capital are 'contested domains' for PKM which is often about individual responsibility and the organization of information and records.

My list of PKM tools:
* PC based search and indexing engines
* PIMs & outliners
* Concept and mindmaps (that do not encourage collaborative editing / design)
* Blogs
* Word processors
* Spreadsheets
* Tracking and link repositories
* E-mail clients
* Web homepages
* RSS aggregator
* Personal thinking / visualization tools

The key distinction between KM and PKM tools then is individual vs. shared spaces, personal vs. collaborative environments. Ask yourself -  who has control: 'me' vs. 'us'.

http://www.voght.com/cgi-bin/pywiki?PkmTools

http://www.jhorman.org/wikidPad/

Reflecting on PKM - it's not mainly about individual branding, networking for personal gain, learning or thought collation.

PKM merits a wider mandate.

May 01, 2005

KM in the library

Libraries IMO would greatly benefit from changing their vision to become knowledge centers.

Consider what needs to happen:

1) They pay greater attention to ephemeral exchanges and promote networking.

2) They offer opt-in services based on collaborative filters to point the patrons to interesting works and people

3) They redesign their architecture to promote 'collisions', host CoPs, concentrate on active learning, offer brown-bag gatherings....

4) They become active community participants gathering patron interest profiles and facilitate connections

5) They promote virtual exchanges, offer blogging spaces, deliver RSS feeds, actively inform their patrons of new developments, new literature and new people - this is a far cry from posting covers of new books on a noticeboard.

Here are some links and further thoughts

http://www.voght.com/cgi-bin/pywiki?KmLibrary

Changing to a KM mindset is not about the software adopted. It requires a deep understanding of the differences between knowledge & information and a radical revision of traditional library dogma, e.g. managing the collection.