Aus dem Homeoffice: ISR Kollegen*Innen packen aus und berichten von ihren Erfahrungen mit dem Eskalationsmanagement bei ihren Projekten.
Das kleine 1×1 aus Projektmanagement-Methoden beherrscht das #TeamISR im Projektalltag nur zu gut.
In den vergangenen Blogposts haben wir spannende und vor allem persönliche Einblicke in die Stakeholderanalyse, das persönliche Kanban, die Timeboxing Methode und das virtuelle Kommunikationsmanagement
gegeben. Bei diesem Blogpost ist alles anders: nicht nur eine Person gibt Einblicke in das Eskalationsmanagement bei Projekten, sondern gleich eine ganze Schar an KollegenInnen. Aber warum haben wir uns für das Thema entschieden? Bernward Ketteler (Service Manager) fasst unseren Beweggrund gut zusammen und liefert zusätzlich ein selbstbewusstes Statement: „Vor einer Eskalation haben die meisten Projektbeteiligten Angst. Ich habe da eine andere Einstellung.“ Wir wollen Ihnen die Angst nehmen und erreichen, dass Sie mit dem Eskalationsmanagement ab sofort etwas Positives verbinden – so wie wir bei ISR!
Eskalationsmanagement? Was meinen wir „Projektnerds“ damit?
Was wir nicht meinen: Kleine Konflikte, die sich durch gemeinsame Diskussionen im Team auf der operativen Ebene wieder erledigen. Diese Konflikte werden im Eskalationsmanagement nicht behandelt.
Was wir meinen: Wenn eine Hierarchieebene ein auftretendes Problem nicht selbst lösen kann, dann sprechen wir von Eskalationsmanagement. Eskalationen sind in vielen Köpfen negativ besetzt. Es meint aber eigentlich nur einen Projektautomatismus, bei dem festgelegt ist, wer, wann und in welcher Form ein eskalationsrelevantes Thema an die nächst höhere Entscheidungsebene weitergibt (siehe Abbildung 1). In diesem Zusammenhang hört man die ein oder andere projektbeteiligte Person oftmals sagen: „Das müssen wir eskalieren!“
Abbildung 1: Eskalationspyramide
Wie eskaliert man richtig?
Meistens treten eskalationsrelevante Themen auf der operativen Projektebene auf, da hier oftmals keine ausreichenden Mittel, Handlungsspielräume oder Kompetenzen vorliegen, um Maßnahmen zur Behebung des Problems einzuleiten oder eine kritische Entscheidung selbstständig und entlang der definierten Kompetenzen zu treffen. Demnach wird die administrative Ebene kontaktiert. Sollten auch hier die Handlungsspielräume nicht ausreichen, dann wird auf die Hilfe der strategischen Ebene zurückgegriffen. Eine Eskalation sollte allerdings nur dann stattfinden, wenn das Projektteam alle anderen denkbaren Möglichkeiten ausgeschöpft hat. Dadurch, dass eine höhere Instanz in das Projekt einwirkt, hat dann das Team inkl. Projektleiter i.d.R. nicht mehr die Möglichkeit, ohne fremde Hilfe zu interagieren. „Die emotionale Ebene muss – wenn möglich – außen vor bleiben, so dass auf sachlich, konstruktive Weise die Schwierigkeiten analysiert, erkannt und dann aus dem Weg geräumt werden können“ (Sandra Bartke, Senior Consultant). Bei ISR haben wir für das Eskalationsmanagement interne Eskalationsrichtlinien festgelegt, die für die ProjektkollegenInnen auf Confluence frei zugänglich sind.
Mark Hommolas (Head of Business Unit – Business Process Automation) Statement zu Eskalationen: “Eskalationen sind für die meisten Menschen unangenehm und stellen eine Gefahr oder Bedrohung dar. Dies ist aber genau der falsche Ansatz, denn Eskalationen sind ein wichtiges organisatorisches Mittel, um festgefahrene Situationen im Projekt auf einer höheren Ebene zu entscheiden. Und da gehören diese Entscheidungen auch hin. Es wäre viel schlimmer, wenn die Entscheidung auf der Ebene darunter gefällt wird und dann merkt man erst viel zu spät, dass diese Entscheidung falsch getroffen wurde.”
Die drei Phasen von Eskalationen
Nach den Interviews der ISR KollegenInnen zu ihren Erfahrungen und Erkenntnissen mit Eskalationsmanagement haben sich drei Phasen herauskristallisiert (siehe Abbildung 2).
Anbahnungsphase (Phase 1):
“Eskalationen in Projekten sind nicht grundsätzlich schlecht. Um in schwierigen Projektsituationen Klarheit zu schaffen, ist es immer gut, die Dinge zuerst offen anzusprechen und klar mit allen Beteiligten zu kommunizieren.“ (Birger van der Spek, Business Team Lead, Business Process Automation)
Eskalationsphase (Phase 2):
„Sieht sich das Projekt dann trotz Transparenz nicht in der Lage die Situation aufzulösen und zu entscheiden, dann hilft die aktive Eskalation z.B. an den zuständigen Lenkungsausschuss (strategische Ebene)! Das Projekt wird entlastet und kann nach der Entscheidung unter klaren Vorgaben weiter arbeiten.” (Birger van der Spek, Business Team Lead, Business Process Automation)
Wichtig hierbei ist, dass jede Eskalation mit einem entsprechenden Entscheidungstemplate aufbereitet und dem Entscheiderkreis zur Verfügung gestellt wird.
„Neben der Aufarbeitung bestehender Probleme, steht selbstverständlich auch die Planung der Folge-Schritte im Fokus. Diese Planung muss abgestimmt und von allen Projektverantwortlichen getragen werden. Alle Beteiligte müssen zudem bereit sein, an einer Lösung mitzuwirken. Eingeleitete Schritte müssen überwacht werden. Ein starker Austausch der einzelnen Parteien während der Eskalation und die Kontrolle des Fortschritts sind hier wichtig.“ (Sandra Bartke, Senior Consultant, Business Process Automation)
Reflexionsphase (Phase 3):
„Das Zusammentragen von Lessons Learned nach der Eskalation halte ich ebenfalls für sinnvoll.“ (Sandra Bartke, Senior Consultant, Business Process Automation)
In der Reflexionsphase wird über die getroffene Entscheidung reflektiert und notfalls können mögliche Nachjustierungen durchgeführt werden. Das soll aber auf keinen Fall bedeuten, dass getroffene Entscheidungen sofort wieder hinterfragt werden. Wir wollen hiermit lediglich sagen, dass Entscheidungen eine Reflektion benötigen, um vom Gesamtprojekt akzeptiert zu werden und einen möglichen Weg für zukünftige Entscheidungen zu ebnen.
Abbildung 2: Phasen des Eskalationsmanagements
Welche Konflikte und Probleme sollten eskaliert werden?
Es gibt sicherlich Unterschiede von Projekt zu Projekt, aber folgende Situationen sollten definitiv über den definierten Eskalationsweg entschieden werden:
- Ressourcenkonflikte (z.B. Budget, Zeit, Personal)
- Qualitätsprobleme (z.B. Nicht-Einhaltung von Standards)
- Prioritätenkonflikte (z.B. Fokus auf Projekt A oder B)
- Zielkonflikte zwischen verschiedenen Stakeholder (z.B. Auftraggeber und Auftragnehmer)
- Strategische Entscheidungen (z.B. Ausweitung des Projektangebots auf eine neue Zielgruppe)
Bernward Ketteler (Business Team Lead, Business Process Automation) erklärt: „Wenn das Projekt nicht aus eigener Kraft weiterkommt, dann darf sich das Projektteam Hilfe auf anderer Ebene holen. Genau das meint ja auch “Eskalieren”. Die Hilfe kann dann z.B. in Form von zusätzlichen sachlichen Ressourcen oder Zeit oder einfach der Priorisierung gegenüber anderen Aufgaben oder Projekten kommen.“
Wann? When? Cuando? Das Timing der Eskalation ist entscheidend!
„Eine frühzeitige Ansprache von potenziellen Konflikten und eine offen Kommunikation sind bei der Eskalation sehr hilfreich“ (Sandra Bartke, Senior Consultant, Business Process Automation). Allerdings sollten Sie sich auch bewusste sein, dass eine zu frühe Eskalation zu Vorwürfen an den/die ProjektleiterIn und eine zu späte Eskalation zu ungewollten Zeit- und Budgetüberschreitungen führen kann. Wir sind uns sicher, dass die folgenden Projektsituationen sehr gute Indizien für eine notwendige Eskalation sind und damit einen Richtwert für einen guten Handlungszeitpunkt darstellen.
- Wenn der Kompetenzbereich auf der Ebene, wo das Problem aufgetreten ist, erschöpft ist.
- Wenn Probleme wiederholt im Team diskutiert werden.
- Wenn es relevante Abweichungen vom definierten Lösungskonzept gibt.
Optimalerweise sind solche Timings bereits in Ihrem Unternehmen allgemeingültig festgelegt worden. Recherchieren Sie doch gerne mal. Sollte dies nicht der Fall sein, dann empfehlen wir Ihnen das Thema „Eskalationsmanagement“ in Ihrem Unternehmen anzusprechen und entsprechende Eskalationsrichtlinien festzulegen.
Was haben Sie heute über das Eskalationsmanagement gelernt? Ein Überblick.
- Unter Eskalationsmanagement wird ein definierter und gewollter Prozess innerhalb eines Projektes verstanden, um Entscheidungen auf die nächst höhere Ebene zu delegieren.
- Das Eskalationsmanagement kann in drei Phasen gegliedert werden: Anbahnungs-, Eskalations- und Reflexionsphase.
- Das richtige Timing der Eskalation ist ausschlaggebend.
- Eskalationen im Projekt sollten positiv besetzt sein, weil Eskalationen projektrelevante Entscheidungen treffen und somit den Erfolg des Projektes garantieren.
Haben Sie immer noch Angst vor Projekt-Eskalationen?
Dann sprechen Sie uns gerne an! Wir haben ein paar weitere Ideen und Anregungen, wie man mit diesem häufig unangenehm wahrgenommenen Thema umgehen kann. Hierzu abschließend noch eine aufmunternde Aussage von Sandra Bartke (Senior Consultant, Business Process Automation): „Es geht bei der Eskalation nicht darum, einen Schuldigen ausfindig zu machen, sondern eine praktikable Lösung zu finden, die alle Parteien gutheißen.“
Mark Hommola
Head of Business Process Automation
Business Process Automation
mark.hommola@isr.de
+49(0)151 422 05 426
