Knowledge is derived from activity, and re-used in activity. However the path between the two is not linear, and needs some form of "knowledge interchange system".
|image by stockarch - stockarch.com|
Knowledge is generated in operational work, which very often takes the form of projects. In projects, people from many disciplines come together to deliver an objective or to create a product.
Knowledge is re-used in projets.
However in its journey from project to project, knowledge is handled and managed using a different dimension. This can be
- the dimension of Practice - where knowledge is discussed in communities of practice, complied into practice guidance, and stewarded by a practice owner (subject matter expert);
- the dimension of Product - where knowledge is discussed in product focused communities, complied into product guidance, and stewarded by a product lifecycle manager, or product line engineer;
- the dimension of Customer - where knowledge is discussed in customer-based communities, and stewarded by a key account manager.
Whichever of these three dimensions best fits your your corporate context, knowledge needs to be taken from the project dimension, managed in the practice/product/customer dimension, then returned to the projects.
Let's look at lesson learning in a practice based organisation - a construction company.
- Let's imagine Project A has generated some excellent learnings about contract management, safety, and site survey
- Let's imagine Project B has generated some excellent learnings about mobilisation, safety, and piling
- Let's imagine Project C has generated some excellent learnings about piling, steelwork construction and contract management.
If we leave the lessons in the project reports, effectively filing the knowledge in a project dimension, then future project wishing to find lessons about mobilisation, or piling, or contract management, need to read each project report to see if there are relevant lessons. That's not difficult if there are only 3 projects and only 6 topics, but once it gets to 300 projects and 60 topics, filing the knowledge by project is untenable.
Instead, the lessons management system should tag each lesson by topic, so it becomes easy to find piling lessons, safety lessons, steelwork lessons and so on.
In addition, the lessons management system should route those lessons (eg by email) to the relevant communities of practice and to the relevant practice owners, so they can be notified of new knowledge in their area of practice, and update practice guidance accordingly.
So the practice owner for contract management (head of Contracts, for example) is notified that Project A and Project C have new lessons. The practice owner for safety (head of Safety, for example) is notified that Project A and Project B have new lessons. And so on.
Then once the practice guidance is updated, the future projects know where to go to learn how best to manage a contract, or how best to construct steelwork.
This is the interchange system
This system is like a railway interchange, shifting knowledge from a Project track to a Topic track. Without a system such as this, it can be very difficult to route knowledge to its correct destimation, so it can be reused in future.