This is a post I put up on our internal company blog. I have copied it here (somewhat redacted) mostly because it seemed an appropriate place to put it:
This follows on from my previous post on KM [on the internal blog] with some further thoughts especially with respect to the comments made by others. Forgive me if this starts a little abstract; I'm an architect and that's how I think about problems. It may also be a somewhat long and meandering - be warned.
First question when dealing with Knowledge Management is:- What are we talking about when we say Knowledge? [The second question is "why bother to manage it?" but I think that has been covered outside this channel and I don't intend to address it here].
As I see it there are two forms of knowledge that we are concerned about within our company (or any corporate environment). I will call these 'formal' and 'informal' for convenience; although the terms are not wholly correct.
Formal knowledge is anything which has been documented in some defined form. A file, be it DOCX, PDF or MP3. In other words a static artefact. These may change (sometimes at lot) but changes can be tracked and versioned if necessary.
This is the sort of knowledge that we are already managing with Sharepoint and it forms the basis of a true knowledge base. These are the known unknowns and we just need to work on the structure and process or management. Taxonomies of documents, storage locations, classifications etc all come into this and represent known problems in search of solutions.
For instance, I think that the IDT categorisation needs to be done as metadata tags. Mostly this is because almost any document will have an 'I' a 'D' and a 'T' value and may have (many) more than one. Any other mechanism is going to way too complex to be useful.
One other thing to highlight is that the prime capability that any useful knowledge base MUST have is searchability. Information will not be used if it can't be found and we don't need a write-only repository.
This sort of knowledge is literally the intelligence of the business and represents a sort of corporate memory.
Informal knowledge is the stuff that each of us knows which is not written down anywhere. At the extreme this includes stuff that we don't know that we know (an unknown known!) which is usually referred to by the overarching term 'experience'.
I won't be covering this - mostly because I can only see only practical way of formally managing it and that is already covered under the term 'mentoring'.
Informal knowledge is the diffuse information in our heads that no-one ever bothers to write down. It includes directly relevant information such as the history of a project, including the reasons behind minor decisions, past discussions and their outcomes - what has been tried and failed in the past, what has not been tried and why. Often this is critical in understanding the current position within a client, or ourselves and we rely on staff continuity to preserve the back-story.
Informal knowledge may also include 'irrelevant' details which may seem unimportant but, in reality, are a critical part of how we do business. For instance the politics within a client and the personal preferences of key stakeholders can make or break a bid, or even impact the perceived success of a deployment, but is considered too sensitive to communicate. Information about a small issue in application maintenance may turn out to be the source of a major pain point for a client but is considered too trivial to mention to the design team.
In short the informal knowledge consists of small pieces or snippets of information, inferences and deductions, hints and allegations; transferred through gossip and chatter.
Following the above analogy, this is the instinct of the business and, like any instinct, although it may or may not always be correct, it forms the very real basis for any decision.
To revert back to the original question - how is this sort of knowledge to be managed?
I don't think there is any easy answer, but the business need to be aware that the question exists - even if it cannot be fully addressed.
To my mind a good start is the Wiki approach. A loosely controlled structure where people are welcome to add, modify, correct or link small snippets of information would be a valuable starting point. The goal is to create a brain dump site to cross-link and consolidate the diffuse knowledge spread across the organisation with the expectation that it eventually resolves into something useful.
Obviously this process would require significant contribution from everyone and that itself is likely to be the biggest hurdle.
First question when dealing with Knowledge Management is:- What are we talking about when we say Knowledge? [The second question is "why bother to manage it?" but I think that has been covered outside this channel and I don't intend to address it here].
As I see it there are two forms of knowledge that we are concerned about within our company (or any corporate environment). I will call these 'formal' and 'informal' for convenience; although the terms are not wholly correct.
Formal knowledge is anything which has been documented in some defined form. A file, be it DOCX, PDF or MP3. In other words a static artefact. These may change (sometimes at lot) but changes can be tracked and versioned if necessary.
This is the sort of knowledge that we are already managing with Sharepoint and it forms the basis of a true knowledge base. These are the known unknowns and we just need to work on the structure and process or management. Taxonomies of documents, storage locations, classifications etc all come into this and represent known problems in search of solutions.
For instance, I think that the IDT categorisation needs to be done as metadata tags. Mostly this is because almost any document will have an 'I' a 'D' and a 'T' value and may have (many) more than one. Any other mechanism is going to way too complex to be useful.
One other thing to highlight is that the prime capability that any useful knowledge base MUST have is searchability. Information will not be used if it can't be found and we don't need a write-only repository.
This sort of knowledge is literally the intelligence of the business and represents a sort of corporate memory.
Informal knowledge is the stuff that each of us knows which is not written down anywhere. At the extreme this includes stuff that we don't know that we know (an unknown known!) which is usually referred to by the overarching term 'experience'.
I won't be covering this - mostly because I can only see only practical way of formally managing it and that is already covered under the term 'mentoring'.
Informal knowledge is the diffuse information in our heads that no-one ever bothers to write down. It includes directly relevant information such as the history of a project, including the reasons behind minor decisions, past discussions and their outcomes - what has been tried and failed in the past, what has not been tried and why. Often this is critical in understanding the current position within a client, or ourselves and we rely on staff continuity to preserve the back-story.
Informal knowledge may also include 'irrelevant' details which may seem unimportant but, in reality, are a critical part of how we do business. For instance the politics within a client and the personal preferences of key stakeholders can make or break a bid, or even impact the perceived success of a deployment, but is considered too sensitive to communicate. Information about a small issue in application maintenance may turn out to be the source of a major pain point for a client but is considered too trivial to mention to the design team.
In short the informal knowledge consists of small pieces or snippets of information, inferences and deductions, hints and allegations; transferred through gossip and chatter.
Following the above analogy, this is the instinct of the business and, like any instinct, although it may or may not always be correct, it forms the very real basis for any decision.
To revert back to the original question - how is this sort of knowledge to be managed?
I don't think there is any easy answer, but the business need to be aware that the question exists - even if it cannot be fully addressed.
To my mind a good start is the Wiki approach. A loosely controlled structure where people are welcome to add, modify, correct or link small snippets of information would be a valuable starting point. The goal is to create a brain dump site to cross-link and consolidate the diffuse knowledge spread across the organisation with the expectation that it eventually resolves into something useful.
Obviously this process would require significant contribution from everyone and that itself is likely to be the biggest hurdle.
No comments:
Post a Comment