IT Projekte und Konfliktmanagement – Erklärungen und Lösungsansätze

By 17. November 2016 April 19th, 2017 Aus der Praxis, Meinungen

Gezieltes Konfliktmanagement in IT-Projekten, statt passive Risikobewirtschaftung

Konflikte sind in IT-Projekten. Regeln, Prozesse, Ausschüsse etc. dienen zwar als Massnahme Konflikte zu vermeiden, eine Garantie für ein konfliktfreies IT-Projekt sind sie jedoch keineswegs. Sind denn Konflikte nicht einfach nur die natürlichen Folgen der Auseinandersetzung der Projektbeteiligten um ihre Interessen? Aus dieser positiven Perspektive können Konflikte auch als Quelle für Entwicklung oder Innovation gesehen werden. Wenn sie produktiv genutzt werden. Es gilt Konflikte in Projekte also nicht zu unterdrücken, sondern die Informationen und Erkenntnisse aus deren Bewältigung zu nutzen. Konflikte sind aus dieser Perspektive durchaus sinnvoll. Die sinnlose Seite der Konflikte, sind Konflikte die nicht bearbeitet werden. Sie wirken destruktiv, kosten Zeit und Geld, schädigen die Reputation und den wirtschaftlichen Erfolg.

 

Differenz oder Konflikt?

Die Fachliteratur kennt unzählige Definitionen des Begriffs Konflikt. Für uns hat sich in der Praxis folgende Unterscheidung bewährt:

  • Die Differenz, bzw. das Missverständnis: Die Beteiligten sind unterschiedlicher Meinung. Es herrscht offene Meinungsvielfalt, jedoch noch keine Einigkeit über den Dissens oder den Konsens. Keine der Parteien fühlt sich dabei in ihren Handlungsfreiheiten beeinträchtigt. Häufig handelt es sich bei Differenzen auch einfach nur um Missverständnisse.
  • Der Konflikt: In der Interaktion zwischen zwei oder mehreren Personen entstehen Unvereinbarkeiten, die von als Beeinträchtigung verstanden wird. Die Beeinträchtigungen können aus der Wahrnehmung der Parteien unterschiedlicher Art sein. Emotional, finanziell, Einschränkung unternehmerischen oder persönlichen Entfaltung, usw. Der Gegenstand des Konflikts ist ein Interessensgegensatz (z.B. Anforderungen vs. Kosten, Zeit vs. Qualität, …). Dieser wird im Hintergrund von unterschiedlichen Werten gesteuert, die zu unterschiedlichen Beurteilungen, Gefühlen und Zielen führen aus denen die Beteiligten dann ihr Konfliktverhalten ableiten. Konflikte können zudem nicht über ein Schwarz-Weiss-Schema isoliert betrachtet und bearbeitet werden, da sie sich meist in einem Kontext vielzähliger anderer entlastender oder befeuernder Faktoren entwickeln.

 

IT-Projekt = Widerspruchsmanagement

In IT-Projekten wirken, vereinfacht beschrieben, stets Faktoren wie

  • die Zeit,
  • das Geld,
  • die Menschen (als Individuen und in ihren Rollen innerhalb und ausserhalb des Projekts),
  • die Organisationen und deren Kultur, Strukturen und Ziele,
  • die Rahmenbedingungen (sachliche, fachliche, wirtschaftliche, politische, …).

In IT-Projekte treffen stets Systeme und Menschen in grosser Bewegung aufeinander. Sie streben danach Dinge zu gestalten: das Ergebnis des Projekts, die finanziellen Ziele, die eigene Reputation oder noch vieles andere. Die stets hoffnungsvolle Annahme vieler Auftraggeber ist es, dass sich alle Beteiligten voll und ganz den Zielen des Projekts verpflichten. Dabei wird vergessen, dass die Projektbeteiligten häufig mehr «als einem Herren dienen». Widersprüche sind also Teil der Rahmenbedingungen und ergeben sich immer wieder aufs Neue im Verlauf von Projekten.

 

Vielfältige Konfliktlandschaften

Plakativ gesagt, liegen IT-Projekte stets etwas «quer». Quer zu Organisationsstrukturen und Hierarchien, quer zu organisationationen Zielen, quer zu Prozessen, usw. Sie stossen (bewusst oder unbewusst) Veränderungen kleiner und grosser Art an und bringen häufig zwangsweise Menschen zusammen, die sich im «normalen» Alltag gerne aus dem Weg aus dem Weg gehen. IT-Projekten sind also auch Zwangsgemeinschaften, hinzu kommt ein weiterer erschwerender Faktor: Das Zusammenspiel mit externen Beratern oder Partnern.

So entsteht in IT-Projekten ein Beziehungsvieleck zwischen unterschiedlichsten Projektbeteiligten:

  • Die Fachabteilung, die für die Anwendung fachlich und finanziell verantwortlich ist.
  • Die Anwendenden innerhalb und manchmal auch ausserhalb der Organisation.
  • Die interne IT der Organisation, die für die Umsetzung, die Projektierung, den Betrieb, die Sicherheit usw. verantwortlich ist.
  • Die externen IT-Partner: Berater, Projektleiter, Softwarelieferanten usw.
  • Die Projektaufsicht (Auftraggeber, Steuerungsausschuss, usw.).
  • Weitere (politisch) interessierte Kreise.

Die Folge sind Konflikte mit verschiedensten Ursachen und Hintegründen:

  • Unterschiedliche Arbeitskulturen: Organisation A, mit Abteilung B und Aufraggeber N stellen beispielsweise Mitarbeitende in ein IT-Projekt. Jede Organisation, jede Abteilung ist dabei anders organisiert, hat andere Werte, andere Arbeitsweisen und eine andere Kultur der Führung, Zusammenarbeit und Konfliktbewältigung.
  • Rollen- und Kompetenzkonflikte: Die Mitarbeitenden im neu formierten Projektteam verfügen in ihren Heimatorganisationen jeweils über eine eigene hierarchische Funktion. Diese steht im Widerspruch mit der Rolle im Projekt. Projekte übersteuern immer wieder bestehende Hierarchien, Rollen und Kompetenzregelungen. Unterschiedliche Kompetenzregelungen oder Unterstellung an einen hierarchisch niedrigeren Projektleiter sorgen dann für Konflikte.
  • Zielkonflikte und Loyalitäten: Im neuen Projektteam gelten «weitere/andere» Aufgaben, Kompetenzen und Verantwortungen. Die Projektmitglieder sollen sich nun vollumfänglich den Zielen des Projekts verpflichtet fühlen und loyale Teammitglieder sein. Gleichzeitig appelieren ihre Heimatorganisationen an das Einhalten ihrer Ziele und fordern Loyalität ein. Diese Situation führt bei den Beteiligten zwangsweise zu unterschiedlichen Einschätzungen, Gefühlslagen und Reaktionen.

 

Drei Perspektiven auf die Konfliktlandschaft

Der Einfachheit halber greifen wir nachfolgend die drei klassichen Perspektiven in der IT-Projektarbeit auf. Die externen IT-Experten, die interne IT-Organisation und die Fachorganisation. Sie alle haben ihren eigenen Blick auf die Dinge und müssen doch gemeinsam ein Projekt stemmen.

Die Konfliktlandschaft der externen IT-Experten und -Berater

Externe IT-Experten stehen stets unter einem hohen Erwartungsdruck. Sie sollen interne Ressourcen ergänzen, fehlendes Wissen kompensieren, für einen schnellen Projektfortschritt sorgen, Vermittler zwischen den Fachabteilungen und der internen IT-Organisation sein, verantwortlich und loyal gegenüber dem Auftraggeber sein, ein Sparringpartner sein usw.

Ohne gut geklärten Auftragsrahmen sind, besonders in Zwangsauftragsbeziehungen (z.B. einziger Anbieter) oder unerwünschten Auftragsbeziehungen (Auswahl gemäss Kriterien der WTO, jedoch nicht Wunschfirma) Konflikte vorprogrammiert. Aus der Tatsache dass externe IT-Firmen ihre Leistung gegen Geld erbringen, erwächst zudem der Widerspruch zwischen wachsenden/sich verändernden Anforderungen des Kunden und dem offerierten Preis.

Konfliktfelder der externen IT-Experten und –Berater:

  • Klarheit im Auftragsverhältnis, besonders bezüglich Anforderungen an das Endprodukt (u.a. Werkvertrag vs. Dienstleistungsvertrag) und der Rolle als externen im Projekt (Aufgaben, Kompetenzen, Verantwortung).
  • Sündenbockfunktion.
  • Parallellaufende Aufträge in der gleichen Organisation, Doppelbauftragungen.
  • Unklarheiten bezüglich der Kommunikation und Reporting.
  • Unklare Situation bezüglich der Rechte und Verpflichtungen (Wer ist der Auftraggeber? Fachlich, vertraglich, …).
  • Unklare Rollendefinition bezüglich Change Requests, Tests, Abnahmen.

 

Die Konfliktlandschaft der Fachorganisation

In den Fachorganisationen treffen die Perspektiven der Nutzenden und des Auftraggebers aufeinander. Als Nutzer ist die Fachorganisation direkt von den Veränderungen des Projekts betroffen. Als Auftraggeber einer Software muss sie die Notwendigkeit der Investition und deren Nutzen aufzeigen können. Also beispielsweise ein Stopp des Stellenwachstums bei gleichzeitigem Wachstum der Kundenfälle (Effizienzgewinn).

Die Konfliktlandschaft der Fachorganisation:

  • Nutzen rechtfertigen, nachweisen und nach der Einführung realisieren.
  • Kulturelle, methodische und prozessuale Veränderungen bei den Mitarbeitenden anstossen und bewältigen.
  • Einflussmöglichkeiten auf die Qualität, das Ergebnis und die Kosten über den gesamten Produktionsprozess, trotz geringen IT-Fachkenntnissen, nehmen können.
  • Unklarheit in der Rolle Auftraggeber gegenüber IT-Abteilung und externen IT-Beratern.
  • Eigene Unklarheit über die wirklichen Anforderungen an die Software (fehlender klarer Business Case) und daraus folgende permanente Anpassung der Anforderungen.
  • Fachliche Überforderung mit der Komplexität von IT-Projekten.

 

Die Konfliktlandschaft der internen IT-Organisation

Die interne IT-Organisation steht häufig vor vielfältigen Rollenkonflikten. Vor allem dann, wenn Prozesse und Rollen in der IT ungeklärt oder übersteuert werden. Also, wenn z.B. der Leistungserbringer IT vom Leistungsbezüger Fachabteilung Rollen übernimmt. Wenn unklar ist, wer Auftragnehmer oder Auftraggeber ist oder wenn die finanzielle Verantwortung für die Finanzierung von Produktion und Betrieb unklar sind oder vermischt werden. Sehr häufig wirkt im Zusammenspiel mit der Fachorganisation der Mechanismus: Wer zahlt befiehlt.

Die Konfliktlandschaft der internen IT-Organisation

  • Forderungen zeitlicher, finanzieller und qualitativer Art.
  • Anforderungsmanagement: Fehlende Klarheit über den Business Case bei den Fachorganisationen Auftrag.
  • Positionierung der IT in der Organisation: Teuer, träge, unkommunikativ, unkooperativ, unverständlich, …
  • Doppelbeauftragungen.
  • Defensive Haltung in Konflikten, die häufig zu noch mehr Druck auf die IT führt.
  • Unklare Verantwortlichkeiten für die Entwicklungskosten und Betriebskosten.
  • Umgang mit Anliegen und Konflikten, die ins Projekt «gespült» werden und nichts mit der zu erstellenden IT Anwendung zu tun haben.
  • Rollen- und Zielkonflikte, wenn gleichzeitig die Gesamtprojektleitung in der IT liegt.
  • Unklare Rollendefinition bezüglich Change Requests, Tests, Abnahmen

 

Die restlichen Mitspieler

In IT-Projekten sind Fachorganisation, IT-Organisation und Externe selten alleine. Die Konfliktanalyse sollte daher die Steuerungsgremien des Projekts, Legal und Compliance, die Personabteilung, die Kommunikationsabteilung, das politische Umfeld und die Medien nicht ausklammern. Sie alle haben eine eigene Deutungshoheit über die Geschehnisse im Projekt, gesteuert durch ihre Ziele und ihren Kontext.

 

Vielfältige Handlungsstrategien im Konfliktfall

Macht, Regeln, Verhandlung. Das sind die drei grossen Optionen für die Konfliklösung. Im Detail sind es jedoch fünf Strategien zur Konfliktösung:

  1. Durchsetzen/Kampf (Win-Lose-Strategie, eigenen Interessen wird maximaler Vorrang gegeben)
  2. Kompromiss (Feilschen, Bazarlösungen führen oft an den Zielen des Projekts vorbei)
  3. Vermeiden (führt meist zu Verlusten auf beiden Seiten oder zu Eskalationen am Ende des Projekts)
  4. Nachgeben (Lose-Win-Strategie, eigene Interessen werden hinten an gestellt, was dauerhaft zu Unzufriedenheit führt, wenn die andere Seite nicht auch ein Mal nachgibt)
  5. Integration (Win-Win, Kooperativer Ansatz der den eigenen und fremden Interessen und Bedürfnissen gleichermassen Platz für die Lösung eingeräumt.)

Auch in IT-Projekten werden Konflikte häufig «hoffnungsvoll ausgesessen», bis der Konflikt so stark eskaliert, dass eine Verhandlungslösung ohne externe Hilfe nicht mehr möglich scheint. Der Griff in die giftige Macht-Kiste bereinigt dann zwar das Terrain, doch zerstört er auch gleichzeitig das Vertrauen. Manchmal so nachhaltig, dass sach- oder lösungsfokussiertes Verhandeln gar nicht mehr möglich ist. In dieser eher giftigen Konfliktdynamik greifen die Beteiligten dann zu unterschiedlich harten und beziehungsschädigenden Optionen.

Die Optionen der externen IT-Berater:

  • Der Vertrag. Sofern dieser gut formuliert ist, ist er ein mächtiges Mittel um unberechtigte Forderungen abzulehnen. Die Folge ist eine verrechtlichung des gesamten Projektprozesses. Meist sind Anwälte stete Begleiter in Projektausschussitzungen.
  • Disziplin bei der Protokollführung und Dokumentation. Starker Fokus auf Verschriftlichung im Miteinander: Protokolle, Aktennotizen, schriftliche Abnahmen und Vereinbarungen. Fokus auf ein starkes Regelwerk.
  • Kunden seinerseits in Leistungsverzug setzen. Bedingt jedoch verbindliche Terminpläne in denen die Leistungen aller Beteiligten festgehalten wurden.
  • Leistungsverweigerung, wenn der Kunde die von ihm zu liefernden Leistungen nicht in der formulierten Zeit und im formulierten Umfang leistet. Bedingt ein sehr strenges Projektmanagement auf Lieferantenseite.
  • Jegliche Umsetzung nur mit schriftlicher Abnahme der Anforderungen. Ohne Freigabe der Anforderungen keine Leistungen.

Die Optionen der internen IT-Abteilung:

  • Abnahmen verweigern/verzögern. Bedingt sehr klare vertraglichen Abmachungen und Anforderungsbeschreibungen.
  • Disziplin bei der Protokollführung und Dokumentation. Starker Fokus auf Verschriftlichung im Miteinander: Protokolle, Aktennotizen, schriftliche Abnahmen und Vereinbarungen.
  • Die Loyalitätsfrage. Appell an die Ehre des Lieferanten das Projekt erfolreich zu Ende zu bringen. Angriffe auf die Reputation in der Öffentlichkeit.
  • Die Rechtskeule. Verschriftlichung und sofortige in Verzugsetzung des Lieferanten mit dem Rechtsdienst.
  • Druck und Verantwortung an den Auftraggeber, die Fachorganisation abgeben: Schuld ist der unklare Business Case.

Die Optionen der Fachorganisation:

  • Abnahmen verweigern. Mit dem Hinweis, dass die Leistungen nicht vollumfänglich erbracht wurden, für die Mitarbeitenden nicht verständlich sind, den Anforderungen nicht genügen.
  • Verweigerung der Mitarbeit im Projekt. Stellen von Mitarbeitenden mit geringer zeitlicher und /oder fachlicher Kompetenz oder ohne Entscheidkompetenzen. Generelle Verweigerung der Zusammenarbeit: Nichterscheinen in Sitzungen etc.
  • Anpassungen in den Anforderungen. Ihr habt uns nie richtig zugehört / verstanden.
  • Obstruktion in der Projektführung. Sitzungen ohne alle wichtigen Beteiligten, Ablehnen der Protokolle, Verweigerung von Entscheiden, Einschalten weiterer Spieler und Hierarchieebenen.
  • Stete Eskalation nach oben. Schutz von einer nächsthöheren Macht erhalten.

Nicht nur die gewählten Handlungen, sondern auch die Beziehungen der einzelnen Beteiligten untereinander sind massgebend für den Konfliktverlauf. Unterschiedliche Koalitionenbildungen sorgen für eine jeweils andere Konfliktdynamik.Egal welche Koalition entsteht, die Konfliktlösung liegt mit der Koalitionsbildung bereits auf einer Eskalationsstufe, bei der die Beteiligten aus der Win-Win-Zone in die Win-Lose-Zone treten. Häufig ist ab dieser Stufe eine selbstbestimmte Konfliktlösung kaum mehr möglich. Mit Bildung von Koalitionen geht es nicht mehr um die Sache, sondern um das Gewinnen. Auf Kosten eines Verlierers.

 

IT-Projekte mit integrierter Mediation und integriertem Konfliktmanagement – Die Lösung?

Konflikte verhalten sich selten linear und statisch. Im Gegenteil, sie entwickeln sich aus der Dynamik der Situation. Sie können jederzeit entstehen oder sind stets vorhanden. Konflikte und die Themen die sie tragen sind wichtige Informationen über das Projekt. Sie sind damit ein guter Indikator für das Klima im Projekt oder für Themen die eine höhere Aufmerksamkeit benötigen. In diesem Sinne sind Konflikte der Fieberthermometer, den es im Sinne der Projektziele stets gut zu lesen gilt.

Das Problem in vielen IT-Projekten ist, dass der Fieberthermometer nur zu Beginn angelegt wird. Zielkonflikte werden z.B. gemäss Hermes 5 bei der Initialisierung (vom Auftraggeber) bereinigt. Danach sollten sie (scheinbar) nicht mehr entstehen. Dabei wird vergessen, dass sich im Zeitverlauf des Projektes Ziele, Rahmenbedingungen, Menschen usw. durchaus verschieben. Der Fieberthermometer ist also regelmässiger anzusetzen.

Dies bedingt jedoch ein in die Projektmethodik integriertes Konfliktmanagementsystem inklusive Projektmediation. Ersteres wird übrigens häufig unter dem Risiko- und Stakeholder-Management subsummiert. Projektmediation als integrierte Konfliktklärungsalternative ist in den meisten Projektmanagementmodellen zudem gar nicht existent. Dabei das Konfliktmanagement ein in das Projektmanagement integrierter eigenständiger Prozess sein und aus Massnahmen zur Aufdeckung, Analyse, Vermeidung  und kooperativen Bewältigung von Konflikten bestehen. In diesem Sinne sollte es auch klare Prozesse und Mechanismen Konfliktösung wie Konfliktberatung, -coaching, Projektmediation usw. enthalten. Die Hauptziele: Konfliktkosten reduzieren, einen möglichst ziel- und lösungsfokussierten Projektverlauf ermöglichen, Erkenntnisse aus den Konflikten gewinnbringend für Projekt und Organisation nutzen. In der Folge müssten sich Projekte daher ebenso systematisch mit Konflikten auseinandersetzen wie mit Risiken und anderen Themen.