Wissen 43 projektManagementaktuell | ausgabe 1.2016 Aufgrund des steigenden Innovationsdrucks werden die Produkte in der Automobilindustrie bei gleichem Produktlebenszyklus immer komplexer. Dabei bewegt sich die Projektpriorisierung stets im klassischen Dreieck Kosten, Zeit und Qualität. Der steigende Kostendruck führt zu Sparmaßnahmen, die wiederum die Zeit und Qualität des Projektes beeinflussen. Wird zu hohe Priorität auf eines der drei Ziele gelegt, so kommt es zu einer Problemsituation. Die Folge daraus sind häufig Eskalationen. Im Folgenden werden drei Phasen unterschieden: 1. Vor der Eskalation - fehlende Grundlagen 2. Während der Eskalation - mangelhafte Durchführung 3. Nach der Eskalation - keine konkrete Maßnahmenumsetzung Innerhalb dieser drei Phasen gibt es verschiedene Herausforderungen, die zum Scheitern der Eskalation führen können. Es werden Best Practices beschrieben, wie sie angegangen werden können. Vor der Eskalation - Fehlende Grundlagen Die Eskalation kann bereits vor der Durchführung scheitern, wenn die Grundlagen nicht gelegt worden sind. Für eine einfache Orientierung gilt: Es ist zu zeigen, was die Grundlagen der Eskalation sind. Im Folgenden wird auf die nachstehenden vier Punkte eingegangen: 1. Rollendefinition ist nicht vorhanden oder unklar formuliert 2. Eskalationsprozesse sind im Unternehmen nicht vorhanden oder nicht vollständig definiert 3. Kommunikationsmatrix und Eskalationsstufen sind nicht vorhanden 4. Interne und externe Eskalationswege fehlen 1. Rollendefinition ist nicht vorhanden oder unklar formuliert In einem Entwicklungsteam müssen im Projekt klar Rollen zugewiesen werden. Dies ist nicht nur erforderlich, um alle technischen Inhalte umzusetzen, sondern auch, um Verantwortliche im Rahmen einer Eskalation klar definieren zu können. Zu jeder Rolle gehören Themen, die passend zur Tätigkeit eskaliert werden können. Im Rahmen einer agilen Entwicklung zum Beispiel nach SCRUM (einem Framework für das Vorgehen im Projekt- und Produktmanagement) kommen zusätzliche Rollen bzw. Aufgaben hinzu, die entsprechend geplant werden. Dies ist beispielsweise der SCRUM Master, der dafür verantwortlich ist, dass der Vorgehensrahmen SCRUM verstanden und eingehalten wird. Ein SCRUM Master kann bei mangelhafter Kommunikation und Zusammenarbeit im Team eskalieren. Eine weitere Rolle in Entwicklungsteams ist die der Projektqualität. Sie hat die Aufgabe, bei einem Missstand von Produkt- oder Prozessqualität zu eskalieren. Ein Beispiel an dieser Stelle ist, wenn die Abarbeitung nach einem gewählten Key Performance Indicator (KPI), wie z. B. „Implementiert und getestet“, nicht bei einem vereinbarten Abarbeitungsstand von 100 % liegt. Dann sollte eine Eskalation an die definierte nächste Ebene vorgenommen werden. Ein Projektleiter muss den Eskalationsprozess einleiten, wenn er erkennt, dass beispielsweise das Timing nicht eingehalten werden kann. Für den Projektleiter ist dabei die Meilensteintrendanalyse ein mögliches Werkzeug, um zeitnah einen Eskalationszeitpunkt zu erkennen und die Eskalation gemäß einem definierten Prozess auszulösen. Auch Entwickler können technische Themen eskalieren. Für eine Abteilung ist es daher wichtig, dass jeder das Bewusstsein für seinen Verantwortungsbereich hat und bei Notwendigkeit eine Eskalation als Maßnahme ergreift. In der Praxis müssen sowohl Verantwortliche als auch zu informierende Rollen klar definiert sein. Die Autoren empfehlen ein RASI (Responsible, Action, Support, Information)-Chart im Prozess zu definieren und die Rollen dann projektbezogen zu verteilen. Es ist wichtig, eine Eskalation konkret an eine Rolle beziehungsweise einen Ansprechpartner zu adressieren. Eine ungerichtete Kommunikation führt zum Scheitern einer Eskalation, da es hier keinen Verantwortlichen gibt, der das Thema weiterführt und die Lösungsfindung vorantreibt. Ein Beispiel ist die Eskalation eines Testfehlers via E-Mail an das ganze Projektteam - die Kommunikation ist nicht an eine konkrete Person gerichtet und wird in den meisten Fällen nicht verfolgt. Wird ein kritisches Thema identifiziert, so muss jedem Projektteammitglied bewusst sein, wer für das Thema zuständig ist und an wen eskaliert werden muss. Die Definition einer 10 Gründe, warum Eskalationen scheitern >> Für eilige Leser Eine Eskalation ist eine kritische Situation, in der der aktuell handelnden Ebene keine Option mehr zur Verfügung steht, über die sie eigenständig entscheiden kann. Kennzeichnend ist daher, dass eine Entscheidung fehlt oder getroffen werden muss. Die eskalierende Person bittet daher die höhere zuständige Ebene um Entscheidung, einen Input bzw. um Vorgabe einer Richtung von außen. Merksatz Eskalation: „Eskalation so hoch wie möglich, aber nur so hoch wie nötig.“ autoren: Tanja Hupf, Turgay sahin PM-aktuell_1-2016_Inhalt_01-68.indd 43 29.01.2016 8: 20: 03 Uhr projektManagementaktuell | ausgabe 1.2016 44 Wissen dene Tools oder Dokumente integrieren lässt. Die Dokumentation einer Eskalation soll kein separates Dokument sein, das getrennt gehandhabt und gegebenenfalls verlegt wird. Ein Beispiel für die Integration in ein Tool ist bei einem taskbasierten System wie PTC Integrity die Nutzung eines entsprechenden Feldes. Auch kann die Eskalation im Projekt-Report oder in der Projekt- LOP (List of Open Points) verfolgt werden. Eine weitere Schwierigkeit besteht im Führen von Protokollen. Das Führen eines Protokolls ist eine Grundfähigkeit für viele Rollen im Projekt und darf nicht unterschätzt oder vernachlässigt werden. In Projekten kann es passieren, dass Protokolle gar nicht oder falsch geführt werden. Wird ein Protokoll erstellt, ist darauf zu achten, dass folgende Inhalte vollständig sind: Beschreibung der Herausforderung oder des Problems sowie Definition eines Termins bis hin zur Bestimmung eines Verantwortlichen. 3. Kommunikationsmatrix und Eskalationsstufen sind nicht vorhanden Eine Eskalation hat viele Stufen und kann sich durch viele Hierarchieebenen bewegen (Abb. 2). Es ist zu beachten, dass technische Themen auch projektübergreifend relevant sein können. Können Termine nicht eingehalten werden, was Tracker-Tool) und kann spezielle Templates zur Verfügung stellen. Weiterhin kann es passieren, dass eine Eskalation nicht wahrgenommen wird, da sie nicht klar und nicht an die richtige Person eskaliert wurde. Ein Beispiel wäre hier, dass dem Eskalationsempfänger gar nicht bewusst ist, dass er etwas entscheiden soll, weil die Formulierung das nicht nahelegt. Im Projektumfeld kann dies bei einer Meldung von sicherheitskritischen Fehlern als FYI im Betreff einer Mail der Fall sein. Ein anderes Bespiel sind fehlende Informationen in der Beschreibung eines Fehlers, sodass die Notwendigkeit für eine Eskalation nicht erkannt wird. Die Folge eines solchen Versäumnisses ist die Eskalation durch den entsprechenden Kunden oder das Management zu einem späteren Zeitpunkt. Wenn kein Prozess definiert ist, kann es passieren, dass es nie zum Abschluss einer Eskalation kommt, da das Thema nie formal abgeschlossen wurde und in Vergessenheit geraten ist. Daraus erkennt man, dass eine Eskalation ohne definierte Prozesse zum Scheitern verurteilt ist. Die Autoren empfehlen deshalb, die Projektteams über Methode und Form einer Eskalation zu schulen. Die Dokumentation einer Eskalation soll möglichst einfach gehalten werden. Die Autoren raten zu einer Dokumentationsform, die sich in vorhan- Aktion für die Abarbeitung mit Verantwortlichkeit und Zeitpunkt ist an dieser Stelle unerlässlich. 2. Eskalationsprozesse sind im Unternehmen nicht vorhanden oder nicht vollständig definiert Aufbauend auf der erläuterten Rollenverteilung (RASI) soll in einem Unternehmen ein vollständiger und verständlicher Eskalationsprozess definiert und etabliert sein. Es muss sichergestellt sein, dass jeder Mitarbeiter Zugang zu der Prozessdefinition hat und darüber informiert wird. In der Praxis kann für die Sicherstellung ein Prozessportal eingesetzt werden, in dem die entsprechenden Prozesse, Rollen und Templates zur Verfügung gestellt werden. Zu dem Eskalationsprozess gehört der Prozessablauf, der sowohl Input-/ Output-Dokumente jedes Prozessschrittes als auch die betroffenen Rollen enthält. Weiterhin gehören zu dem Prozess Templates und Richtlinien, wie beispielsweise Kommunikationsrichtlinien (siehe Punkt 3). Diese Rollen werden dann jeweils unterteilt in Verantwortung, Mitarbeit und Information (Abb. 1). Im Prozessablauf sind die Vorbereitung, Durchführung und die Aktivitäten nach der Eskalation beschrieben. Ein Unternehmen muss sich dann für zu verwendende Medien entscheiden (Telefon, Mail, Ablagesystem, Problem- Abb. 1: Beispielhafter Eskalationsprozess mit RASI und Input-/ Output-Dokumenten PM-aktuell_1-2016_Inhalt_01-68.indd 44 29.01.2016 8: 20: 04 Uhr Wissen 45 projektManagementaktuell | ausgabe 1.2016 diese Möglichkeiten, führt es zu einer Situation, in der nicht mehr klar zwischen den Eskalationswegen unterschieden werden kann. In einem solchen Fall kann es passieren, dass Eskalationen sich vermischen und bei dem falschen beteiligten Stakeholder eskaliert werden. Ein Beispiel an dieser Stelle ist ein Bug im Zulieferercode bzw. in einer Blackbox, der zu einer Fehl funktion führt. Unklare Schnittstellen können dazu führen, dass die Analyse des Problems beim falschen Unternehmen startet und berichtet wird und dadurch wichtige Zeit verloren geht. Die zweite Schwierigkeit bei einer fehlenden Definition der Schnittstellen ist, dass Probleme von Zulieferteilen sich mit der Hauptaufgabe vermischen und dadurch durch verschiedene Parteien berichtet werden. Während der Eskalation - Mangelhafte Durchführung Eskalationen scheitern nicht ausschließlich schon vor der Durchführung, sondern die Durchführung an sich hat Potenzial für eine falsch durchgeführte oder gescheiterte Eskalation. Im Folgenden wird auf die nächsten vier Punkte eingegangen: 5. Eskalationen werden falsch kommuniziert 6. Priorisierung im Projekt behindert den Erfolg der Eskalation 7. Es ist der falsche Zeitpunkt für die Eskalation 8. Europas Fehlerkultur lässt Scheitern nur ungern zu • Changemanagement-Tool: In einem Changemanagement-Tool wie PTC Integrity werden Themen in Form von Tickets bzw. Analyseanfragen an die entsprechenden Fachabteilungen auf einer ersten Ebene eskaliert. An dieser Stelle kann durch ein Feld bereits die Dringlichkeit und Wichtigkeit hervorgehoben werden. Durch eine höhere Einstufung der Auswirkung kann eine höhere Priorisierung erreicht werden. 4. Interne und externe Eskalationswege fehlen Für Eskalationen spielen nicht nur Eskalationswege in der internen Entwicklung eine Rolle, sondern auch die Eskalationswege auf der Supply Chain. Hierzu wird auf die Möglichkeiten eingegangen, wie Eskalationen für interne und externe Themen umzusetzen sind. Hier sind die Eskalationswege oftmals nicht klar definiert worden. Das führt dazu, dass bei speziellen Situationen mit den Zulieferern Eskalationen lange dauern beziehungsweise lange Wege gehen, bevor sie gelöst oder kommuniziert wurden. Für die geordnete Koordination und Kommunikation an den Schnittstellen zwischen OEM, Tier 1 oder zwischen verschiedenen Zulieferern müssen klare Schnittstellenvereinbarungen getroffen werden, die Aufgabenzugehörigkeiten zwischen den beteiligten Parteien vorgeben. Durch die Definition der Aufgabenzuordnung werden die beteiligten Parteien befähigt, sich auf ihre Verantwortungsbereiche zu konzentrieren. Fehlen zu einer Kundenunzufriedenheit führt, kann dies aufgrund der resultierenden Kundeneskalation schnell im Management thematisiert werden. Dabei stellt die Eskalation zum Management die letzte Instanz für eine Eskalation dar. In Abbildung 2 wird verdeutlicht, wie typische Eskalationsstufen aussehen können. Es empfiehlt sich, eine Kommunikationsmatrix zu erstellen, damit klar ist, wer sich an wen, zu welchem Thema wenden muss. Wenn der Einleitende der Eskalation bei der nächsten Hierarchiestufe nichts erreicht oder er nicht gehört wird, sollte er in der Kommunikationsmatrix eine Stufe überspringen. So kann vor allem eine Eskalation per Mail nicht verloren gehen. Zu jeder gerichteten Eskalation gehören klare Kommunikationsregeln. Diese können themenabhängig strukturiert werden, äquivalent zu Sicherheitsrichtlinien von Dokumenten. Im Folgenden ist ein kurzes Beispiel ohne Anspruch auf Vollständigkeit aufgeführt: • E-Mail: Die E-Mail kann als Medium genutzt werden, um Themen vorab zu besprechen bevor sie in ein Tool eingestellt werden, oder zur Koordination von Task Force-Themen. Als Hilfsmittel zu dieser Form soll immer ein Tool und das Meeting ergänzend genutzt werden. • Meeting: Das Meeting wird genutzt, sofern es durch die geografische und zeitliche Dimension möglich ist, um die Eskalationen mit E-Mail und Tool zu koordinieren. Dabei fallen unter das Thema Meeting oder mündliche Kommunikation Themen, die nicht immer dokumentiert werden sollen. Abb. 2: Schematische Darstellung von Eskalationsstufen PM-aktuell_1-2016_Inhalt_01-68.indd 45 29.01.2016 8: 20: 05 Uhr projektManagementaktuell | ausgabe 1.2016 46 Wissen listischen Zielvorgaben oder noch nicht abgestimmten Anforderungen. Um damit fertigzuwerden, ist die Einrichtung eines funktionsfähigen Risikomanagements der einfachste Weg, Herausforderungen, die sich bei der Erreichung von Meilensteinen von Auslieferungen stellen, zu erkennen. Das Management von Projektrisiken kann dabei helfen, die Themen zu adressieren bzw. an das Management zu kommunizieren. Ein funktionierendes Risikomanagement identifiziert und bewertet projektrelevante und projektübergreifende Risiken. Es ist wichtig, den Risiken Kritikalität und eine Gegenmaßnahme zuzuordnen, um die Auswirkungen und die Wahrscheinlichkeit des Risikoeintritts zu minimieren. Die nächsten Schritte hängen davon ab, ob die Kommunikation der Risiken bereits Lösungsansätze enthält oder nicht (siehe Abb. 3 für Beispiele von Aktionen zu einem Lösungszeitpunkt). 7. Es ist der falsche Zeitpunkt für die Eskalation Die richtige Kommunikation bei Eskalationen beinhaltet neben dem „Wie“ auch das „Wann“. Ist der Zeitpunkt für die Eskalation falsch gewählt, wird sie zu keiner Aktion führen. Dabei kann es passieren, dass das Risiko klar vorhanden ist, aber aktuell noch niemand dazu bereit ist, die Eskalation ernst zu nehmen bzw. direkte Aktionen abzuleiten. Ein Beispiel für eine verspätete oder verschobene Eskalation sind typischerweise Eskalationen mit Bezug auf Ressourcen. Eine Eskalation für Ressourcen kann und wird häufig auf Basis von Abschätzungen zu Entwicklungstätigkeiten durchgeführt. Die Eskalation kann zu einem frühen Zeitpunkt im Projekt vorausschauend durchgeführt werden, aber unter Umständen keine Reaktion auslösen. Gründe hierfür können zum Beispiel sein: • parallel laufende Projekte mit kritischen Verläufen, • Mangel an finanziellen Mitteln, • fehlerhafte Kommunikation. Wird das Thema in einem schon fortgeschrittenen Projekt erneut eskaliert und an das Management herangetragen, werden dem Projekt beispielsweise neue Ressourcen zugewiesen, weil nun der Kunde das Thema verfolgt und einen entsprechenden Druck aufbaut. Um den richtigen Zeitpunkt und die richtige Kritikalität für eine Eskalation zu ermitteln, empankommt und auf die Verantwortungsbereiche, siehe Kapitel 1. Damit eine Eskalation sauber und schnell funktioniert, müssen daran immer Entscheidungsvorlagen gekoppelt werden, mit denen man das Problem einer Lösungsrichtung zuordnen kann. Viele Mitarbeiter verstehen nicht immer, dass eine Entscheidungsvorlage nur dann den Namen verdient, wenn in ihr eine zugehörige Alternative angeboten wird. Eine Methode und Beispiel einer geeigneten Kommunikationstechnik ist das Vier-Ohren-Modell von Schulz von Thun. Dabei geht es um die Interpretation der Nachricht auf vier verschiedenen Wegen: dem Sachinhalt, der Selbstoffenbarung, der Beziehung und dem Appell. Weiterhin wird empfohlen, die Schulungskataloge für Soft Skills zu überarbeiten und in die Mitarbeiter zu investieren, damit die Kommunikationsverluste reduziert werden. Es sollte immer darauf geachtet werden, dass notwendige Informationen transparent und strukturiert dargestellt werden. Dabei soll die Kernaussage stets am Anfang stehen, um die Aufmerksamkeit des Vorgesetzten auf das Thema zu ziehen. Es wird empfohlen, die Kommunikationsfähigkeit von Mitarbeitern zu schulen, da eine gut definierte Aussage weniger zu Missverständnissen und fehlgeleiteten Interpretationen führt. Die Nutzung von speziellen Kommunikationstechniken erleichtert die Eskalation und ist ein wichtiges Thema sowohl für interne als auch externe Kommunikation. 6. Priorisierung im Projekt behindert den Erfolg der Eskalation Die Priorisierung in Projekten hat einen hohen Einfluss auf den Erfolg von Eskalationen. Ein wichtiger Einflussfaktor für die Entwicklung in der Automobilbranche ist der hohe Kostendruck und das ressourcenminimale Engineering (siehe auch [1]). Dabei können Veränderungen des Business Case und die Kostenentwicklung dazu führen, dass für die Entwicklung neue Materialien vorgegeben werden. Auch kann eine Veränderung der Anforderungen, welche durch die Entwicklungsteams zu realisieren sind, die Folge sein. Dies bedeutet häufig, dass laufende Projekte neuen Risiken ausgesetzt sind. Die Risiken entstehen vor allem durch die Einführung von neuen Meilensteinen oder durch die Entwicklung von neuen Funktionalitäten mit unrea- 5. Eskalationen werden falsch kommuniziert Bei Eskalationen handelt es sich um eine sensible Form der Kommunikation. Die Kommunikation muss gut strukturiert sein, da es sonst leicht zu Missverständnissen kommen kann. Dabei ist nicht nur das Kommunikationsmedium von Bedeutung, sondern auch die Art der Eskalation. Dies bedeutet eine Unterscheidung zwischen persönlicher und fachlicher Eskalation. Im Normalfall ist nur eine der beiden Eskalationen im Unternehmen dargestellt. Dabei spielt die Organisation des Unternehmens eine Rolle. Bei einem Mapping auf die weit verbreitete Matrixorganisation entstehen Herausforderungen durch die Parallelstrukturen. Hierbei geht es vor allem um die Unterscheidung zwischen dem organisatorisch abgebildeten Programm und dem Projekt. Bei der Betrachtung der beiden Eskalationsarten werden folgende Annahmen getroffen: • Eine fachliche Eskalation wird immer über Projekt- und Prozessstrukturen durchgeführt, sofern diese vorhanden sind. • Eine persönliche Eskalation wird über die Linie oder die Hierarchie durchgeführt. Als Grundsatz für eine geordnete Eskalation muss folgende Merkregel zugrunde gelegt werden: „Eskalation so hoch wie möglich, aber nur so hoch wie nötig.“ Das heißt, es müssen Kriterien für die Eskalationsstufen definiert werden und klar messbar sein. Der Ablauf einer Eskalation hängt dabei maßgeblich vom Managementstil der verantwortlichen Hierarchiestufen ab. Diese Eskalationswege müssen im Idealfall von der Organisation getragen werden, da die Eskalation von unten zu höheren Aufwänden führt. Ein Beispiel ist die Eskalation eines Qualitätsbeauftragten an den Abteilungsleiter. Dabei hat der Qualitätsbeauftragte erkannt, dass es im Verhältnis zur Größe des Projektteams zu viele Arbeiten gibt, die im Changemanagement-Tool angelegt sind. Der Qualitätsbeauftragte möchte vorausdenken und schlägt die Erhöhung der Ressourcen vor. Die Eskalation geht schief, da der Abteilungsleiter sich persönlich angegriffen fühlt. Er denkt, dass seine Arbeit als Planer des Teams kritisiert wird. Zudem könnte er die Hilfe des Qualitätsbeauftragten falsch interpretieren und so verstehen, dass dieser seine eigene Rolle wohl besser beherrsche als er selbst. Anhand dieses Beispiels wird klar, dass es bei Eskalationen vor allem auf eine gute Formulierung PM-aktuell_1-2016_Inhalt_01-68.indd 46 29.01.2016 8: 20: 05 Uhr Wissen 47 projektManagementaktuell | ausgabe 1.2016 Nach der Eskalation - Keine konkrete Maßnahmenumsetzung Wenn die Eskalationen durchgeführt worden sind, ist der Abschluss eine letzte mögliche Fehlerquelle, die zum Scheitern führen kann, wie nachstehend ausgeführt wird. 9. Maßnahmen nach Eskalationen werden nicht mit Aktionen versehen 10. Eine Blockade im Management verhindert Handlungen 9. Maßnahmen nach Eskalationen werden nicht mit Aktionen versehen Eskalationen sollen möglichst allgemein formuliert werden, indem der Ist-Status eines Sachverhaltes dem Soll-Status gegenübergestellt wird. In einer beispielhaften Eskalation wird ein mangelhaftes Tracking der Software-Entwickleraktivitäten und der Auslastung von Teammitgliedern thematisiert. Einen Monat später kommt das Thema wieder auf. Die Eskalation ist gescheitert, da keine konkreten Maßnahmen formuliert wurgutes Beispiel ist hier ein Zitat von Laurence Johnston Peter, einem amerikanischen Managementberater: „Fehler vermeidet man, indem man Erfahrung sammelt. Erfahrung sammelt man, indem man Fehler macht.“ Ein Fehler oder Scheitern wird als Möglichkeit zur persönlichen Entwicklung gesehen. Anders in Europa: Wird ein Thema der Prozessqualität in der Softwareentwicklung durch den Projektqualitätsverantwortlichen eskaliert, so kann es passieren, dass der verantwortliche Gruppenleiter dies als ein persönliches Scheitern seiner Arbeit betrachtet. Das Fehlschlagen von Projekten wird nicht gerne zugelassen und daher ungern gehört. Die Betreffenden machen sich oft selbst für das Misslingen verantwortlich und sehen die Eskalation als persönliche Kritik an ihrer Arbeit. Der Rollenträger, der eine Eskalation einleitet, sollte daher stets daran denken, Themen möglichst neutral zu formulieren und keinen Schuldigen zu suchen. Um trotz der negativen Fehlerkultur eine erfolgreiche Eskalation durchzuführen, sind Geduld, Ausdauer sowie klar definierte Vorgaben vonnöten. Die Nutzung von Prozessen und Templates wird empfohlen. fiehlt es sich, ein übergreifendes Risikomanagement zwischen den Projekten einzurichten, damit die Kommunikation einheitlich ist und die Reaktion des Managements vorher eingeschätzt werden kann. Dies wird dazu führen, dass sich dem richtigen Zeitpunkt der Eskalation immer besser angenähert werden kann. Sinnvoll ist es, bei einer Multiprojektbetrachtung und der entsprechenden Einschätzung von Managemententscheidungen zusätzliche Lösungen zu definieren. Als Beispiel kann man weitere Lösungen definieren, wie sie in Abbildung 3 beschrieben sind. 8. Europas Fehlerkultur lässt Scheitern nur ungern zu Die Businesswelten zwischen USA und Europa unterscheiden sich stark. Dies ist auch bei kritischen Projekten zu spüren. Im Allgemeinen riskieren amerikanische Unternehmen mehr, hingegen haben gerade deutsche Unternehmen ein starkes Sicherheitsbedürfnis. Dies spiegelt sich auch in Europas Fehlerkultur wider. Man spricht hier von einer negativen Fehlerkultur, ein Fehler wird als schlecht angesehen. In den USA dominiert eher eine positive Fehlerkultur. Ein Abb. 3: Auswahl von Aktionen für einen definierten Lösungszeitpunkt PM-aktuell_1-2016_Inhalt_01-68.indd 47 29.01.2016 8: 20: 06 Uhr projektManagementaktuell | ausgabe 1.2016 48 Wissen Kompetenzelemente der ICB 4.0 3.05 Organisation, Information und Dokumentation, 3.06 Qualität, 3.10 Planung und Steuerung Autoren Tanja Hupf beschäftigt sich als Consultant bei der INVENSITY GmbH mit Entwicklungsprozessen und Software-Qualitätssicherung. Anschrift: INVENSITY GmbH, Parkstraße 22, 65189 Wiesbaden, E-Mail: Tanja.Hupf@ invensity.com Turgay Sahin ist als Senior Consultant Leiter des Center of Excellence Safety Management bei der INVENSITY GmbH und aktuell im Bereich Software-Projektleitung tätig. Anschrift: INVENSITY GmbH, Parkstraße 22, 65189 Wiesbaden, E-Mail: Turgay.Sahin@ invensity.com lagen für die Eskalationen, mangelhafte Durchführung der Eskalationen oder die fehlende Umsetzung von konkreten Maßnahmen sein. Es wurden Beispiele von Eskalationen und Empfehlungen für jede Phase gegeben, die zum Erfolg einer Eskalation führen. Konkret wurde dabei auf zehn Gründe für das Scheitern einer Eskalation eingegangen, bei denen verschiedene Standpunkte und Stakeholder als Ausgangspunkte angenommen wurden. Die Gründe für die Eskalationen bewegen sich dabei von fehlerhaften Kommunikationen über fehlende Ressourcen bis hin zu persönlichen Absprachen. Eskalationen können vielfältige Ausgangspunkte haben und bilden einen Missstand ab, der eine gewisse Kritikalität für ein Projekt erreicht. Die Maßnahmen, die getroffen werden können, um die Missstände zu verhindern, werden in diesem Artikel auch anhand von Beispielen vorgestellt. Die wichtigste Maßnahme ist die Bereitstellung von Grundlagen für eine Eskalation. Sie bedeutet nicht nur, Prozesse und Kommunikationswege klar zu definieren, sondern alle beteiligten Stakeholder in diesem Prozess zu schulen. Die Schulung muss sich vor allem mit der Prozesstreue und der Kommunikation an sich beschäftigen. Mit allen Stakeholdern sind nicht nur Projektmitglieder in einem Unternehmen gemeint, sondern auch in der Supply Chain eines Gesamtsystems, damit alle Beteiligten in dieser Supply Chain ihre Rollen kennen und wissen, welche Rechte und Pflichten sie haben. In der Zukunft werden Themen zu Prozessen immer wichtiger werden, vor allem wenn der Vernetzungsgrad in Fahrzeugen durch das Internet of Things erhöht wird. Die steigende Kommunikation zwischen den Teilnehmern im Alltag und die sich öffnenden Schnittstellen führen zu neuen Herausforderungen in den Abstimmungen bei der Entwicklung. Die Schnittstellen müssen zusätzlich vor Missbrauch und Interoperabilität abgesichert werden. Eine Eskalation dient hier zum rechtzeitigen Adressieren und Handeln bei kritischen Themen.  Literatur [1] Überleben im Chaos - Erfolgreiches ressourcenminimales Systems Engineering. INVENSITY GmbH, TdSE, 2014 Schlagwörter Eskalation, Projektmanagement, Prozesse, Qualität, Risikomanagement den und vor allem keine Person benannt wurde, die diese verfolgt und kontrolliert. Die Autoren empfehlen deshalb im Rahmen des Unternehmens sowohl bezüglich Aktionen, Verantwortlichen und Terminen eine Vorlage zu erstellen als auch im Eskalationsprozess die Rollen und Aktionen nach einer Eskalation festzulegen, siehe auch Kapitel 2. 10. Eine Blockade im Management verhindert Handlungen Der letzte Grund, der zum Misslingen von Eskalationen führen kann, sind Blockaden im Management. Blockaden haben oft politische Gründe, die sich nicht immer auf ein Projekt beziehen müssen. So kann es sich z. B. um eine Entscheidung handeln, der ein Prestigethema zugrunde liegt. Der Grund kann das Streben sein, der Vorreiter für ein spezifisches Thema zu sein oder sich in einer Sparte positionieren zu wollen. Andere Gründe können politische Themen sein, bei denen Absprachen zwischen Stakeholdern getroffen wurden, ohne die Projektsituation zu berücksichtigen. Ein weiteres Beispiel ist, dass die Eskalation die Verschiebung eines Termins vorsieht. Das Management hat aber bereits eine Terminzusage getroffen und will „das Gesicht gegenüber dem Kunden nicht verlieren“. Dies bedeutet nun, dass verschiedene Interessen aufeinandertreffen. Das Management wird einer Verschiebung des Termins nicht zustimmen. Eine solche Entscheidung kann legitim sein, erfordert nun jedoch Alternativen. Das heißt, entweder vom Management oder vom Projektteam müssen Alternativen aufgezeigt werden. Derartige Möglichkeiten sind in Abbildung 3 aufgeführt. Die Lösung an dieser Stelle ist, konstruktive Alternativen im Dialog mit den Projekt-Stakeholdern zu finden. Eine Möglichkeit ist das Einsetzen eines Kontrollausschusses, der Entscheidungen des Managements plausibilisiert und die Gründe überprüft. Situationen, in denen das Management sinnvolle Aktivitäten unterbindet, können so abgefedert werden. Fazit Im vorliegenden Fachartikel wurden Gründe für das Scheitern einer Eskalation dargelegt. Dazu wurden die drei Phasen vor, während und nach der Eskalation betrachtet. Gründe für das Scheitern einer Eskalation können fehlende Grund- Corporate Quality Akademie Projektmanagement Einführungslehrgang per�Fernlehre: �www.cqa.de PM-Normen�+�Methoden info@cqa.de www.cqa.de 029161�908951 Anzeige PM-aktuell_1-2016_Inhalt_01-68.indd 48 29.01.2016 8: 20: 07 Uhr