KM-A Wissen ist was wirkt
Skip navigation links
About KM-A
KM-Journal
KM-Community
KM-Team
KM-Downloads
Termine
Impressum
Kontakt
Kann WM in Projekten funktionieren? 
 

Summary
Tatsache ist, dass auch in der Projektumgebung die Beobachtungszyklen immer kürzer werden. Nicht nur, dass wir in immer kürzerer Zeit immer mehr erreichen müssen, so haben wir keine Zeit mehr Kollegen um deren Wissen zu befragen, geschweige denn während der Projektdurchlaufzeit auch noch Wissen zu externalisieren und damit zugreifbar zu machen. Dass dabei auch der Wissensarbeiter längst an seine Grenzen gestoßen ist, ist wohl kein Geheimnis. Wir, als „t4s-team for solutions“ und als Partner der KM-A haben uns dieser Herausforderung gestellt und wollen mit SharePoint und der individuellen Erweiterung des Business Framework „myBENgine“ eine Plattform schaffen, in der auch nebenbei Wissen im Projekt gesammelt wird. Letztendlich soll sich nicht mehr die Frage stellen: „Habe ich Zeit meine Säge zu schärfen – oder muss ich mit der stumpfen Säge weiterarbeiten?“


Warum Wissensmanagement ausgerechnet in Projekten umsetzen? Handelt es sich bei Wissensmanagement und Projektmanagement nicht um zwei Disziplinen, die in ihrem Kern schon widersprüchlich sind? Da werden die Projektmanager in langen Seminarreihen trainiert und dann in regelmäßigen Projektreviews dafür auch belohnt, dass das Arbeitspaket oder die Phase in noch kürzerer Zeit mit noch weniger Geld und somit noch höheren Deckungsbeiträgen abgeschlossen wurde. Wie soll sich da der Projektleiter noch Zeit nehmen für eine abschließende - wenn schon nicht begleitende, laufend aktualisierte, Dokumentation oder sogar für eine moderierte „lessons learned“ Sitzung? Können Sie sich als Projektteammitglied oder Projektleiter in die hier beschriebene Situation versetzen? Eine solche Abschlussbesprechung mit allen Projektteammitgliedern, um zu analysieren was denn in diesem konkreten Projekt gut oder schlecht gelaufen sei, fordert jetzt nicht nur Zeit, die in jedem Projektleiterverständnis sofort in Euro umgerechnet wird, sondern zusätzlich auch noch psychologisches Feingefühl, um hier keine nachträgliche Vergeltungsschlacht der nicht ausgetragenen Gefechte nachzuholen. Ich sehe aus meiner Praxis nachfolgend aufgelistete konkrete Fragestellungen, die sich Projektmanager in einer solchen Situation stellen:

  • Ist es nicht viel zu spät am Ende eines Projektes zu ergründen warum ein Arbeitspaket in Phase4 zu lange gedauert hat?
  • Wer sucht nach welchen Informationen im Projekt - und warum?
  • Wer profitiert von den im Projektabschluss gesammelten Informationen?
  • Welchen Vorteil hat der Projektleiter am Ende des Projektes davon - wo doch schon alles vorbei ist?
  • Nimmt sich auch der Projektauftraggeber Zeit dafür für eine derartige Besprechung? - und wenn ja – welchen Mehrwert bringt er aus strategischer Sicht ein?
  • Ist „lessons learned“ ein reiner Formalismus nur um das Gewissen zu beruhigen?
  • Ist es der Aufwand wirklich wert wenn jetzt – angenommen fünf Personen nochmals einen halben Tag zusammensitzen, um über Wissen und dessen Nutzung zu „philosophieren“?
  • Welche Veranlassung hat ein Projektmitarbeiter, der zu großen Erfolgen während der Projektdurchführung beigetragen hat, hier nochmals Zeit aufzuwenden? Ist dieser Mitarbeiter nicht schon längst so begehrt für das nächste Projekt, dass er mit solch einem „administrativen“ Aufwand nicht belästigt werden sollte?
  • Welches Interesse hat jener Mitarbeiter, der unabhängig von den wahren Gründen Verzögerungen in den ihm anvertrauten Aufgaben vermelden musste, an diesen Abschlussbesprechungen teilzunehmen?
  • Wo kann ein Projektmitarbeiter diese Stunden verrechnen?

Wer kennt sie nicht, all diese Vorbehalte in der von Zweiflern und Kritikern nur so wimmelnden Projektumwelt? Und doch behaupte ich, dass der Prozess der konstruktiven Auseinandersetzung und des Reviews eines Projektes von immensem Wert für das Unternehmen sein kann und die Durchführung auch möglich ist. Das Besondere dabei ist, dass entgegen dem Projektgeschehen die uns so geläufige Aktion-Reaktion-Wechselwirkung nur mit einer langen Verzögerung erfassbar wird. Um diese Wechselwirkung als solche wahrzunehmen, bedarf es einen Paradigmenwechsel. Die Anforderungen beim Projektabschluss unterscheiden sich dabei signifikant von den Anforderungen, die während der Projektdurchführung erfolgversprechend sind. Wenn während der Projektdurchführung der Fokus, bei den im Rahmen der Projektabgrenzung streng eingegrenzten Inhalten und Zielen liegt, so bedarf es jetzt diesen Blickwinkel zu verändern und „das Ganze“ zu sehen. Dieses „Ganze“ liegt dabei nicht mehr alleine in der Verantwortung des Projektleiters.

Wenn ich selbst Projektmanager trainiere dann werden sie auch weiterhin den Satz hören: „Der Projektmanager ist resultatsverantwortlich!“ Und genau an dieser Stelle des Projektes ist es notwendig diese Verantwortung auch mit der Organisation zu teilen. Jeder Projektmitarbeiter trägt hier die Verantwortung, dass Erfahrungen aus dem aktuellen Projekt dokumentiert werden, dass Wissen damit externalisiert wird und nach der Wissenstreppe von North auch der Organisation zur Weiterverwendung angeboten wird.


 
Wissenstreppe nach Klaus North, wissensorientierte Unternehmensführung, 2002


Bitte beachten Sie dabei, dass das Wissen jedes einzelnen Beteiligten im Projekt mit dem Entzug der Dimension „persönliche Erfahrung“ - die nicht weitergeben werden kann - sofort wieder auf die Ebene Information „degradiert“ wird. Die empfangene Person(1) kann dann diese Information als einen Baustein nutzen und mit Anreicherung der eigenen Erfahrungen und Werten zu wiederum neuem Wissen wachsen lassen. Konkret heißt das, dass der Projektleiter hier die Verantwortung trägt die im Projekt gewonnenen Erkenntnisse soweit als möglich zu dokumentieren. Dazu können Wissensmanagement-Methoden wie Lessons-Learned, Storytelling oder Worldcafe genutzt werden, damit die Beteiligten bei der Kommunikation ihrer Erfahrungen und persönlichen Erkenntnisse unterstützt werden können. Die reiche Erfahrung jedes Einzelnen wird aber leider durch den Versuch diese zu externalisieren auf ein Minimum reduziert, auf jenes Maß, das er gerade noch in die vorhandenen Formulare, Strukturen und moderierten „lessons learned“ hineinzwängen kann. Die Redewendung „kleinster gemeinsamer Nenner“ ist hier wohl mehr als angebracht. Jetzt könnten Sie als Leser die berechtigte Frage aufwerfen, ob die abschließende Dokumentation dann überhaupt Sinn macht, wenn festzustellen ist, dass
a) die Mitarbeiter kaum in der Lage sind die Erfahrungen festzuhalten und
b) diese wenige Information dann auch nicht sofort für neue Projekte umsetzbar ist, da diese erst wieder von der Organisation soweit umgestaltet werden muss, damit sie in neuen Projekten eingesetzt werden kann.

Wir von „t4s-team for solutions“ haben mit unserer jahrelangen Erfahrung als Unternehmensberater und im Speziellen im Bereich Projektmanagement, Prozessmanagement und Wissensmanagement diese klassische Konfliktsituation analysiert und Lösungswege aufgezeichnet. Bei unseren Analysen haben wir festgestellt, dass ein Großteil der Kommunikation im Projekt ineffizient mit dem „Planen planen“ verschwendet wird.

Lassen Sie mich die Situation an einem Beispiel erklären: Jeder kennt wohl die Situation, dass während einer Besprechung zwar viel diskutiert und analysiert wird, die dabei gesammelten Informationen werden aber wenn, dann auch nur bruchstückhaft in einem Besprechungsprotokoll zusammengefasst. In den meisten Fällen wird dies im Word erfasst und als Dokument an zentraler Stelle gespeichert. Wenn der Autor noch vor wenigen Jahren jedem Teilnehmer sein Eingangsverzeichnis angefüllt hat, so wird heute bereits in vielen Fällen ein „link“ zu einem zentralen Ablageplatz versendet. Unabhängig von der Form der Verteilung für die eine Zusammenfassung aller Sachverhalte in einem einzigen Dokument sehr effizient ist, wird durch die Speicherung dieser Sachverhalte in einem Dokument eine Art Gefangennahme der Informationen vorgenommen.

Wir haben uns im Geschäftsleben so an diese Art der Geiselhaft für Informationen gewöhnt, dass es uns schon gar nicht mehr auffällt in wie vielen Situationen des Arbeitsalltags wir unsere Informationen wegsperren. Lange geübte Vorgehensweisen, meist unterstützt durch den Einsatz von Dokumenten Management Systemen (DMS) haben ihr Übriges dazu beigetragen dem Benutzer einen effizienten Umgang mit Informationen abzugewöhnen. Klar strukturieren DMS die Ablage und den Zugriff auf die Dokumente und das war in der Weiterentwicklung unserer Arbeitsweise ein Meilenstein, der nächste Schritt in der Weiterentwicklung ist jedoch nicht das Verwalten der Dokumente, sondern das direkte Arbeiten mit den darin gespeicherten Informationen. Das gilt insbesondere im dynamischen Umfeld eines Projektes, bei dem es auf das effiziente Verarbeiten, Klassifizieren, und damit Auswerten von Informationen geht.

Meist jedoch erfolgt dies in folgenden Abläufen:

  • Besprechung-1:
    Jeder Teilnehmer schreibt eigenverantwortlich die ihm zugewiesenen Aufgaben auf und meldet bei der nächsten Besprechung den Fortschritt. Damit sind Aufgaben klar zugeteilt und der administrative Aufwand ist gering. Der Preis dafür ist, dass durch die persönlichen Informationsinseln die Möglichkeit der einheitlichen Verschlagwortung der Information als Grundlage für standardisierte Auswertungen nicht realisiert wird und damit der Gesamtüberblick verloren geht. So werden ggf. die wichtigsten Aufgaben, die vom Projektleiter als projektrelevant eingestuft werden, im Besprechungsprotokoll dokumentiert.
  • Besprechung2:
    In der nächsten Controllingsitzung werden dann die offenen Punkte des Meetings durchgearbeitet und nach einem Fortschritt abgefragt. Hinweisen möchte ich auch auf die damit meist implizit gegebene Diskrepanz zwischen den unterschiedlichen Aufgabenlisten (siehe Skizze-1).

.
 
Skizze-1: Verwendung unterschiedlicher Aufgabenlisten

Mit jedem neuen Dokument erhöht sich die Fehlerquote und so bedarf es eigener Strukturen für die Verwendung von Filenamen und deren Versionierung. Ich darf Ihnen nachfolgend ein Beispiel eines Excel Dokuments übermitteln mit dem wir im Projekt - KEINE – Protokolle mehr erstellen, sondern jede Aufgabe einzeln dokumentiert wurde.  Diese Tabelle wurde dann an zentraler Stelle im Projekt abgespeichert und diente uns als ersten Schritt auf dem Weg zur heutigen Sharepoint Lösung. In jeder Controllingsitzung konnten wir so einen nachvollziehbaren Status aktualisieren. Zusätzlich wurde daraus ein Gesamtprotokoll pro Controllingsitzung erstellt.

Die Aufgaben, die während der Besprechung jedem einzelnen zugewiesen wurden, werden von jedem selbst in seiner persönlichen Aufgabenplanung verwaltet. Dazu werden Listen in Notizbüchern erstellt, oder im Outlook Aufgaben verteilt, oder schnell mal Aufgaben und Termine in den Blackberry getippt. Diese Aufgaben haben aber keinerlei Zusammenhang mit dem zeitgleich erstellten Besprechungsprotokoll oder den Entwicklungen und Veränderungen im Projekt. Entweder sind Informationen schon während der Finalisierung des Besprechungsprotokolls veraltet oder es wird anschließend in einer Mail-Konversation oder dem vorher definierten Genehmigungsprozess des Besprechungsprotokolls über einzelne Details weiter verhandelt. Ist diese Art der Zusammenarbeit jedoch noch zeitgerecht?
 

 

 
Wir von „t4s – team for solutions“ haben dazu die klare Antwort, die da lautet: „Entsperren Sie Information vom Dokument – Organisieren Sie sich auf Informationsebene! Schaffen Sie die Basis für ein weitgehend automatisiertes Wissensmanagement!"

 

Um diese Ziele zu erreichen haben wir folgende Lösung konzipiert:

Plattform:
Auf Basis unserer mehr als 25jährigen Erfahrung mit Dokumenten Management und Vorgangsbearbeitungssystemen und dem eigenen Einsatz diverser Plattformen für eigene Produkte wie (Oracle, Informix, Notes/Domino, Java, ..) haben wir uns unter anderem aufgrund der hohen Integration mit den Office Produkten, den umfangreichen Integrationsmöglichkeiten in externe Datenquellen, der Suchfunktion und Möglichkeit der Programmierung für das Mainstream Produkt SharePoint entschieden.

Struktur:
SharePoint verfügt über  alle wesentlichen Grundstrukturen um Informationen, und Dokumente verwalten, bearbeiten und auswerten zu können. Wir haben die Erfahrung gemacht, dass wir uns durch den Einsatz von SharePoint wieder auf das Wesentliche, unseren Geschäftszweck konzentrieren können und nicht in der Ebene IT stecken bleiben.

Funktion:
SharePoint stellt zwar alle wichtigen Grundfunktionen zur Verfügung, ist aber selbst nur ein Baukasten und wir sind selbst dafür verantwortlich diesen so einzusetzen, dass wir unsere Geschäftsvorfälle bzw. –anwendungen bestmöglich abbilden können. Das bedeutet, dort wo etwas fehlt oder nicht entspricht wird erweitert. So auch im Projekt- und Wissensmanagement.

Unsere Erweiterung heißt myBENgine und ist ein Business Framework das aus dem SharePoint eine Unternehmensplattform macht und alle wesentlichen Erweiterungen in Form von Modulen enthält. Als Basis für das Projektmanagement setzen wir den „Responsibility Workflow“ ein. Aufgaben, Projektaktivitäten, Vorgänge können so auf der Informationsebene bearbeitet und verwaltet werden und ergänzen die Logik des Zusammenarbeitens um die Zuordnung der Verantwortlichkeit und der Kenntnisnahme. Jeder Mitarbeiter erhält die Funktionalität „myWorkspace, Mein Arbeitsbereich“. Eine Schattenverwaltung in diversen anderen Systemen oder Lösungen entfällt.

Das Arbeiten auf Informationsebene ermöglicht zum einen die Klassifizierung, bzw. Taxonomie der Information effizient in den Arbeitsablauf zu integrieren und die so entstandene Informationsbasis besser auszuwerten.

Jedes Arbeitspaket kann so gemanagt werden, dass alle relevanten Informationen oder zugehörige Dokumente immer aus dem Blickwinkel dieser Aufgabe gesehen werden. Haben wir durch den Fokus der Bearbeitung auf der Informationsebene die Effizienz in der Zusammenarbeit und die Auswertbarkeit des aktuellen Status erhöht, so zahlen wir dies durch den Verlust an historischem Wissen. Trotz Versionierungs-Funktionalität auf Ebene der Sachverhalte / Informationen verkomplizieren sich Auswertungen mit der Fragestellung „Was hat sich seit der letzten Besprechung verändert?“. Für Vergleiche, Analysen der Veränderung sind Dokumente wiederum sinnvoll einzusetzen. Dokumente stellen dabei einen Snapshot der Information zu einem definierten Zeitpunkt dar. z.B.: werden parallel zur Verarbeitung eines Protokolls auf Listen Basis, jeweils automatisch ein Gesamt-Status zum Zeitpunkt der Besprechung als Dokument erzeugt. Die Qualität in der Aussage eines solchen Dokuments wird dabei deutlich besser sein, da die Veränderung zur vorhergehenden Besprechung automatisch umsetzbar ist. (Welche Protokollpunkte / Aufgaben wurden seit dem letzten Mal dazugenommen, welche sind neu, bei welchen Aufgaben droht nunmehr Fristüberschreitung, etc.)

Überträgt man dieses Prinzip der Datenhaltung auf Informationsebene so ergeben sich einige Lösungsansatz für das Projektmanagement.

SharePoint bietet mit seinen technischen Funktionen - Verwaltung von standardisierten Inhaltstypen (Informationstypen), dem Verwalten von Listen und Bibliotheken, der Taxonomie und Verschlagwortung, Workflow Standards, den zugehörigen Benutzerfunktionen - eine gute Ausgangsbasis, schon während des laufenden Projekts, Information so aufzubereiten, das diese am Projektende einfach ausgewertet werden können.

Werden diese SharePoint Standard Funktionen, durch ein Business Framework wie myBENgine ergänzt so kann auch die inhaltliche Sicht auf die verwalteten Informationen standardisiert und damit die Aufbereitung und Auswertung weitestgehend automatisiert werden. Wir sprechen gern im Rahmen des Business Frameworks von Micromanagement, das alle Informationen auf einem hohen Detailierungsgrad beinhaltet, ohne mit zusätzlichem Arbeitsaufwand bezahlen zu müssen. Wir integrieren dabei standardisierte Prozesse und Dokumentvorlagen des PMI, IPMA oder PRINCE-2 in den täglichen Arbeitsauflauf und ermöglichen damit die Datenerfassung in einem SharePoint basierten Repository.

Die Dokumente dienen dabei als gewohnte Formatvorlagen, jedoch die Informationen werden in einem Repository gehalten und erfüllen entgegen der dokumentenorientierten Variante alle Voraussetzungen für eine Auswertung im Sinne des Wissensmanagements. Diesen im SharePoint gespeicherten Projektdetails können mit dem „Responsibility Workflow“ jederzeit „Owner“ zugewiesen werden. Darüber hinaus ermöglicht das Berechtigungskonzept, dass jeder Mitarbeiter nur die für ihn relevante Informationen erhält. Bei MS Project kann der Detailierungsgrad der Planung damit auf einer höheren Ebene abgebrochen werden, da die Projekterfahrung zeigt, dass eine zu große Verfeinerung nur den Pflegeaufwand der Projektpläne unnötig erhöht, bzw. vielfach dieser nicht mehr zu leisten ist. Micromanagement ermöglicht die Generierung der Informationen aus dem Arbeitsablauf heraus, der Verbesserung der Kommunikation mittels klarem Verantwortungsübergang und der standardisierten Auswertung der so gewonnen Informationen.

Zusammenfassend möchte ich bemerken, dass durch die Umstellung der Datenbasis von Dokumenten zu informationsbasierten Systemen bzw. dem Einführen von Micromanagement im Rahmen eines Business Frameworks wie myBENgine eine gute Grundlage geschaffen werden kann, um das Wissensmanagement in Projekten auf eine neue Basis zu stellen und den Widerspruch von Kosten zu Nutzen deutlich zugunsten des Wissensmanagement ausfallen zu lassen.


Literatur
(1) Klaus North: Wissensorientierte Unternehmensführung, Wiesbaden 2002

 

Informationen zum Autor:

Robert Peszt ist Partner der KM-A und Referent der KM-Academy. Er arbeitet als Berater und Trainer im Bereich Projekt-, Prozess-, und Wissensmanagement. Durch seine Erfahrung in diversen nationalen und internationalen Projekten kennt er die Herausforderungen um Wissensmanagement im projektorientierten Untenehmen zu etablieren.

Robert Peszt gründete 2010 mit Partnern das Unternehmen „t4s – team for solutions“. Das Unternehmen entwickelt das Businessframework „myBENgine“ basierend auf Microsoft Sharepoint. Das Ziel ist es mit Hilfe von Entwicklungspartnern und mit wissenschaftlicher Beratung die Anforderungen aus dem Prozess- und Projektmanagement in diesem Framework umzusetzen um auf einer einheitlichen Plattform unterschiedliche Managementebenen des Unternehmens zu unterstützen.