Erfolgreiche Fallbeispiele - So gelingt der Turnaround bei Troubled-Projects
- Kazimierz Salewicz
- 6. Mai 2018
- 5 Min. Lesezeit
Aktualisiert: 25. Juli
Beispiel 1: Ein 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 könnte nicht verschoben werden. Aufgrund der geringsten Priorität die Ressourcen am Server fehlten.
Gemeinsam mit dem Testmanagement-Team des Kunden haben wir die 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. Übergabe der Abweichungen an die Geschäftsführung in Form eines Reports der Regressionstestergebnisse.
Der erste Report hat schon ergeben, dass keine der Plattform mit den laufenden Webservices genügend Ressourcen bereitgestellt worden sind. Deshalb wurden Daten unvollständig 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.
Beispiel 2: Software Entwicklung in Bereich Automobilindustrie
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. Durch Einführung von einem Smoke-Test konnte mehrmals täglich eine zeitnahe Rückmeldung von Abweichungen an das Entwicklerteam weitergeleitet werden und so innerhalb weniger Wochen ein erster funktionierender Prototyp mit Basisfunktionalität dem Kunden präsentiert werden. 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. Wir von mpindustries.at haben in dieser Phase hauptsächlich als externen Tester dem Softwarelieferanten durch unsere Tests vor Ort auf die Sprünge geholfen.
Im nächsten Schritt haben wir die Testabdeckung über eine Requirements-Testmatrix ermittelt und in der Gap-Analyse gemerkt, dass mit Hilfe von User-Stories für Tests die Mehrheit an offenen Anforderungen abgedeckt werden kann. In Durchschnitt konnte ein Test mehr als fünfzehn Anforderungen abdecken. Dadurch konnte ein vollständiger Testzyklus innerhalb von einem halben Tag abgewickelt werden. Nach zwei Monaten "Bugfixing" konnte überraschend schnell die finale Testphase angegangen werden und im Fahrzeug wird vor Ort beim Softwarelieferanten getestet. 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:
Zwischenlieferungen vom Softwarelieferanten wurden automatisiert und manuell auf die Grundfunktionalität überprüft. Dies geschah oft auch vor Ort beim Softwarelieferanten, was dazu geführt hat, dass der Endkunde erstmals nach Jahren einen Projektfortschritt wahrgenommen hat. Mehrmals täglich konnten wir Feedback direkt an die Entwicklermannschaft liefern und wurden mit einer Firmware-Zwischenlieferung belohnt.
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.
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 Kundenvertrauen in Bezug auf eine erfolgreiche Projektumsetzung wiederhergestellt hat und auch ein herausfordernden 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.
Beispiel 3: Softwareentwicklung und Implementierung für eine Verkaufskette
Eine Verkaufskette in Tschechien hat die Softwarelösung für die Unterstützung des Verkaufsbetriebes bei einer ausländischer Firma beauftragt. Die Implementierung der Softwarelösung und die Unterstützung bei produktiver Inbetriebnahme der Lösung lag in der Verantwortung von Systemintegrator. Leider die Softwarelösung hat nicht richtig funktioniert.
Die Landesorganisation von Systemintegrator hat auf eigene Faust das Problem zu lösen und Zentrale nicht vollständig über den Status informiert. Als Konsequenz hat hoch unzufriedene Kunde das Problem an Zentrale des Systemintegrator eskaliert und mit Kündigung des Vertrages gedroht.
Die Zentrale hat unserer, damals bei Systemintegrator beschäftigter, Mitarbeiter beauftragt die Lage zu ermitteln und die Sanierungsmaßnahmen zu definieren und implementieren.
Die Begutachtung des Projektes haben gezeigt, dass:
Die Entwicklungsdokumentation war nicht vollständig, insbesondere in Hinblick auf fehlerhafte Module;
Die Grunde für fehlerhafte Verhalten der Software waren unbekannt;
Softwarelieferant hat nicht ausreichende Ressourcen für das Projekt zugeordnet;
Die Landesorganisation des Systemintegrators hat versucht die Probleme gegenüber der Zentrale zu verstecken und Missstände zu vertuschen;
Projektleiter war im nicht ausreichenden Ausmaß mit Projekt beschäftigt und deswegen hat er die Situation nicht kontrolliert.
Die rasche Implementierung von korrektiven Maßnahmen, wie:
Inspektion des Softwarehauses mit Schwerpunkten auf Zustand der Dokumentation (Anforderungen und High Level Design der Anwendung);
Durchführung von Quellencode Review in Hinblick auf mögliche Fehlerursachen;
Verstärkung des Entwicklungsteams mit erfahrenen Software Architekten;
Identifizierung von fehlerhaften Code;
Korrektur von Softwaremängel;
Austausch des Projektleiters;
Austausch des Managers in der Landesorganisation des Systemintegrators
haben dazu geführt, dass innerhalb von wenigen Wochen wurde die Lage völlig stabilisiert zu voller Zufriedenheit des Kunden.
Beispiel 4: Outsourcing Projekt für die Österreichische Versicherung
Service Provider hat einen mehrjährigen Vertrag über Betrieb der gesamter IT Infrastruktur unterzeichnet. Nach einiger Zeit hat sich herausgestellt, dass der Betrieb nicht ordentlich funktioniert, es kommt zu Ausfälle der Infrastruktur und der Kunde war mit der Qualität von Leitungen unzufrieden. Das Management von Service Provider hat unser, damals bei Service Provider beschäftigter, Mitarbeiter beauftragt die Situation des Projektes zu Begutachten.
Im aus der Begutachtung resultierenden Bericht wurden folgende Defizite identifiziert:
Nicht ausreichende Qualifikationen von Delivery Mannschaft in Bereich Risiko- und Issue Management;
Reaktive statt präventive Vorgehensweise bei Betrieb;
Überbelastung von kritischen Ressourcen;
Technische Fehler begangene durch nicht immer ausreichend qualifizierte Mitarbeiter.
Als Antwort und Reaktion auf identifizierten Mängel wurden zahlreiche korrektiven Maßnahmen unternommen und durchgeführt. Diese Maßnahmen haben inkludiert:
Nominierung eines Risiko Managers, der alle auf Risikomanagement bezogene Aktivitäten koordiniert und geleitet hat;
Breite Schulung des Mittelschicht Managements und Delivery-Mannschaften in Sachen Risiko- und Issue-Management;
Einführung von Werkzeugen und Prozessen, die regelmäßige Durchführung von Risiko- und Issue-Management ermöglicht haben;
Regelmäßige Risiko- und Issue-Management Aktivitäten auf allen Ebenen des Projektes;
Einführung von Regelmäßigen Reviews und Assessment von Risiken und Probleme mit der Teilnahme von Führung Team des Projektes und Risiko Manager;
Verbesserung von Ressourcen Management um die fachlichen Kenntnissen von verfügbaren Mitarbeiter effektiv zu nutzen;
Einführung von "vier Augen" Prinzip bei der Durchführung von komplizierten Aktivitäten um die Eintreten von Fehler zu eliminieren.
Konsequente, mehrjährige Implementierung von allen vorgeschlagenen Maßnahmen haben dazu geführt, dass die Erfüllung des Vertrages zu Zufriedenheit des Kunden in weiterer Folge die Verlängerung des ursprünglichen Vertrages über mehrere Jahre ermöglich hat.
