Wissensmanagement in Projekten

In einem Projektabschlussgespräch, das ich letzte Woche moderiert habe, gab es eine interessante Diskussion um Sinn oder Unsinn von „Lessons Learned“-Workshops. Der Tenor war: „Wir machen seit Jahren diese Workshops. Wir haben aber eigentlich allesamt nicht das Gefühl, dass sich dadurch irgendetwas geändert hat.“

Das kann durchaus sein. Lessons Learned (oder Wissenssicherung oder wie auch immer dieser Workshop lautet), macht nur dann Sinn, wenn das Unternehmen und die involvierten Mitarbeiter aus den Ergebnissen Konsequenzen ziehen. Ansonsten sind das, etwas brutal formuliert, nette Plauderrunden, auf denen man entweder mal dem Kollegen richtig die Leviten lesen kann oder sich gegenseitig auf die Schulter klopft, wie gut man das Projekt mal wieder gestemmt hat.

Das Ziel von Wissenssicherung oder auch Wissensmanagement allgemein ist es ja, entstandenes Wissen aus der gemeinsamen Arbeit und den gemachten Erfahrungen, wiederverwendbar zu machen. Auch und gerade dann, wenn andere Mitarbeiter in künftigen Projekt zusammenarbeiten.

Nach meiner Meinung gibt es für diese Umsetzung zwei Ansätze. Beide sind notwendig. Sie ergänzen sich.

  • Erfahrungen fließen in die permanente Verbesserung der Prozesse ein
  • Mitarbeiter mit ähnlichen Fragestellungen werden vernetzt, sodass Wissensträger ihr Wissen, ihr Können und ihre Erfahrungen weitergeben können.

Beispiel zu a): Im letzten Projekt ist der Kollege Müller mit dem Lieferanten A auf die Nase gefallen. Terminverzug, Qualitätsmängel und ein ewiges Gezerre wegen Nachforderungen.
Die naheliegende Konsequenz: Dieser Lieferant erhält keine Aufträge mehr.

Das greift natürlich viel zu kurz. Wenn es (wie in kleineren Unternehmen nicht unüblich) keine Lieferantendatenbank gibt, kann es durchaus sein, dass aus einem anderen Projekt heraus in einem Jahr wieder mit dem Lieferanten zusammengearbeitet wird. Und es nicht unwahrscheinlich, dass es in der Zusammenarbeit mit anderen Lieferanten zu ähnlichen Problemen kommt.

Die Konsequenz muss doch stattdessen sein, die Prozesse so zu verbessern, dass Fehler künftig grundsätzlich, also mit jedem Lieferanten vermieden oder verringert werden können. Dazu muss ich aber Arbeit in die Analyse stecken. Warum hatte der Lieferant Lieferverzug bei diesem Bauteil? Was waren die Ursachen für die Qualitätsprobleme? Dann kann ich im nächsten Schritt die Prozesse so verbessern, dass diese Probleme seltener auftauchen, früher erkannt werden usw. Verbesserte Prozessschritte können zum Beispiel die konsequente Erstellung eines formalen Lastenheft, die Abstimmung und Verfolgung von Meilensteinen mit dem Lieferanten und viele andere Punkte mehr sein.

Diese Prozessänderungen müssen dokumentiert werden, die Mitarbeiter müssen über die Änderungen informiert und ggf. geschult werden, die notwendigen Werkzeuge (z. B. die neue Vorlage für das Lastenheft) müssen zur Verfügung gestellt werden. Wenn die Verbesserungen konsequent umgesetzt werden, stellen sich schnell Verbesserungen ein. Da reibt sich so Mancher verwundert die Augen.

Zu Punkt b) ist schon viel geschrieben worden. Zum Beispiel auf dem Blog von Stefan Hagen. Sehr gute Präsentationen dazu gibt es auf Slideshare. Da wird sehr schön dargelegt, warum Wissensdatenbanken und häufig auch Wikis nicht funktionieren, und welche Möglichkeiten es dennoch gibt. Der Schlüssel liegt in der Vernetzung der Menschen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.