Knowledge Sharing Pattern Language


Pattern

KSP27
Contributed Experience Base

Dimensions and Knowledge Flow:
 


I2
Knowledge Sharing
in an Organization

 


Lessons Learned
L1-L3
 

Organization

<---- 

Project Manager
(& Team)

   

Problem

Lessons learned are collected in projects but not shared at the organizational level. The same problems are occurring again and again in different projects.
 

Initial Context An organization has Established an Experience Base (KSP16). Lessons are discovered (KSP15) in project teams.
 
Roles An organization represented by persons responsible for the maintenance of the experience base. If the experience base is automated enough it could also represent here the organization role. Project manager (including other project team members).
 
Forces In organizations gained knowledge is "wasted" if not shared. The existing knowledge should not be difficult to find and reuse for e.g. project managers. (Komi-Sirviö et al. 2002.)

Rus and Lindvall (2002) remind of the importance of knowledge sharing in utilizing the individual knowledge at the organization. They say that: ”Large organizations cannot rely on informal sharing of employees’ personal knowledge. Individual knowledge must be shared and leveraged at project and organization levels.” (Rus and Lindvall 2002, p. 27). One important part of the organization level knowledge sharing is the lessons learned type of knowledge.
 

Solution
 

  1. Report Lessons Learned. Report the lessons learned collected in a project team (see Discovered Lessons, KSP15). Instead of lessons learned, the input can also be some other feedback to be noticed in the experience base or other assets. This same procedure can be used also for the other input.
  2. Study Lessons Learned. Do the lessons include new material for the experience base or for some other assets or forums? Do the lessons learned create a need to update the assets? etc.
  3. Process and Add to Experience Base. Translate the material into a form that others can use (Dixon, 2000, p. 21). Update the Experience Base (or other assets).
  4. Communicate Bigger Changes. If the previous steps have resulted in bigger changes in the experience base or other assets, inform project managers and project teams. Different ways of communication could be used for different purposes. For example, a news group to inform about the availability of some knowledge or direct communication supported with emails to everyone if very big changes happen.
  5. Study. Follow the information related to the experience base and other possible supporting assets some reasonable way.
Resulting Context An organization having implemented systematic experience collecting and storing.
 
Instances Follow this pattern always when receiving lessons learned of relevant feedback related to the experience base or other such assets.

One potential pitfall is that the lessons learned could be collected and even stored into the system, but in such a way that the system can not be used for retrieving knowledge in a reasonable way.
 

Process Connection Supports process improvement and organizational development. This can affect any of the processes.
 

References

Dixon, N.M. (2000). Common Knowledge: How Companies Thrive by Sharing What They Know. Harward Business School Press, Boston, Massachusetts.

Komi-Sirviö, S., Mäntyniemi, A. and Seppänen, V. (2002). Toward a Practical Solution for Capturing Knowledge for Software Projects. IEEE Software, vol. 19, no. 3.

Rus, I. and Lindvall, M. (2002). Knowledge Management in Software Engineering. IEEE Software, 19(3), 26-38.

 

Home
Catalog

Last changes at 24th July 2007