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 ;-)

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?

 Mehr über Projektkommunikation

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

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

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.

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.

Warum Sichtbarkeit für Projekte wichtig ist

Es gibt Projekte in Unternehmen, über die weiß scheinbar jeder Bescheid und es gibt Projekte, die kennt kein Mensch. Stimmt´s? Das hat interessanterweise gar nichts mit der strategischen Bedeutung der Projekte für das Unternehmen zu tun.

Georg leitet ein großes Infrastrukturprojekt in seinem Unternehmen, einer Versicherung. Die Netzwerk-Struktur soll an die gestiegenen Anforderungen angepasst werden. Ein längst fälliges Vorhaben und für die Zukunftssicherung wichtig. Also durchaus strategisch zu nennen. Das Projekt läuft, die Meilensteine werden pünktlich erreicht, es gibt immer mal wieder kleinere Abweichungen, Fehler treten auf und werden beseitigt. Georg ist ein eher ruhiger Projektleiter („Fragen stören eh nur“ ist seine Lieblingseinstellung), ein sehr genauer Fachmann, der das auch von seinem Team erwartet. Außerdem gilt er als QS-Fanatiker, der sich gerne mal in Details verliert. Das Team spricht sich untereinander ab, und ist es gewohnt, selbständig nach Lösungen zu suchen, bevor jemand von außen hinzugezogen wird. Daher wissen auch relativ wenige Kollegen im Unternehmen über dieses Projekt Bescheid.

Hans leitet ein ähnliches Projekt im gleichen Unternehmen. Das Projekt hat einige Abhängigkeiten zu Georgs Projekt. In Hans´ Projekt gibt es laufend Verzögerungen: die Hardware wurde zu spät geliefert, Zusagen von Lieferanten wurden nicht eingehalten, Details in der Auslieferung und Installation übersehen, und so weiter. Hans ist dementsprechend laufend unter Druck und sehr überlastet. Vor lauter Überlastung übersieht er regelmäßig Aufgaben, die er leicht delegieren könnte, aber es lieber „schneller selbst erledigt“. Fragen seines Teams stören ihn eher, im Zweifelsfall kümmert er sich um kritische Dinge lieber selbst. Er gilt als QS-Fanatiker, der sich gerne mal in Details verliert. Das Team ist vorsichtig geworden und sichert sich in kritischen Situationen lieber ab. Da die kritische Situation ein Dauerzustand ist, geht die Arbeit nur zögerlich voran.

Aufgrund der Probleme bei Hans´ Projekt ist die Unternehmensleitung bestens über den aktuellen Stand informiert. Schließlich müssen laufend Entscheidungen getroffen werden, Änderungen genehmigt, Risiken diskutiert, usw. Für Georgs Projekt bleibt entsprechend weniger „Management Attention“ übrig. Einerseits nicht schlecht, dann kann Georg wenigstens in Ruhe arbeiten, sollte man meinen. Das geht so lange gut bis folgende Situation eintritt: In Hans Projekt verschiebt sich aufgrund der Verzögerungen der Fertigstellungstermin soweit, dass Georgs Projekt davon massiv betroffen ist. Im letzten Steuerkreis zu den Infrastrukturprojekten ging es letztendlich darum, welches der beiden Projekt gestoppt und auf später verschoben werden soll. Da alle Beteiligten bestens über Hans´ Projekt informiert waren und wenig über Georgs Projekt, fiel die Entscheidung gegen Georg.

Georgs Projekt lief zwar gut, war aber zu wenig „sichtbar“ im Unternehmen. Kritische Abhängigkeiten konnte Georg zu dem Zeitpunkt, als er von der anstehenden Entscheidung erfuhr, nicht mehr klar vermitteln, da insgeheim die Entscheidung schon getroffen worden war. Eine paradoxe Situation: über problematische Projekte sind Alle gut informiert, glatt laufende Projekte werden übersehen und erhalten nicht die Aufmerksamkeit auf Entscheider-Ebene, die sie bräuchten.

Eine einzige, wichtige Projektleiter-Aufgabe hatte Georg schlicht unterschätzt: für angemessene Sichtbarkeit seines Projektes sorgen.

So habe ich das nicht gemeint ....

"Die Basis erfolgreicher Projekte ist eine gute persönliche Beziehung zu Auftraggeber und Stakeholdern." Das war das Ergebnis eines intensiven Erfahrungsaustausches zwischen Geschäftsführern der IT-Branche in Augsburg, den wir kürzlich moderiert haben. Dabei kam ein ganz typischer Fall eines Projektes zur Sprache, in dem der Projektleiter formal alles richtig gemacht hat, und das Projekt trotzdem in Schieflage zu geraten droht.

„Meine Projektleiter setzen manchmal Sachen um, ohne Verstanden zu haben, was der Kunde damit tun möchte.“ Peter, Geschäftsführer eines mittelständischen Software-Dienstleisters, versteht die Welt nicht mehr. „Der Kunde wollte einen Button, mit dem alle Aktionen zur Bestellbearbeitung auf einmal rückgängig gemacht werden sollen. Das habe ich ihm programmieren lassen und jetzt beschwert er sich, dass diese Funktion kompletter Unsinn ist.“, berichtet Projektleiter Hans in der internen Projektleiter-Runde seinem Chef. „Ist ja klar, dass wir so mit den geplanten Aufwänden niemals hinkommen. Ich kann mich auf die Aussagen beim Kunden offenbar überhaupt nicht verlassen.“

Peter, der Geschäftsführer, rauft sich die Haare. Das Projekt sollte schon längst fertig sein und Hans sollte das nächste Projekt begonnen haben. Das geht aber nicht, weil ein „normaler“ Kunde auf einmal zum verärgerten Kunden zu werden droht. Und offenbar weil er etwas verlangt hat, was er anschließend nicht mehr haben wollte.

Ist Ihnen eine derartige Szene auch schon vorgekommen?

„Hast Du gefragt, was der Kunde mit der Funktion beabsichtigt hat“, möchte Peter von seinem Projektleiter wissen. „Nein, er hatte ja alles ausführlich beschrieben, dann habe ich es umsetzen lassen. Die Anforderungs-Dokumentation war komplett ausgefüllt. Außerdem war die Zeit zu knapp. Das nächste Projekt steht ja schon an.“ Hans findet, er hat alles richtig gemacht.

Das hat er auch, nur reicht das nicht. Solange der Projektleiter Hans nicht genau verstanden hat, was für den Kunden der Sinn und Nutzen der Software ist, die er beauftragt hat, werden solche Szenen immer wiederkehren. Peter möchte das verständlicherweise abstellen. Sein erster Impuls ist, für seine Projektleiter eine neue Regel aufzustellen: „Hinterfrage jede Anforderung immer genau nach Sinn und Nutzen für den Kunden.“ Dann stellt er fest, dass im Formular für die oben erwähnte Anforderungsdokumentation bereits ein entsprechendes Feld dafür vorhanden ist. Füllen es die Projektleiter aus? Ja, typische Standard-Antwort: „Kunde hat gesagt, er braucht das.“

Ok, Regeln scheinen nicht weiter zu helfen. Was dann?

In der Projektleiter-Runde kommt ein anderer Lösungsansatz zur Sprache, und zwar ganz intuitiv. Einer der neuen Projektleiter, Micha, fängt an, Hans` Situation zu hinterfragen, weil er als Neuer die Zusammenhänge und Arbeitsweisen noch genauer kennenlernen möchte. Und je genauer Micha nachfragt, umso mehr wird die Lösung für Hans klar: dieses Gespräch hätte er vor der Programmierung der Bestellbearbeitung mit dem Kunden führen sollen. Michas Fragen haben ihn darauf gebracht, den Nutzen der Funktion nochmal genauer zu durchdenken. Und es fällt ihm auf, dass er tatsächlich eine andere Annahme darüber hatte als der Kunde. Peter und seine Projektleiter beschließen, dass der regelmäßige Bericht an den Kunden über den Projektfortschritt eine andere Qualität bekommen muss. Es soll nicht nur ein Bericht über den Stand des Projektes sein, sondern auch ein Dialog mit dem Kunden, um ihn und die Absichten „hinter der Software“ besser zu verstehen. Projektkommunikation eben.

Wenn eine Aufgabe als Projekt endet

Es gibt Aufgaben, die klingen anfangs einfach und überschaubar, doch kaum hat man sie begonnen, zeigt sich, wie komplex sie sind. Der Rollout einer neuen Software, die Einführung neuer Tools oder die Neugestaltung der Firmenwebseite sind solche Aufgaben. Weil sie häufig zusätzlich zum Tagesgeschäft bewältigt werden müssen, stoßen Verantwortliche schnell an ihre Grenzen. Denn Projekte wie diese müssen sorgfältig geplant, souverän gesteuert und laufend überwacht werden. Das kann ein Vollzeitjob sein.

Wann wird aus einer Aufgabe ein Projekt?

Peter Kaiser ist Geschäftsführer eines mittelständischen Unternehmens im Anlagenbau mit rund 250 Mitarbeitern. Herr Kaiser hatte erkannt, dass die Unternehmenswebseite völlig veraltet war. Die Inhalte waren nicht mehr korrekt, das Design war aus der Mode gekommen und die Funktionalität musste verbessert werden, um Interessenten leichter zu Kunden zu machen. Also beauftragte Herr Kaiser eine Agentur zur Überarbeitung der Webseite.

Recht zügig legte diese einen übersichtlichen und gut strukturierten Meilensteinplan vor. Ziel: die neue Webseite ist in 2,5 Monaten online. Herr Kaiser war erfreut, dass das so schnell gehen sollte. Er gab den Meilensteinplan frei und die Agentur begann mit der Umsetzung.

Die erste Hürde

Alles verlief reibungslos, bis die Agentur den ersten Entwurf des Layouts zur Freigabe schickte. Herr Kaiser war zu diesem Zeitpunkt mit seinem Vertriebsleiter auf Geschäftsreise in China und hatte keinen Freiraum, eine fundierte Entscheidung zu treffen. Folgerichtig delegierte er das Thema an seine Assistentin, Tanja Walter. Sie war, nach ihm und dem Vertriebsleiter, am ehesten vertraut mit dem Projekt. „Bitte treiben Sie das Projekt weiter voran und führen Sie eine Entscheidung herbei“, lautete sein Auftrag.

Bei der Besprechung nach Herrn Kaisers Rückkehr eröffnete ihm seine Assistentin: „Wir haben uns leider auf kein Design einigen können. Jeder Beteiligte hat andere Vorstellungen, wie die Seite aussehen soll. Die Diskussion war uferlos! Was machen wir jetzt?“ „Keine Sorge, Frau Walter, wir finden bestimmt eine Lösung“, beruhigte sie der Geschäftsführer. „Welche Punkte sind denn konkret offen?“ „Nun, wir müssen entscheiden, welche Inhalte auf die Seite sollen und wer die Produktbeschreibungen und die Unternehmensdarstellung textet. Vertrieb und Marketing waren sich hier überhaupt nicht einig. Außerdem hatten die Kollegen vom Außendienst noch einige gute Ideen für den Webshop, die allerdings Auswirkungen auf das Design haben. Und an die Karriereseite hatten wir nicht gedacht, bis uns die Personalleiterin darauf hinwies. Die Agentur verlangt von uns eine schnelle Entscheidung, sonst kann sie die Termine nicht einhalten“, schloss Tanja Walter, sichtlich außer Atem.

Läuft das Projekt aus dem Ruder?

Herrn Kaiser war der Kern der vielen Fragen von Frau Walter klar: „Wer koordiniert intern das Projekt?“ Er ging im Kopf die Möglichkeiten durch: Der Vertriebsleiter wäre die beste Wahl, aber er und sein Team sind aktuell mit der Vorbereitung der wichtigsten Branchenmesse völlig ausgelastet, für die auch die Webseite rechtzeitig fertig sein muss. Seine Assistentin wiederum brauchte er dringend für die Nacharbeitung der Chinareise. „Wir brauchen jemanden, der Zeit und Geduld hat, Ergebnisse und Entscheidungen einzufordern und mit der Agentur zu kommunizieren“, sprach er seine Gedanken laut aus. „Die Person muss neutral genug sein, um widersprüchliche Anforderungen zu Kompromissen zu machen.“ „Genau!“ warf Frau Walter ein. „Am besten wäre ein Projektleiter, der die Sprache der Agentur versteht und die Webseite ausführlich für uns testen kann, bevor sie online geht.“

Das EBH - Team ist der Ansprechpartner für Ihre Aufgaben, die als Projekt enden. Egal, ob es um Ihre neue Webseite, den Rollout eines neuen EDV-Systems oder die Einführung neuer Tools geht: Wir helfen Ihnen, Ihr Projekt zu führen. Wir reden mit allen Beteiligten im Unternehmen, stimmen uns mit Ihren Lieferanten in Ihrem Sinne ab und sorgen dafür, dass Meilensteine erreicht und Entscheidungen getroffen werden.

Was ist das richtige Projektteam?

Folgende Frage diskutierte ich vor einiger Zeit mit einem Projektleiter:

"Ich habe ein neues Projekt bekommen. Das Thema ist technisch sehr interessant, es ist neu, das Unternehmen betritt hier Neuland, obwohl wir ähnliche Dinge schon mal entwickelt haben. Ich würde das Projekt gerne übernehmen, weil mich die Herausforderung reizt.
Doch weil die Technik neu ist, bin ich auf ein gutes Team ganz besonders angewiesen.

Woher weiß ich, dass ich die richtige Mannschaft habe?"

Das war die Kernfrage vor dem Start des Projektes. Nicht, ob das Thema technisch lösbar ist, oder das Budget richtig berechnet. Die meisten Dinge sind technisch lösbar und lassen sich berechnen.
Nicht, ob er die Unterstützung seines Auftraggebers bekommt. Die meisten Auftraggeber unterstützen ihr Projekt, wenn sie merken, dass es gut läuft.

Damit das Projekt gut läuft, braucht der Projektleiter ein Team, in dem die notwendige Kompetenz (technischer undvor allem kommunikativer Art) ausreichend vorhanden sind.

Wir haben uns dann gemeinsam überlegt, welche Fähigkeiten, Kenntnisse und Ressourcen im Team vorhanden sein müssen, damit das Projekt die Grundvoraussetzung für Erfolg bekommt.
Bei unseren Überlegungen waren technisches Wissen und Kommunikationskompetenz und soziale Fähigkeiten gleichermaßen wichtig.
(Warum? nun - die Frage ist mehrere eigene Projektgeschichten wert.)

Mit dieser Erkenntnis, welche Fähigkeiten erforderlich seien, haben wir ein Diagramm erstellt und uns die Verteilung im Team angesehen. Auf einer Skala (y-Achse) von 0 (fehlt) bis 5 (perfekt) wurden die notwendigen Fähigkeiten (x-Achse) aufgelistet und die einzelnen Team-Mitglieder eingetragen.
Dabei wurde sichtbar, an welcher Stelle Kompetenz fehlt oder schwach ausgeprägt war.

Im nächsten Schritt hat der Projektleiter das Diagramm mit dem Team bearbeitet. Die Selbsteinschätzung jedes einzelnen wurde miteinbezogen und in der anschließenden Diskussion hat sich ein Team entwickelt, das seine Stärken genau kannte und wusste, wie es am besten zusammenarbeitet.

Und Achtung: die wahre Stärke von Projekt-Teams liegt in den Unterschieden und der Fähigkeit, sich zu ergänzen, nicht in den Gemeinsamkeiten.