Wenn Sherlock Holmes Ihr Projektleiter wäre

Sind Sie in der Lage, ein paar typische, immer wiederkehrende Konflikte in der Zusammenarbeit von Projekten aufzuzählen? Sicher, oder? Wenn Sie aber schon all diese Schwierigkeiten so gut verstehen und antizipieren – warum kommen sie denn dann immer wieder?

In meinem letzten Beitrag hier bei microtool habe ich argumentiert, dass dies zum Teil daran liegt, dass wir den Schwierigkeiten die falschen Ursachen zuschreiben  (6 Mythen über Probleme in der Zusammenarbeit in Projekten). Deswegen werden Maßnahmen getroffen, die wirkungslos verpuffen. In diesem Beitrag möchte ich Ihnen eine Methode vorstellen, die Ihnen bessere Dienste liefert, um den Problemen auf den Grund zu gehen. Diese Methode stammt aus meinem Konfliktlösungs-Spiel ‚GameChanger‘. Am besten bringe ich Ihnen die Methode an einem Beispiel näher, das häufig in der Implementierungsphase von Projekten auftritt.

Die Ursache von Konflikten mit Methode finden

Hier ist die Geschichte: Eine IT-Abteilung ist immer wieder damit konfrontiert, dass andere Abteilungen des Unternehmens, beispielsweise das Marketing oder der Vertrieb, Software von Anbietern bestellen, ohne die IT-Abteilung vorher zu konsultieren. Mit unterschriebenem Vertrag und gebuchten Beraterstunden für die Implementierung kommen die Manager oder Berater der Anbieter später zu Ihnen und erwarten eine reibungslose Implementierung. Diese ist dann oft nicht möglich, weil viele Abhängigkeiten und technische Rahmenbedingungen nicht berücksichtigt wurden. Die Software wird dann mit Einbußen an Funktionalität und deutlich höherem Aufwand implementiert, obwohl die Schwierigkeiten im Vorfeld leicht hätten adressiert werden können.

Diese Situation kommt regelmäßig vor, obwohl es immer wieder Gespräche dazu gibt und die Abteilung Ihre Beratung im Vorfeld aktiv anbietet. Trotzdem wird diese meist nicht in Anspruch genommen und die Situation wiederholt sich in unschöner Regelmäßigkeit. Warum ist das so? Haben Sie eine Antwort? Die Abteilung, mit der ich dieser Frage vor einiger Zeit gemeinsam nachgegangen bin, hatte keine. Die Antwort liegt auch nicht auf der Hand. Ganz im Gegenteil. Die anderen Manager sind ja nicht dumm. Die wissen doch, dass es immer wieder Schwierigkeiten in der Implementierung gibt, wenn die Experten nicht frühzeitig mit einbezogen werden. Sie wissen auch, dass Sie die Spezialisten einfach nur einladen müssen. Das Angebot dazu steht. Warum machen Sie es trotzdem nicht?

Was würde Sherlock Holmes machen, wenn Sie ihn für diese Frage engagieren würden?
“Watson, wenn Sie alle Möglichkeiten prüfen und dann jene ausschließen, die nicht in Frage kommen – dann muss die, die zum Schluss übrig bleibt, die richtige sein.”

Also schnappen Sie sich die Detektivmütze und prüfen Sie alle Möglichkeiten. Mit allen Möglichkeiten meine ich 6 Möglichkeiten. Die folgenden 6 Optionen decken nämlich alle möglichen Ursachen ab. (Wenn Sie wissen wollen, warum das so ist, dann finden Sie im Anschluss an den Artikel einen Link zu einem Erklärungsvideo.)

Diese 6 Optionen systematisch zu prüfen, ist die effektivste Methode, um die Ursache von Konflikten bei der Zusammenarbeit von Menschen zu finden:

– Ursache #1: Es liegt an der Motivation einzelner Beteiligter

Das bedeutet, dass die Parteien einfach andere Präferenzen haben (selbst wenn sie die andere Partei und deren Argumente gut verstehen).

In unserem Fall könnte diese bedeuten, dass die entsprechenden Manager oder Abteilungsleiter letztendlich doch nicht überzeugt sind, dass es vorteilhaft ist, die IT-Experten frühzeitig mit einzubeziehen. Möglicherweise sehen sie einfach mehr Nachteile als Vorteile in diesem Vorgehen. Beispielsweise, weil die Diskussionen gleich viel zu technisch werden oder die bevorzugten Applikationen aus technischen Gründen ausgeschlossen werden könnten. Dann scheint die beste Strategie: Gleich Fakten herstellen, denn dann klappt es später auch irgendwie mit der Umsetzung. Lieber um Entschuldigung bitten als um Erlaubnis zu fragen.

Möglicherweise haben die Manager auch die Erfahrung gemacht, dass es regelmäßig technische Diskussionen mit dem Anbieter gibt, wenn ein IT-Experte mit am Tisch sitzt. Dies empfinden sie in dieser Phase als unproduktiv und störend. Oder die Manager sind der Meinung, dass die IT eine Service-Abteilung ist und sich in die Auswahl der Werkzeuge nicht einzumischen hat.

– Ursache #2: Es liegt an den Fähigkeiten einzelner Beteiligter.

Das bedeutet, dass die gewünschte Lösung Fähigkeiten der Beteiligten voraussetzt, die nicht vorhanden sind.

In unserem Beispiel könnten das mangelnde technische Kenntnisse sein. Der anwesende IT-Experte könnte die Frage an den Anbieter richten: “Wir müssten Ihre Software an einen TIBCO messaging bus anschließen. Welche Schnittstellen gibt es dafür?“ Das sind Sätze, mit denen können Marketingleiter nichts anfangen. Und oft auch die Verkaufsberater des Anbieters nicht. Denn diese sind in der frühen Phase darauf spezialisiert, die Anwender bei deren Problemen abzuholen. In solchen Momenten entsteht Unsicherheit, die Anwender können nicht mehr mitreden und haben das Gefühl, die Kontrolle über den Prozess zu verlieren. Sie verstehen nicht, ob es sich hier um Routine handelt oder um unüberbrückbare Probleme, die ein K.O. bedeuten können. Es entstehen Verzögerungen, weil Klärungsbedarf entsteht. Diese Unsicherheiten sind unangenehm und werden deshalb lieber auf später verschoben. Der IT-Experte wird daher vorsichtshalber lieber nicht eingeladen, denn ‘dafür gibt es ja später noch genügend Zeit’.

– Ursache #3: Es liegt an den Zielkonflikten der Parteien.

Das bedeutet, dass die Beteiligten unterschiedliche Ziele haben, die zumindest teilweise unvereinbar sind.

In unserem Beispiel gibt es vermutlich ein gemeinsames Ziel: Gut funktionierende Software im Unternehmen. Im Detail gibt es trotzdem Konfliktpotential. Die IT-Abteilung wird letztlich immer eine Software bevorzugen, die auf bekannten Technologien aufbaut, die sich gut in die bestehende Infrastruktur einpasst, leicht zu warten ist und keine Abhängigkeiten zum Anbieter aufbaut. Wichtig sind auch Stabilität, Sicherheit, Datenschutz. Die Anwender hingegen interessiert all dies nur sekundär. Viel wichtiger ist die Funktionalität, die Benutzerfreundlichkeit, die Geschwindigkeit und umfassender Datenzugriff. Häufig zeichnen sich hier schon im Vorfeld mögliche Konflikte ab, denen sich die Anwender nicht aussetzen wollen, da es sowieso keine gute Lösung dafür geben wird. Damit die Anwender später nicht gezwungen sind, bei Ihren Lieblings-Features Abstriche zu machen, stellen Sie lieber zuerst Fakten her und schlagen sich später mit den Problemen herum.

– Ursache #4: Es liegt am Teamwork zwischen den Parteien.

Das bedeutet, dass die Beteiligten nicht gut zusammen arbeiten.

In unserem Beispiel könnte das bedeuten, dass die beiden Abteilungen zwar die Notwendigkeit zur Zusammenarbeit erkennen und auch wahrnehmen, aber nicht das Gefühl haben, ein gutes Team zu sein. Beide Parteien unterstellen sich gegenseitig, am Ende des Tages vor allem auf die eigenen Interessen bedacht zu sein und die der anderen Abteilung nicht angemessen zu berücksichtigen. Auch mögliche Interessenskonflikte werden nicht offen ausgesprochen. Damit kommen die wirklichen Themen und Bedenken nicht auf den Tisch. Auch Verantwortung wollen alle nur für Ihre eigenen Bereiche, nicht für das gemeinsame Projekt übernehmen.

– Ursache #5: Es liegt an systemischen Konflikten.

Die Ursache liegt im Design der Rahmenbedingungen, beispielsweise der Unternehmensorganisation.

In unserem Beispiel könnte dies bedeuten, dass das Problem darin liegt, dass die beiden Abteilungen künstlich getrennt sind und an unterschiedlichen Zielen gemessen werden. Die IT-Abteilung wird vor allem an Kennziffern wie Stabilität, Kosteneffizienz, Mitarbeiter pro Server oder Verfügbarkeit gemessen. Wichtig sind daher Standards, langfristige Planung, einfache Wartung, Verfügbarkeit von Experten. Die Marketingabteilung hingegen hat zum Ziel, möglichst rasch auf Veränderungen zu reagieren, alle Möglichkeiten der Kontaktbeschaffung zu nutzen, mit neuen Trends zu experimentieren. Das bedeutet: Flexibilität, Geschwindigkeit, Experimente, neue Technologien, möglichst breiter Zugriff auf Daten. Letztlich stehen diese Ziele zumindest teilweise in Konflikt und solange beide Abteilungen von der Geschäftsleitung angehalten sind, ihre Ziele möglichst intensiv zu verfolgen, zeigen sich diese Konflikte dann auch automatisch in der Zusammenarbeit. Im Gegensatz zu den Zielkonflikten (#3) sind diese Ziele nicht von den Beteiligten selbst gewählt (z.B. Kosteneffizienz), sondern sie werden durch die Rahmenbedingungen vorgegeben.

– Ursache #6: Es liegt an organisatorischen Hürden.

Die Ursache liegt an Defiziten im System, beispielsweise an etablierten Prozessen und Regeln.

In unserem Beispiel könnte dies bedeuten, dass Konflikte dadurch provoziert werden, dass die IT-Abteilung angehalten ist, sehr rigide zu agieren, beispielsweise durch Audits oder Qualitäts- oder Security-Zertifizierungen. Diese nötigen die IT-Experten (auch über deren persönliche Präferenz hinaus) zu Maßnahmen und Restriktionen, welche die anderen Abteilungen als zu starr und unflexibel empfinden. Diese fühlen sich daher von Aussagen wie: “Das dürfen wir nicht, weil wir sonst beim Audit Probleme bekommen.“ mit Ihren Wünschen allein gelassen und der Eindruck kann entstehen, dass die IT-Abteilung sich hinter solchen für sie unprüfbaren K.O.-Aussagen versteckt.

Die Gretchenfrage bei Problemen

Nun die Gretchenfrage: An welcher dieser Ursachen liegt das Problem letztendlich?

Wenn Sie keine konkrete Situation vor Augen haben, dann sind alle Varianten möglich. Vermutlich sogar mehrere davon gleichzeitig. Das ist nicht ungewöhnlich, sondern sogar wahrscheinlich. Denn komplexe Situationen haben selten einfache, lineare Ursache-Wirkung-Beziehungen. Vielmehr wirken meist mehrere Kräfte gleichzeitig und es ist nicht immer klar, welche Faktoren besonders schwer wiegen und welche nur die Folge von Ursachen in anderen Bereichen sind.

In der Praxis zeigt sich, dass auch im selben Team – wo scheinbar alle von derselben Situation reden – die Meinungen plötzlich auseinander gehen, wenn die Analyse der Ursache derart konkret wird. Indem Sie jedoch eine Ursache nach der anderen ausschließen oder hinten anstellen, dringen Sie zur wichtigsten Ursache vor – zu jener, die Sie zuerst lösen sollten.

Die Vorteile der Methode

Was haben Sie mit dieser Methode gewonnen?
Vor allem Klarheit.

Klarheit darüber, dass die Ursachen für Ihre Situation vielschichtiger sind als anfangs vermutet und oft auch ineinander greifen.
Klarheit darüber, dass die anderen Beteiligten in der Regel gute Gründe für Ihr Verhalten haben.
Klarheit darüber, dass viele der üblichen Lösungsansätze nichts bewirken können, weil Sie an der Ursache vorbei gehen.

Damit ändert sich jedoch die Sichtweise, die Sie auf das Problem haben. Besonders dann, wenn Sie diese Übung in einer Gruppe durchführen und jede der Personen individuell abstimmt, welche Option sie denn für die wichtigste hält und warum. Ich verspreche Ihnen: da macht es ‚Klick’ im Kopf.

Und die Lösung für das Problem?

Die haben Sie damit immer noch nicht in der Tasche. Aber Probleme lösen ist ja Ihre Spezialität. Und wenn Sie an der richtigen Ursache ansetzen, dann arbeiten Sie in Zukunft in die richtige Richtung und werden rasch Fortschritte erkennen.

Falls Sie darüber hinaus noch gerne ein paar zusätzliche Tipps hätten, wie Sie dabei anders vorgehen können als bisher, dann schreibe ich Ihnen gerne meine besten Tricks zusammen – in einem zukünftigen Beitrag hier bei microTOOL.

 

Hinweise zu Alex Rammlmair:

Konflikte spielerisch lösen mit dem GameChanger

 

Wissen zum Mitnehmen im praktischen eBook Format: Das kleine grüne Buch gegen den täglichen Unfug, 5 wirkungsvolle Tricks für souveräne Kommunikation
Der kleine grüne Workshop Wirksame Sprache, In 10 Lektionen zu mehr Ausdruckskraft in Ihrer Sprache, kostenloser Download (59 Seiten)