Wenn man IT-Projekte aus psychologischer Sicht betrachtet, dann scheint die erste und wichtigste Frage die nach der Beziehung zwischen Auftraggeber und Auftragnehmer zu sein. Diese Beziehung „trägt“ das Projekt. Fragt man IT-Dienstleister nach den Erwartungen ihrer Auftraggeber, dann lauten das am häufigsten genannte Stichwort „Lösungen“, manchmal ergänzt um die Adjektive „schnelle“, „fertige“ oder „preiswerte“. Durch die Eigenarten der menschlichen Kommunikation ist aber keineswegs gesichert, dass der Auftragnehmer auch verstanden hat, was der Auftraggeber erwartet. Oft ist dies auch dem Auftraggeber nicht ganz klar. Wenn dann noch der in der Praxis nicht unübliche Umweg über Berater hinzukommt (der Auftraggeber spricht mit seinem Berater, und der Berater beauftragt und steuert die Entwicklung), kommt beim Entwickler mit einiger Sicherheit etwas ganz anderes an, als der Auftraggeber gesagt hat.
IT-Berater und oft auch Entwickler übernehmen ganz bestimmte Funktionen für den Auftraggeber: Sie führen nicht nur einen Auftrag aus, sondern sie helfen – manchmal (a) bei der Klärung dessen, was eigentlich das Problem ist, das es zu lösen gilt, und manchmal (b) bei der Beantwortung der Frage, was die richtige Lösung sei. Beides hat noch gar nichts mit der © eigentlichen Entwicklung der Lösung zu tun. In allen drei Fällen wird eine Leistung erbracht, die man auch als „Hilfe“ im eigentlichen Sinne des Wortes bezeichnen könnte.
Wenn es sich bei diesen Leistungen tatsächlich um Hilfe handelt, dann, so lautet die Hypothese dieses Textes in Anlehnung an eine Vermutung Edgar Scheins (2010), ist auch die „tragende Beziehung“ zwischen Auftraggeber und Auftragnehmer helfenden Charakters. Schein (ebd.) unterscheidet drei Arten helfender Beziehungen:
Modus 1 – Spezialistenhilfe: Der Auftraggeber weiß nicht nur, dass er ein Problem hat, sondern er weiß genau, welches Problem er hat. Er kann es genau beschreiben und kennt die entsprechende Lösung. Die Auftraggeberseite wendet sich an einen entsprechenden Spezialisten und kauft die Lösung dort ein. Braucht man also für die Erledigung von Standardaufgaben für sieben Arbeitsplätze die entsprechende Standardsoftware mit einigen spezifischen Anpassungen an die Gegebenheiten des Unternehmens, so ist dies ein typischer Fall für Spezialistenhilfe.
Modus 2 – Das Arzt-Patient-Verhältnis: In diesem Fall weiß der Auftraggeber, dass er ein Problem hat, aber er weiß ggf. nicht genau, was in diesem Fall hilft. Auch hier wendet sich der Auftraggeber an Spezialisten, die jedoch nicht sofort die Lösung anbieten, sondern zunächst eine Diagnose erarbeiten, die dann die Grundlage für die Lösung bildet.
Modus 3 – Beratung und Lösungssuche als Prozess: In dieser dritten Variante kennen weder die auftraggebende noch die beratende bzw. auftragnehmende Seite die genaue Natur des Problems, geschweige denn die Lösung. Die Ausgangslage ist so komplex, dass nur ein gemeinsamer Prozess des Suchens, der Analyse und des Entwickelns zur Lösung führt. Die Grundlage dieses Prozesses bildet die helfende Beziehung zwischen den Beteiligten.
Hier werden nun einige der erheblichsten Kommunikationsstörungen in IT-Projekten deutlich:
1. Beide Seiten agieren in Modus 1, sprechen aber über völlig unterschiedliche Dinge: Im Idealfall weiß der Auftraggeber, welches Problem er hat und wer ihm die Lösung liefern kann. Drückt er sich klar aus und tut der Auftragnehmer nur das, was tatsächlich bestellt wurde, kommt es tatsächlich zum gewünschten Ergebnis. Kennt der Auftraggeber aber nicht alle Facetten seines Problems, und entwickelt der Auftragnehmer – gleichsam prophylaktisch – Lösungsszenarien für den Fall, dass der Kunde sie brauchen könnte, kommt es zu Störungen. Für den Auftraggeber sieht die Lösung anders aus als das, was er erwartet hat. Dass sich diese Erwartungen mit der Zeit verändert haben und von vornherein schon etwas anders lagen, als sie anfangs beschrieben wurden, wird der Auftraggeberseite dabei nicht bewusst. Der Auftragnehmerseite ist in diesem Fall nicht bewusst, wie die Erwartungen tatsächlich lagen und wie sich die Lösung während der Entwicklung wie von selbst („Das könnte der Auftraggeber brauchen.“ oder „Wenn wir das so herum machen, ist es doch viel einfacher.“) und ohne Abstimmung verändert hat. Das Ergebnis ist ein tiefer Graben zwischen ursprünglicher Erwartung und fertiger Lösung.
2. Beide Seiten kommunizieren in unterschiedlichen Modi: Während der Auftraggeber in Modus 1 kommuniziert und Lösungen erwartet, versuchen viele IT-Fachleute in Modus 2 oder 3 zu kommunizieren und Fragen bezüglich der Anforderungen zu stellen. Kommt es zu Störungen, macht der Auftraggeber nicht selten seine Erwartung deutlich, dass er von kompetenten Beratern oder Entwicklern eine funktionierende Lösung erwarte. Schließlich bezahle er dafür, weil er eben nicht das Fachwissen habe. Damit wird jeder klärende Dialog und jede Form der Hilfe unterdrückt.
Die hier beschriebenen Probleme steigern sich noch, wenn Irritationen nicht zum Lernen aus Erfahrung, sondern zur Verhärtung der jeweiligen Standpunkte führen. So mag sich bspw. ein Geschäftsführer zu Beginn eines Projektes über mögliche Schwierigkeiten bei der Veränderung der ERP-Software bewusst gewesen sein. Doch angesichts des steigenden Drucks während der Einführung werden sein Denk- und Handlungsweisen immer automatischer, und Aussagen wie „Ich bezahle Sie, und Sie sind die Experten. Ich erwarte von Ihnen, dass Sie die vertraglich vereinbarten Ziele halten.“ fallen häufiger. Die Ursache für diese Verhärtung kann in einem der mächtigsten psychischen Abwehrmechanismen, der Projektion, liegen.
„Der Abwehrmechanismus der Projektion bewirkt, dass eine Person Empfindungen und Wünsche, die sie an sich selbst unerträglich findet, zunächst leugnet. Bis hierher ähnelt der Vorgang der Verdrängung. Das Spezifische an der Projektion ist, dass die (im Unbewussten wirksam bleibenden) Gefühle und Impulse unbewusst einer anderen Person zugeschrieben werden. Beinahe klassische Beispiele sind besonders dominante Menschen, die ihre eigene Aggressivität leugnen und dafür andere Menschen als besonders dominant und aggressiv kritisieren. Den Mechanismus der Projektion gibt es auch in umgekehrter Richtung (Introjektion), indem sich eine Person, um bestimmte Situationen zu bewältigen, Gefühle und Verhaltensweisen anderer Personen in sich hineinprojiziert und so empfindet und handelt, wie die andere Person vermeintlich empfunden und gehandelt hätte.“ (Heidig et al. 2012, S. 38)
So kann der besagte Geschäftsführer beispielsweise seine eigenen Schwierigkeiten während des Einführungsprozesses (etwa die Konflikte mit den mittleren Führungskräften des Unternehmens oder die anhaltenden Blockadehaltungen einiger Standorte) in den Berater oder den Geschäftsführer des mit der Implementierung des neuen Systems beauftragten Unternehmens projizieren. Der „Benefit“ für den Geschäftsführer liegt in der psychischen Entlastung von den Konflikten und der erlebten Wirkungslosigkeit. In einer solchen Konstellation kann die auftragnehmende Seite nur verlieren, es sei denn, es kommt zu einer Klärung.
Wie aber kann so eine Klärung aussehen?
In den meisten Fällen werden irritierende Erlebnisse übergangen. Nachdem ein Projekt gescheitert ist, heißt es jedoch oft: „Eigentlich hätten wir es damals schon ahnen können…“ Der erste Schritt zur Klärung ist, der eigenen Verwunderung oder Irritation Raum zum Wirken zu geben. Auch wenn dies erst einmal befremdlich klingt – oft handelt es sich beim Management von Projekten weniger um ein technisches, als vielmehr um ein zwischenmenschliches Unterfangen. Und in zwischenmenschlichen Situationen sind Irritationen die erste und zu Beginn auch einzige Informationsquelle. Die Kunst besteht nun darin, diese Beobachtungen und Wahrnehmungen in einen zielorientierten Klärungsprozess einfließen zu lassen. In der Beratungspsychologie kennt man den Grundsatz „Störungen haben Vorrang.“ Das gilt auch für das Management komplexer IT-Projekte. Die Grundlage für die Klärbarkeit schwieriger Sachlagen bildet eine gewachsene helfende Beziehung, wofür andere Kompetenzen und Methoden erforderlich sind als man für Management oder Softwareentwicklung braucht. Die Fähigkeit, den eigenen Irritationen in wertschätzender Weise Ausdruck zu verleihen, Fragetechniken, konstruktives Feedback, Beteiligungsszenarien zur Einbeziehung der Mitarbeiterebenen, Moderationstechniken und prozessorientierte Softwareentwicklungsmethoden wie Scrum führen hier weiter.
Man braucht eine ganze Menge Durchhaltevermögen, Fehler und Verbesserungsvorschläge immer wieder anzusprechen. Hilfreich ist, dafür ein regelmäßiges Setting zu schaffen (bspw. ein wöchentlich stattfindendes Meeting zur kontinuierlichen Verbesserung mit den Fragen „Was lief gut?“ und „Welche Probleme gab es, und wie lassen sich diese Probleme lösen?“). Wenn die Routinen („Das machen wir schon immer so!“) besonders gefestigt sind oder die Beziehung zwischen Auftraggeber und Auftragnehmer nicht belastet werden soll, kann es helfen, die Rolle des „Rufers in der Wüste“, also desjenigen, der seinen Irritationen und Beobachtungen Ausdruck verleiht, an eine Person zu delegieren, die nur diese und keine andere Funktion innehat.