The last posts from last year where about using and reusing (project) knowledge.
I want to start this year with a more practical post about how we do this currently.
One of my (personal) objectives of last year was to improve the use of collaborative project work spaces.
The target audience for this are our technical innovation and development departments.
These groups already have the habit of using a project work space for big projects, but the local drive was the big favorite. Creating a Technical Report at the end of a project is also standard (for most of the projects to be honest). This report is highly technical, written by development engineers, for development engineers.
The management of these highly valued reports from the past and in the future was also an item to be covered.
We have the technology in place. Our collaborative platform allows for the easy creation of dedicated work spaces for a project, with delegated access right management, document repositories, forums, and an integrated search function.
People have been trained on how to use these tools. Several info sessions have been organized, training material is available in several formats, …
The only thing remaining was that they actually started using it in the day to day live.
It took me some dedicated sessions to convince and demonstate how it will work in practice, but as of the beginning of this year there is a consensus on how to use these tools from now on.
A simple process was set up and approved.
For each project a dedicated work space is set up. This consists of an area for the project team and an area with wider read access where the technical reports can be published.
Once the project is finalised, all information is archived and the access rights are opened to a larger audience (customised to the project).
Using customised searches, the engineers can now look for :
– archived or current project info
– all project information or technical reports only
– all combinations of these
This process is now included in the regular project management process, without creating extra work.
Sounds simple, but the mental shift from ‘This is something that looks good and that we can do’ to ‘This is our normal way of working since it is the only thing which makes sense’ is a big step.
Next is to get a formal knowledge reuse step included in the project start up phase.
In the AOK archives I found this contribution from Nancy Dixon about the creation and reuse of project knowledge.
The reuse of project knowledge has always been one of my favourites; and one of the key issues which initiated my involvement in knowledge management.
Nancy created a structured framework for transfering knowledge from one project team to another, carefully combining the use of knowledge databases with social processes.
On the knowledge supply side there is :
– a ‘Sensemaking’ step, where the knowledge supplying team comes to
a common understanding of it’s experience
– a ‘Translation’ step, where this knowledge is reviewed to identify
the most important and usefull learnings
– a ‘Spread’ step, where the learnings are captured in a reusable format
On the knowledge demand side we have :
– a ‘Scanning’ step, knowledge sharing is only possible and relevant when
there is a demand, a request
– an ‘Assist’ step, where a team with a question is coached (assisted)
by the team which supplied their learnings
– an ‘Adaptation’ step, where the learnings are adapted
by the new team in the new context this team will operate in
For the knowledge managers, who want to manage the knowledge, you can analyse and manage the knowledge database with the lessons learned.
I am (re) reading the book ‘Common knowledge‘ by Nancy Dixon.
The theme of the book is sharing. Knowledge only has value when it is used and reused.
The book is the result of a research project envolving major companies (among others British Petroleum, the US Army, Ernst & Young, …), where the knowledge sharing processes were studied.
She concludes that three criteria will define which transfer process will be effective :
– the intended receiver : same team or different team, context
– the nature of the task : routine or nonroutine job
– the type of knowledge : from tacit to explicit knowledge
With these criteria, she identifies five knowledge transfert processes :
– serial transfer : when the same team is using the same knowledge again
– near transfer : when another team is using the same knowledge in a smilar context
– far transfer : when tacit knowledge is transferred about a nonroutine task
– strategic transfer : when large parts of the company are impacted
– expert transfer : when explicit knowledge is transferred about nonroutine tasks
In the following chapters, each of these transfers is explained in more detail, with practical examples of how the transfer process was implemented in different companies.
What I like so far is the emphasis on the using of knowledge, not so much on the creation of databases with lessons learned.