Erfolgreiche Fallbeispiele - So ist uns der Troubled-Projects-Turnaround gelungen

Zuerst haben wir den Status (Gesundheitszustand) des Projektes ermittelt, inklusive Empfehlungen der wichtigsten Kennwerten des Projektes. Bei geringen Abweichungen von Planwerten können die Korrekturen ohne große Aufwände durchgeführt werden, damit das Projekt als „gesund“ zu betrachte ist.

In der Situation, wenn die Abweichungen signifikant sind und damit die Durchführung von Korrektivmaßnahmen (Sanierung des Projektes) mit signifikanten Aufwänden verbunden ist, muss das Projekt genau beobachtet werden. In kritischen Fällen, wenn die Sanierungskosten zu hoch sind oder andere Faktoren dafür sprechen, kann auch die Auflösung des Vertrags empfohlen werden. Solche Projekte nennt man „Troubled Projects“.

Genaue und objektive Begutachtung des Projektes ist von primärer Bedeutung und deswegen soll durch Projekt-unabhängige Instanz durchgeführt werden. An dieser Stelle kann mpindustries.at zur Durchführung der Begutachtung eingeladen werden.

Eine ordentlich durchgeführte Begutachtung resultiert in einem Bericht mit folgenden Aspekten:

• Auflistung von identifizierten Defiziten;

• Die Ursachen von eingetretenen Schwierigkeiten und Defiziten;

• Technische, wirtschaftliche, rechtliche Defizite mit Konsequenzen für die Vertragspartner

• Aktionsplan, also ein Katalog von Korrektivmaßnahmen um die Defizite zu eliminieren;

• Kosten und Zeitrahmen die notwendig sind, um Korrektivmaßnahmen zu implementieren;

• Zeitplan für die Durchführung von Korrektivmaßnahmen;

• Verantwortlichkeiten für die Verwirklichung von definierten Korrektivmaßnahmen;

• Berichts- und Kommunikationsstruktur verbunden mit zu durchführenden Tätigkeiten.

Dabei ist es wichtig, dass die Ergebnisse der Begutachtung und die geplanten Maßnahmen mit dem Kunden besprochen werden.

In weiterer Folge findet die Implementierung der Korrektivmaßnahmen unter genauer Beobachtung seitens des Auftraggeber und Auftragnehmer statt. Die Umsetzung von oben in Kürze beschriebener Punkten ist mit vielen, manchmal sehr sensitiven Aspekten verbunden, die nicht nur technische oder wirtschaftliche Faktoren betreffen, aber auch s.g. „soft skills“ beinhalten.

Diese Erfahrung haben wir im Rahmen von zusammen mehr als 50 Mannjahre dauerten Tätigkeiten in Österreich, Tschechien, Deutschland und Schweiz gesammelt. Nachfolgend finden Sie Fallbeispiele:

Fallbeispiel von einem Troubled-Project-Turnaround für eine Plattform zum Melden von Unfällen:

Eine Webservice-Erweiterung rund um eine Handy-Applikation zur Unfallmeldung drohte zu scheitern, weil das Webservice  bei Last abstürzte und Unfallmeldungen nur teilweise am Server eingegangen sind, obwohl in der App am Handy eine Unfallwarnung abgesetzt worden ist. Der interne "Go-Life"-Termin ist nicht verschiebbar, aber diesem Projekt fehlt Aufgrund der geringsten Priorität die Ressourcen am Server.

Wir haben gemeinsam mit dem Testmanagement-Team folgende folgende Strategie erarbeitet:  

1. Priorisierte Umsetzung aller Anforderungen rund um Zahlungsabwicklung (Demoversion).  

2. Aussetzen der Regressionstests für jedes Code-Update um Anforderungen zu implementieren.  

3. Manuelle Lasttests unterstützen das Entwicklerteam direkt, um die Server-Engpässe aufdeckten.  

4. Einmal wöchentlicher Issue-Reports der Regressionstestergebnisse an die Geschäftsführung.

Der erste Report hat ergeben, dass keine der Plattform mit den laufenden Webservices keine Ressourcen bereitgestellt worden sind. Deshalb wurden keine Unfalldaten gemeldet.

Innerhalb von einer Woche hat das Management genügend Kapazitäten am Server bereitgestellt, die Webservices laufen seitdem stabil und alle Unfallmeldungen werden im Backend weiterverarbeitet. Eine weitere Woche später konnten die restlichen Features, wie zum Beispiel die Übermittlung zusätzlicher Informationen freigeschalten.

Fallbeispiel von einem Troubled-Project-Turnaround in der Automobilindustrie

Als lebendige Beispiel für die Sanierung von einem „Trouble Project“ fassen wir ein Firmwareentwicklungsprojekt mit Mechatronikanteil zusammen, wo wir durch unsere technische Expertise verbunden mit Soft-Skills weitaus mehr erreicht haben als die Testabdeckung von 0 auf 100 Prozent zu erhöhen.

Nach zweijähriger Projektüberlaufzeit sind alle Meilensteine des Projektes gerissen. Mittlerweile schwindet die Hoffnung auf ein erfolgreiches Projektende nicht nur beim verantwortlichen Unternehmen, sondern auch bei allen Lieferanten und der Kunde überlegt eine Rückabwicklung unter Zuhilfenahme der Rechtsabteilung. Der Auftragnehmer versucht diesen hohen finanziellen Schaden durch Zuhilfenahme eines neuen externen Testmanager von mpindustries.at abzuwenden.

Durch unsere Beratung konnten wir schon in der ersten Beauftragungswoche ein positives Feedback vom Kunden erhalten, weil wir eine einfache Feedbackschleife nach Durchführung unserer Smoke-Tests einführen. Vor allem wird der Projektleiter durch unsere aktive Unterstützung bei der Einführung eines einfachen Issue-Tracking-Systems und Aufbau eines Softwarelebenszyklus (SDLC)entlastet. Aber vor allem hat der Softwarelieferant Softwarelieferant einen unabhängigen externen Tester erhalten.

Im nächsten Schritt haben wir die Testabdeckung über eine Requirements-Testmatrix ermittelt und in der Gap-Analyse schnell gemerkt, dass wenige essentielle Tests eine Vielzahl an offenen Anforderungen abdecken. Nach zwei Monaten "Bugfixing" konnte überraschend schnell die finale Testphase angegangen werden und im Fahrzeug wird vor Ort beim Softwarelieferanten getestet, mit bis zu drei Feedbackschleifen für die Entwicklung. Wenige Wochen später hat unser Kunde die Freigabe für die Firmware gegeben. Mit unserer Hilfe konnte in weit unter einem Jahr das Projekt erfolgreich abgeschlossen werden.

Welche Faktoren haben dazu geführt, dass dieses Projekt erfolgreich abgeschlossen werden konnte:

1. Zwischenlieferungen vom Softwarelieferanten wurden manuell auf Funktion überprüft. Dies geschah oft auch vor Ort beim Softwarelieferanten, was dazu geführt hat, dass die Grundfunktionen innerhalb weniger Wochen stabil funktioniert hat. Mehrmals täglich konnten wir Feedback direkt an die Entwicklermannschaft liefern und wurden mit einer Firmware-Zwischenlieferung belohnt.
   

2. Durch eine vollständige Testabdeckung konnten Regressionstest durchgeführt und Rückschritte in der Software zeitnah den Entwicklern gemeldet werden. Dadurch wurden die kontinuierlichen Lieferungen stabiler und durch eine höhere Testabdeckung konnten auch neue Features der Firmware entwicklungsbegleitend unter Test gestellt werden.
   

3. Durch die zusätzliche Testkapazität ist eine Multiplikator Wirkung ausgegangen, weil auch beim Kunden und Softwarelieferanten mehr Mitarbeiter im Projekt eingesetzt worden sind. Dies zeigt, dass es wichtig ist auf allen Ebenen zusammenzuarbeiten.

   
   

Das Beispiel zeigt, dass durch die Einbringung einer externen Unterstützung im Testumfeld das verlorengegangene Vertrauen vom Kunden wiederhergestellt hat und auch ein schwieriges Projekt erfolgreich abgeschlossen worden ist. Im Vergleich mit einer Abwicklung des Projektes auf rechtlicher Ebene konnten wir mit Sicherheit finanzielle Nachteile im sechs- bis siebenstelligen Euro-Bereich abgewandt werden.