Why you can’t solve knowledge problems with information tools alone

Often a client comes to us and says something like “We have a Knowledge Management problem. Our project teams can’t find the knowledge they need to deliver their projects. We want you to work with us to develop a better system to store and access project information”.

They have a Knowledge problem, which is a lack of access to project knowledge.  They think this problem can be solved with Information tools, such as taxonomies, metadata, portals and search. They think better access to project documents is the answer. However you cannot solve knowledge problems with information tools alone (I say “alone”, as these tools will be part of the final framework) for the following reasons.

Firstly much of the knowledge of the organisation is never codified as information. People know more that they can tell, and tell more than they can write. Maybe as much as 80% of the knowledge in an organisation is undocumented, and can only be accessed through networks, communities of practice, and conversational processes such as Peer Assist and Knowledge Exchange. Information tools leave this knowledge untouched.

Secondly, a common problem (a corollary of the first) is that project knowledge may never have been recorded in project documents. The project may never have created knowledge products, because these were never in the workplan, nobody was assigned to create them, and therefore knowledge never got recorded. Maybe the project might have collected a few one-liner lessons, but frequently these are poor quality as there is no quality control on lesson content. You need to introduce processes of team reflection and lesson-learning, together with the relevant accountabilities and quality control, for this knowledge even to be recorded in the first place. So even if you provide better access to project documents 

• you might find what the project did, but not what they learned, or would have done differently in hindsight;
• you might find what the project spent, but not where the value came from, or the reasons for any overspend;
• you might find the slide-decks and the reports, but not an analysis of the reasons for success and failures.

Thirdly, and a corollary to the first two, the vast majority of project information is not knowledge anyway. If you are relying on project documents as a source of knowledge, you will be relying on a very diluted source – a lot of noise and not much signal. Many of the documents are purely transactional (reports, memos, invoices, charts), and looking for knowledge content would be like looking for a needle in a haystack, no matter how good your search. If you want to create and pass on needles, then a haystack is not the place to keep them. 

Fourthly, if there is codified knowledge in the project documents, it tends to be scattered across many documents and many projects. Project A may have learned a little bit about a specific process, product or client, and so may Projects B, C, E and Z.  But those little bits will not have been pulled together and synthesised into a body of knowledge without specific accountabilities and processes to do so. Managing little bits is not like managing the whole.

Finally, many of the knowledge problems are cultural. People are incentivised to rush on to the next job rather than to spend time reflecting on lessons, no matter how important. They may not want to share knowledge, as they feel this knowledge is better kept to themselves in order to build their in-house status and value. People suffer from “not invented here” syndrome which leads them to prefer to reinvent than to reuse. There is no point in organising your project information if people do not want to seek for knowledge, and would not use it if they found it. I often use the analogy of teaching your child to read. The first thing you do is instil a love of books, so the child is eager for stories. Afterwards you can organise the book collection, but that comes later. Firstly we need the hunger for stories. Similarly we need to instil a hunger for knowledge as one of the first steps in KM, before organisation can be helpful.

Once we know that project knowledge is being collected, that projects are creating knowledge products and that these are of high quality, that these products are being synthesised into a body of knowledge, and we know that there is a demand for this knowledge and that people are actively seeking it, then the information tools really will provide an excellent support, as tools within the knowledge workstream I described last week.