eJournals PROJEKTMANAGEMENT AKTUELL 32/4

PROJEKTMANAGEMENT AKTUELL
pm
2941-0878
2941-0886
UVK Verlag Tübingen
10.24053/PM-2021-0070
Es handelt sich um einen Open-Access-Artikel, der unter den Bedingungen der Lizenz CC by 4.0 veröffentlicht wurde.http://creativecommons.org/licenses/by/4.0/91
2021
324 GPM Deutsche Gesellschaft für Projektmanagement e. V.

Turnaround-Management in agilen IT-Projekten

91
2021
Jörg Brüggenkamp
Peter Preuss
Tobias Renk
Beim agilen Projektmanagement spielt die Konsensfindung selbstorganisierter Teams eine zentrale Rolle. Diese kann in Krisensituationen dazu führen, dass notwendige Entscheidungen verzögert werden. Um das zu vermeiden, ist es wichtig, im agilen IT-Projektumfeld die Signale möglicher Krisen frühzeitig zu erkennen und mit gutem Turnaround-Management gegenzusteuern.
pm3240047
47 PROJEKTMANAGEMENT AKTUELL · 32. Jahrgang · 04/ 2021 DOI 10.24053/ PM-2021-0070 Turnaround-Management in agilen IT-Projekten Jörg Brüggenkamp, Peter Preuss, Tobias Renk Für eilige Leser | Beim agilen Projektmanagement spielt die Konsensfindung selbstorganisierter Teams eine zentrale Rolle. Diese kann in Krisensituationen dazu führen, dass notwendige Entscheidungen verzögert werden. Um das zu vermeiden, ist es wichtig, im agilen IT-Projektumfeld die Signale möglicher Krisen frühzeitig zu erkennen und mit gutem Turnaround-Management gegenzusteuern. Schlagwörter | Turnaround-Management, Turnaround-Manager, Projektkrise, agiles IT-Projekt, Krisensymptome Vorspann Befindet sich ein Unternehmen in einer wirtschaftlichen Schieflage, ist Turnaround-Management notwendig. Ein solches Management kann aber auch relevant sein, wenn es zu Problemen in IT-Großprojekten kommt. Wie der Begriff bereits ausdrückt, geht es dabei um das „Umdrehen eines Projekts"-- heraus aus der Krise und zurück auf die Erfolgsspur. Obwohl die agile Vorgehensweise das frühzeitige Erkennen von Risiken erleichtert und es daher gar nicht erst zu kritischen Problemen kommen dürfte, zeichnet sich in der Praxis häufiger ein anderes Bild. Agile, selbstorganisierte Projektteams sind bei ruhiger See ein echtes Erfolgskonzept, zumal in dieser Zeit im Prinzip keine Führung benötigt wird. Was ist aber bei stürmischer See zu tun? In diesem Beitrag wird beschrieben, warum agile IT-Projekte in eine Krise geraten können und mit welchen Maßnahmen das Projekt wieder auf Kurs kommt. Projekte in der Schieflage-- Symptome von Projektkrisen Eine Krise aus Sicht des Projektmanagements zeichnet sich durch Ausweglosigkeit und weitreichende Lähmung der Entscheidungsträger aus. Sie entsteht meistens aus einer Abfolge kritischer Situationen, die in der Summe eine große negative Auswirkung auf das Projekt haben und nicht mehr beherrschbar sind. Grundsätzlich gilt: je größer das Ausmaß der Krise, desto weniger Handlungsspielraum bei der Krisenbeseitigung. Die Berechenbarkeit im Projekt geht dann verloren, Entscheidungsalternativen nehmen ab, der Handlungsdruck steigt und ein Ende der kritischen Situationen ist nicht absehbar. Wird die Projektkrise immer größer, kann sie bei Großprojekten sogar in eine Unternehmenskrise münden (siehe Abbildung 1). Auch wenn die Ursachen von Projektkrisen abhängig vom jeweiligen Projekt sind, gibt es dennoch sich wiederholende Symptome. Hierzu gehören beispielsweise: • Der Projektauftrag ist nicht klar definiert und die Projektmitarbeiter wissen nicht, was zu tun ist. • Das Projekt meldet überhaupt keine Probleme. • Es gibt über einen längeren Zeitraum hinweg keine Planänderungen und alle Arbeitspakete sind angeblich seit einigen Wochen schon „fast fertig“. • Die Projektmitarbeiter haben verstärkt Gesprächsbedarf außerhalb des Projekts und sie haben Angst, Probleme offen zu adressieren. • Die Aufstellung der Projektrisiken ist zu kurz oder zu lang. • Im Projekt herrscht eine hohe Fluktuation. • Die Stakeholder stellen sich gegen das Projekt. Werden diese Symptome frühzeitig erkannt, kann die Krise in vielen Fällen noch vom Projektteam selbst gelöst werden. In der Praxis ist aber leider immer wieder festzustellen, dass ein Turnaround-Management erst im späten Verlauf einer sich manifestierten Krise oder sogar erst bei einer nicht mehr beherrschbaren Krise in Anspruch genommen wird. Wissen | Turnaround-Management in agilen IT-Projekten 48 PROJEKTMANAGEMENT AKTUELL · 32. Jahrgang · 04/ 2021 DOI 10.24053/ PM-2021-0070 Krisenverarbeitung im Projekt In Krisenzeiten agieren Menschen häufig nach einem bestimmten Muster, das die Sterbeforscherin Kübler-Ross in den fünf Phasen des Sterbens beschrieben hat. Diese Sterbephasen sind auch bei Krisen in IT-Projekten zu beobachten (siehe Abbildung 2). Am Anfang der Krise überwiegt die Hoffnung, dass das Ganze „intern“ geregelt werden kann. Da niemand gerne negative Nachrichten erhält, werden in dieser Verleugnen- Phase Informationen nur eingeschränkt weitergegeben und die Kommunikation im Projektteam nimmt kontinuierlich ab, bis sie nachhaltig gestört ist. Als nächstes folgt die Zorn-Phase. Hier werden Projektmitarbeiter ausgegrenzt, Schuldzuweisungen häufen sich, Verteidigungshaltungen werden eingenommen und das Bestehen auf dem eigenen Standpunkt behindert die konstruktive Zusammenarbeit. Oft wird parallel argumentiert, dass die Krisenursache nicht im Projekt oder beim Projektteam zu finden ist. Es werden einfach nur mehr Zeit, größere finanzielle Mittel oder umfangreichere Entwicklungskapazitäten benötigt. Dann würden sich schon alle Probleme lösen und die Krise wäre überwunden (Verhandeln-Phase). Ist das nicht umsetzbar, resignieren viele Mitarbeiter, verlieren das Vertrauen in das Management sowie in die eigene Leistungsfähigkeit und es wird nur noch „Dienst nach Vorschrift“ gemacht (Depression-Phase). Parallel dazu verlieren die Stakeholder das Interesse an dem Projekt oder stellen sich sogar dagegen und die notwendige Projektunterstützung geht langsam verloren. Irgendwann wird die Krise von allen Beteiligten akzeptiert (Zustimmungsphase). Dadurch wird zwar ein Turnaround-Management im Projekt ermöglicht, in vielen Fällen ist es dann aber für eine Sanierung zu spät und das Projekt wird abgebrochen. Dabei ist es wichtig zu verstehen, dass ein bewusst herbeigeführter Projektabbruch nicht per se als schlecht anzusehen ist. Er kann eine sinnvolle Maßnahme sein, um die Krise zu beenden. Wird das Projekt im Anschluss neugestartet, ist die Krise häufig erstmal verflogen und es herrscht wieder eine positive Aufbruchsstimmung. Eine erfolgreich gemeisterte Krise kann zu einem konflikt- und krisenfesteren Projekt führen und damit einen positiven Effekt für die Zukunft haben. Wichtig ist aber, dass bei einem Neustart möglichst schnell erste Erfolge vorgewiesen werden können, damit das Ganze kein Strohfeuereffekt ist. Warum agile Projekte in eine Krise geraten können Erstaunlicherweise werden Krisen gerade in agilen IT-Projekten häufig ausgeblendet bzw. nicht als solche wahrgenommen. Das führt dazu, dass erst sehr viel später Gegenmaßnahmen ergriffen werden. Dabei hätte die agile Vorgehensweise mit ihrer empirischen Prozesssteuerung ideale Voraussetzungen, um kritische Situationen frühzeitig zu erkennen und gegenzusteuern, bevor es zu einer Krise kommt. Methodenkrise-- Wahl einer geeigneten Projektmanagementmethode Die Wahl der richtigen Projektmanagementmethode und deren unternehmens- und projektspezifischen Anpassungen ist die erste kritische Phase in einem Projekt. Trifft man hier die falschen Entscheidungen, sind die negativen Auswirkungen häufig erst zu einem viel späteren Zeitpunkt sichtbar. Es gibt eine Reihe von Handreichungen und Modellen, die einen bei der Auswahl unterstützen. Hierzu gehören unter anderem die Stacey-Matrix in Kombination mit dem Cynefin-Modell, die Einteilung von Ebert, die Kriterien von Timinger und das Modell von Boehm / Turner. Nach aktuellen Umfragen ist Scrum nach wie vor das meistverwendete Rahmenwerk im agilen Umfeld und wird daher in den nachfolgenden Ausführungen als Beispiel herangezogen. Scrum hat einen guten Anteil an formalen Prozessen, die eine Steuerung von Teams erleichtern und gleichzeitig genügend Freiraum zur Entfaltung bieten. Bei Scrum gibt es ein eigenverantwortliches Projektteam mit den Verantwortlichkeiten Product Owner, Scrum Master und Entwickler. Daneben gibt es aber weitere Beteiligte (Stakeholder), die einen nicht unerheblichen Einfluss auf das Projekt haben. Hierzu gehören insbesondere die Manager bzw. Führungskräfte eines Unternehmens. Im Idealfall haben diese Grundkenntnisse in der Anwendung agiler Projektmanagement-Methoden und kennen deren Vor- und Nachteile in der praktischen Anwendung. Abbildung 1: Typischer Verlauf von Projektkrisen Wissen | Turnaround-Management in agilen IT-Projekten 49 PROJEKTMANAGEMENT AKTUELL · 32. Jahrgang · 04/ 2021 DOI 10.24053/ PM-2021-0070 Führungskrise-- Konsensfindung oder kurze Entscheidungswege Ein wesentliches Managementziel im agilen Umfeld ist die Etablierung selbstverantwortlicher Projektteams. Führungskräfte sollen den Projektteams den notwendigen Raum geben, damit diese sich frei entfalten können. Sie sollen eine positive Fehlerkultur etablieren und durch Vertrauen, Offenheit und Wertschätzungen ein Arbeitsumfeld schaffen, das alle Projektmitarbeiter dazu ermutigt, Verantwortung zu übernehmen. Während bei klassischen Projektmanagementmethoden die Vorteile hierarchischer Strukturen bei der Entscheidungsdurchsetzung deutlich werden-- mit allen Nachteilen, wie den Motivationsproblemen der Mitarbeiter, dem langsamerem Informationsfluss zwischen den Ebenen, der Unterdrückung von Eigenverantwortung und Kreativität- - ist bei den agilen Ansätzen eine erschwerte Entscheidungsfindung erkennbar. Das Selbstmanagement der Projektteams, bei dem man sehr auf Konsensfindung bedacht ist, führt dazu, dass in Konfliktsituationen keine konsequenten und schnellen Entscheidungen getroffen werden. Natürlich ist gegen den Konsens als höchste Stufe der Konfliktlösung nichts einzuwenden. Das gilt insbesondere, wenn die Alternativen Kompromiss, Delegation, Unterordnung, Vernichtung und Flucht sind. Allerdings zählt in Krisensituationen die Schnelligkeit. Wenn stattdessen die dezentrale Konsensfindung zu lange dauert, wäre es zielführender, dass eine Führungskraft im Ernstfall das Ruder übernimmt und versucht, das Projekt wieder in sicheres Fahrwasser zu bekommen. Der Scrum Master und der Product Owner sind aufgrund ihrer Ausbildung hierfür weniger gut geeignet. Führungskräfte, die dann kurzzeitig in die Bresche springen, müssen aber berücksichtigen, dass allein ihre Anwesenheit schnell dazu führt, dass sich viele Projektbeteiligte nicht mehr in der Verantwortung sehen-- getreu nach dem Motto: „Der neue Chef wird es schon richten.“ Ist Kontrolle besser als Vertrauen? Im agilen Umfeld wird insbesondere Vertrauen als Basis für die Zusammenarbeit hervorgehoben. Viele Führungskräfte sehen Vertrauen gar als Gegenpol zur Kontrolle. Vertrauen ist sicherlich wichtiger als Kontrolle, die beiden Werte schließen sich aber nicht gegenseitig aus. Es ist daher situationsabhängig, was angewendet werden sollte. Erschwerend kommt hinzu, dass in agilen Projekten selten Kennzahlen verwendet werden, die zur Kontrolle geeignet sind. Typische agile Kennzahlen wie Velocity, Cycle und Lead Time haben aufgrund ihrer Eindimensionalität keine große Aussagekraft oder können leicht missinterpretiert werden. Zudem können Führungskräfte im agilen Umfeld in vielen Fällen nur noch über die Einflussnahme im Sprint Review Kontrolle ausüben. Die Stakeholder immer im Blick? In agilen Projekten steht der direkte Kundenkontakt im Vordergrund. Bei Scrum wird der Kunde maßgeblich durch den Product Owner repräsentiert. Es gibt aber weitere wichtige Stakeholder und die agilen Frameworks geben wenig Hinweise, wie man im agilen Umfeld gutes Stakeholder-Management bzw. eine gute Projektumfeldanalyse betreibt. Dabei tragen professionelles Stakeholder-Management und eine gute Kommunikationsstrategie maßgeblich zum Projekterfolg bei, allein um sich die Unterstützung für das Projekt zu sichern. Im Gegensatz dazu gehört das bei klassischen Wasserfallprojekten zum Standardwerkzeug eines jeden Projektmanagers. Abgesehen davon, dass in agilen Projekten meistens keine richtige Stakeholder-Analyse gemacht wird, sind die Ziele der relevanten Stakeholder oft nicht bekannt und deren Interessen werden fehlinterpretiert. Eine schlechte Kommunikationspolitik beschleunigt das Ganze zusätzlich. Wenn die relevanten Stakeholder und das Projektteam divergierende Interessen haben, werden in der Folge Entscheidungen im „engsten Stakeholder-Kreis“ unter geringer Einbindung des Kernprojektteams getroffen. Das hat destruktive Auswirkungen auf das Projekt. Eine weitere Folge divergierender Interessen ist auch, dass sich in kritischen Situationen die Machtverhältnisse zwischen den Stakeholdern verschieben können, wodurch Themen, die vorher einfach mit dem richtigen Ansprechpartner geregelt werden konnten, zu einer größeren und zeitintensiven Herausforderung werden. Abbildung 2: Typische Verarbeitungsphasen von Projektteams bei Krisensituationen Wissen | Turnaround-Management in agilen IT-Projekten 50 PROJEKTMANAGEMENT AKTUELL · 32. Jahrgang · 04/ 2021 DOI 10.24053/ PM-2021-0070 Fehlende strategische Ausrichtung agiler Projekte Es ist wichtig, dass jedes IT-Projekt seinen strategischen Beitrag kennt. Der Scrum Guide gibt hierzu aber keine konkreten Hinweise, da der Schwerpunkt des Frameworks auf der taktischen Umsetzungsebene liegt. Das Produktziel wird zwar als wichtiges Element genannt, es ist aber nicht klar, mit welchen Schritten man es erreicht. Erschwerend kommt hinzu, dass agile Methoden einen dazu verleiten, in wilden Aktionismus zu verfallen und einfach mal anzufangen, ohne dass die strategische Ausrichtung des Projektes festgelegt wurde. Weil sich bereits nach kurzer Zeit vermeintliche Erfolge einstellen, wird man dann darin bestärkt, auf dem richtigen Weg zu sein. Es ist aber essenziell für den Projekterfolg, dass die Vision, die Strategie, die Produkt- und die Projektziele sowie die Taktik eines Projekts vollständig beschrieben werden. Das Ganze muss sich auch an der übergeordneten Mission ausrichten. Fehlende Steuerungsgrößen in agilen Projekten In Projekten, die nach der klassischen Wasserfallmethode durchgeführt werden, gibt es eine Reihe von Kennzahlen, die für die Früherkennung von Krisen eingesetzt werden können. In agilen Projekten werden solche Frühwarnsysteme seltener verwendet, obwohl die eingesetzten Software-Tools viele Daten produzieren, die hierfür genutzt werden könnten. Es widerspricht nämlich dem agilen Mindset, wenn die Projektmitarbeiter vermeintlich kontrolliert werden und das Ganze wird als Vertrauensverlust fehlinterpretiert. Vertrauen ist ein Kernthema aller agilen Vorgehensweisen, das nicht in Frage gestellt werden darf. Das Nichtvorhandensein von Frühwarnsystemen erschwert aber nicht nur die frühzeitige Erkennung von Krisen, sondern auch ein erfolgreiches Turnaround-Management. Die Vorboten einer Krise werden nicht erkannt Größere, negative Veränderungen kündigen sich meist durch schwache, nicht eindeutige Krisensignale an, die zwar wahrgenommen werden, auf sie wird aber nicht oder nur unzureichend reagiert. Diese schwachen Signale werden zwar häufig in Scrum-Retrospektiven adressiert. Da sie aber (noch) zu unkonkret sind, wird darauf nicht eingegangen und es werden keine Gegenmaßnahmen eingeleitet. Zudem lernen Teams leider zu oft, dass sich jeder Konflikt, der vom Projektteam nach außen getragen wird, negativ auf das Projekt auswirkt. Die Folge ist der Versuch, keine Konflikte außerhalb des Projektes sichtbar zu machen. Typische erste Signale in Projekten sind dann erstaunlicherweise, dass keiner über Probleme berichtet, bei gleichzeitiger Häufung sarkastischer Bemerkungen zum Projektverlauf. Danach werden die Projektbeteiligten zynisch und die negative Meinung zu den Erfolgsaussichten des Projekts häufen sich, worunter wiederum die Motivation leidet, die oft in einer erhöhten Anzahl von Krankheitstagen oder der verstärkten Suche nach Einzelgesprächen mit Führungskräften mündet. Hinzu kommt eine deutliche Häufung von Meetings, die parallel zu den agilen Events stattfinden und wichtige Stakeholder bleiben den Projektbesprechungen immer häufiger fern, wodurch das Projekt langsam an Bedeutung verliert oder sogar mit anderen Projekten, bei denen dann üblicherweise der Top-down-Ansatz im Vordergrund steht, zusammengelegt wird. Turnaround-Management-- der Weg aus der Krise Wird die Projektkrise schlussendlich von den Beteiligten akzeptiert, stellt sich die Frage, welche Wege es aus der Krise gibt. Dieses Turnaround-Management zeichnet sich sowohl bei klassischen als auch bei agilen IT-Projekten durch eine Abfolge kurzer, zeitlich begrenzter Phasen aus, die in enger Abstimmung mit den Stakeholdern durchlaufen werden. Da die Vorgehensweise an Sprints erinnert, ist man in der agilen Welt gut damit vertraut. Deshalb ist die Akzeptanz in agilen Projekten in der Regel höher. Auch wenn die Abfolge beim klassischen Wasserfallmodell und bei agilen Methoden vergleichbar ist, gibt es im Detail doch Unterschiede. So müssen beim Turnaround von Wasserfall-Projekten zu Beginn immer ein genaues Ziel, ein Master-Projektplan und eine detaillierte Scope-Beschreibung entwickelt werden. Bei agilen Projekten ist das nicht der Fall. Im Mittelpunkt stehen hier die Produktziele und die Entwicklung einer zielorientierten Roadmap auf der Basis wesentlicher Kernfunktionalitäten. Der geeignete Turnaround-Manager Das Turnaround-Management von IT-Projekten dauert normalerweise nicht länger als wenige Wochen. Wichtig ist der Einsatz eines oder mehrerer Turnaround-Manager, die eine unbelastete Sicht auf das Projekt haben und daher meistens externe Berater sind. Die große Herausforderung besteht darin, einen Turnaround-Manager zu finden, der neben den notwendigen Soft-Skills umfangreiche Kenntnisse in klassischen und agilen Projektmanagementmethoden hat-- idealerweise gepaart mit betriebswirtschaftlichem Hintergrundwissen, um in der Krisensituation zwischen IT und Fachbereich vermitteln zu können. Nachdem ein geeigneter Turnaround-Manager gefunden wurde, werden vier Turnaround-Phasen durchlaufen (siehe Abbildung 3). Die einzelnen Phasen sind vergleichbar mit agilen Sprints, bei denen sich die Sprint-Ziele aus den Phasenin- Abbildung 3: Vorgehensweise beim Turnaround-Management von IT-Projekten Wissen | Turnaround-Management in agilen IT-Projekten 51 PROJEKTMANAGEMENT AKTUELL · 32. Jahrgang · 04/ 2021 DOI 10.24053/ PM-2021-0070 halten ableiteten. Die Umsetzung der einzelnen Maßnahmen kann aber mehrere Sprints dauern. Phase 1: Situationsanalyse In der ersten Phase ist mit einer ganzheitlichen Krisenanalyse zu prüfen, ob das Projekt grundsätzlich sanierungsfähig ist. Anschließend gilt es, die Sanierungswürdigkeit zu untersuchen. Nur wenn ein Projekt werthaltig genug ist, sollte ein Turnaround in Erwägung gezogen werden. Relevante Kriterien sind u. a. die Ertragserwartungen, die Projektrestkosten, der zu erwartende zeitliche Verzug und die zukünftigen Risiken. Das Ziel eines erfolgreichen Turnaround-Managements ist es natürlich, möglichst viele Interessen der unterschiedlichen Stakeholder zu erfüllen. Es ist aber in der Praxis kein leichtes Unterfangen, ein Gleichgewicht zwischen diesen Interessengruppen herzustellen. Der Turnaround-Manager benötigt daher einen Vertrauensvorschuss aller Beteiligten, damit er in der Lage ist, auch unangenehme Entscheidungen treffen zu können. Wenngleich bei jedem Konflikt der Fokus auf der Sachebene liegen sollte, gibt es immer auch Auswirkungen auf der psychosozialen Ebene. Das führt regelmäßig dazu, dass die Konfliktparteien auf ihren Standpunkten beharren und einzelne „Konflikte gewinnen wollen“, was für das Projekt nicht zielführend ist. Es ist daher wichtig, eine für alle gesichtswahrende Lösung zu finden und den Stakeholdern deutlich zu machen, dass ein Projekt lediglich ein zeitlich begrenztes Vorhaben ist. Phase 2: Strategieentwicklung Nach der Situationsanalyse gilt es, in der nächsten Phase eine tragfähige Strategie für das Krisenprojekt zu entwickeln. Wie bereits beschrieben, haben agile Methoden ihren Schwerpunkt auf der taktischen Umsetzung und die strategische Projektausrichtung wird gerne vernachlässigt. Hierbei stehen keine glamourösen Projektziele, sondern Pragmatismus im Vordergrund. Das muss bei der Ausarbeitung der Strategie offen kommuniziert werden. Nach der Festlegung der neuen strategischen Ausrichtung sind die Voraussetzungen für die Umsetzung zu klären. Neben der notwendigen Projektorganisation (inkl. Verantwortlichkeiten) ist u. a. zu ermitteln, welche finanziellen Mittel und welche Projektmitarbeiter mit welchen Fähigkeiten etc. für eine erfolgreiche Beendigung des Projekts benötigt werden. Phase 3: Maßnahmenumsetzung In der nachfolgenden Phase werden die identifizierten Turnaround-Maßnahmen umgesetzt. Diese sind individuell je Projekt und Krise. Hierbei sollte man sich zuerst darauf fokussieren, die offensichtlichsten Probleme mit Sofortmaßnahmen anzugehen, damit das Projekt fortgeführt werden kann. Eine grundlegende Ursachenforschung ist nicht zielführend, da ein Brandmarken der Schuldigen kontraproduktiv ist. Parallel zur Einleitung der Sofortmaßnahmen ist ein vollständiger Maßnahmen- und Umsetzungsplan zu entwickeln. Hierfür müssen detaillierte Ziele, Verantwortliche und Budgets geklärt und eine Roadmap mit Zeitvorgaben erstellt werden. Die Roadmap ist aber nicht gleichzusetzen mit dem Projektplan bei einer klassischen Projektvorgehensweise. Sie ist vielmehr eine Richtschnur für die Umsetzung der Maßnahmen. Hilfreich ist hier eine zielorientierte Roadmap, die einzelne Maßnahmen zu einem Ziel in der Zukunft zusammenfasst. Sofern im agilen Projekt bereits Feature-Roadmaps verwendet werden, können die Turnaround-Maßnahmen hier problemlos integriert werden. Die identifizierten Turnaround-Maßnahmen sollten zudem wie Anforderungen im agilen Umfeld bewertet, priorisiert und sortiert werden- - vergleichbar mit dem Product-Backlog-Management bei Scrum. Es ist außerdem empfehlenswert, die dritte Turnaround- Phase in mehreren kurzen, zeitlich begrenzten Iterationen zu durchlaufen. Das ermöglicht eine Ergebniskontrolle nach jeder Iteration. So wird auch der notwendige Druck aufgebaut, damit in kurzen Zeiträumen erste Ergebnisse geliefert werden. Gleichzeitig werden Erfolge schneller sichtbar und die Motivation im Projektteam verbessert sich. Phase 4: Turnaround-Abschluss Wenn das Projekt nach der Umsetzung der Turnaround-Maßnahmen wieder auf Erfolgskurs ist, muss in der letzten Phase die Nachhaltigkeit des Turnarounds sichergestellt werden. Hierfür bietet sich eine Retrospektive wie bei Scrum an. In dieser Turnaround-Retrospektive sollten die Projektmitglieder die Turnaround-Maßnahmen kritisch würdigen und notwendige Verbesserungen für die Zukunft erarbeiten. Dadurch wird auch das Gemeinschaftsgefühl gestärkt und den Projektbeteiligten wird bewusst, dass Projektkrisen überwunden werden können, wenn alle an einem Strang ziehen. Resümee Krisen in IT-Projekten sind durchaus keine Seltenheit. Vielmehr geht es darum, Krisensymptome frühzeitig zu erkennen und entgegenzusteuern. Agile Projekte machen hierbei keine Ausnahme, wobei ein Erkennen von Krisenanzeichen durch das Selbstorganisieren der Teams eher noch erschwert Prof. Dr. Peter Preuss Peter Preuss lehrt Wirtschaftsinformatik an der FOM Hochschule für Oekonomie & Management in Stuttgart. Er ist zertifizierter Project Management Professional (PMP) nach PMI und Professional Scrum Master. Parallel zu seiner Lehrtätigkeit ist Peter Preuss geschäftsführender Gesellschafter der Unternehmensberatung People Consolidated GmbH. FOM Hochschule für Oekonomie und Management Fachbereich Wirtschaftsinformatik Rotebühlstraße 121, 70 178 Stuttgart eMail: peter.preuss@fom.de Tobias Renk Tobias Renk ist Chief Information Officer der Mobene Unternehmensgruppe. Er ist als Experte und Keynote Speaker zu den Themen Innovation, kultureller Wandel und Digitale Transformation unterwegs. Außerdem ist er als Dozent für Unternehmensführung an verschiedenen deutschen Hochschulen tätig gewesen. Wissen | Turnaround-Management in agilen IT-Projekten werden kann. Diese Tatsache steht im Kontrast zur üblichen Aussage, dass Risiken durch eine agile Vorgehensweise minimiert werden. Es gibt verschiedene Gründe, weshalb agile Projekte in Schieflage geraten können. Neben der möglicherweise falschen Auswahl der Projektmanagementmethode und eines falschen Angangs an die Entscheidungsfindung gehören sicherlich ungenügendes Stakeholder-Management, eine fehlende strategische Ausrichtung und fehlende Steuerungsgrößen zu den Kernursachen. Eingangsabbildung: © Alexander Limbach- - stock.adobe. com Jörg Brüggenkamp Jörg Brüggenkamp ist geschäftsführender Gesellschafter der PMC- - ProjektManagement und Controlling GmbH in der Schweiz. Er ist als Speziallist mit über 20 Jahren Erfahrung in den Bereichen Turnaround-/ Interims-Management im klassischen und agilen Umfeld tätig. PMC-- ProjektManagement & Controlling GmbH Artherstrasse 28a, 6300 Zug (CH) eMail: joerg.brueggenkamp@promanage.ch MITGLIEDER WERBEN MITGLIEDER Mitglied bei der GPM sein lohnt sich und wenn Sie es weiter sagen gleich doppelt. Für Ihre erfolgreiche Empfehlung erhalten Sie ein attraktives Geschenk als Dankeschön! Jetzt Weitersagen und Prämie erhalten! www.gpm-ipma.de Anzeige