Wenn viel gesprochen wird und trotzdem wenig ankommt – Kommunikation im IT-Projekt
Ein Fachbereich formuliert eine Anfrage an die IT. Die IT kennt das System seit Jahren, kennt SAP, kennt die Standardprozesse und geht davon aus, den Bedarf im Kern verstanden zu haben. Rückfragen erscheinen überflüssig. Der Fachbereich beschreibt seinen Bedarf nur grob, in der Erwartung, die IT werde die passende Lösung schon finden. Beide Seiten sprechen miteinander. Trotzdem entsteht am Ende ein System, das technisch einwandfrei funktioniert und fachlich nicht das leistet, was gebraucht wird.
Das Problem liegt nicht zwingend in fehlendem Einsatz oder zu wenig Kommunikation. Die IT arbeitet möglicherweise parallel für weitere Fachbereiche, was Wartezeiten erklären kann. Es erklärt aber nicht, warum eine Lösung am tatsächlichen Bedarf vorbeigeht. Dafür gibt es eine andere Ursache: Beide Seiten haben nicht ausreichend geprüft, ob aus ihren Gesprächen ein gemeinsames Verständnis der Aufgabe entstanden ist. Die Folge sind zusätzliche Abstimmungen, Nacharbeit und Entscheidungen auf einer unvollständigen Grundlage.
Im vorherigen Beitrag „Warum IT-Projekte scheitern“ ging es darum, wie fehlende Anforderungs- und Prozessklärung sowie eine unpassende Projektorganisation Projekte ins Stocken bringen. Dieser Beitrag setzt bei der Kommunikation selbst an. Entscheidend ist nicht, wie viele Informationen ausgetauscht werden, sondern ob die Beteiligten dasselbe Bild von der Aufgabe entwickeln.
Viel Austausch ist noch kein Beweis für Verständigung
Wer in Projekten arbeitet, kennt volle Kalender: Status-Meetings, Abstimmungsrunden, Eskalationstermine und Problemlösungsworkshops. An Gelegenheiten zum Austausch mangelt es selten. Genau daraus entsteht ein Trugschluss: Man hält die Menge der Gespräche für einen Beleg ihrer Wirksamkeit.
Die wichtigere Frage lautet: Was ist nach dem Gespräch bei den Beteiligten angekommen? Zwei Menschen können am selben Termin teilnehmen, dieselben Worte hören und trotzdem mit unterschiedlichen Vorstellungen herausgehen. Das beobachte ich zwischen Fachbereich und IT immer wieder. Ein IT-Mitarbeiter beschreibt ein neues System über Funktionen, Schnittstellen und Datenstrukturen. Ein Anwender beschreibt dasselbe System über das Ergebnis, das er im Tagesgeschäft erreichen möchte. Beide sprechen über dieselbe Sache, aber nicht notwendigerweise über dieselbe Aufgabe.
Das ist für mich kein Kommunikationsdefizit im Sinn von zu wenig Reden. Es ist ein Verständigungsproblem, das auch bei viel Austausch bestehen bleibt. Mehr Meetings lösen es nicht automatisch. Sie können das Problem sogar verdecken, weil nach mehreren Terminen der Eindruck entsteht, man habe sich ausführlich genug mit dem Thema beschäftigt.
Für die Projektsteuerung folgt daraus: Die Zahl der Termine darf nicht als ausreichender Beleg für Verständigung gelten. Vor einer Entscheidung muss erkennbar sein, ob Fachbereich und IT dasselbe Problem, denselben Ablauf und dasselbe gewünschte Ergebnis vor Augen haben. Sonst kann ein Projekt formal gut kommuniziert wirken und trotzdem in eine falsche Lösungsrichtung laufen. Die spätere Korrektur kostet meist mehr als eine frühzeitige Prüfung des Verständnisses.
Zwischenfazit: Viele Termine zeigen, dass gesprochen wurde. Sie zeigen nicht, dass die Beteiligten dieselbe Aufgabe vor Augen haben. Dafür muss sichtbar werden, wie Fachbereich und IT die Situation jeweils verstehen.
Foto von Memento Media auf Unsplash
Warum dieselben Wörter unterschiedliche Vorstellungen erzeugen
Bedeutung wird in einem Gespräch nicht einfach von einer Person zur anderen übertragen. Jeder ordnet Informationen vor dem Hintergrund eigener Erfahrungen, Fachbegriffe und Aufgaben ein. Deshalb löst dasselbe Wort nicht automatisch dieselbe Vorstellung vom Ablauf aus.
Im Projektalltag fällt das häufig erst auf, wenn eine Entscheidung getroffen oder eine Lösung vorgestellt wird. Die IT denkt in Systemlogik, Datenstrukturen und technischen Abhängigkeiten. Der Fachbereich denkt in Zielen, Ergebnissen und konkreten Arbeitsschritten. Begriffe wie „Auswertung“, „Freigabe“ oder „Prozess“ können auf beiden Seiten vertraut klingen und dennoch unterschiedliche Erwartungen enthalten.
Das zeigt sich besonders deutlich, wenn die IT vor allem die Systemdarstellung eines Prozesses vor Augen hat, während der Fachbereich zusätzliche manuelle oder physische Arbeitsschritte kennt. Diese Schritte finden vielleicht außerhalb des Systems statt, entscheiden im Tagesgeschäft aber darüber, ob eine Lösung tatsächlich funktioniert. Wer nur die Systemfunktionen betrachtet, sieht dann einen anderen Ablauf als die Menschen, die täglich mit diesem Prozess arbeiten.
Fachbereich und IT halten den aktuellen Ablauf deshalb gemeinsam sichtbar fest, einschließlich der Arbeitsschritte, die zunächst nebensächlich erscheinen. Es geht nicht um einen aufwendigen Workshop. Es geht darum, die eigene Vorstellung so offenzulegen, dass die andere Seite sie prüfen und ergänzen kann.
Ich habe selbst früh im Prozessanalyse-Umfeld erlebt, wie leicht man sich von einer solchen Ist-Erfassung abbringen lässt, wenn jemand meint, die Situation sei doch ohnehin bekannt. Das war ein Anfängerfehler. Sobald die Beteiligten den Ablauf gemeinsam sichtbar machen, zeigt sich oft, dass das vermeintlich gemeinsame Bild weniger gemeinsam ist als angenommen.
Damit wird auch die Abgrenzung zur reinen Anforderungsklärung deutlich. Eine Anforderung kann dokumentiert sein und trotzdem unterschiedlich verstanden werden. Die Verständigungsprüfung ist der zusätzliche Schritt, der sichtbar macht, ob hinter der Anforderung dieselbe Vorstellung von Arbeit, Problem und gewünschtem Ergebnis steht.
Zwischenfazit: Unterschiedliche Vorstellungen sind in Projekten mit verschiedenen fachlichen Perspektiven normal. Das Risiko entsteht dort, wo sie unbemerkt bleiben und in eine Entscheidung oder technische Lösung einfließen.
Urheber unbekannt. Gemeinfrei / Public Domain Mark 1.0. Quelle: Wikimedia Commons.
Erst verstehen, dann verstanden werden wollen
An dieser Stelle wird klar, warum die Lösung nicht in noch mehr Austausch liegt, sondern in einer bestimmten Handlung innerhalb des Gesprächs. Stephen Covey beschreibt sie mit dem Grundsatz: „Erst verstehen, dann verstanden werden wollen.“ Wer voraussetzt, dass alle ohnehin dasselbe meinen, überspringt genau diesen Arbeitsschritt.
Verstehen bedeutet dabei mehr als aufmerksam zuzuhören. In einem internationalen Projekt mit sprachlichen und fachlichen Verständigungsbarrieren war eine Diskussion festgefahren. Eine Erklärung wurde zwar gehört, aber nicht in ihrer fachlichen Bedeutung verstanden. Ich habe die Aussage damals als Moderator in eigenen Worten wiederholt und anschließend gefragt, ob diese Zusammenfassung die Position richtig wiedergibt. Dadurch wurde ein Missverständnis sichtbar. Erst danach konnte die andere Seite ihre Sicht ergänzen und die Diskussion wieder auf die eigentliche Aufgabe zurückgeführt werden.
Der entscheidende Schritt bestand darin, das eigene Verständnis offenzulegen, statt es still vorauszusetzen. Eine Rückfrage wie „Verstehe ich Sie richtig, dass …?“ macht aus einem vermuteten Verständnis ein prüfbares Verständnis. Sie gibt dem Gegenüber die Möglichkeit, zu bestätigen, zu korrigieren oder einen fehlenden Zusammenhang zu ergänzen.
Für Projektentscheidungen ist das besonders wichtig. Bevor aus einer Beschreibung eine Lösung, ein Auftrag oder eine Priorität wird, sollte erkennbar sein, welches Problem die Beteiligten tatsächlich lösen wollen. Sonst wird zwar eine Entscheidung getroffen, aber möglicherweise über unterschiedliche Sachverhalte. Die IT bewertet dann die technische Machbarkeit einer anderen Aufgabe, als der Fachbereich sie im Alltag erlebt.
Diese Haltung ist keine Einbahnstraße. Der Fachbereich kann nicht erwarten, dass die IT unausgesprochene Anforderungen errät. Die IT kann umgekehrt nicht davon ausgehen, dass ihre Systemkenntnis bereits ein vollständiges Bild des Bedarfs erzeugt. Beide Seiten müssen bereit sein, das eigene Verständnis zur Prüfung zu stellen.
Zwischenfazit: Wirksames Zuhören ist für mich kein weicher Wert am Rande, sondern eine konkrete Praxis mit direkter Wirkung auf das Projektergebnis. Diese Praxis wirkt aber nur, wenn Fachbereich und IT sie gleichermaßen anwenden und daraus für den Projektalltag eine klare Konsequenz ziehen.
Was daraus für die Projektsteuerung folgt
Das Muster aus dem SAP-Beispiel vom Anfang zeigt sich in vielen Varianten. Wenn die IT ihre Systemkenntnis mit einem vollständigen Verständnis des Bedarfs verwechselt, werden gezielte Rückfragen schnell als überflüssig behandelt. Wenn der Fachbereich sein gewünschtes Ergebnis benennt, ohne die zugrunde liegende Arbeit ausreichend zu beschreiben, entsteht auf der anderen Seite eine ebenso problematische Lücke. Beide Seiten können sich später unverstanden fühlen, aus ihrer jeweiligen Sicht zu Recht.
Technische Leitplanken wie Wartbarkeit, Upgradefähigkeit oder Herstellergarantie sind dabei nicht das Problem. Sie gehören zu einer tragfähigen Lösung. Problematisch wird es, wenn sie die offene Klärung des Bedarfs ersetzen, statt auf ihr aufzubauen.
Für die Projektleitung bedeutet das: Die Prüfung des gemeinsamen Bildes darf nicht dem Zufall überlassen bleiben. Vor einer wesentlichen Lösungsentscheidung sollte sie dafür sorgen, dass Fachbereich und IT den aktuellen Stand der Aufgabe in eigenen Worten beschreiben können. Stimmen die Beschreibungen nicht überein, ist das kein Zeichen für persönliches Versagen, sondern ein Hinweis, dass die Entscheidung noch nicht reif ist. Die notwendige Klärung muss im Ablauf vorgesehen sein und darf nicht erst beginnen, wenn die fertige Lösung zurückgewiesen wird.
Die IT-Leitung hat eine andere, aber ebenso konkrete Aufgabe. Sie muss eine Arbeitsweise fördern, in der Systemkenntnis zu besseren Fragen führt, nicht zu vorschnellen Annahmen. In Reviews reicht es deshalb nicht, nur technische Machbarkeit und Aufwand zu betrachten. Es muss auch geprüft werden, welches fachliche Problem die Lösung tatsächlich adressiert und ob die gelebte Prozessrealität darin wiedererkennbar ist.
Fachbereichsverantwortliche wiederum müssen sicherstellen, dass die eigene Organisation nicht nur ein gewünschtes Ergebnis benennt. Sie müssen auch die Arbeit beschreiben, die zu diesem Ergebnis führt, einschließlich manueller, informeller oder physischer Schritte außerhalb des Systems. Was für die Beschäftigten vor Ort selbstverständlich ist, kann für die IT unsichtbar sein.
Das gemeinsame Bild entsteht nicht einmalig zu Projektbeginn. Anforderungen verändern sich, neue Details werden sichtbar und Lösungen verändern wiederum die Arbeitsweise. Deshalb muss das Verständnis an relevanten Übergängen erneut geprüft werden: vor einer Lösungsentscheidung, bei wesentlichen Änderungen und bevor die Umsetzung als abgeschlossen gilt. Nicht jede Abstimmung braucht dafür ein eigenes Format. Entscheidend ist, dass die Frage gestellt und beantwortet wird, ob die Beteiligten noch dieselbe Aufgabe vor Augen haben.
Aus meiner Sicht liegt darin der eigentliche Führungsbeitrag zur Projektkommunikation. Führung besteht hier nicht darin, weitere Termine anzusetzen. Sie besteht darin, die Qualität der Verständigung zu einer Voraussetzung für Entscheidungen zu machen.
Meine Schlussfolgerung: Wirksame Projektkommunikation entsteht nicht durch möglichst viele Gespräche, sondern durch ein gemeinsam geprüftes Bild von Problem, Ablauf und gewünschtem Ergebnis. IT und Fachbereich müssen ihre unterschiedlichen Sichtweisen offenlegen und abgleichen, bevor eine Lösung beschlossen wird. Die Projektleitung muss diese Prüfung an wichtigen Entscheidungspunkten verankern. So wird technische Kompetenz mit gelebter Prozessrealität verbunden und das Risiko reduziert, dass aus einer unklaren Anforderung eine technisch saubere, aber fachlich unpassende Lösung entsteht. Weil sich Anforderungen und Abläufe verändern, muss das gemeinsame Bild im Projektverlauf erneut geprüft werden..
Foto von Lance Grandahl auf Unsplash
Bonus: Wenn „fertig“ für zwei Seiten etwas anderes bedeutet
Stellen Sie sich folgende Situation vor: In einem Projekt wird eine neue Funktion zur Abnahme vorgestellt. Die IT bewertet die Aufgabe als abgeschlossen, weil die vereinbarten Systemfunktionen umgesetzt und technisch geprüft sind. Der Fachbereich betrachtet die Funktion aus dem Ablauf heraus und stellt fest, dass ein notwendiger Arbeitsschritt vor der Nutzung noch nicht geklärt ist.
Beide Seiten verwenden dasselbe Wort: „fertig“. Für die IT bedeutet es, dass die technische Umsetzung abgeschlossen ist. Für den Fachbereich bedeutet es, dass die Funktion im tatsächlichen Arbeitsablauf eingesetzt werden kann. Die Abnahme droht zu einer Grundsatzdiskussion über Zuständigkeiten zu werden, obwohl der entscheidende Unterschied in den zugrunde liegenden Vorstellungen bisher nicht sichtbar war.
Eine tragfähige Klärung beginnt deshalb nicht mit der Frage, wer recht hat. Fachbereich und IT beschreiben zunächst unabhängig voneinander, was mit der Funktion möglich sein soll, an welcher Stelle sie im Ablauf eingesetzt wird und welche Voraussetzungen dafür erfüllt sein müssen. Erst dann wird sichtbar, ob beide Seiten dasselbe Ergebnis meinen. Technische Fragen lassen sich anschließend auf dieser gemeinsamen Grundlage bewerten.
Der Prüfimpuls für ähnliche Situationen lautet:ht im fachlichen Wissen, das auf beiden Seiten schon vorhanden war. Er liegt allein darin, ob sich jemand die Zeit nimmt, dieses Wissen sichtbar zusammenzuführen, bevor eine Lösung entsteht.
- Beschreiben Fachbereich und IT den aktuellen Stand der Aufgabe in eigenen Worten gleich?
- Sind auch manuelle, informelle oder außerhalb des Systems liegende Arbeitsschritte berücksichtigt?
- Wurde das Verständnis zurückgespiegelt und von der jeweils anderen Seite bestätigt?
- Sind technische Leitplanken auf einen geklärten Bedarf bezogen?
- Wird das gemeinsame Bild bei relevanten Änderungen erneut geprüft?
Projektkommunikation entscheidet sich nicht daran, wie viel gesprochen wird, sondern daran, ob aus unterschiedlichen Sichtweisen ein gemeinsames Verständnis entsteht. Wo dieses Verständnis in Ihrem Projekt noch nicht belastbar ist, steigt das Risiko, dass aus einer gut gemeinten Anforderung unnötige Abstimmung, Nacharbeit oder eine Lösung am Bedarf vorbei entsteht.
