Dienstag, Dezember 29, 2015

Warum Lessons Learned für ein Projekt so wichtig ist und meistens nichts bringt

INSiRA - Bild: EBH GmbH
Das Projekt ist abgeschlossen und die beliebte Lessons Learned Runde steht an. „Mal wieder Fehler finden.“, sagen die Teammitglieder des Projektes und meinen es teils resigniert und teils ironisch.

Hans, Geschäftsführer und Vorgesetzter von Hugo, dem verantwortlichen Projektleiter würde allerdings lieber mehr über die tatsächlichen Erfolgs-Faktoren des Projektes erfahren, statt sich Rechtfertigungen über Fehler der Vergangenheit anzuhören.

Erfahrene Projektleiter und Unternehmer wissen, wie wertvoll Feedback ist. Und: wie selten man es bekommt. Hans daher hat von seinen Projektleitern gelernt, dass nach Abschluss eines Projektes eine „Lessons Learned“ Reflektion gemacht werden soll und fordert hier nun die Ergebnisse ein. Hugo und sein Projektteam analysieren den Projektverlauf und kommen auch zu einigen wertvollen Erkenntnissen. Erkenntnisse darüber, was für zukünftige Projekte zu verbessern und auch zu vermeiden wäre. Wichtiges Feedback nicht nur für Hugo sondern auch für Hans, der die Projekte im Unternehmen verantwortet.

Die Erkenntnisse des Lessons Learned Workshops von Hugos Projektteam sind zum Beispiel folgende:
  • Projektleiter und Teilprojektleiter müssen für das Projekt Entscheidungen treffen können, die dann auch entsprechend umgesetzt werden können und nicht von Linienvorgesetzten durch eine andere Priorisierung aufgehoben werden.
  • Projektmitarbeiter müssen auch Zeit für das Projekt haben und nicht zusätzlich andere Aufgaben erledigen.
  • Abhängigkeiten zu andern Projekten müssen rechtzeitig aufgedeckt werden.
Und davon einiges mehr. Es handelt sich um Erkenntnisse, die nichts mit dem Projekt selbst zu tun haben, sondern mit den Rahmenbedingungen, unter denen Projekte arbeiten.

„Das muss die Geschäftsleitung wissen“, sind sich alle im Projektteam einig. Nicht einig werden sie sich, wie und wann diese Ergebnisse an die Geschäftsleitung, also Hans, weitergegeben werden. „Das ändert ja doch nicht“, ist nur eine, aber eine typische Meinung dazu. Das Projektteam überlegt, eine „abgespeckte Form“ der Ergebnisse weiterzugeben, und einiges an „internen Erkenntnissen“ für sich zu behalten.

Hans, der Ergebnisse erwartet hat, die sich auf den Projekterfolg bezogen, erwartet nicht, Beschwerden über Ressourcenmanagement und Projekt-Priorisierungen zu erhalten. Schließlich wurde das Projekt ja erfolgreich abgeschlossen und der Kunde war weitgehend zufrieden. Hugo, der die Erwartungen von Hans kennt, passt die Lessons Learned Ergebnisse entsprechend an. Schließlich möchte er auch in Zukunft interessante Projekte leiten und nicht als Querulant dastehen. Das führt dazu, dass sich für das nächste Projekt eigentlich nichts ändert. Das führt auch dazu, dass diese Feedback-Runden immer weniger Ergebnisse bringen. Irgendwann kommt jemand auf die Idee, für Lessons Learned eine weitere Checkliste zu entwerfen, die der Projektleiter nach Ende des Projektes ausfüllt und im Projektlaufwerk ablegt.

Das ist verschenktes Potenzial und verlorene Zeit.

Lessons Learned bedeutet, das Projekt und seinen Verlauf zu reflektieren, um daraus Erkenntnisse zu gewinnen, was man beim nächsten Projekt besser machen könnte. In der Regel wird daraus eine Analyse, welche Fehler das Projekt gemacht hat und was alles falsch gelaufen ist und so nicht wieder passieren darf. Das ist leider etwas vollkommen anderes und gar nicht im Sinne von Lessons Learned.

Viel wichtiger als einzelne Projekt intensiv zu „zerpflücken“ wäre es für Hans, den Geschäftsführer, zu erkennen, welche Rahmenbedingungen er für seine Projekte (und Projektleiter) verändern müsste, damit er kontinuierlicher erfolgreiche Projekte bekommt. Projekterfolg als Methode sozusagen. Dazu müsste Hans übergreifend die Stellschrauben all seiner Projekte kennen, um daraus Rückschlüsse für die gesamte Projektorganisation zu erhalten.

Diese Meta-Ebene zu betrachten, ist für Hans nützlicher und gibt ihm wertvolles Feedback darüber, wie die Projektorganisation nach strategischen Gesichtspunkten besser ausgerichtet werden kann, was nicht nur einzelnen Projekten, sondern dem ganzen Unternehmen Gewinn bringt.

INSiRA tut genau das: Projektorganisationen daraufhin analysieren, wo die wichtigsten Stellschrauben und Optimierungspotenziale zu finden sind. Mit einer externen, durchgängigen Analyse, die quantitative und qualitative Faktoren der Projektorganisation untersucht, erhält Hans ein schnelles und umfassendes Feedback über die Stärken (und Schwächen) seiner Projekte.

Berater können das Analyse Tool INSiRA nutzen, um genau diese Stellschrauben im Unternehmen schnell zu erkennen und eindeutig zu belegen. Um INSiRA zu nutzen, erhalten Sie mit der Zertifizierung eine Einführung in das Tool und alle Materialien für die strategische Projektberatung als INSiRA Facilitator. Mehr Informationen

Einen tieferen Einblick in das Analyse-Tool INSiRA erhalten Sie in unserem kostenlosen Webinar am 21.01.2016. Nach der Anmeldung erhalten Sie eine Bestätigung mit den Zugangsdaten zum Webinar.

Montag, Dezember 21, 2015

Wie Checklistendenken Konflikte im Projekt entstehen lässt.



Andreas und Peter haben sich in Ihrem Projekt in eine komplizierte Kommunikationsspirale begeben.

Irgendwann kommt der Projektleiter Peter zu der Erkenntnis, dass Stakeholdermanagement schwierig ist, die Stakeholderanalyse nichts bringt und er eigentlich gar keine Zeit hat, so viele Fragen seines Stakeholders Andreas zu beantworten. Daher werden seine eMails auch immer knapper. Aus seiner Sicht hat er recht. 

Andreas, aus seiner Sicht, hat leider auch Recht. Die knapper werdenden eMail versteht er als Unfreundlichkeit und Unwilligkeit, zu kommunizieren. Andreas denkt über erste Eskalationsschritte nach. Das macht die Kommunikation noch schwieriger.
Diese Situation ist das Ergebnis eines grundsätzlichen Missverständnisses über 

Projektkommunikation, wenn sie mit Checklistendenken abgewickelt wird. Wie entsteht dieses Missverständnis?

Gehen wir mal einen Schritt zurück.

Eine sehr einfache Definition lautet, dass Kommunikation die Interaktion zwischen 2 Parteien ist. Und weiter:   

Kommunikation ist
A) die Verständigung und Interaktion zwischen Menschen 
B) der Austausch von Informationen zwischen Geräten.

Da haben wir den Grund. Mit Checklistendenken verwechselt man A und B. 

Was Kommunikation nämlich nicht ist, ist der Austausch von Informationen zwischen Menschen. Das ist zu wenig. Dabei geht der Teil der Kommunikation unter, der auf die Verständigung, also das Verstehen der Information zielt. 

Mit Checklistendenken kann ich dafür sorgen, dass Informationen vollständig und korrekt ausgetauscht werden. Was ich mit Checklisten nicht erreiche, ist dafür zu sorgen, dass mein Kommunikationspartner die ausgetauschten Informationen auch versteht. 

Projektkommunikation muss also mehr sein, als das Verteilen von Informationen über das Projekt. Wenn ein Projektleiter das übersieht, kommt es zu solchen Situationen wie bei Andreas und Peter.
Was Andreas gefehlt hat, war die Interaktion mit Peter (oder irgendjemandem aus dem Projekt), um die Informationen zu verstehen, die er erhalten hat. Projektkommunikation ist nicht eingleisig. Sie geht immer in beide Richtungen. 

Peter was das nicht klar. Die Informationen waren durchaus richtig und aus Peters Sicht auch vollständig. Was fehlte war die Interaktion mit Andreas. Checklistendenker vervollständigen jetzt die Checkliste zur Stakeholderkommunikation um den Punkt „Interaktion mit dem Stakeholder“: Oder noch konkreter „Interaktion mit Andreas“. Das wird in diesem Fall vielleicht helfen, das Problem zu beheben und nachträglich zu verstehen. Da aber je nach betroffener Person, Situation, Informationsbedürfnis und Projekt die Interaktion immer eine andere sein wird, kommt Peter mit Checklistendenken immer wieder an Grenzen: Situationen, die im Projekt niemand erwartet hat und viel Zeit in Anspruch nehmen.

Freitag, Dezember 18, 2015

Für Checklistendenker: Was passiert bei Nicht-Kommunikation?


Kommunikations-Probleme wie die zwischen Projektleiter Peter und Stakeholder Andreas wie hier beschrieben treten immer wieder auf. Typischerweise sind das Kommunikationsthemen wie

  • Stakeholderverunsicherung:Ein (oder mehrere) Stakeholder eines Projektes möchte Informationen über das Projekt. Er erhält sie auch, versteht aber Zusammenhänge nicht oder interpretiert sie falsch. Nachfragen beim Projektleiter werden nicht zufriedenstellend oder noch schlimmer, gar nicht beantwortet. Der Stakeholder ist verunsichert und stellt noch mehr Fragen, die auf die gleiche Weise beantwortet werden. Diese fehlende Interaktion führt verständlicherweise zu Verärgerung beim Stakeholder. Ein verärgerter Stakeholder, der den Eindruck hat, dass das Projekt seiner Meinung nach in die falsche Richtung läuft, kann ist eine Situation, die kein Projektleiter für sein Projekt wünscht.
  • Falsch verstandene Anforderungen:
    Das ist die größte und wahrscheinlich bekannteste Kommunikationsfalle, die in Projekten passieren. „So habe ich das aber nicht gemeint“ als Kommentar eines Anwenders zu einer neuen Softwarefunktion ist der Kommunikationsfehler mit der größten Auswirkung. Eine Anforderung wurde gestellt, beschrieben, umgesetzt, getestet und erst beim Einsatz stellt sich heraus, das3s etwas ganz anderes gewollt war. Meistens hätte mehr „Interaktion“ ganz am Anfang dieser Ereignisse geholfen.
  • Verloren gegangene Informationen:
    Im Laufe eines Projektes werden innerhalb des Projektteams viele Informationen ausgetauscht. Typischerweise läuft 80% des Informationsaustausches über eMail. Das sich schnell, einfach und funktioniert meistens. Aber auch innerhalb des Teams kann es passieren, dass eMails übersehen werden, Informationen falsch verstanden werden oder unvollständig weiter gegeben werden. Je größer das Projektteam ist und je verteilter das Team arbeitet, umso schwerer wirkt es sich aus, wenn Kommunikation nur als Weitergabe von Informationen verstanden wird.

Was kann man für gute Projektkommunikation tun?
Wie schafft ein Projekt den Weg von „Information austauschen“ hin zu „Verständigung zwischen allen Beteiligten“?

Eines der wichtigsten Kommunikationsthemen ist hier „Feedback“, also „Rückmeldung geben und erwarten“. Der Austausch zu einem Thema ist erst dann beendet, wenn der Gegenüber signalisiert „Ok, danke, ich habe es verstanden.“ Diese Haltung in der Kommunikation im Projekt führt dazu, dass alle Beteiligten viel schneller merken, wenn Missverständnisse und Informationslücken entstehen. Eine entstehende Informationslücke kann der Projektleiter schnell schließen.

Projektkommunikation ist eine Aufgabe, die Zeit erfordert und nicht automatisiert werden kann. Kommunikation ist immer 2seitig. Ohne Rückmeldung bleibt es bei der Weitergabe von Information mit dem Risiko, dass sich Missverständnisse und Konflikte aufbauen. Auch wenn es viele Hilfsmittel gibt die das Weitergeben von Informationen erleichtern, bleibt doch der Teil der Interaktion aller Beteiligten der erfolgskritische Punkt.

Die meisten Stakeholder eines Projektes sind dem Projekt zu Beginn positiv eingestellt. Nicht-Kommunikation kann sie schnell zu kritischen Gegnern machen. Je kontinuierlicher ein Projektteam kommuniziert und auf Feedback achtet, umso leichter wird es mit der Zeit und umso stabiler sind die Kommunikationswege, wenn es im Projekt auch einmal kritisch wird. Regelmäßige Verständigung mit allen Projektbeteiligten sorgt dafür, dass das Verständnis darüber, was das Projekt macht und was von dem Ergebnis des Projektes erwartet wird, in Einklang bleibt.

Missverständnisse und Konfliktpotentiale lassen sich ausräumen, wenn das Projektteam sein Projekt aus der Perspektive des Gegenübers zu betrachten. Damit wächst auch das Verständnis über das eigene Projekt.

Projektkommunikation ist am einfachsten ist, wenn die von Anfang an in die Projektarbeit integriert wird und ihr auch Zeit eingeräumt wird. Aus diesem Grund muss sie immer nebenher laufen, ohne unterschätzt zu werden.

Die Checkliste gegen Checklistendenken in der Projektkommunikation
1. Projekt-Kommunikation ist immer 2 seitig.

2. Projekt-Kommunikation ist eine Haltung, keine Aufgabe.

3. Stakeholder möchten das Projekt verstehen und selbst verstanden werden.

4. Das Projekt muss seine Stakeholder verstehen, um erfolgreich zu sein.

5. Ein Wechsel der Perspektive hilft, um Missverständnissen auf die Spur zu kommen.

6. Der Ton macht die Musik – es kommt auch darauf an, wie kommuniziert wird, damit die Information verstanden wird.

7. Wenn das Projekt die Punkte 1-6 verstanden hat und berücksichtigt, darf man auch über ein Tool nachdenken, das das ein oder andere Kommunikationsthema erleichert ;-)

Donnerstag, Dezember 17, 2015

Projektkommunikation: Warum ist Checklistendenken gefährlich?



Laut Stakeholderanalyse vom Projektbeginn ist Andreas im Projekt von Peter einer der wichtigsten Stakeholder. Andreas Abteilung kümmert sich um die Berechnung von Angebotspreisen im Unternehmen. Die Berechnungsmethoden sind komplex. Die Software von Peters Projekt soll vieles automatisieren und vor allem ermöglichen, neue Berechnungsmethoden schneller umzusetzen. Das hat direkten Einfluss auf die Auftragsbearbeitung im gesamten Unternehmen. Nicht nur Andreas Abteilung ist also auf die Software von Peters Projekt angewiesen. Andreas möchte also gerne wissen, ob die Software rechtzeitig zum geplanten Termin fertig wird.  Peter versteht das so, dass er Andreas regelmäßig über den Status des Projektes informiert. Andreas erhält nun wöchentlich den Statusbericht per eMail. Aufgabe erledigt, Andreas ist ja informiert, so denkt Peter.

Das ist gefährliches Checklistendenken. Warum ist das gefährlich? 

Aus Andreas Perspektive sieht die Situation so aus:

Andreas erhält regelmäßig eine Mail von Peter mit einem Bericht über ein Projekt, an dessen Ergebnis er zwar stark interessiert ist, aber von dessen Inhalt er nichts versteht. Es ist auch nicht das einzige Projekt, von dem er im Unternehmen betroffen ist. Er ist Profi in der Kalkulation von Preisen, nicht in der Entwicklung von Software. Andreas fühlt sich überhaupt nicht informiert, denn er versteht in dem Bericht viele Details nicht. Trotzdem versucht er sich ein Bild zu machen und interpretiert die Details des Berichts, die er nachvollziehen kann. 


Dadurch entsteht bei Andreas zwangsläufig ein Eindruck über das Projekt, das mit der „Wirklichkeit“ im Sinne von Peters Wahrnehmung des Projektes nur noch wenig gemein hat.  Irgendwann beschwert sich Andreas bei Peter, dass er nicht versteht, warum das Projekt eine bestimmte Funktion anders umsetzt, als er sich das vorstellt. Das ist der Beginn einer langen und zeitaufwändigen eMail-Kommunikation über einzelne Funktionen der Software. Peter versucht die Fragen zu beantworten und liefert Informationen an Andreas (Checklistendenken!). 

Andreas versteht die Informationen teilweise nicht oder anders, als Peter sie gemeint hatte. Außerdem gefällt Andreas der Ton nicht, den er in den Mails von Peter herauszulesen glaubt.

Dadurch entsteht eine Informations-Spirale, die sich aus Informationen, Detailsaspekten und Fragen entwickelt, die immer größer wird. Können Sie sich vorstellen wie das weitergeht? 

Ich bin sicher, jeder hat schon mal in Peters oder Andreas Schuhen gesteckt, nicht wahr?

Montag, Dezember 14, 2015

Projektkommunikation funktioniert nicht mit Checklisten

Projektleiter lieben Checklisten. Checklistendenken ist für die vielen Detailaufgaben und z.B. wiederkehrende Aufgaben nicht nur in der Softwareentwicklungsprojekten hilfreich und nützlich.

Checklistendenken ist nützlich, wenn es darum geht, einzelne Dinge zu erledigen und sicherzustellen, dass sie vollständig und korrekt erledigt werden. Das kann zum Beispiel der Erstellung eines email-Verteilers für die Projektkommunikation sein. Verteiler vollständig, alle Adressen geprüft, Klar-Namen ohne Tippfehler erfasst, alle Informationen geprüft, Freigabe für den Verteiler eingeholt, und so weiter. Kleine Details, die zu erledigen und zu prüfen sind. Dafür gibt es nichts Besseres als Checklisten. Mit einer Checkliste stelle ich sicher, dass alles vollständig erledigt wird.








Bildquelle: fotolia.com

 Darum ist die To Do Liste auch eines der wichtigsten Werkzeuge für ein Projekt. Die Bearbeitung einer To Do Liste funktioniert hervorragend mit Checklistendenken. Doch sobald die Aufgaben etwas komplexer werden, wird Checklistendenken gefährlich. Da entgehen dem Projektleiter möglicherweise wichtige Dinge. Nämlich immer dann, wenn außer der vollständigen Erledigung auch die Qualität der Erledigung eine Rolle spielt.

Diesen Aspekt unterstützt keine noch so ausführliche Checkliste vollständig. Ein Projektleiter kann über eine Checkliste sicherstellen, dass alle Stakeholder alle Informationen erhalten haben. Was das Abhaken der Checkliste jedoch nicht sicher stellt ist, ob alle Stakeholder die Information auch verstanden haben.
Projektkommunikation ist wesentlich mehr als das Verteilen von Informationen.


Gehen wir mal einen Schritt zurück. Was ist Kommunikation?
Eine sehr einfache Definition lautet, dass Kommunikation die Interaktion zwischen 2 Parteien ist. Und weiter: Kommunikation ist

  • A) die Verständigung und Interaktion zwischen Menschen
  • B) der Austausch von Informationen zwischen Geräten.


Da haben wir den Grund. Mit Checklistendenken verwechselt man A und B. Was Kommunikation nämlich nicht ist, ist der Austausch von Informationen zwischen Menschen. Das ist zu wenig. Dabei geht der Teil der Kommunikation unter, der auf die Verständigung, also das Verstehen der Information zielt.

Mit Checklistendenken kann ich dafür sorgen, das Informationen vollständig und korrekt ausgetauscht werden. Was ich mit Checklisten nicht erreiche, ist dafür zu sorgen, dass mein Kommunikationspartner die ausgetauschten Informationen auch versteht. Projektkommunikation muss also mehr sein, als das Verteilen von Informationen über das Projekt. Wenn ein Projektleiter das übersieht, kommt esregelmäßig zu "Kommunikationsunfällen" wie falsche verstandene Anforderungen, zeitaufwändige Rückfragen von Stakeholdern und unerledigten Aufgaben, weil die Bedeutung der Aufgabe oder der Zusammenhang unklar war.

Mehr über Projektkommunikation: www.ebh-muenchen.de



Freitag, Dezember 11, 2015

Gibt es eine geheime Superkraft?

Heute erscheint mein Artikel im Blog des Projektmagazins zu einer oft unterschätzten Kompetenz von Projektleitern.
Ich habe es die "geheime Superkraft" genannt. Eigentlich ganz einfach und selbstverständlich, doch wie das so ist mit den Dingen, die man mit "eigentlich" benennt: sie kommen immer etwas zu kurz.

Um was es genau geht, steht im Blog des Projektmagazins

Bildnachweis: fotolia.com