P R O J E K T M A N A G E M E N T 4 / 2 0 0 0 32 lagen Wissen, das in Projekten wieder verwandt wird, und durch Befragungen von erfahrenen Mitarbeitern und Analyse der Routinetätigkeiten kann Wissen während der Projekte erhoben werden. Der Transfer von Wissen und Erfahrungen aus der Projektarbeit in die (anschließende) Routinetätigkeit ist im Projektmanagement ausdrücklich vorgesehen und etabliert: Die Produktdokumentation übernimmt diese Rolle, sei es beispielsweise in Form von technischen Zeichnungen, die als Teil des Projektergebnisses an die Produktion übergeben werden, oder sei es in Form eines Benutzer- und Bedienerhandbuchs bei einer neuen Software, in dem Handhabungswissen für zukünftige Benutzer und Systemadministratoren niedergelegt ist. Ebenso wichtig und wünschenswert ist der Transfer von Wissen und Erfahrungen aus vorhergehenden Projekten. Zwei Beispiele mögen die folgende Argumentation illustrieren. Ein Unternehmen entwickelt in einem Projekt ein neues Material oder eine neue Materialzusammensetzung. Während der Projektarbeit kommt der Kontakt zu einem Forschungsinstitut im Ausland zu Stande, das auf diesem Gebiet arbeitet, und es entsteht eine sehr fruchtbare Kooperation. Die Zusammenarbeit ist für das Projekt im Unternehmen sehr wertvoll, weil die Arbeitsgebiete des Forschungsinstituts einen hohen Deckungsgrad zum Projektauftrag aufweisen, gemeinsame Sprachkenntnisse die Kommunikation erleichtern, das Institut auf Anfragen offen und zügig reagiert und kleinere Forschungsaufträge an das Institut kompetent, schnell und termingerecht ausgeführt werden. Zudem wird ein Modus zur Kompensation der Aufwendungen gefunden, der beide Seiten zufrieden stellt. Doch was geschieht am Ende des Projektes innerhalb des Unternehmens mit dem Wissen über diesen Kontakt und die Ansprechpartner sowie den Erfahrungen der Zusammenarbeit? Wie erfahren nachfolgende Projekte mit ähnlicher Aufgabenstellung davon? In der Regel bleiben bezüglich der externen Kooperationspartner das Wissen über Personen, Spezialkenntnisse, technische Einrichtungen, Kommunikationswege usw. sowie die Erfahrungen zu Arbeitsweisen, Antwortzeiten, Sensibilitäten usw. in den Köpfen der Projektmitarbeiter verborgen und werden nicht systematisch ausgewertet und weitergeleitet. Zweites Beispiel: In einem Projekt wird das neue Release einer Software zum Projektmanagement eingesetzt. Die Änderungen des Releases gegenüber der im Unternehmen bekannten Version sind erheblich und lösen umfangreichen Einarbeitungsaufwand und Änderungen an Standardvorgaben aus. Einige Funktionen der neuen Software stellen sich nach einiger Zeit als unbrauchbar heraus, andere sind erst durch spezielle Tricks bei der Benutzung sinnvoll zu nutzen. Während der Projektarbeit werden also Wissen und Erfahrungen in erheblichem Umfang zu diesem neuen Software-Release aufgebaut. Wie erfahren Mitarbeiter nachfolgender Projekte davon und können so davon profitieren? In der Regel bleiben dies Handhabungskenntnisse einzelner Projektmitarbeiter. Traditionelle Transfermethoden zwischen Projekten greifen oftmals zu kurz: Projekthandbücher sind selten aktuell und spielen meist die Rolle von „Schrankware“, Checklisten sind generisch und decken kaum Details ab, nur zufällig ist einer der in dieser speziellen Sache erfahrenen Mitarbeiter aus vorhergehenden Projekten wiederum Projektmitglied usw. Die beiden geschilderten Beispiele verdeutlichen, dass diese Methoden in vielen Situationen untauglich sind. Nur für wenige Teilbereiche wie die Weitergabe von Erfahrungswerten zur Aufwandsschätzung sowie die Nutzung von Standard-Templates bei der Netzplantechnik haben sich Transfermethoden etabliert [2, S. 436 ff.]. Abb. 2: Wissen und Erfahrungen als Input und Output von Projekten 33 3 DOKUMENTATION ENTHÄLT SELTEN „LESSONS-LEARNED“ Die Dokumentation von Projekten hält nur selten Wissenswertes für nachfolgende Projekte bereit. Die Produktdokumentation (Zeichnungen, Arbeitsanweisungen, Benutzerhandbuch, Systemhandbuch …) hat als Zielgruppe die zukünftigen Anwender, Benutzer oder Betreiber des Ergebnisses von Projekten. Die Projektdokumentation (Projektauftrag, Projektpläne, Terminpläne, Kostenübersichten, Fortschrittsberichte, Sitzungsprotokolle …) dient vor allem der Kommunikation während der Projekte und hat als Zielgruppe die Mitarbeiter und das Management der Projekte und die Mitglieder von Kontroll- und Aufsichtsgremien. Selten ist eine Dokumentation vorgesehen, die sich an Mitarbeiter zukünftiger Projekte wendet. Diese Dokumentation stellt Methoden und Vorgehensweisen dar, schildert konkrete Probleme, beschreibt erfolgreiche und erfolglose Lösungsans ätze, nennt Ansprechpartner und externe Experten, enthält Schilderungen erfolgreicher Kooperationen und deren Erfolgsfaktoren, überliefert Handhabungstricks etc. In diesem Sinne wären Beschreibungen der „Lessons- Learned“ für nachfolgende Projekte wertvoll. Jedoch geht derartiges Erfahrungswissen mangels geeigneter Identifikation und Aufbereitung oftmals verloren [6, S. 8]. Ebenso wäre oft hilfreich, Mitarbeiter vorheriger Projekte gezielt finden und befragen zu können. Dies mag in kleineren und mittleren Unternehmen noch ohne Regelungsaufwand funktionieren. In größeren Unternehmen muss jedoch davon ausgegangen werden, dass zum Beispiel die Mitarbeiter eines Projektes ein Jahr nach Projektende nur mit erheblichem Aufwand identifiziert und ihre jetzigen Arbeitsplätze innerhalb eines Unternehmens herausgefunden werden können. 4 BARRIEREN ERSCHWEREN WIS- SENS- UND ERFAHRUNGSAUSTAUSCH Projektarbeit steht fast immer unter Zeitdruck, termingerechte Projektabschlüsse haben z. B. bei der Softwareerstellung Seltenheitswert. Daher muss oftmals die Fertigstellung des Produkts als Ende des Projekts angesehen werden, sich anschließende, notwendige Nacharbeiten zur Identifikation und Aufbereitung von Wissen und Erfahrungen müssen wegen aufgebrauchter Zeitressourcen entfallen. Projektmitarbeiter werden zudem nachdrücklich für Folgeprojekte angefordert; oftmals lösen sich so Projektgruppen sukzessive auf, ohne dass alle Projektbeteiligten systematische Nacharbeit und Dokumentation von Wissen und Erfahrungen betreiben können. Zudem bestehen erhebliche individuelle und soziale Barrieren, Wissen und Erfahrungen aus Projekten zu artikulieren und zu dokumentieren [3]. So wären zum Beispiel Analysen von Fehlschlägen, Irrtümern und Irrwegen besonders wertvoll, oftmals fehlt jedoch eine offene und konstruktive Atmosphäre, um diese zu artikulieren und zu analysieren. Mitarbeiter scheuen das Eingeständnis und Ansprechen von Fehlern, da sie negative Auswirkungen für sich fürchten. Oder: Offensichtlich haben andere Mitarbeiter des Unternehmens zu einem späteren Zeitpunkt den Nutzen einer derartigen Erfahrungssicherung und -dokumentation. Weitreichende Synergien entstehen erst, wenn sich alle Mitarbeiter an diesem Austausch beteiligen. Dieses Nutzenversprechen ist jedoch für den einzelnen Mitarbeiter oft zu vage und abstrakt („Was habe ich davon? “) und löst keine ausreichende Motivation zur Dokumentation von „Lessons-Learned“ aus. Auch wird dieser Dokumentation nicht genug Anerkennung in den Unternehmen zugemessen. Erfahrungssicherungspläne, wie etwa von Burghardt in seinem Standardwerk vorgeschlagen [2], werden nur selten aufgestellt. Warum sollen Mitarbeiter die Erfahrungssicherung für wichtig halten, wenn dafür noch nicht einmal in der Projektplanung explizit und ausreichend zeitliche Ressourcen vorgesehen werden? Für das Management der Unternehmen ergeben sich damit wichtige Aufgaben: Etablieren von Projektphasen der Identifikation und Sicherung von Wissen und Erfahrungen, vorbildhaftes Wirken bei der Sicherung von Wissen und Erfahrungen, Schaffen einer offenen und konstruktiven Atmosphäre zum Wissensaustausch, Motivation der Mitarbeiter zum Engagement beim Wissensaustausch [9]. Im Folgenden werden einige Maßnahmen vorgestellt, die den Wissensaustausch zwischen Projekten forcieren können. 5 MASSNAHMEN 5.1 Erfahrungssicherungsplan und Reflexion Schon während der Planung eines Projektes sind am Ende Arbeitsschritte und Zeitkontingente vorzu- P M - M E T H O D E N / I N S T R U M E N T E P R O J E K T M A N A G E M E N T 4 / 2 0 0 0 34 sehen, die dezidiert Aufgaben der Wissens- und Erfahrungssicherung zugeordnet werden. Dabei ist z. B. festzulegen, wer dafür zuständig ist, auf welchen Gebieten neues Wissen erwartet wird, wie Erfahrungen zu dokumentieren, zu speichern und zu archivieren sind [2, S. 435-436]. Damit rückt die Phase des Projektabschlusses in den Mittelpunkt der Anstrengungen um eine systematische Aufbereitung des in Projekten neu aufgebauten Wissens [8, S. 13]. Bezeichnungen wie „Experience Retention“ und „Debriefing“ [1, S. 11] weisen darauf hin, dass diese Phase eine wichtige Gelegenheit darstellt, um Wissen und Erfahrungen der Projektmitarbeiter aufzunehmen und zu sichern; beispielsweise soll BP entsprechende systematische Projektschritte erfolgreich im Zuge eines Wissensmanagements eingeführt haben [5, S. 19]. Fragen, die diesen Prozess initiieren, können etwa lauten: ● Wie ist das Projekt in den verschiedenen Phasen gelaufen: Planung, Analyse, Konzept, Umsetzung, Implementierung? ● Welche Faktoren waren für die Akquisition eines (Kunden-)Projektes erfolgskritisch? ● Wo waren wir gut, was würden wir aus heutiger Sicht anders machen? ● Wo waren besondere „Klippen“ im Projektverlauf, wie haben wir sie umschifft? ● Wie war die Kommunikation zwischen den Projektmitgliedern? Was hat den Projektverlauf gefördert, was gehemmt? ● Wie können wir bei künftigen Projekten Planung/ Steuerung/ Kontrolle verbessern? ● Welche Erfahrungen können wir wie aus diesem Projekt an andere weitergeben? Somit wird eine Reflexion des Projektverlaufs eingeleitet, deren offener und konstruktiver Verlauf durchaus nicht selbstverständlich ist. Manche Erfahrungen aus einem Projekt werden kritisch zu betrachten sein, so dass die Beteiligten die notwendige Distanz zu einer Reflexion aufbringen müssen und zum Beispiel Schuldzuweisungen zu vermeiden sind. Um die besonders wichtigen Lerneffekte aus kritischen und problematischen Projektsituationen auslösen und umsetzen zu können, ist von den Führungskräften eine entsprechende vertrauensvolle und offene Arbeitsatmosphäre zu erzeugen und zu sichern. 5.2 Sammlung von Lessons- Learned Eine wichtige Möglichkeit, die Ergebnisse derartiger Reflexionsphasen festzuhalten, bieten so genannte „Lessons-Learned“. Diese Darstellungen enthalten die ausführliche und detaillierte Dokumentation der Identifikation und Lösung konkreter und abgegrenzter Problemstellungen, die als modellhaft für Folgeprojekte angesehen werden. So werden etwa technische Fragestellungen, organisatorische Konstellationen oder soziale Situationen, die in Projekten auftreten und deren Handhabung im Nachhinein - während der Reflexion - als erfolgskritisch angesehen werden, detailliert beschrieben. Neben dem erfolgreich realisierten Lösungsweg zur Bewältigung werden ebenso gegebenenfalls missglückte Lösungsans ätze oder Lösungsans ätze, die nicht für eine Realisierung ausgewählt wurden, beschrieben. Dabei wird bei der Dokumentation von Lessons-Learned darauf Wert gelegt, dass für erfolgreiche wie erfolglose Lösungen genauestens die Problemsituation geschildert und der Kenntnisstand über Gründe und Folgen des Handelns wiedergegeben wird. Dies soll Mitarbeitern von Folgeprojekten die Möglichkeiten geben, dieses Wissen aufzunehmen und unmittelbar oder - durch Übertragung auf ähnliche Situationen - mittelbar nutzbringend einzusetzen. Zudem können diese Dokumentationen als Fallstudien zu Schulungszwecken eingesetzt werden. Durch die detaillierte Beschreibung der Problemsituation und die ausführliche Darlegungen erfolgreicher wie erfolgloser Lösungsans ätze gelten Lessons-Learned als eine Möglichkeit, implizites Wissen zu erschließen und niederzulegen. Derartiges implizites Wissen wird überwiegend durch Erfahrungen erlangt und ist eingebettet in individuelle Denkmuster und Verhaltensweisen. Dieses Wissen ist damit stark von den Individuen abhängig, die es aufgebaut haben und besitzen. Es ist schwer zu kodifizieren und zu dokumentieren sowie an andere Mitarbeiter zu übertragen. Im Gegensatz dazu ist explizites Wissen leicht zu kodifizieren und daher z. B. in Arbeitsanleitungen oder Lehrbüchern zu finden. Lessons-Learned stellen einen Weg dar, implizites Wissen zu externalisieren und damit zumindest teilweise zu explizitem Wissen umzusetzen, das sich beispielsweise in Form von Dokumentationen erhalten und weitergeben lä sst [7]. 35 5.3 Sammlung von Projektprofilen Standardisierte Projektprofile („Projektsteckbriefe“), die zum Projektabschluss zur Ergänzung der traditionellen Dokumentation erstellt werden müssen, können Wissen und Erfahrungen zumindest schlagwortartig und zusammenfassend aufnehmen. Diese Profile können dann mithilfe einer Datenbank und Suchmaschinen Mitarbeitern zukünftiger Projekte zur Verfügung gestellt werden, die über Deskriptoren oder im Volltext suchen können. Beispielsweise können bei Software-Entwicklungsprojekten in Projektprofilen Merkmale abgelegt werden wie: Entwicklungsumgebung und Einsatzumgebung der Software (Hardware, Systemsoftware), eingesetzte Entwicklungstools, beteiligte Stellen und Unternehmensbereiche, Funktionsbereiche, Anwendungsgebiete, Umfang Datenbasis, beteiligte Mitarbeiter usw. Insgesamt entsteht damit eine systematische Sammlung von Projektprofilen, die nachfolgenden Projekten einen Fundus an Wissen und Erfahrungen bereitstellen oder zumindest die Möglichkeit bieten, gezielt auf Wissensträger zuzugehen. 5.4 Yellow Pages Ein anderer Ansatz greift das Problem auf, dass nach dem Ende von Projekten die Mitarbeiter nur noch mit großem Aufwand identifizierbar und kontaktierbar sind. Dies verhindert Ad-hoc-Nachfragen an diese Mitarbeiter aus nachfolgenden Projekten, in denen ähnliche Frage- oder Problemstellungen auftauchen. Daher werden Personenregister aufgebaut, in denen den Mitarbeitern ihre Projektzugehörigkeiten sowie die Schwerpunkte ihrer Projektaufgaben zugeordnet werden. Außerdem werden Angaben zu weiteren Kenntnissen, Fähigkeiten und Merkmalen den Mitarbeiterangaben hinzugefügt (Sprachkenntnisse, Erfahrungen mit speziellen Verfahren, Materialien oder Maschinen, Mitgliedschaften in Netzwerken und Vereinigungen usw.), so dass interne Yellow Pages entstehen (oder: Expertenregister, Werweiß-was-Datenbank). Diese könnte bei Bedarf nach Deskriptoren oder Stichworten durchsucht werden, um schnell einen Ansprechpartner zu einer spezifischen Fragestellung zu finden. Sinnvollerweise werden die Personendaten ergänzt um Daten zu Kommunikationswegen (derzeitiger Arbeitsplatz, Telefonnummer, E- Mail-Adresse …), um eine schnelle und unbürokratische Kontaktaufnahme zu unterstützen. Informationstechnik dient neben der Unterstützung der Verzeichnisfunktionen vor allem der Unterstützung der direkten Kommunikation zwischen Mitarbeitern etwa via Telefon, Bildtelefon, Fax, E-Mail, Videokonferenz, Diskussionsforen, Chat u. Ä. Möglicherweise können in eine derartige Datenbank auch externe Wissens- und Erfahrungsträger aufgenommen werden (z. B. Lieferanten, Berater, ehemalige Mitarbeiter), wenn eine Kontaktaufnahme im Problemfall mit ihnen möglich und gewünscht ist. Der Aufbau von Yellow Pages folgt einer Strategie der Personalisierung, nach der für ein Unternehmen wichtiges Wissen sehr stark an die Personen geknüpft ist, die es aufgebaut und entwickelt haben; dieses implizite Wissen kann zuvorderst über direkte und persönliche Kommunikation ausgetauscht werden [4]. Nach dieser Strategie wird Wissen nicht primär in Dokumenten oder Dateien gesammelt, aufbereitet und verfügbar gemacht, sondern vor allem die direkte Kommunikation zwischen Wissensnachfrager und Wissensanbieter zum Wissensaustausch angestrebt und unterstützt. Dies wird durch Expertenregister forciert, die Auskunft geben, wer in einem Unternehmen zu welchen Themen kompetent Auskunft geben kann. Akzentuiert ausgedrückt geht es bei dieser Strategie der Personalisierung „eigentlich“ gar nicht um das Management von Wissen, sondern um das Management der Kommunikation zwischen Wissenden. Der Aufbau von Yellow Pages ist mit keinem großen Aufwand verbunden, der Nutzen wird im Unternehmen jedoch relativ schnell sichtbar werden. Oftmals bietet sich eine Einbindung in ein unternehmensinternes Intranet an. Allerdings muss bei der Umsetzung ein Konzept für die laufende Ergänzung und Pflege der Einträge vorgesehen werden, da dies für die Qualität der Daten entscheidend ist. 6 FAZIT Projektorganisation wird in Unternehmen immer häufiger eingesetzt, um schnell und flexibel auf innovative und interdisziplinäre Fragestellungen zu reagieren. Projekte gelten zudem als besonders lernintensive Organisationen. Jedoch sind Projekte temporäre Organisationen, nach Projektende sind Unterlagen und Ansprechpartner nur schwer erreichbar. Daher gilt es für Projekte besonders, P M - M E T H O D E N / I N S T R U M E N T E P R O J E K T M A N A G E M E N T 4 / 2 0 0 0 36 durch gezielte Maßnahmen neues Wissen und neue Erfahrungen zu identifizieren, aufzubereiten und zu verteilen. Erfolg versprechende Maßnahmen setzen vor allem beim Projektabschluss an, währenddessen ausdrückliche und bewusste Schritte der Reflexion des Projektgeschehens - insbesondere der Identifikation und Darstellung von „Lessons-Learned“ - intensiviert werden müssen. Dabei ist von den Führungskräften eine Arbeitsatmosphäre zu sichern, die eine offene und konstruktive Diskussion erlaubt. Daneben können systematische Sammlungen von Projektsteckbriefen und von Ansprechpartnern für Fachthemen die Wiederverwendung von Wissen im Unternehmen unterstützen. ■ Literatur [1] Backof, M. B./ Hartman, C.: Changing the Future of World. In: Knowledge Edge 1/ 1999, S. 11 [2] Burghardt, M.: Projektmanagement - Leit faden für die Planung, Überwachung und Steuerung von Entwicklungsprojekten. 4. Aufl., Siemens, München 1997 [3] Disterer, G.: Social Barriers for Knowledge Databases in Professional Service Firms. In: Khosrowpour, M. (Hrsg.): Challenges of IT- Management in the 21st Century - Proc. IRM A 2000 Conference. Idea, Hershey-London 2000, S. 1088-1089 [4] Hansen, M. T./ Nohria, N./ Tierney, T.: What‘s Your Strategy For Managing Knowledge. In: Harvard Business Review 2/ 1999, S. 106-116 [5] Hartman, C. P.: Interview with Michael Earl: CKOs - Who Are They and What Do They Do? In: Knowledge Edge 1/ 1999, S. 16-21 [6] Heisig, P.: Erfahrung sichern und Wissen transferieren: Wissensmanagement im Projektmanagement. In: PROJEK TM ANAGEMENT 4/ 98, S. 3-10 [7] Nonaka, I.: A Dynamic Theory of Organizational Knowledge Creation. In: Organization Science 2/ 1994, S. 14-37 [8] Saynisch, M.: Wissensmanagement im PM tut not - aber so einfach ist das nicht! In: PROJEK TM ANAGEMENT 4/ 98, S. 11-13 [9] Steinle, C./ Eickhoff, M./ Vogel, M.: Vitalisierung von Unternehmen durch organisationales Lernen in Projekten. In: Steinle, C./ Eggers, B./ Thiem, H./ Vogel, B. (Hrsg.): Vitalisierung. FA Z, Frankfurt 2000, S. 277-293 Autor Georg Disterer ist Professor für Wirtschaftsinformatik am Fachbereich Wirtschaft der Fachhochschule Hannover. Seine Lehr- und Forschungsgebiete umfassen Informationsmanagement, Projektmanagement, Wissensmanagement; sein beruflicher Werdegang schließt langj ä hrige Stationen als Unternehmensberater und als Verwaltungsdirektor ein. Anschrift Fachbereich Wirtschaft Fachhochschule Hannover Ricklinger Stadtweg 120 D -30459 Hannover Tel.: 05 11/ 92 96-6 51 Fax: 05 11/ 92 96-6 60 E -Mail: georg.disterer@wirt.fh-hannover.de 37 Zusammenfassung Am Ende jeder Projektbesprechung stehen Ergebnisse und Entscheidungen. Moderation ist das Werkzeug, das Sie dabei unterstützt, dieses Ziel zu erreichen: Mit Moderation kommen Sie zeitsparend zu Ergebnissen und Entscheidungen. Als Moderator behalten Sie die Übersicht: Die Diskussionen sind zielorientiert. Es werden keine Punkte vergessen. Voraussetzung für effektive Moderation ist die Kenntnis der Moderationsregeln und Erfahrung in Team-Kommunikation und Visualisierung. Misserfolge in Projektbesprechungen sind das Ergebnis mangelnder Kenntnisse in den „soft facts“. Deshalb sollte jeder Projektleiter seine Moderationsfä higkeiten entwickeln. Abstract The aim of each project meeting is to get results and decisions. Presentation is the tool that supports you to achieve this goal: Presentation helps you to results and decisions without waste of time. The presenter has the overall view: Discussions are single-minded. Points won’t fall into oblivion. Requirement for effective presentation is the knowledge of the presentation rules, experience in team communication and in visualisation. Failures in project meetings are the outcome of lacking knowledge in “soft facts”. Therefore each project leader should develop his presentation abilities. Schlagwörter Ablauf, Abschluss, Maßnahmenplanung, Moderationsregeln, Tagesordnung(spunkte), Themenbearbeitung, Vereinbarungen, Ziel 1 DIE SITUATION: UNBEFRIEDIGEND Neun Personen sind voller Begeisterung dabei. Die Ideen sprudeln, kaum kann der Erste aussprechen, da fällt schon der Nächste ihm mit einem neuem Einfall ins Wort. Alle sind davon überzeugt: Das Projekt „Unser erster Messeauftritt“ wird der Hit! Für den Messestand gibt es schon drei Vorschläge, als Aufmerksamkeitserreger liegen eine Produkt- Show auf Großleinwand, ein sprechender Roboter und ein Schnellzeichner als Ideen auf dem Tisch - gut, dass die Sekretärin mitschreibt! Nach eineinhalb Stunden trennt man sich, geht gut gelaunt auseinander: „Prima, wie gut wir uns verstehen, wie kreativ wir gemeinsam sind. Wir sind eben einfach ein tolles Team! “ Die ersten Zweifel beschleichen die Sekretärin, als sie das Protokoll schreibt. Wer ist jetzt eigentlich wofür verantwortlich? Und bis wann soll was erledigt sein? Es sind ja nur Vorschläge P M - M E T H O D E N / I N S T R U M E N T E So machen Ihre Projektbesprechungen Sinn! Von rituellen Routineveranstaltungen zu Ergebnissen und Entscheidungen U L R I K E W I K N E R P R O J E K T M A N A G E M E N T 4 / 2 0 0 0 38 da und noch keine Entscheidungen! Und sollten nicht auch Einladungen an Kunden und Geschäftspartner geschrieben werden? Darüber wurde ja noch gar nicht gesprochen! 2 DIE URSACHEN: ALTBEKANNT Die Unzufriedenheit über Projekt- Meetings ist weit verbreitet. Nur die Hälfte aller Projektbesprechungen werden als nützlich und effizient empfunden. Die Gründe für die Unzufriedenheit sind vielfältig: ● Einladungen sind ungenau oder nichts sagend, ● die Tagesordnung ist überfrachtet oder nicht strukturiert, ● während der Sitzung schweifen einzelne Teilnehmer ab, andere wiederum halten Monologe, ● Teilnehmer, die sich während der Besprechung passiv verhielten, identifizieren sich nicht mit den Ergebnissen und behindern Entscheidungen oder „karten nach“, ● es werden keine Entscheidungen getroffen, ● die Entscheidungen werden nicht oder mit erheblichem Zeitverzug dokumentiert, keiner weiß mehr so genau, worum es eigentlich ging, ● und das alles hat außerdem noch „ewig“ gedauert. 3 DIE LÖSUNG: MODERATION So komplex wie die Ursachen sind auch die Fähigkeiten, die für effektive Projektbesprechungen erforderlich sind. Gefordert sind hier Kompetenzen wie Organisation, aktives Gestalten von Gruppenprozessen und eine starke Zielausrichtung. Gefordert ist also team- und ergebnisorientierte Gesprächsleitung durch einen Moderator. Die organisatorischen Vorbereitungen von Besprechungen fallen Projektleitern relativ leicht. Schwieriger wird es, wenn es um die gruppendynamischen Prozesse geht. Die meisten Projekt-Manager befassen sich lieber mit Zahlen und Strategien als mit den so genannten „soft facts“. Dabei sind gerade diese für das Gelingen von Sitzungen ausschlaggebend! Wenn eine Besprechung schief läuft, liegt das fast immer an der schlechten oder gar nicht vorhandenen Moderation. Den Beweis dafür anzutreten ist allerdings schwierig. Die Frustration ist bekannt und wird zum Scherz gemacht: „Ich habe die ganze Woche gesessen - völlig umsonst! “ Zahlen, die die verantwortlichen Führungskräfte zum Handeln bringen würden, gibt es so gut wie nicht. Kaum ein Unternehmen weiß wirklich, wie viel Zeit und Energie in Besprechungen verschwendet werden. Sitzungscontrolling ist unbekannt. Für Kaffeefilter gibt es ein Budget, das überwacht wird - für die viel kostbarere Zeit und Kompetenz, die Mitarbeiter in Besprechungen verwenden oder verschwenden, hingegen nicht. 4 DER ABLAUF „Gute“ Projekt-Meetings sind aber weder Zufall noch Zauberei. Generell müssen Sitzungen vom Projektleiter oder einem der Teilnehmer moderiert werden. Der Moderator macht am Anfang noch einmal das Besprechungsziel klar, dann werden Informationen zusammengetragen und Aufgaben verteilt. Am Ende jedes Meetings steht eine Rückblende, bei der über Ergebnisse und Ablauf reflektiert wird. Der klassische Ablauf einer Moderation besteht aus vier Phasen: Einstieg, Bearbeitung der Tagesordnungspunkte, Maßnahmenplanung und Abschluss. 4.1 Der Einstieg Die Sitzung wird eröffnet, das Besprechungsziel, das auf der Agenda steht, noch einmal bekannt gegeben, der Zeitplan abgestimmt. Teilnehmer, die neu in der Gruppe sind, stellen sich vor. Bei der ersten Sitzung werden außerdem Vereinbarungen für Gesprächsführung und Verhalten sowie die Protokollverantwortung festgelegt. Vereinbarungen für Gesprächsfüh- Abb. 1: Die Projektbesprechung