Project Recovery Management

Rettung von Software-Projekten in Schieflage

Einleitung

Recovery Manager 3.jpg

Die Möglichkeiten, mit Methoden der agilen Software-Entwicklung auf sich verändernde Rahmenbedingungen zu reagieren, tragen in vielen Fällen zum Projekterfolg bei, wo rein prädiktive („klassische“) Ansätze nicht flexibel genug sind. Trotzdem gerät nach repräsentativen Umfragen[1]weiterhin ein erheblicher Anteil der IT-Projekte während des Projektverlaufs in eine Schieflage. Soweit es sich nicht um temporäre Herausforderungen handelt, welche aus eigener Kraft bewältigt werden können, sollte ausdrückliches „Project Recovery Management“ (Synonym: „Turn-around Management“) zur nachhaltigen Verbesserung der Situation in Erwägung gezogen werden. Mögliche Project-Recovery-Ansätze und -Schwerpunkte werden in diesem Blog vorgestellt.

Erkennen der Schieflage

Aus gutem Grund gibt es keine einheitliche Definition, ob und in welchem Umfang ein Projekt in Schieflage ist. Je nach angewandter Projektmethodik, den zur Anwendung kommenden Standards, gegebenenfalls festgelegten Schwellwerten und vor allem der Interpretation der Interessengruppen kann ein Projekt noch als erfolgreich, in Schieflage oder sogar als nicht mehr zu retten angesehen werden. Auch hier soll keine Definition erstellt werden; vielmehr werden typische Kriterien der Beurteilung vorgestellt.

Klassisches Projektmanagement

Klassisches Projektmanagement basiert auf einer ganzheitlichen Planung sowie auf formal einfließenden Änderungen in Form von Change Requests. Je nach angewandter Controlling-Methodik (z.B. Earned Value Analyse, Meilensteinanalyse) werden Planabweichungen festgestellt und in Umfang, Ursache und Wirkung beurteilt. Bestenfalls existieren im Projektkontext bereits Regeln und Schwellwerte, um Abweichungen vom Plan zu bewerten. Beispiele:

  • Kosten im Planverlauf: Status grün,
  • Kostensteigerung, welche durch den Budgetpuffer abgedeckt ist: Status gelb,
  • Kostensteigerung, durch welche das Budget nicht eingehalten werden kann: Status rot.

Analog lässt sich das Beispiel auf zeitlichen Verzug im Projektfortschritt anwenden. Dabei kann die Analyse auf das Gesamtprojekt, einen Teil davon oder auch als gleitender Durchschnitt angewandt werden, um einerseits einen Trend rechtzeitig zu erkennen, aber andererseits einzelne Abweichungen nicht zu hoch zu bewerten. Der Begriff „Projekt in Schieflage“ entspricht hierbei einem längeren Verweilen im Status rot.

Agiles Projektmanagement

Auch im agilen Projektmanagement[2] können Plan- und Ist-Werte nachhaltig auseinander laufen. Der vordergründige Einwand „agiles Vorgehen kennt keine langfristige Planung, somit auch keine nachhaltige Plan-Verletzung“ ist zu kurz gegriffen. Jeder Sprint bietet einen Planungshorizont von einigen Wochen. Wenn über mehrere Sprints hinweg ein jeweils erheblicher Anteil der User Stories im Backlog nicht umgesetzt wird, kann man von einem Projekt in Schieflage sprechen.

Ebenso wären – im agilen ebenso wie im klassischen Kontext – gehäuft auftretende Fehler im Produktivsystem ohne adäquate Verbesserung des Test- und Qualitätsprozesses ein Indikator für eine Schieflage des Projektes insgesamt.

Weiche Faktoren

Genau wie weiche Faktoren maßgeblich zum Projekterfolg beitragen, können diese als Indikator für ein Projekt in Schieflage herangezogen werden. Dies sind unter anderem:

  • Die subjektive Zufriedenheit des Projektsponsors mit dem Projektverlauf.
  • Die subjektive Einschätzung des Projektteams selbst.

Diese subjektive Einschätzung ist insbesondere dann relevant, wenn sie im Widerspruch zu oben genannten formalen Kriterien steht. So kann beispielsweise durch formal korrekte Scope-Reduzierung mittels Change Requests vertuscht werden, dass die Projektlieferung für diesen Scope-Anteil eben nicht erfolgreich war – der Status wird somit schöngefärbt. Mit anderen Worten: „it’s not a bug – it’s a feature“.

Ursachen für die Schieflage

Die Ursachen für die Schieflage zu finden und zu beheben ist zentraler Ansatz des „Project Recovery Management“. Die obigen Ausführungen zur Feststellung der Schieflage zielen ausdrücklich auf Fakten oder deren Wahrnehmung, nicht aber auf deren Ursachen ab. Eine zu frühe Festlegung auf mögliche Ursachen erschwert die ganzheitliche und nachhaltige Verbesserung, da häufig nur an Symptomen operiert wird.

Der erste Schritt

Der erste Schritt ist häufig der schwierigste. Soweit die Situation und Leistungsfähigkeit des Projektes nicht durch das eigene operative Projektmanagement verbessert werden können, ist die Unterstützung durch einen erfahrenen „Project Recovery Manager“ eine geeignete Maßnahme. Obwohl sich dieser erst in die Situation einarbeiten muss, ist gerade die hierbei einsetzende Dynamik im Team vorteilhaft nutzbar, um z.B. von den Problemen hin zu den Ursachen zu kommen.

Voraussetzungen für erfolgreiches Recovery Management

Komplexe Probleme erfordern einfache Lösungen, um auch in kritischen Situationen einsetzbar zu sein. Diese zu finden und erfolgreich anwenden zu können basiert jedoch auf einigen Voraussetzungen.

  • Offene Kommunikation. Alle Projektbeteiligten müssen offen mit der Situation und der Notwendigkeit externer Unterstützung umgehen. Probleme müssen offen angesprochen statt unter den Teppich gekehrt werden.
  • Unterstützung – in vielfacher Hinsicht. Der Ansatz des Project Recovery Managements soll zu Veränderungen führen, doch diese bergen aus der Perspektive der beteiligten Parteien auch Unsicherheiten. Nur wenn die Zurückhaltung überwunden wird und die Veränderungen unterstützt werden, kann die Situation nachhaltig verbessert werden.
  • Ergebnisoffenheit. Der Recovery Manager ist kein Werkzeug, um eine schon vorher beschlossene Maßnahme durch einen Strohmann zu begründen. Selbstverständlich ist das Mandat jedoch auch kein Freibrief, gewachsene Strukturen auf den Kopf zu stellen. Die beteiligten Parteien sollten mit Maß und Ergebnisoffenheit agieren, um die im jeweiligen Kontext bestmögliche Vorgehensweise zu finden.
  • Erfahrung. Recovery Management ist Projektmanagement – nur eben für ein Projekt, welches sich bereits in Schieflage befindet. In dieser Situation ist es von großer Bedeutung, entsprechende Erfahrung bei der Lösung ähnlicher Aufgabenstellungen einzubringen.

Ansätze des Recovery Management

So vielfältig die Aufgabenstellungen sind, so sind es auch die Ansätze zu deren Lösung. Eine – stark verkürzte – verallgemeinerte Vorgehensweise wird im Folgenden skizziert.

Mandat und Einstieg

Der Recovery Manager wird mit einem ausdrücklichen Mandat versehen. Die Situation, die Ziele und Leitplanken sollten festgelegt werden. Ein „eleganter Einstieg“ zum richtigen Zeitpunkt und im richtigen Rahmen hilft, die Unterstützung der Projektparteien zu fördern.

Project Assessment

Im „Project Assessment“ macht sich der Recovery Manager ein umfassendes Bild von der Situation. Die Quellen hängen vom Projektkontext ab, beinhalten aber in jedem Fall:

  • Gespräche mit den Projektparteien. In Einzel- und Gruppengesprächen wird eine Vielzahl von Erkenntnissen gewonnen, welche maßgeblich zur Ursachen- und Lösungsanalyse beiträgt. Insbesondere gilt es hier Missverständnisse und fehlerhafte Annahmen aufzudecken sowie das Vertrauen in das weitere Vorgehen zu entwickeln.
  • Auswertung der Projektdokumentation. Dabei sind nicht nur der Ablaufplan und aktuelle Statusberichte von Interesse, sondern – soweit vorliegend – insbesondere auch der ursprünglich festgelegte Projektrahmen, die Methodik und der sich aus den Berichten ergebende Verlauf des Schiefstandes.
  • Bisherige Maßnahmen. Hier soll insbesondere evaluiert werden, inwieweit Probleme bereits erkannt und adressiert werden sowie ob die bisherigen Maßnahmen erfolgreich waren. Wichtig ist, aus Fehlern zu lernen und diese nicht zu wiederholen sowie daraus bessere Maßnahmen für die Zukunft abzuleiten.

Vorschläge erarbeiten

Im Anschluss werden Vorschläge erarbeitet, um die Projektsituation nachhaltig zu verbessern. Dabei gibt es verschiedene Ansatzpunkte:

  • Ursachen. Die Ursache der Probleme zu finden und zu beheben ist originärer Auftrag im Recovery Management, insofern steht dieser Punkt zu Recht an erster Stelle. Jedoch ist die Ursachenbehandlung weder Selbstzweck noch isoliert umsetzbar, sodass meist flankierende Maßnahmen notwendig sind.
  • Wirkungskette. Auf dem Weg von der Ursache zum Symptom durchläuft ein „Problempunkt“ ggf. eine Wirkungskette. Diese kann an einem Punkt gezielt unterbrochen bzw. abgeschwächt werden. Ähnlich der Symptombehandlung ist hier zwar die Ursache noch existent, jedoch in der Wirkung auf das Projekt deutlich abgeschwächt.
  • Wirkung/Symptome. Diese zu behandeln löst das zugrundeliegende Problem zwar nicht nachhaltig, jedoch tritt die Besserung i.A. schneller ein. Soweit es sich um bewusste, transparente und zeitlich oder inhaltlich begrenzte Symptombehandlung handelt, kann dies einen maßgeblichen Beitrag zur Verbesserung leisten.

Auch hinsichtlich der betroffenen Parteien unterscheiden sich die Maßnahmen:

  • Intern, d.h. die Umsetzung der Maßnahme und die Wirkung derselben betrifft nur das Projektteam. Beispiel: Schulung von Projektmitgliedern.
  • Extern, d.h. die Maßnahme muss durch nicht dem Projekt zugeordnete Personen oder Parteien umgesetzt werden. Beispiel: mehr Unterstützung durch die Fachseite.
  • Gemischt. Eine erfolgreiche Umsetzung der Maßnahme erfordert die Einbindung von Parteien sowohl innerhalb als auch außerhalb des Projektes. Beispiel: Änderung des Anforderungsprozesses.

Schließlich unterscheiden sich die Maßnahmen noch hinsichtlich ihrer zeitlichen Wirkung:

  • Kurzfristig, somit ist eine sofortige Wirkung zu erwarten. Beispiel: Einführung eines täglichen Stand-up Meetings. Während einerseits die schnelle Verbesserung offensichtlich wünschenswert ist, muss andererseits darauf geachtet werden, keine Unruhe durch zu hektische Veränderungen zu schaffen.
  • Mittelfristig. Die Maßnahme kann mit einer mäßigen Vorlaufzeit eingeführt werden. Beispiel: Anpassen der Reporting-Intervalle. Vorteilhaft ist, dass die jeweilige Maßnahme ausreichend entwickelt und kommuniziert werden kann und deren Einführung nicht als Überraschung oder gar Störung empfunden wird.
  • Langfristig. Bis zur Umsetzung der Maßnahme kann eine im Verhältnis zur Projektlaufzeit längere Zeit vergehen. Beispiel: Schulung und Zertifizierung von Projektmitarbeitern. Zu beachten ist hier insbesondere, dass das Projekt noch ausreichend von der Maßnahme profitiert und ob die Maßnahme nicht gegebenenfalls außerhalb des Projektes umgesetzt werden sollte.

Maßnahmen umsetzen

Der Recovery Manager bewertet die Vorschläge hinsichtlich Wirkung und Aufwand sowie gegenseitiger Abhängigkeit. Günstig ist es, ein Portfolio aus sich gegenseitig ergänzenden Maßnahmen mit optimierter Kosten-Nutzen-Wirkung zu formen. Auch ist eine sinnvolle Abwägung zwischen kurz-, mittel- und langfristiger Wirkung zu treffen. Schließlich ist zu beachten, dass die Einführung einiger Maßnahmen das Projekt zeitweise unterbrechen kann (z.B. Durchführung von Schulungen), während andere Maßnahmen parallel zum Projektbetrieb umsetzbar sind.

Nach der Bewertung und Priorisierung der Maßnahmen gibt ein Gremium auf Kundenseite – im besten Fall besetzt mit Vertretern der einzelnen Stakeholder-Gruppen – diese zur Umsetzung frei. Im Allgemeinen haben die Maßnahmen auch eine Auswirkung auf Zeit- und Budgetpläne, sodass die Änderungen in der Freigabe enthalten sein müssen (Anwendung eines integrierten Change-Request-Prozesses). Nur in seltenen Fällen ist es möglich, alle Maßnahmen ohne Einfluss auf Zeit und Kosten umzusetzen.

Während und nach der Umsetzung ist weiterhin eine offene Kommunikation und fokussierte Erfassung der Veränderungen notwendig, um die Wirksamkeit zu beurteilen.

Maßnahmen bewerten

Je nach Maßnahme kann deren Effektivität nach der Umsetzung gemessen, qualitativ bewertet oder nur subjektiv beurteilt werden. Auch wenn konkrete Auswirkungen (wie verringerte Fehlerrate) häufig nicht einer einzelnen Maßnahme zuzuordnen sind, so sollte doch eine Verbesserung der Projektsituation insgesamt darstellbar sein.

Ein wichtiges Ziel des Recovery Managers ist es, das Projekt aus dem reaktiven, problemgetriebenen Modus wieder in den aktiven, lösungsorientierten Modus zu überführen. Damit geht typischerweise eine Verbesserung der Zufriedenheit sowohl der externen Stakeholder sowie auch der Projektmitglieder selbst einher.

Im Allgemeinen begleitet der Recovery Manager das Projekt bis zum erfolgreichen Projektabschluss. Selbstverständlich ist es auch möglich, das nun stabilisierte Projekt wieder allein durch die bisherige Projektorganisation zu leiten. Im Rahmen des Projektabschlusses sollten die Situation, die Maßnahmen und die Wirkung der Projektrettung nochmals reflektiert und abschließend dokumentiert werden, um entsprechende Probleme bei Folgeprojekten zu vermeiden.

Abschluss

Referenzen

Erfahren Sie mehr zu unseren Kompetenzen im Projektmanagement

Zur Vertiefung des Themas sind folgende Publikationen empfehlenswert:

Autor

Ich freue mich über Ihr Feedback und beantworte gerne Ihre Anfragen zum Thema Project Recovery.

Philipp von Bassewitz
Senior Project Manager bei it-economics
Project Management Professional (PMP)
Diplom-Informatiker
info@it-economics.de

 

[1] z.B. CHAOS Reports,https://www.standishgroup.com/

[2] Begriffe entsprechend Scrum-Methodik; ggf. abweichende Begriffe in anderen agilen Methoden