Ever since I first become the manager of a software development team I have been grappling with knowledge management. The main reason for this was that, to me, it seemed like the thing I have to get right to enable my team to learn from each other. It also seemed like the right thing to do to help new members of the team learn what the rest of the team already knew.
However at the time my definition of knowledge management was quite limited. At first I struggled with how to store knowledge. To create a software system in which we can store our knowledge and make it easily retrievable for team members. Once we agreed that we would use a web based solution, viz a vie, and intranet, the challenge become how to represent the knowledge in the system. This of course generated much debate and many compromises.
We then shifted our focus to how to capture all this wonderful knowledge that the team acquired while working on their projects. We started of with the need for documenting the code. This is a great idea, but not easy to implement, since developers despise writing documentation. So most of the time the documentation becomes out of date very quickly and you might as well not have had the documentation in the first place. Then we tried modelling with the Unified Modelling Language (UML). This was another great idea, but had quite a steep learning curve for the developers. Some liked it and adopted it, while others did not bother.
At this point I was ready concede defeat that we are not able to effectively do knowledge management, so you start to rationalise about why it failed. You think things like, “…this organisation is just not mature enough…” or “…if only the software developers were not so lazy… “, etc. The bottom line remained that i could not find an approach to knowledge management that worked.
It has been many years of struggling and learning for me to appreciate that knowledge managements consists of 3 distinct but related components. Firstly, it involves the harvesting of knowledge, which implies some learning must have already occurred, typically through experience. Secondly, the building of knowledge accelerators. At this point i must state that my definition of a knowledge accelerator is quite broad; It is: Any artifact that allows the user to gain knowledge faster than if he learned by self experience. So this includes, books, manuals, project documentation, process models, information models, etc. These knowledge accelerators are quite inert though and require some activation. Thirdly, we need to ‘activate’ these inert knowledge accelerators, and for this we make use of Executable Knowledge components. These Executable Knowledge components can have many manifestations, for example, a graduate development program, a workflow system that utilises a new process model, a regression test pack, etc.
In my next article i will discuss how Executable Knowledge can be used to reduce cost in a Knowledge Rich Environment.