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

Donnerstag, Oktober 29, 2015

Wann ist der richtige Zeitpunkt um über ein Projekt zu informieren?

Carl hat eine richtig gute Idee. Eine kleine Software-Anpassung und schon würden die Abläufe in der Auftragsabwicklung seines Unternehmens viel einfacher laufen. Daten müssten nicht mehr manuell übertragen werden und die Kollegen vom Controlling bekämen ihre Auswertungen auch viel schneller. Eine richtig gute Idee, findet Carl. Er redet mit einigen Kollegen aus der IT darüber. Auch die finden die Idee gut. Er redet mit seinem Chef darüber, ob er die Anpassung in der nächsten Zeit einfach mal umsetzen soll und legt ihm einen Projektplan vor.

Doch wie das so ist, mit Projekten, die man für eine gute Idee hält, es gibt immer auch eine andere Meinung zu der Idee. Carl war so begeistert von seinem zukünftigen Projekt, dass er an diese Möglichkeit gar nicht dachte.

Der Leiter der Auftragsabwicklung war gar nicht begeistert von Carls Idee. Einer seiner Mitarbeiter hatte ihm davon erzählt, nachdem Carl am Rande eines Meetings zu einem andern Thema begeistern von seinem neuen Projekt erzählt hatte. Das Gespräch war nur kurz, obwohl Carl gerne ausführlicher über seine Idee diskutiert hätte. Doch der Kollege hatte sich ein paar Details gemerkt und berichtete dem Leiter der Auftragsbearbeitung davon. Ein kurzes Gespräch mit dem IT-Leiter, Carls Chef, und das Projekt wurde gestoppt, bevor es angefangen hatte. Carl erfuhr nie den Grund.

Seine Begeisterung hatte schlussendlich dazu geführt, dass der sich in seiner Motivation gebremst fühlte und der Leiter der Auftragsabwicklung verärgert war über eigenmächtige Eingriffe in die Abläufe seiner Abteilung.

Es hätte auch ganz anders laufen können.

Auch wenn Carl von dem Nutzen seiner Idee vollkommen überzeugt ist bedeutet das nicht automatisch, dass andere Kollegen es auch sofort sind. Daher lohnen sich ein paar Überlegungen im Vorfeld, zum Beispiel:

Über das Umfeld des Projektes:
- Wie ist das Umfeld (wer ist für / wer ist gegen das Projekt ---> das ist die klassische „Stakeholderanalyse“)
- Wer ist in welcher Form von dem Projekt betroffen und welche Reaktionen können sich daraus ergeben?
- Wen brauche ich, um mein Projekt zu unterstützen?

Über den gegenwärtigen Projektzustand:
- wo steht mein Projekt? Was habe ich schon / Was fehlt noch?
- Was ist das größte Risiko?

Über eine „geschickt eingefädelte“ Kommunikation: - wen informiere ich wann am besten über das Projekt?
- in welcher Detailtiefe?
- in welcher Form (persönlich, schriftlich, öffentlich, unter 4 Augen, etc.)?
- wann informiere ich worüber?

Zuviel Details können zum falschen Zeitpunkt für Verwirrung und Ablehnung stoßen.
Zuwenig Information oder zu späte Information kann ebenfalls zur ablehnenden Reaktionen führen.


Das sind nur ein paar Fragen, um den "richtigen Zeitpunkt" zu finden. Je nach Projekt und Umfeld, fallen Euch bestimmt noch mehr ein.

Entscheidend ist oft, die Art und Weise, wie ich über das Projekt informiere. Dabei auch immer die Reaktionen des Gegenübers beachten. Bei Themen, bei denen ich mit einer großen emotionalen Reaktion rechnen muss, muss ich sensibler vorgehen, als bei Themen, die eher nüchtern bewertet werden. Das hat übrigens nichts mit dem Thema zu tun. Auch technische Themen können sehr emotionale Reaktionen hervorrufen. Je emotionaler, desto sorgfältiger muss ich informieren, da hier die Risiken von Missverständnissen in der Kommunikation steigen.


Dienstag, Oktober 13, 2015

Projekte sichtbar machen - Visualisieren Sie Ihr Projekt

Wir lieben scheinbar ungewöhnliche Methoden, die Projekte zum Ziel führen. Wie in unserer letzten Projektgeschichte erzählt, ist die Sichtbarkeit eines Projektes ein Erfolgsfaktor (hier...)
Ein Projekt wird leicht sichtbar, wenn es Inhalte gibt, die man sehen kann, im einfachsten Sinne des Wortes: Zur Sichtbarkeit gehört Visualisierung. Wir haben uns kürzlich mit den Experten von Visual Braindump dazu unterhalten.

Hier ist ein Auszug unseres Gesprächs als Experten-Interview:




In welchen Situationen im Projekt ist die Visualisierung für Projektleiter nützlich?

Die Frage möchte ich zuerst zurückgeben: Wann ist die Visualisierung für Projektleiter nicht nützlich? Genau dann, wenn alle Inhalte zu Thema, Ziel und Ablauf allen Beteiligten klar sind. Da das in einem Projekt in den seltensten Fällen zutrifft, lautet die Antwort auf die ursprüngliche Frage: so oft wie möglich! 

Visualisierung im Projekt besticht durch klare Vorteile:

  1. Als Projektleiter schaffe ich es, durch Visualisierung Inhalte schnell und effektiv zu transportieren. (Prozess)-Beschreibungen mit grafischen Stilelementen, Kanban, Ziel-Bilder…  auch die Ausgestaltung klassischer Power-Point-Folien ist möglich. 
  2. Die Methode der Visualisierung ist eine Kreativmethode. Die Erarbeitung von Inhalten im Team erfolgt durch Visualisierung in einer (von Natur aus) kreativen Art. Als Projektleiter kann ich mit ihr Lücken und Unklarheiten identifizieren und eliminieren. 
  3. Eine Visualisierung dient der Verinnerlichung von Inhalten. Eine grafische Aufbereitung komplizierter Themen liefert einen Gesamteindruck zu spezifischen Themenkomplexen auf den ersten Blick, bleibt im Kopf und lädt bei Interesse zu Detailsichtungen weiterer Inhalte (textuell, verbal oder anhand weiterer Bilder) ein. Schnell und unkompliziert.


Welche Vorurteile/Bedenken gegenüber Visualisierung haben Projektleiter?
Beim Einsatz im Projektteam gibt es vorrangig zeitliche Bedenken. Eine Zeichnung zu erstellen, erfordert Zeit. Dem gegenüber steht die zumeist geforderte Erstellung von Texten durch den Kunden (Dokumentationen, Meeting-Protokolle anhand Vorlagen, Reports…).

Stakeholder, bzw. das klassische Management reagieren in Ausnahmefällen differenziert. Zeichnungen werden gerne aus eigener Unsicherheit heraus als „Überflüssig“ bezeichnet. Meistens sind Reporting-Sheets oder technische Dokumentationen in Unternehmen standardisiert. Zum Zwecke der Vergleichbarkeit wird oft auf diese Formalie bestanden. 

Die Einführungsmaßnahme ist denkbar einfach: machen. Dabei gilt es, die richtige Dosierung der grafischen Gestaltung zu finden, die Dosierung stückweise zu erhöhen und einen schonenden Wechsel zu finden. Der Mehrwert der grafischen Darstellungsweise wird überzeugen. Seien Sie in den Bereichen mutig, in denen keine Standardisierung vorliegt. Beispiele:


  • Das Meeting-Protokoll ist standardisiert -> Ergänzen Sie durch eine weitere Seite mit der visuellen Zusammenfassung.
  • Es existiert eine Vorlage zur Dokumentation von Inhalten (Format, Deckblatt, Überschriften…) -> Ergänzen Sie Einzelbilder im Dokument
  • Die Projekt- oder Aufgabenstellung ist noch nicht klar. Perfekt! Zeichnen Sie ein gemeinsames Bild mit Ihrem Auftraggeber. Halten Sie dann die Ergebnisse in einem „klassischen“ Pflicht- und/oder Lastenheft fest. Doppelter Erfolg: Ein gemeinsames Ziel-Bild wurde geschaffen und dient Ihnen und Ihrem Auftraggeber als Aushängeschild zur weiteren Erklärung vor Dritten.
  • Konkret: Welche Fragen können Sie als Projektleiter im Laufe Ihres Projektes zweifelsfrei mit „ja“ beantworten?
  • Sind die fachlichen Inhalte als Voraussetzung zur schriftlichen Darstellung klar?
  • Ist das kollektive Verständnis zum Thema/Ziel/Scope/Umfang vorhanden?
  • Ist die Schriftform die „beste“ Variante zur Verteilung von Wissen in Kontext des Projektauftrages?

Falls Sie eine der Fragen mit „Nein“ beantworten: Versuchen Sie die grafisch/bildliche Darstellung. 

Ein Bild mag keine technische Dokumentation vollständig ersetzten. Ein Bild bietet dagegen eine wesentliche Ergänzung. Einsatzmöglichkeiten sind auch hier: Bildelemente in Dokumentationen; die Darstellung von Kernelementen in Meetings; grafische Elemente als visueller Anker oder visuelle Darstellungen von Produktinformationen, Abläufen und Prozessen. Selbst gezeichnete Bilder, sind etwas Einzigartiges, laden zur Betrachtung ein und – sofern an der richtigen Stelle platziert – garantieren die Aufmerksamkeit die Ihr Projekt erfordert.