Ausgebrannt

Ein Projektteam zerfällt

Noch vor wenigen Monaten ist das Team hoffnungsfroh in das Projekt gestartet, doch inzwischen sieht es seine Situation als "Mission Impossible". Dass es so weit gekommen ist, liegt nicht nur an widrigen Rahmenbedingungen – eine wesentliche Rolle spielen auch gruppendynamische Prozesse. Welche Fallstricke hier lauern und wie man diese vermeidet, zeigt Gero Lomnitz in seiner Analyse eines Praxisfalls. Eine Checkliste hilft bei der Teamdiagnose.
Ausgebrannt

Ein Projektteam zerfällt

Noch vor wenigen Monaten ist das Team hoffnungsfroh in das Projekt gestartet, doch inzwischen sieht es seine Situation als "Mission Impossible". Dass es so weit gekommen ist, liegt nicht nur an widrigen Rahmenbedingungen – eine wesentliche Rolle spielen auch gruppendynamische Prozesse. Welche Fallstricke hier lauern und wie man diese vermeidet, zeigt Gero Lomnitz in seiner Analyse eines Praxisfalls. Eine Checkliste hilft bei der Teamdiagnose.

Burnout ist mittlerweile ein etablierter Begriff, der sich nicht nur auf einzelne Personen bezieht, sondern auch für Teams (Fengler, Sanz, 2011) und sogar für Organisationen benutzt wird (Greve, 2010). So stand in der Computerwoche vom 3.5.2014: "Immer häufiger geraten tatsächlich ganze Arbeitsgruppen in die Burnout-Falle" (Funk, 2014). Doch ist es überhaupt sinnvoll, von einem "ausgebrannten Team" zu sprechen? Ist Burnout nicht immer gebunden an eine einzelne Person, wobei sich die Folgen in erheblichem Maße auf andere Teammitglieder und letztlich auf das gesamte Team auswirken können?

Ich meine, dass Begriffe wie "Team Burnout" oder "ausbrannte Projektteams" nicht sinnvoll sind, denn nur Individuen können ausbrennen. Klar, wenn eine kritische Zahl von chronisch erschöpften Teammitgliedern erreicht ist, dann kann das Team seine Aufgabe nicht mehr erfüllen. Die Ziele werden nicht erreicht, Konflikte und Hoffnungslosigkeit machen sich breit, das Team kann zu Grunde gehen. Das gilt für Fußballteams und für Projektteams gleichermaßen, wobei sich die Symptome in einem Fußballteam sehr viel schneller zeigen.

Lohnt es sich nach diesen Überlegungen überhaupt, über den Zerfall eines Teams zu schreiben, wenn Burnout an die einzelne Person gebunden ist? Ich meine ja, denn es lohnt sich, die Einflüsse der gruppendynamischen Prozesse und des Teamumfelds auf den Niedergang eines Projektteams zu verstehen. Was mich interessiert, ist die Ansteckungsgefahr von Burnout innerhalb eines Teams.

Ein Praxisfall

In diesem Beitrag beschreibe ich den Zerfall eines Projektteams, der schleichend begann, und zuletzt mit hoher Geschwindigkeit zum endgültigen Niedergang des Teams führte. Ich habe im Titel des Beitrags bewusst auf das Etikett "Team Burnout" verzichtet und stattdessen den Titel "Zerfall des Teams" vorgezogen, auch wenn "Burnout des Projektteams" moderner und attraktiver klingen mag. Anhand dieses konkreten Falls aus der Praxis werde ich folgenden Fragen nachgehen:

  1. Welche Rolle spielen das Verhalten, die persönliche Einstellung und die Werte des Individuums? Wir werden sehen, dass diese Faktoren eine zentrale Rolle für den Niedergang des Teams spielten und ich gehe davon aus, dass diese Einflussfaktoren auch für andere Projektteams bedeutend sind.
  2. Welche Kommunikationsmuster und welche Teamkultur führten dazu, dass der Funke im Team von einem auf den anderen überspringen konnte? Warum haben sich Teammitglieder nicht rechtzeitig abgegrenzt? Warum hat das Team sich nicht geschlossen gegen die extreme, auf Dauer unzumutbare Belastung gewehrt? Was ist innerhalb des Teams passiert und welche Konsequenzen ergeben sich daraus für die Praxis?
  3. Individuum – Teamkultur – Organisation, alle drei beeinflussen das Subsystem Projektteam. Die Probleme des Teams sind untrennbar mit den Problemen des Unternehmens verbunden. Ich bin davon überzeugt, dass chronische Überlastung von einzelnen Projektmitarbeitern und die daraus resultierenden Probleme für ein Team nur verstanden und beeinflusst werden können, wenn wir den Einfluss der Organisation – von ihren gelebten Werten bis zu den Arbeitsmitteln des Teams – berücksichtigen. Sie werden in meinem Beitrag keine kritische Analyse zu Unternehmenswerten und ‑kulturen finden oder Gedanken zur Beschleunigung und Entfremdung in unserer Gesellschaft, wenn auch die Beschäftigung mit diesen Themen notwendig ist, um das Thema ganzheitlich zu begreifen (siehe Buchempfehlung im Abschnitt "Literatur"). Stattdessen möchte ich Anregungen bieten, wie sich Projektmitarbeiter als Teil des Teams verhalten können, wenn der Leistungsdruck zur chronischen Überlastung führt.

Der Leser sollte zunächst wissen, in welcher Beziehung ich zu diesem Projektteam stand. Auf Wunsch des gesamten Teams und mit Zustimmung des Managements hatte ich das Team eine Zeitlang beraten. Als die Beratung begann, arbeitete das Projektteam bereits seit acht Monaten. Die Symptome traten deutlich zu Tage; sie konnten weder von der Projektleiterin, von den Projektmitarbeitern noch von den Vorgesetzten verdrängt werden. Die Beratung wurde beendet, bevor das Team endgültig auseinanderbrach.

Sie werden also keine Erfolgsstory lesen nach dem Motto "Der gute Coach konnte durch seine richtigen Interventionen das Team retten", sondern ich möchte die Prozesse im Team – vor allem in der kritischen Phase – und die untrennbar damit verbundenen Verhaltensweisen der Akteure beschreiben, die zum Zerfall des Teams führten. In der Praxis gibt es sicherlich spezifische Einflussfaktoren, die zum Niedergang eines Teams führen können und die im Rahmen einer Teamdiagnose zu beachten sind. Dennoch bin ich überzeugt, dass der hier beschriebene Fall exemplarische Züge aufweist, die sich auf den Zerfall anderer Teams übertragen lassen.

Projekt und Projektteam

Die herausfordernde Ausgangslage

Zunächst ein kurzer Überblick über das Projektziel, das organisatorische Umfeld und die Struktur des Teams. Diese Informationen sind wichtig, um die Ereignisse zu verstehen.

In einem größeren Finanzdienstleitungs-Unternehmen hatte das Projektteam vom Vorstand die Aufgabe bekommen, eine neue Software für die Abwicklung von finanziellen Transaktionsprozessen zu implementieren.

  • Das neue SW-System hatte große Bedeutung für den Handel mit Finanzprodukten, dementsprechend hoch war die Priorität des Projekts.
  • Der Endtermin des Projekts war markt- und unternehmensbedingt sehr anspruchsvoll, der Zeitdruck für alle Beteiligten extrem.
  • Die Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) machte inhaltliche und zeitliche Vorgaben, die zwingend einzuhalten waren.
  • Mit der Aufgabenstellung waren veränderte Geschäftsprozesse verbunden. Die internen Schnittstellen zu diversen…

Bewertungen und Kommentare

(nur angemeldete Benutzer)

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
Gesamt
Bewertungen 21
Kommentare 4

Alle Kommentare

Hans-Heinz
Maier
Hallo, ein interessanter Artikel. Wie löst man so ein Problem? Ganz einfach: - Man reduziert die Anforderungen. Und das in einem harten, mehrstufigen Ringen, da sollte man den Aufwand investieren, immer mit der Frage an die Programmierer und Anwender: - welche Funktion / Eigenschaft bringt besonders viel Aufwand, können wir das weglassen oder vereinfachen? Am Ende des Projektes war es dann ja auch so, aber ungeplant und mit viel Stress.
Jürgen
Sturany
Die Projektleiterin hat offensichtlich das Magische Dreieck "vergessen". Es ist noch NIE besiegt worden, noch NIE! Kollege Hans-Heinz Maier sieht dies in seinem Kommentar ganz realistisch. Beratung und Coaching ist ein Unterschied Herr Lomnitz - aber das wissen Sie bestimmt. Was wurde nun geleistet? Beratung oder Coaching? Sie schreiben Zitat:" ...damit war die Beratung beendet..." also doch Beratung. Möglicherweise wäre es hilfreich sich an die Basics (Magisches Dreieck, Bruce Tuckman, holistischer Ansatz etc.) zu erinnern auch wenn man in einem Burnout berät (ich spreche aus eigener Erfahrung). In jedem Fall danke ich herzlich für Ihre Mühe einen Fall zu schildern wie er so oder so ähnlich häufig vorkommt - nochmals mein ausdrücklicher DANK für das exzellente Beispiel!
Claudia
Payer
Klasse Beitrag, mehr davon! Es gibt so viele Bücher zu PM-Methodik und viel zu wenig Erfahrungsberichte. Ich rate im übrigen dazu, bereits früh in Projekten Review-Zyklen (Lessons Learned) durchzuführen, da oft Mitarbeiter das Projekt vorzeitig verlassen bzw. abgezogen werden. Damit gehen wichtige Erfahrungen und Erkenntnisse verloren, die auch das laufende Projekt noch auf Kurs bringen können. Außerdem kann auch Positives reflektiert werden, was dem Team wertvolle Motivation geben kann. Für mich ist dieser Beitrag nach meinem letzten Krisenprojekt außerordentlich aufschlussreich und stützt meine These, dass auch "Bedenkenträger" eine wichtige Rolle im Projekt spielen. Diese liefern Input für das Risklog.
Hans-Heinz
Maier
Sehr geehrter Herr Lomnitz, beschreiben Sie doch bitte kurz, was Sie dem Projekt in den einzelnen Problemphasen geraten haben. Ich hatte in 5 größeren SW-Projekten einen Auftrag als Berater, kein einziger Ratschlag wurde befolgt. Dann habe ich nur noch folgendes gemacht: Ich habe das Projekt analysiert und überlegt, wo das Problem liegt: - Ist es der PL, ist es der Auftraggeber der schlicht nervös ist, oder sind die Probleme im Normalbereich. Dann habe ich das Resultat als Ergebnis abgegeben und die Beratung beendet. Ich glaube folgendes: Wenn man meint, ein Projekt braucht einen Berater, dann sollte man stattdessen sofort den PL austauschen. mfg Maier
Alle anzeigen